Implementando o teu MTProxy Telegram con estatísticas

"Herdei esta desorde,
comezando polo descarado Zello; LinkedIn
e rematando con "todos os demais" na plataforma de Telegram
no meu mundo.

E despois hipo,
O funcionario engadiu apresuradamente e en voz alta:
pero vou poñer as cousas en orde (aquí en IT)"
(...).

Durov, cre con razón que son os estados autoritarios os que deberían ter medo del, un cypherpunk, e Roskomnadzor e os escudos dourados cos seus filtros DPI non lle molestan realmente.
(técnica política)

A miña política técnica é máis sinxela, podo describir aquí os meus pensamentos sobre o bloqueo descoidado en RuNet, pero creo que os cidadáns progresistas do ruso moderno e os usuarios de Habr sentiron a falta de profesionalidade do goberno actual na súa propia pel, polo que me limitarei a unha única frase: a nosa política técnica é "Resistencia dixital". "proporcionando a familiares e amigos unha canle de comunicación estable".

Implementación de proxy MTProto Telegram

• O nivel técnico de complexidade é "fácil", se, por exemplo, segues esta folla de trampas.
• O nivel de fiabilidade está "por encima da media": a imaxe do docker funciona de forma estable, non é necesario reiniciarse todos os días, como escribiron os desenvolvedores na súa documentación oficial de Telegram, pero o contedor probablemente conteña algunhas vulnerabilidades.
• Nivel de resistencia/ansiedade: 10 membros do ISIS están tecendo as súas conspiracións "os familiares úsano", a prohibición non chegou do RKN nin sequera unha vez (desde a primavera).
• O nivel de confianza é a "desconfianza pública do bebé", un problema no lado do cliente (algúns amigos sospeitan do meu MtprotoProxy).
• Os niveis de testosterona - "non aumentaron".
• Custos financeiros - "0₽".
• Recompensa financeira - "non depende do cidadán Durov". Promoción - a capacidade de impoñer publicidade.

Aumentaremos o noso TelegramProxy sobre as capacidades "gratuítas / persoais" de Amazon-ec2: t2.micro. usei isto coche.

Está ben, implantou o teu servidor gratuíto, vai ao sitio web oficial dockerhub e descarga o contedor docker.

Non é necesario buscar algunha imaxe, ficheiro ou botón máxico: "non están alí", toda a maxia faise na CLI:

$ docker pull telegrammessenger/proxy #образ скачан.

Pero antes de "iso", instale docker para CLI:

sudo apt-get install docker.io docker

Ademais, na documentación oficial de MtprotoProxyTelegram, ofrécenos facer algo como o seguinte, facemos:

$ sudo su && docker run -d -p443:443 --name=mtproto-proxy --restart=always -v proxy-config:/data telegrammessenger/proxy:latest #запускаем наш контейнер «mtproto-proxy».

Despois deste comando, aparecerá unha cadea HEX na saída do terminal, pero non nos interesa.

Escribimos en CLI:

$ docker logs mtproto-proxy

E obtemos os datos necesarios:

Na saída deste rexistro, móstranse (untado):

A) o noso servidor ip (ip do servidor externo);
B) e un segredo aleatorio: unha cadea aleatoria en HEX.

Antes de rexistrar o noso MtproProxy, cómpre configurar o firewall principal a través de iptables (non importa como redirecciones o tráfico a este VPC, será malo, xa que o firewall principal de Amazon-EC2 está situado na interface web e ten unha prioridade máis alta que iptables).

imos a "consola Amazon-EC2" no grupo de seguridade e abra o porto de entrada 443 (enmascaramento lóxico tráfico por primeira vez).

Collemos os nosos datos "ip e secretos" do rexistro e imos ao mensaxeiro de Telegram, atopamos o bot oficial de administración de MTProxy (@MTProxybot) e rexistramos o noso MtproProxy: executa o comando [/newproxy] e introduce [our_ip:443], e entón o noso [segredo /HEX].

Se estropeas ao introducir datos, o bot enfadarase e enviarache a...

Se enche dúas liñas sen erros, recibirá aprobación e unha ligazón de traballo ao seu MtprotoProxyTelegram actual, que pode compartir con calquera.

