
Herede esta confusión,
comenzando con los sinvergüenzas de Zello; LinkedIn
y terminando con los 'demás' en la plataforma Telegram
en mi mundo.Y luego, tras un sobresalto,
el funcionario añadió apresuradamente y en voz alta:
pero yo pondré orden (aquí en IT).
(…).
Pável Dúrov, considera con razón que son los estados autoritarios los que deben temerle, a su criptopolítica, y que las Roskomnadzor y los escudos dorados con sus filtros DPI no le preocupan demasiado.
(Técnica Política)
Mi política técnica es más sencilla; podría detallar aquí mis reflexiones sobre los bloqueos indiscriminados en la red rusa, pero creo que los ciudadanos progresistas de la Rusia moderna y los usuarios de Habra han sentido en carne propia la falta de profesionalismo del poder actual, por lo que me limitaré a una única frase: nuestra política técnica es 'Resistencia Digital'. 'proporcionar a los seres queridos un canal de comunicación resistente'.
Despliegue del proxy MTProto de Telegram
- El nivel de complejidad técnica es 'simple', si, por ejemplo, se sigue esta hoja de referencia.
- El nivel de confiabilidad es 'superior a la media': la imagen de Docker funciona de manera estable, no es necesario reiniciarla cada día, como afirmaron los desarrolladores en su documentación oficial de Telegram, pero el contenedor seguramente tiene algunas vulnerabilidades.
- El nivel de resistencia/preocupación es 10, los peshmergas tejen sus conspiraciones 'la familia lo usa', no ha llegado ninguna prohibición de la Roskomnadzor en todo este tiempo (desde la primavera).
- El nivel de confianza es 'desconfianza pública de los bebés', el problema está del lado de los clientes (algunos amigos son sospechosos respecto a mi MtprotoProxy).
- El nivel de testosterona es 'no ha aumentado'.
- Los costos financieros son '0₽'.
- La compensación financiera es 'no depende de ciudadano Dúrov'. La recompensa es la posibilidad de imponer publicidad.
Levantaremos nuestro TelegramProxy en las capacidades 'gratuitas/personales' de Amazon-ec2: t2.micro. Utilicé esto la máquina.
Está bien, desplegamos nuestro gratuito servidor, vamos al sitio oficial dockerhub y descargamos el contenedor de Docker.
No es necesario buscar ninguna imagen, archivo o botón mágico: 'no hay', toda la magia se hace en CLI:
$ docker pull telegrammessenger/proxy #la imagen ha sido descargada.Pero antes de 'eso', instalen Docker para CLI:
sudo apt-get install docker.io dockerA continuación, en la documentación oficial de MtprotoProxyTelegram nos proponen hacer aproximadamente lo siguiente:
$ sudo su && docker run -d -p443:443 --name=mtproto-proxy --restart=always -v proxy-config:/data telegrammessenger/proxy:latest #iniciamos nuestro contenedor 'mtproto-proxy'.
Después de este comando, aparecerá una cadena HEX en la salida del terminal, pero no nos interesa.
Escribimos en la CLI:
$ docker logs mtproto-proxyY obtenemos los datos necesarios:

En la salida de este registro nos muestran (he mezclado):
A) nuestra ip del servidor (ip externa del servidor);
B) y un secreto aleatorio — una cadena aleatoria en HEX.
Antes de registrar nuestro MtproProxy, necesitamos configurar el firewall principal sobre iptables (aunque redirijas el tráfico en esta VPC, será rebelde, ya que el firewall principal en Amazon-EC2 está en la interfaz web y tiene mayor prioridad sobre iptables).
Accedemos a «consola Amazon-EC2» en Security Group y abrimos el puerto 443 entrante (una máscara lógica del tráfico por un tiempo).

Tomamos de los registros nuestros datos «ip y secreto» y vamos al mensajero Telegram, encontramos el bot oficial MTProxy Admin Bot (@MTProxybot) y registramos nuestro MtproProxy: ejecutamos el comando [\/newproxy] e introducimos [nuestro_ip:443], y luego nuestro [secreto\/HEX].
Si cometes un error al ingresar los datos, el bot se enojará y te enviará a...
Si introduces ambas líneas sin errores, recibirás la aprobación y un enlace funcional a tu MtprotoProxyTelegram, que puedes compartir con cualquiera.

