«Ho ereditato questa confusione,
a partire dagli sfacciati Zello; LinkedIn
e finendo con «tutti gli altri» sulla piattaforma Telegram
nel mio mondo.E poi, dopo aver ruttato,
l'ufficiale aggiunse in fretta e ad alta voce:
«ma io metterò ordine qui (nell'IT)»
(…).
Durov giustamente ritiene che siano gli stati autoritari a dover temere il suo, il cripto-anarchico, mentre i roskomnadzor e gli scudi d'oro con i loro filtri DPI non lo preoccupano affatto»
(Tecnica politica)
La mia politica tecnica è più semplice, posso qui elaborare le mie riflessioni riguardo ai blocchi incauti nel runet, ma ritengo che i cittadini progressisti della Russia moderna e gli utenti di Habra abbiano già sperimentato sulla propria pelle l'incompetenza dell'attuale potere, pertanto mi limiterò a una sola frase: la nostra politica tecnica è «Resistenza Digitale». «assicurare ai propri cari un canale di comunicazione resistente».
Distribuzione del proxy MTProto Telegram
- Il livello di complessità tecnica è «non complicato», se ad esempio si segue questo cheat sheet.
- Il livello di affidabilità è «sopra la media»: l'immagine Docker funziona in maniera stabile, non è necessario riavviarla ogni giorno, come riportato dagli sviluppatori nella loro documentazione ufficiale di Telegram, ma il contenitore contiene sicuramente alcune vulnerabilità.
- Il livello di resistenza/ansia è di 10 complottisti di IGIL che tessono le loro trame «la famiglia usa», nessun divieto è mai arrivato dal RKN in tutto questo tempo (dalla primavera).
- Il livello di fiducia è «puppy distrust», il problema è dalla parte dei clienti (alcuni amici sono sospettosi verso il mio MtprotoProxy).
- Il livello di testosterone è «non è aumentato».
- Costi finanziari - «0₽».
- Ricompensa finanziaria - «non dipende dal cittadino Durov». Incentivo - possibilità di imposizione di pubblicità.
Avvieremo il nostro TelegramProxy su risorse «gratuite/personali» di Amazon-ec2: t2.micro. Ho utilizzato questa macchina.
Ok, abbiamo avviato il nostro gratuito server, andiamo al sito ufficiale dockerhub e scarichiamo il contenitore Docker.
Non è necessario cercare un'immagine, un file o un pulsante magico - «non ce ne sono», tutta la magia si fa nel CLI:
$ docker pull telegrammessenger/proxy #immagine scaricata.Ma prima di «questo» installa Docker per CLI:
sudo apt-get install docker.io dockerSuccessivamente, nella documentazione ufficiale di MtprotoProxyTelegram ci viene suggerito di fare più o meno quanto segue, procediamo:
$ sudo su && docker run -d -p443:443 --name=mtproto-proxy --restart=always -v proxy-config:/data telegrammessenger/proxy:latest #avviamo il nostro contenitore «mtproto-proxy».
Dopo questo comando, nel terminale apparirà una stringa HEX, ma non ci interessa.
Scriviamo in CLI:
$ docker logs mtproto-proxyE otteniamo i dati necessari:
Nel log vengono mostrati (mascherato):
A) il nostro IP del server (IP esterno del server);
B) e un segreto casuale — una stringa casuale in HEX.
Prima di registrare il nostro MtproProxy, è necessario configurare il firewall principale sopra iptables (indipendentemente da come reindirizzate il traffico su questa VPC, sarà indisciplinato, poiché il firewall principale in Amazon-EC2 si trova nell'interfaccia web e ha una priorità più alta rispetto a iptables).
Accediamo a "console Amazon-EC2" nel Security Group e apriamo la porta 443 in entrata (una mascheratura logica del traffico per un po').
Prendiamo dal log i nostri dati "ip e segreto" e andiamo su Telegram, troviamo il bot ufficiale MTProxy Admin (@MTProxybot) e registriamo il nostro MtproProxy: avviamo il comando [\/newproxy] e inseriamo [nostro_ip:443], e poi il nostro [segreto\/HEX].
Se sbagliate nella digitazione dei dati, il bot si arrabbierà e vi manderà a...
Se compilate due righe senza errori, riceverete l'approvazione e un link funzionante per il vostro MtprotoProxyTelegram, che potrete condividere con chiunque.
Inoltre, tramite questo bot potete aggiungere il vostro canale sponsorizzato (ma non una chat), dove potrete convincere gli utenti che si sono collegati al vostro server, oppure potete non "spamare", e non disturbare i vostri potenziali clienti, non mostrando il canale nell'elenco fissato del messaggero.
Ancora qualche parola sul bot, lì potete richiedere statistiche, ma è un "buco". Evidentemente le "statistiche" sono disponibili quando vi segue una "folla di parassiti".
Monitoraggio
E quanti utenti possiamo collegare al nostro server? E in generale, chi\/cosa c'è lì? Cosa? E quanto?
Controlliamo la documentazione ufficiale... Ah, ecco, dobbiamo fare così:
$ curl http:\/\/localhost:2398\/stats oppure così $ docker exec mtproto-proxy curl http:\/\/localhost:2398\/stats # e ci forniranno le statistiche direttamente in CLI."Tieni stretto il portafoglio" Con i comandi suggeriti riceveremo sempre un errore simile:
«curl: (7) Impossibile connettersi alla porta 2398 localhost: Connessione rifiutata»
Il nostro proxy funzionerà. Ma! Un buco, non statistiche che otterremo.
Possiamo occuparci delle attività per gli occhi rossi: controllare
$ netstat -an | grep 2398 e...Inizialmente ho pensato che fosse un altro errore degli sviluppatori di Telegram (e ancora lo penso), poi ho trovato una soluzione temporanea decente: limare il contenitore Docker.
In seguito mi è capitata tra le mani l'informazione:
sulle danze governative di Roskomnadzor riguardo alle «statistiche».
«Abbiamo bloccato sui nostri server una parte dei proxy pubblici, utilizzando i database del progetto firehol. Questo progetto monitora le liste di proxy pubblici e crea database con essi.
Da questo momento (cioè da quasi due giorni) non è stato bloccato nessun indirizzo IP del nostro proxy russo.
3. Spieghiamo come creare un proxy quasi invulnerabile per Roskomnadzor e condividiamo uno script per bloccare i proxy pubblici.
— Aggiorna il contenitore docker (o il demone) MTProto proxy all'ultima versione: RKN individua le versioni vecchie tramite la porta delle statistiche, che era legata a 0.0.0.0 e si identificava in modo univoco per l'intero internet. O meglio: apri le porte necessarie tramite iptables e chiudi le altre (ricorda che nel caso di un contenitore docker, bisogna usare la regola FORWARD).
— Roskomnadzor ha imparato da tempo a fare il dump del traffico: vedono le richieste all'interno dei proxy HTTP e SOCKS5, e vedono anche la vecchia versione di offuscamento del MTProto proxy.
Quando i clienti di alcuni provider, che hanno installati tali dumpers, si connettono a Telegram tramite questi proxy, RKN vede tali richieste e blocca immediatamente questi proxy. Lo stesso vale per i proxy MTProto con la vecchia offuscazione.
Soluzione: distribuisci ai clienti che si connettono al proxy, un secret che inizi con dd (non è necessario specificare lettere aggiuntive dd nelle impostazioni del mtproto proxy). Questo attiverà una versione di offuscamento che i dumpers non riescono a identificare.
E niente proxy HTTP e SOCKS5.
— Un trucco che consente a ogni proprietario di proxy Telegram, che viene regolarmente bloccato da RKN, di interrompere completamente (o quasi completamente) i blocchi (e di verificare che RKN stia mentendo).
Uno script che blocca i proxy pubblici e un piccolo manuale per esso.»
→ Fonte
Il nostro proxy è occidentale, non ho incontrato problemi/blocchi durante le fresche giornate primaverili e estive, non era nemmeno un compito creativo, quindi non mi sono preoccupato di perdere il ritmo e non ho aggiunto il prefisso dd* alla chiave.
Il manuale «ottenere statistiche/monitoraggio» secondo le istruzioni ufficiali di MtprotoProxyTelegram è non funzionante/obsoleto, dovremo riparare l'immagine docker.
Ripariamo.
Il contenitore è ancora in esecuzione:
$ docker stop mtproto-proxy #fermiamo il nostro contenitore docker in esecuzione e avviamo una nuova immagine con il flag statistico omesso
$ docker run --net=host --name=mtproto-proxy2 -d -p443:443 -v proxy-config:\/data -e SECRET=il_tuo_vecchio_segreto_hex telegrammessenger\/proxy:latest
Controlliamo le statistiche:
$ curl http:\/\/localhost:2398\/statscurl: (7) Impossibile connettersi alla porta 0.0.0.0 2398: Connessione rifiutata
Le statistiche sono ancora non disponibili .!..
Scopriamo l'identificativo del contenitore docker:
$ docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f423c209cfdc telegrammessenger\/proxy:latest «\/bin\/sh -c ‘\/bin\/ba…» Circa un'ora fa In esecuzione Circa un minuto 0.0.0.0:443->443\/tcp mtproto-proxy2
Entriamo nel contenitore docker con il nostro statuto:
$ sudo docker exec -it f423c209cfdc \/bin\/bash
$ apt-get update
$ apt-get install nano
$ nano -$ run.sh
E nell'ultima riga dello script «run.sh» aggiungiamo il flag omesso:
«—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»
Aggiungi «—http-stats», qualcosa del genere dovrebbe risultare:
«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 (salvare/uscire da nano/uscire dal contenitore).
Riavviamo il nostro contenitore docker:
$ docker restart mtproto-proxy2Tutto, ora con il comando:
$ curl http:\/\/localhost:2398\/stats #otteniamo statistiche dettagliate
Nelle statistiche è presente molto «spazzatura» (nello screenshot 1\/3 è una parte), creiamo un alias:
$ echo "alias telega='curl localhost:2398\/stats | grep -e total_special -e load_average_total'" >> .bashrc && bashOtteniamo ciò per cui abbiamo lavorato sul contenitore docker: numero di connessioni e carico:
$ telega
Il contenitore Docker funziona, le statistiche scorrono.
Risorse utilizzate
Per quanto tu sia fantastico, Stuart Redman, anche tu lasci il segno della merda sulle tue mutande. Un'immagine Docker in esecuzione lascia una traccia non indifferente.
Non ha senso descrivere i pro e i contro delle immagini docker, il contenitore docker è una mini-macchina virtuale che consuma risorse meno di una «vera» macchina virtuale, come VirtualBox, ma consuma.
1) Eseguito con statistiche dell'immagine docker o senza, due client si divertono o dieci - le risorse vengono utilizzate ~in modo simile: 75% di tutte le capacità della CPU t2.micro.
2) Controlliamo il monitoraggio del server VPC:
Dal grafico di utilizzo delle risorse nel VPC vediamo che il contenitore docker consuma costantemente ~7,5% della massima capacità totale della CPU e il 28 maggio è stato fermato da me intenzionalmente\/temporaneamente (Nota — sul server girano anche OpenVPN & pptp).
Perché il 10% di carico CPU costante è il limite per questo server?
Perché ci sono limitazioni da parte di Amazon EC2 e vengono calcolate in crediti:
1 credito CPU = 1 CPU che lavora al 100% per un minuto, e noi abbiamo 6 crediti (cioè nei picchi è possibile una capacità al 100% della CPU per 6 minuti, dopo di che la potenza della CPU diminuirà). Altre combinazioni: ad esempio, 1 credito CPU = 1 CPU che lavora con un carico del 50% per due minuti (cioè possiamo utilizzare la CPU con un carico del 50% per 12 minuti) o, ad esempio, un carico costante del 10% della CPU per tutto il tempo e così via.
Conclusioni
- Siamo parte della «Resistenza Digitale». Abbiamo fornito ai nostri «papà e mamme» un canale di comunicazione affidabile.
- Se sul server hai attivato MtprotoProxyTelegram e OpenVPN, ma non di più, non ci saranno ritardi/ping/fallimenti, ma se stai continuamente sperimentando con il tuo t2/micro, preparati a rallentamenti nella connessione.
- Il mio ping transoceanico è di circa 100-250 ms, non si avvertono ritardi nella comunicazione vocale.
- I costi finanziari per tutto «questo» (inclusi anche le risorse VPC) = 0₽.
Ristampa del proprio articolo.
UPD: Grazie a alcuni utilizzatori di Habr per i commenti utili, è davvero possibile (la statistica è supportata?), che ci siano alternative migliori all'immagine ufficiale del docker Mtproto proxy Telegram.
Fonte: habr.com