Ademais, a través deste bot, podes engadir a túa canle de patrocinio (pero non un chat), onde impoñerás as túas opinións aos usuarios que se conectaron ao teu servidor, ou non poderás "enviar correo non desexado" e non molestar aos teus clientes potenciais sen mostrando a canle na lista de mensaxería fixada.

Unhas palabras máis sobre o bot, onde podes solicitar estatísticas, pero "tamén unha rosquilla". Ao parecer, as "estatísticas" están dispoñibles cando tes "unha multitude de freeloaders" detrás de ti Makhachkala.

Seguimento

Cantos usuarios podemos conectarnos ao noso servidor? E de todas formas, quen/que hai? Que? E cantos?

Miramos o que hai segundo a documentación oficial... Si, aquí, faino así:

$ curl http://localhost:2398/stats или вот так $ docker exec mtproto-proxy curl http://localhost:2398/stats # и нам выдадут статистику прямо в CLI.

"Manteña o teu peto máis amplo" Segundo os comandos propostos, sempre recibiremos un erro semellante:

«curl: (7) Non se puido conectar ao porto localhost 2398: Rexeitouse a conexión»

O noso proxy funcionará. Pero! Bagel, non temos estatísticas.

Podes facer cousas para os ollos vermellos: comprobar

$ netstat -an | grep 2398 и...

Ao principio pensei que esta era outra traba detrás dos desenvolvedores de Telegram (e aínda así o creo), entón atopei unha boa solución temporal: pulir o Docker Container cun ficheiro.

Máis tarde, chamoume a atención un infa:

sobre os bailes estatais de Roskomnadzor arredor das "estatísticas".

"Bloqueamos algúns dos proxies públicos dos nosos servidores usando as bases de datos do proxecto Firehol. Este proxecto monitoriza listas con proxies públicos e crea bases de datos con eles.

Desde ese momento (é dicir, case dous días xa), nin un só enderezo IP do noso proxy ruso foi bloqueado.

3. Contámosche como facer un proxy case invulnerable para Roskomnadzor e compartir un script para bloquear proxies públicos.

- Actualiza o contenedor docker proxy MTProto (ou daemon) á versión máis recente: RKN calcula as versións antigas polo porto de estatísticas, que estaba vinculado a 0.0.0.0 e identificouse de forma única para toda a Internet. Mellor aínda, abra os portos necesarios mediante iptables e pecha o resto (lembra que no caso dun contenedor docker, debes usar a regra FORWARD).

— Roskomnadzor aprendeu a volcar o tráfico hai moito tempo: ven chamadas dentro dos proxies HTTP e SOCKS5 e tamén ven a versión antiga da ofuscación de proxy MTProto.

Cando os clientes dalgúns provedores que teñen instalados tales volcados acceden a Telegram a través destes proxies, o RKN ve tales solicitudes e bloquea inmediatamente estes proxies. O mesmo ocorre co proxy MTProto con ofuscación antiga.

Solución: distribúa o segredo só con dd ao principio aos clientes que se conectan ao proxy (non é necesario especificar letras adicionais dd na configuración do propio proxy mtproto). Isto activará unha versión de ofuscación que os duppiles non poden detectar.

E non hai proxies HTTP nin SOCKS5.

- Axuste, coa axuda do cal cada propietario dun proxy de telegrama, que está prohibido regularmente polo RKN, pode deixar completamente (ou case por completo) o bloqueo (e ao mesmo tempo asegurarse de que o RKN minte).

Un script que prohibe os proxies públicos e un pequeno manual para iso.

→ Orixe

O noso proxy é pro-occidental, non atopei ningún problema/bloqueo durante a primavera e os días frescos de verán, tampouco atraeu unha tarefa creativa, polo que non perdín o ritmo e non engadín o prefixo dd* a a chave.

O manual "obtención de estatísticas/seguimento" segundo as instrucións oficiais de MtprotoProxyTelegram non está funcionando/desactualizado, terás que reparar a imaxe do docker.

Arranxámolo.

O contedor aínda está funcionando:

$ docker stop mtproto-proxy #останавливаем наш запущенный docker-контейнер и запускаем новый образ с пропущенным флагом статистики