También a través de este bot puedes añadir tu canal patrocinador (pero no un chat), donde podrás imponer tus opiniones a los usuarios que se conectaron a tu servidor, o puedes no «hacer spam», y no molestar a tus potenciales clientes, sin mostrar el canal en la lista fija del mensajero.
Un par de palabras más sobre el bot, allí puedes solicitar estadísticas, pero «también es un agujero». Parece que las «estadísticas» están disponibles cuando detrás de ti hay una «multitud de parásitos» en Majachkalá.
Monitoreo
¿Cuántos usuarios podemos conectar a nuestro servidor? Y en general, ¿quién/qué está allí? ¿Qué? ¿Y cuántos?
Veamos qué dice la documentación oficial… Ajá, así:
$ curl http://localhost:2398/stats o así $ docker exec mtproto-proxy curl http://localhost:2398/stats # y nos darán las estadísticas directamente en la CLI.«Mantén tu bolsillo más ancho» Con los comandos sugeridos, siempre obtendremos un error similar:
«curl: (7) Failed to connect to localhost port 2398: Conexión rechazada»
Nuestro proxy funcionará. ¡Pero! Recibiremos un agujero, no estadísticas.
Podemos hacer cosas para los ojos rojos: verificar
$ netstat -an | grep 2398 y...Al principio pensé que era otro error de los desarrolladores de Telegram (y aún lo creo). Luego encontré una solución temporal bastante buena: afilar con una lima el contenedor Docker.
Más tarde encontré información:
sobre los bailes gubernamentales de Roskomnadzor en torno a las "estadísticas".
"Hemos bloqueado en nuestros servidores parte de los proxies públicos utilizando las bases del proyecto firehol. Este proyecto monitorea listas de proxies públicos y crea bases de datos con ellos.
Desde ese momento (es decir, ya casi dos días) no se ha bloqueado ninguna dirección IP de nuestro proxy ruso.
3. Explicamos cómo hacer un proxy casi invulnerable para Roskomnadzor y compartimos un script para bloquear proxies públicos.
— Actualiza el contenedor Docker (o el demonio) del proxy MTProto a la última versión: Roskomnadzor identifica versiones antiguas por el puerto de estadísticas, que se vinculaba a 0.0.0.0 y se identificaba claramente para todo internet. O mejor aún, abre los puertos necesarios con iptables y cierra los demás (recuerda que en el caso de un contenedor Docker se debe usar la regla FORWARD).
— Roskomnadzor ha aprendido a interceptar tráfico: ven las solicitudes dentro de los proxies HTTP y SOCKS5, y también ven la antigua versión de ofuscación del proxy MTProto.
Cuando los clientes de algunos proveedores, que tienen instalados tales interceptores, acceden a Telegram a través de tales proxies, Roskomnadzor ve esas solicitudes y bloquea inmediatamente esos proxies. Lo mismo ocurre con el proxy MTProto con la antigua ofuscación.
Solución: entrega a los clientes que se conectan al proxy, un secreto que solo comience con dd (no es necesario especificar letras adicionales dd en la configuración del propio proxy mtproto). Esto activará la versión de ofuscación que los interceptores no pueden identificar.
Y nada de proxies HTTP y SOCKS5.
— Un empujón, con el que cada propietario de un proxy de Telegram que es bloqueado regularmente por Roskomnadzor puede detener completamente (o casi completamente) las bloqueos (y, de paso, asegurarse de que Roskomnadzor miente).
Un script que bloquea proxies públicos y una pequeña guía para él.
→ Fuente
Nuestro proxy es pro-Oeste, no he encontrado problemas/bloqueos durante la primavera y cool veranos, así que esto no fue un desafío creativo, por lo que no me preocupé por perder ritmo y no añadí el prefijo dd* a la clave.
El manual «obtención de estadísticas/monitoreo» según la instrucción oficial de MtprotoProxyTelegram está obsoleto/no funciona, tendremos que arreglar la imagen de docker.
Arreglamos.
El contenedor aún está en ejecución:
$ docker stop mtproto-proxy #detenemos nuestro contenedor de docker en ejecución y lanzamos una nueva imagen con el flag de estadísticas omitido
$ docker run --net=host --name=mtproto-proxy2 -d -p443:443 -v proxy-config:/data -e SECRET=su_secreto_anterior_hex telegrammessenger/proxy:latest
Verificamos las estadísticas:
$ curl http://localhost:2398/statscurl: (7) Falló la conexión al puerto 2398 de 0.0.0.0: Conexión rechazada
Las estadísticas aún no están disponibles .!..
Descubramos el identificador del contenedor de docker:
$ docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f423c209cfdc telegrammessenger/proxy:latest «/bin/sh -c ‘/bin/ba…» Hace aproximadamente una hora En ejecución Hace aproximadamente un minuto 0.0.0.0:443->443/tcp mtproto-proxy2
Vamos con nuestro reglamento dentro del contenedor de docker:
$ sudo docker exec -it f423c209cfdc /bin/bash
$ apt-get update
$ apt-get install nano
$ nano -$ run.sh
Y en la última línea del script «run.sh» agregamos el flag omitido:
«—http-stats»
«exec /usr/local/bin/mtproto-proxy -p 2398 -H 443 -M "$WORKERS" -C 60000 —aes-pwd /etc/telegram/hello-explorers-how-are-you-doing -u root $CONFIG —allow-skip-d h —nat-info "$INTERNAL_IP:$IP" $SECRET_CMD $TAG_CMD»
Agregue «—http-stats», algo así debería quedar:
«exec /usr/local/bin/mtproto-proxy -p 2398 --http-stats -H 443 -M "$WORKERS" -C 60000 --aes-pwd /etc/telegram/hello-explorers-how-are-you-doing -u root $CONFIG --allow-skip-d h --nat-info "$INTERNAL_IP:$IP" $SECRET_CMD $TAG_CMD»
Ctrl+o/Ctrl+x/Ctrl+d (guardar/salir de nano/salir del contenedor).
Reiniciamos nuestro contenedor de docker:
$ docker restart mtproto-proxy2Eso es, ahora con el comando:
$ curl http://localhost:2398/stats #obtenemos estadísticas detalladas
En las estadísticas hay mucha «basura» (en la captura de pantalla 1/3 de ella), creamos un alias:
$ echo "alias telega='curl localhost:2398/stats | grep -e total_special -e load_average_total'" >> .bashrc && bashObtenemos lo que pulimos en el contenedor de docker: la cantidad de conexiones y la carga:
$ telega
El contenedor de Docker está funcionando, las estadísticas están circulando.
Recursos gastados
Por mucho que seas genial Stuart Redman, incluso tú dejas huellas de excremento en tus calzoncillos. Una imagen de Docker en funcionamiento deja una huella significativa.
No tiene sentido enumerar las ventajas y desventajas de las imágenes de docker, el contenedor de docker es una mini-máquina virtual que consume menos recursos que una ‘real’ máquina virtual, como VirtualBox, pero consume.
1) Ya sea que se ejecute con estadísticas de imagen de docker o sin ellas, dos clientes se divierten o diez: los recursos se utilizan de manera ~igual: 75% de todo el rendimiento de la CPU t2.micro.
2) Miramos el monitoreo del servidor VPC:

