"Eu herdei essa confusão,
começando pelos descarados Zello; LinkedIn
e terminando com "todos os outros" na plataforma Telegram
no meu mundo.E então, após uma breve tosse,
o funcionário apressadamente e em voz alta acrescentou:
"mas eu vou colocar (aqui em TI) ordem"
(…).
Durov, acredita corretamente que são os estados autoritários que devem temê-lo, o seu 'cifrão', e que os Roskomnadzor e os escudos dourados com seus filtros DPI não o preocupam muito"
(Técnica Política)
Minha política técnica é mais simples, eu poderia escrever aqui meus pensamentos sobre os bloqueios imprudentes na Runet, mas acredito que cidadãos progressistas da Rússia Moderna e usuários do Habr sentiram na pele a falta de profissionalismo do governo atual, então me limitarei a uma única frase: nossa política técnica é "Resistência Digital". "garantir um canal de comunicação estável para amigos e familiares".
Desdobramento do proxy MTProto do Telegram
- O nível de dificuldade técnica é "não complicado", se, por exemplo, seguir este guia.
- O nível de confiabilidade é "acima da média": a imagem docker funciona de forma estável, não é necessário reiniciá-la todos os dias, como os desenvolvedores afirmaram em sua documentação oficial do Telegram, mas o contêiner provavelmente contém algumas vulnerabilidades.
- O nível de resistência/ansiedade é: 10 conspiradores do ISIS tramando "a família está usando", nenhum bloqueio foi aplicado pelo Roskomnadzor durante todo esse tempo (desde a primavera).
- O nível de confiança é "distrust público de bebê", o problema está do lado dos clientes (alguns amigos são suspeitos em relação ao meu MtprotoProxy).
- O nível de testosterona é "não aumentou".
- Custos financeiros são "0₽".
- Recompensa financeira é "não depende do cidadão Durov". Incentivo é a possibilidade de impostura de propaganda.
Vamos configurar nosso TelegramProxy em "recursos gratuitos/pessoais" da Amazon-ec2: t2.micro. Eu usei este a máquina.
Ok, configuramos nosso gratuito servidor, vamos ao site oficial dockerhub e baixamos o contêiner docker.
Não é necessário procurar uma imagem, arquivo ou botão mágico — "não existem", toda a mágica acontece no CLI:
$ docker pull telegrammessenger/proxy #imagem baixada.Mas antes de "fazer isso", instale o docker para CLI:
sudo apt-get install docker.io dockerEm seguida, na documentação oficial do MtprotoProxyTelegram, somos orientados a fazer algo como o seguinte, fazemos:
$ sudo su && docker run -d -p443:443 --name=mtproto-proxy --restart=always -v proxy-config:/data telegrammessenger/proxy:latest #iniciamos nosso contêiner "mtproto-proxy".
Após este comando, uma string HEX aparecerá na saída do terminal, mas isso não nos interessa.
Escrevemos no CLI:
$ docker logs mtproto-proxyE obtemos os dados necessários:
Na saída deste log, nos mostram (ocultei):
A) nosso ip do servidor (ip externo do servidor);
B) e um segredo aleatório — uma string aleatória em HEX.
Antes de registrar nosso MtproProxy, é preciso configurar o firewall principal sobre iptables (não importa como você redirecionar o tráfego nesta VPC, ele será problemático, pois o firewall principal na Amazon-EC2 está na interface web e tem prioridade mais alta que o iptables).
Vamos em "console Amazon-EC2" no Grupo de Segurança e abrimos a porta 443 de entrada (uma camuflagem lógica do tráfego por um tempo).
Pegamos do log nossos dados "ip e segredo" e vamos no mensageiro Telegram, encontramos o bot oficial MTProxy Admin Bot (@MTProxybot) e registramos nosso MtproProxy: executamos o comando [\/newproxy] e digitamos [nosso_ip:443], e em seguida nosso [segredo\/HEX].
Se você cometer um erro ao inserir os dados, o bot ficará irritado e enviará você para...
Se preencher duas linhas sem erros, receberá aprovação e um link ativo para o seu MtprotoProxyTelegram, que você pode compartilhar com quem quiser.
Também através deste bot você pode adicionar seu canal de patrocinador (mas não um chat), onde você imporá suas opiniões aos usuários que se conectarem ao seu servidor, ou pode optar por não “spamar” e não incomodar seus potenciais clientes, não mostrando o canal na lista fixada do mensageiro.
Mais algumas palavras sobre o bot, lá você pode solicitar estatísticas, mas "também é uma ilusão". Evidentemente, as "estatísticas" estão disponíveis quando você tem uma multidão de parasitas atrás de você em Makhachkala.
Monitoramento
Quantos usuários podemos conectar ao nosso servidor? E quem/o que está lá? O que? E quantos?
Vamos ver o que diz a documentação oficial... Ah, sim, faça assim:
$ curl http:\/\/localhost:2398\/stats ou assim $ docker exec mtproto-proxy curl http:\/\/localhost:2398\/stats # e teremos as estatísticas diretamente no CLI."Mantenha o bolso aberto". Com os comandos sugeridos, sempre receberemos um erro semelhante:
«curl: (7) Falha ao conectar-se à porta localhost 2398: Conexão recusada»
Nosso proxy funcionará. Mas! Uma ilusão, e não estatísticas que receberemos.
Podemos realizar ações para os olhos vermelhos: verifique
$ netstat -an | grep 2398 e...A princípio, pensei que fosse mais um erro dos desenvolvedores do Telegram (e ainda penso assim), depois encontrei uma solução temporária satisfatória: lixar o container Docker.
Mais tarde, encontrei informações:
sobre as danças estatais do Roskomnadzor em torno da "estatística".
"Bloqueamos em nossos servidores parte dos proxies públicos, utilizando bases do projeto firehol. Este projeto monitora listas de proxies públicos e cria bancos de dados com eles.
Desde este momento (ou seja, há quase dois dias) nenhum endereço IP de nosso proxy russo foi bloqueado.
3. Contamos como fazer um proxy quase à prova do Roskomnadzor e compartilhamos um script para bloquear proxies públicos.
- Atualize o contêiner docker (ou daemon) do proxy MTProto para a última versão: o RKN identifica versões antigas pela porta de estatísticas, que se ligava em 0.0.0.0 e se identificava claramente para toda a internet. Ou melhor — abra as portas necessárias com iptables e feche as outras (lembre-se de que no caso do contêiner docker, deve-se usar a regra FORWARD).
- O Roskomnadzor aprendeu a fazer o dump de tráfego há muito tempo: eles veem acessos dentro de proxies HTTP e SOCKS5, assim como enxergam a antiga versão de ofuscação do proxy MTProto.
Quando clientes de alguns provedores, que têm esses dumps, acessam o Telegram através de tais proxies, o RKN vê esses acessos e logo bloqueia esses proxies. O mesmo se aplica ao proxy MTProto com ofuscação antiga.
Solução: forneça aos clientes que se conectam ao proxy um segredo que comece com dd (não é necessário indicar letras adicionais dd nas configurações do próprio proxy mtproto). Isso ativará a versão de ofuscação que os dumps não conseguem identificar.
E nada de proxies HTTP e SOCKS5.
- Um ajuste que permite a cada proprietário de proxy telegram que é constantemente banido pelo RKN encerrar totalmente (ou quase totalmente) os bloqueios (assim como comprovar que o RKN está mentindo).
Um script que bane proxies públicos e um pequeno manual a ele.
→ Fonte
Nosso proxy é ocidental, não encontrei problemas/bloqueios durante os dias de primavera e os frescos dias de verão, portanto, não me preocupava em perder ritmo e não adicionei o prefixo dd* à chave.
O manual "obtendo estatísticas/monitoramento" segundo a instrução oficial do MtprotoProxyTelegram está inoperante/ultrapassado, será necessário consertar a imagem docker.
Vamos consertar.
O contêiner ainda está em execução:
$ docker stop mtproto-proxy #paramos nosso contêiner docker em execução e iniciamos uma nova imagem com a flag de estatísticas omitida
$ docker run --net=host --name=mtproto-proxy2 -d -p443:443 -v proxy-config:\/data -e SECRET=seu_segredo_anterior_hex telegrammessenger\/proxy:latest
Vamos verificar as estatísticas:
$ curl http:\/\/localhost:2398\/statscurl: (7) Falha ao conectar a 0.0.0.0 porta 2398: Conexão recusada
Estatísticas ainda não estão disponíveis .!..
Vamos descobrir o identificador do contêiner docker:
$ docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f423c209cfdc telegrammessenger\/proxy:latest «\/bin\/sh -c ‘\/bin\/ba…» Há cerca de uma hora Em funcionamento Há cerca de um minuto 0.0.0.0:443->443\/tcp mtproto-proxy2
Vamos acessar o contêiner docker com nosso comando:
$ sudo docker exec -it f423c209cfdc \/bin\/bash
$ apt-get update
$ apt-get install nano
$ nano -$ run.sh
E na última linha do script «run.sh», adicionamos a flag omitida:
«—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»
Adicionamos «—http-stats», algo como isto deve resultar:
«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 (salvar\/sair do nano\/sair do contêiner).
Reiniciamos nosso contêiner docker:
$ docker restart mtproto-proxy2Pronto, agora com o comando:
$ curl http:\/\/localhost:2398\/stats #obtemos estatísticas volumosas
Nas estatísticas há muito «lixo» (na tela 1\/3 é parte disso), criamos um alias:
$ echo "alias telega='curl localhost:2398\/stats | grep -e total_special -e load_average_total'" >> .bashrc && bashObtemos o que viemos buscar: número de conexões e carga:
$ telega
O contêiner Docker está funcionando, as estatísticas estão rodando.
Recursos utilizados
Não importa quão legal você seja, Stuart Redman, até você deixa uma marca de sujeira em suas calças. Uma imagem Docker em funcionamento deixa uma marca considerável.
Explorar as vantagens e desvantagens das imagens docker não faz sentido; um contêiner docker é uma mini-máquina virtual que consome recursos de forma menos intensa do que uma máquina virtual ‘real’, como o VirtualBox, mas ainda consome.
1) Executado com estatísticas da imagem docker ou sem, dois clientes ou dez — os recursos são utilizados de maneira semelhante: 75% de toda a capacidade de CPU t2.micro.
2) Vamos observar o monitoramento do servidor VPC:
No gráfico de utilização de recursos no VPC, vemos que o contêiner docker consome continuamente cerca de 7,5% da capacidade máxima total de CPU e foi interrompido por mim de forma intencional\/temporariamente em 28 de maio (Nota — no servidor também estão em execução OpenVPN & pptp).
Por que 10% de carga constante da CPU é o limite para este servidor?
Porque existem limitações por parte da Amazon EC2 e são calculadas em créditos:
1 crédito de CPU = 1 CPU operando a 100% de carga durante um minuto, e temos 6 créditos (ou seja, picos de 100% de utilização da CPU são possíveis por 6 minutos, e depois disso a capacidade da CPU será reduzida). Outras combinações: por exemplo, 1 crédito de CPU = 1 CPU operando a 50% de carga durante dois minutos (ou seja, podemos usar a CPU a 50% de carga durante 12 minutos), ou, por exemplo, uma carga constante de 10% da CPU durante todo o tempo, e assim por diante.
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
- Nós somos uma parte da "Resistência Digital". Garantimos para nossos "pais e mães" um canal de comunicação confiável.
- Se no servidor você tiver o MtprotoProxyTelegram e OpenVPN configurados, mas não mais, não haverá atrasos/ping/erros, mas se você experimentar constantemente com seu t2/micro, aguarde lentidão na conexão.
- Meu ping do outro lado do oceano é de ~100-250ms, não sentimos atrasos na comunicação de voz.
- Os custos financeiros de tudo isso (incluindo recursos VPC) = 0₽.
Reimpressão do seu artigo.
UPD: Obrigado a alguns usuários do Habr por comentários úteis, realmente, é possível (a estatística é mantida?) que existem melhores alternativas à imagem oficial do Docker do Mtproto proxy Telegram.
Fonte: habr.com