$ docker run --net=host --name=mtproto-proxy2 -d -p443:443 -v proxy-config:/data -e SECRET=ваш_предыдущий_секрет_hex telegrammessenger/proxy:latest

Vexamos as estatísticas:

$ curl http://localhost:2398/stats

curl: (7) Non se puido conectar ao porto 0.0.0.0 2398: conexión rexeitada
As estatísticas aínda non están dispoñibles.!...

Descubra o ID do contedor docker:

$ docker ps

ID CONTAINER IMAXE COMANDO ESTADO CREADO NOMES PORTOS
f423c209cfdc telegrammessenger/proxy:latest "/bin/sh -c '/bin/ba..." Hai aproximadamente unha hora Arriba Aproximadamente un minuto 0.0.0.0:443->443/tcp mtproto-proxy2

Imos co noso charter dentro do contedor docker:

$ sudo docker exec -it f423c209cfdc /bin/bash

$ apt-get update
$ apt-get install nano
$ nano -$ run.sh

E na última liña do script "run.sh", engade a bandeira que falta:

«--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 raíz $CONFIG --allow-skip-d h --nat-info "$INTERNAL_IP:$IP" $SECRET_CMD $TAG_CMD"

Engade "--http-stats", algo así debería funcionar:

«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 (gardar/saír de nano/saír do contenedor).

Reinicia o noso contedor docker:

$ docker restart mtproto-proxy2

Todo, agora ao mando:

$ curl http://localhost:2398/stats #получаем объемную статистику

Hai moito "lixo" nas estatísticas (1/3 está na pantalla), crea un alias:

$ echo "alias telega='curl localhost:2398/stats | grep -e total_special -e load_average_total'" >> .bashrc && bash

Obtemos para que se pulou o contedor docker: o número de conexións e a carga:

$ telega

O contedor Docker está funcionando, as estatísticas están a xirar.

Recursos gastados

Por máis xenial que sexas Stuart Redman, aínda que deixas unha pegada nas túas bragas. Unha imaxe de Docker en execución deixa unha gran pegada.

Non ten sentido describir as vantaxes e desvantaxes das imaxes docker, un contedor docker é unha mini-máquina virtual que consome menos recursos que unha máquina virtual "real", como VirtualBox, pero si.

1) Lanzado con ou sen estatísticas de imaxe docker, dous clientes xogan ou dez - os recursos utilízanse ~ do mesmo xeito: o 75% do rendemento total da CPU t2.micro.

2) Observamos o seguimento do servidor VPC:

A partir do gráfico de utilización de recursos do VPC, vemos que o contedor docker consome constantemente ~ 7,5 % do total máx. O rendemento da CPU e o 28 de maio foi detido por min de forma intencionada/temporal (Nota: OpenVPN e pptp tamén se executan no servidor).

Por que o 10 % de uso constante da CPU é o límite para este servidor?

Porque hai restricións de Amazon EC2 e calcúlanse en créditos:

1 crédito de CPU = 1 CPU traballando ao 100 % de carga durante un minuto, e temos 6 créditos (é dicir, nos picos, a utilización do 100 % da CPU é posible en 6 minutos, e entón a potencia da CPU diminuirá). Outras combinacións: por exemplo, 1 crédito de CPU = 1 CPU funcionando ao 50% de carga durante dous minutos (é dicir, podemos usar a CPU ao 50% de carga durante 12 minutos), ou, por exemplo, unha carga constante do 10% da CPU durante todo o tempo, etc.

Descubrimentos

• Formamos parte da “Resistencia Dixital”. Proporcionou aos seus "pais e nais" unha canle de comunicación fiable.
• Se tes MtprotoProxyTelegram e OpenVPN implantados no servidor, pero non máis, non haberá atrasos / pings / fallos, pero se estás experimentando constantemente co teu t2 / micro, agarda por freos de comunicación.
• O meu ping no exterior é de ~100-250 ms, non hai atrasos na comunicación de voz.
• Custos financeiros para todo "isto" (incluídos os recursos VPC) = 0₽.

Reimpresión do teu artigo.

UPD: Grazas a algúns usuarios por comentarios útiles, de feito, é posible (as estatísticas son compatibles?), Hai mellores análogos da imaxe docker de Telegram do proxy oficial de Mtproto.

Fonte: www.habr.com