Del gráfico de utilización de recursos en VPC, vemos que el contenedor docker consume constantemente alrededor del 7.5% del rendimiento máximo total de CPU y fue detenido por mí de manera intencionada/temporal el 28 de mayo. (Nota: también están corriendo OpenVPN & pptp en el servidor).
¿Por qué una carga de CPU constante del 10% es el límite para este servidor?
Porque hay limitaciones por parte de Amazon EC2 y se calculan en créditos:

1 crédito de CPU = 1 CPU trabajando a 100% de carga durante un minuto, y nosotros tenemos 6 créditos (es decir, en picos, la utilización del CPU al 100% es posible durante 6 minutos, y después la potencia del CPU se reducirá). Otras combinaciones: por ejemplo, 1 crédito de CPU = 1 CPU trabajando al 50% de carga durante dos minutos (es decir, podemos usar el CPU con una carga del 50% durante 12 minutos), o, por ejemplo, una carga constante del 10% del CPU durante todo el tiempo, etc.
Conclusiones
- Somos parte de la «Resistencia Digital». Proporcionamos a nuestros «papás y mamás» un canal de comunicación confiable.
- Si en el servidor tienes desplegado MtprotoProxyTelegram y OpenVPN, pero no más, no habrá retrasos/pings/fallos, pero si estás experimentando constantemente con tu t2/micro, espera problemas de conexión.
- Mi ping transoceánico es de aproximadamente 100-250ms, no se sienten retrasos en la comunicación de voz.
- Los costos financieros de todo «esto» (incluidos los recursos de VPC) = 0₽.
Reimpresión de su artículo.
UPD: Gracias a algunos usuarios de Habr por los comentarios útiles, realmente, es posible (¿se mantiene la estadística?), que hay mejores alternativas al docker_image oficial de Mtproto proxy Telegram.
Fuente: habr.com
