MTProxy Telegram telepítése statisztikákkal

„Örököltem ezt a zűrzavart,
a lelkiismeretlen Zello-tól; LinkedIn
és vége a „többieknek” a Telegram platformján
a világomban.

Aztán egy akadozó sóhaj után
a hivatalnok sietve és hangosan hozzátette:
de rendet fogok tenni (itt az IT-ben)“
(…).

Durov joggal hiszi, hogy az autoriter államoknak kell félnie tőle, a kódoló punkoknak, és a Roszkomnadzornak, meg az arany pajzsoknak a DPI-szűrőikkel nem túlzottan jelent problémát”
(Politikai technika)

A technikai politikám egyszerűbb, itt leírom a gondolataimat a meggondolatlan blokkolásokról a Runetben, de úgy gondolom, a haladó Modern Orosz polgárok és a Habr felhasználói saját bőrükön tapasztalták a hatóságok szakmai alkalmatlanságát, ezért csak egy mondattal élek: a technikai politikánk – „Digitális Ellenállás”. „biztosítva a családtagoknak és közeli ismerősöknek egy megbízható kommunikációs csatornát”.

MTProto proxy Telegram telepítése

• A technikai nehézség szintje – „nem nehéz”, ha például követjük ezt a segédletet.
• A megbízhatóság szintje – „átlag felett”: a docker-kép stabilan működik, nem kell minden nap újraindítani, ahogy a fejlesztők az official Telegram dokumentációjukban írták, de biztos, hogy a konténer tartalmaz valamilyen sebezhetőséget.
• A szorongás/ellenállás szintje – 10 ISIS tag szövi a terveit „a család használja”, a Roszkomnadzor soha nem küldött eltiltást azóta (tavasz óta).
• A bizalom szintje – „közönséges baba bizalmatlanság”, a probléma az ügyfelek oldalán van (néhány barátom gyanakodva tekint az MtprotoProxy-mra).
• A tesztoszteron szintje – „nem lett magasabb”.
• Pénzügyi költségek – „0₽”.
• Pénzügyi jutalom – „nem függ Durov polgártól”. Jutalom – a reklám kényszerítő lehetősége.

A TelegramProxy-t az „ingyenes/személyes” Amazon-ec2 erőforrásain fogjuk üzemeltetni: t2.micro. Használatban van erre a gép.

Rendben, üzemeltettük a saját ingyenes szerver, lépjünk az official weboldalra dockerhub és töltsük le a docker-konténert.

Nem kell keresni valamilyen képet, fájlt vagy varázsgombot – „nincs”, minden varázslat a CLI-ben zajlik:

$ docker pull telegrammessenger/proxy #a kép letöltve.

De a „mielőtt” telepítenéd a docker-t a CLI-hez:

sudo apt-get install docker.io docker

Ezután az official MtprotoProxyTelegram dokumentációban körülbelül a következőt javasolják nekünk, tehát csináljuk:

$ sudo su && docker run -d -p443:443 --name=mtproto-proxy --restart=always -v proxy-config:/data telegrammessenger/proxy:latest #elindítjuk a konténerünket, a „mtproto-proxy”-t.

A parancs után a terminál kimenetében HEX-sorozat jelenik meg, de az minket nem érdekel.

Írjunk a CLI-be:

$ docker logs mtproto-proxy

És megkapjuk a szükséges adatokat:

A log kimenetében látható (elfedve):

A) a szerverünk IP-címe (külső IP-cím);
B) és a véletlenszerű titok - egy véletlenszerű HEX-sorozat.

Mielőtt regisztrálnánk a MtproProxy-nkat, be kell állítani a fő tűzfalat az iptables fölött (akárhogy is irányítod át a forgalmat ezen a VPC-n, engedetlen lesz, mivel a legfontosabb tűzfal az Amazon-EC2-ban a webes felületen található, és magasabb prioritással bír az iptables felett).

Lépjünk be az „konzolon Amazon-EC2”-be a Security Group-ba, és nyissuk meg a bejövő 443-as portot (logikus álcázás forgalom az első időszakra).

Kivesszük a logból az adatainkat „ip és titok”, és átmegyünk a Telegram üzenetküldőbe, megkeressük az hivatalos MTProxy Admin Bot-ot (@MTProxybot), és regisztráljuk a MtproProxy-nkat: elindítjuk a [\/newproxy] parancsot, és beírjuk a [saját_ip:443]-t, majd a [titkunk\/HEX]-et.

Ha hibázol az adatok megadásánál, a bot dühös lesz, és elküld téged…

Ha két sort hibátlanul kitöltöttél, jóváhagyást kapsz, és egy működő linket a sikeres MtprotoProxyTelegramhoz, amivel bárkivel megoszthatod.

Ezen a boton keresztül a szponzorált csatornádat is hozzá lehet adni (de nem csoportot), ahol az elképzeléseidet ráerőltetheted a felhasználókra, akik csatlakoztak a szerverhez, vagy nem „spamelhetsz”, és nem zavarhatod a potenciális ügyfeleidet, nem mutatva a csatornát a rögzített listában az üzenetküldőben.

Még pár szó a botról, ott statisztikát is lehet kérni, de „ugyanaz a bublik”. Nyilván a „statisztika” akkor érhető el, amikor mögötted Makhachkala „a potyázók tömege” van.

Monitorozás

Hány felhasználót tudunk csatlakoztatni a szerverünkhöz? És egyáltalán, ki/mi ott? Mi? És mennyi?

Nézzük, mi van az hivatalos dokumentáción… Aha, ezt kell csinálni:

$ curl http:\/\/localhost:2398\/stats vagy így $ docker exec mtproto-proxy curl http:\/\/localhost:2398\/stats # és a statisztikát közvetlenül a CLI-ben fogjuk megkapni.

„Tartsd a zsebed szélesebbre” A javasolt parancsok alapján mindig hasonló hibát fogunk kapni:

«curl: (7) Nem sikerült kapcsolódni a localhost 2398-as portjához: A kapcsolódás megtagadva»

A proxyunk működni fog. De! Bublik, és nem statisztikát fogunk kapni.

Lehet foglalkozni a tennivalókkal a piros szemezők számára: ellenőrizni

$ netstat -an | grep 2398 és...

Először azt hittem, hogy ez újabb hiba a Telegram fejlesztői részéről (és még mindig így gondolom), majd találtam egy ideiglenes, de jó megoldást: csiszolni a Docker-konténert.

Később a szemem elé került egy információ:

az Orosz Kommunikációs Felügyelet állami táncairól a „statisztikák” körül.

„A nyílt közvetítők egy részét blokkoltuk a szervereinken, a firehol projekt adatbázisainak felhasználásával. Ez a projekt nyomon követi a nyilvános proxyk listáit, és adatbázisokat készít róluk.

Ettől az időponttól (azaz már majdnem két napja) egyetlen IP-címünket sem blokkolták az orosz proxyink közül.

3. Elmondjuk, hogyan lehet majdnem sebezhetetlenné tenni a Roszkomnadzor számára a proxy-kat, és megosztunk egy nyilvános proxyk blokkolására szolgáló szkriptet.

— Frissítse a docker konténert (vagy MTProto proxy démonját) a legújabb verzióra: a Roszkomnadzor a statisztikai port alapján képes azonosítani a régi verziókat, amelyek a 0.0.0.0-ra voltak bindelve és egyértelműen azonosították magukat az internet számára. Jobb, ha a szükséges portokat megnyitja iptables segítségével, míg a többit lezárja (ne feledje, hogy docker konténer esetén a FORWARD szabályt kell használni).

— A Roszkomnadzor régóta megtanulta a forgalom figyelését: látják a HTTP- és SOCKS5-proxykon belüli kéréseket, valamint látják a régi MTProto proxy obfuszkálást.

Amikor bizonyos szolgáltatók ügyfelei, akiknél ilyen forgalomfigyelők vannak telepítve, ezekkel a proxykkal lépnek kapcsolatba a Telegramon, akkor a Roszkomnadzor észleli ezeket a kéréseket, és azonnal blokkolja ezeket a proxykat. Ugyanez vonatkozik az MTProto proxykra a régi obfuszkálással.

Megoldás: ne adja meg a proxyhoz csatlakozó ügyfeleknek a titkos kulcsot csak dd-vel az elején (nem szükséges további dd betűket megadni a mtproto proxy beállításaiban). Ez aktiválja az obfuszkálás verzióját, amelyet a forgalomfigyelők nem tudnak azonosítani.

És semmilyen HTTP- és SOCKS5-proxy.

— Egy eszköz, amellyel minden telegram-proxy tulajdonos, akit rendszeresen blokkol a Roszkomnadzor, teljesen (vagy majdnem teljesen) megszüntetheti a blokkolásokat (és egyúttal megbizonyosodhat arról, hogy a Roszkomnadzor hazudik).

Egy szkript, amely blokkolja a nyilvános proxykat és egy rövid útmutató hozzá.

→ Forrás

A proxym nyugati, semmilyen problémába/belépőbe nem ütköztem a tavaszi és hűvös nyári napokon, ezért a kreatív feladataim miatt nem foglalkoztam a tempó elvesztésével és a dd* prefixet sem adtam a kulcshoz.

A „statisztika megszerzése/monitorozás” kézikönyv a MtprotoProxyTelegram hivatalos útmutatója — nem működik/lejárt, meg kell javítani a docker képet.

Javítjuk.

A konténerünk még mindig fut:

$ docker stop mtproto-proxy #megállítjuk a futó docker konténert, és elindítunk egy új képet a statisztikai jelző kihagyásával

$ docker run --net=host --name=mtproto-proxy2 -d -p443:443 -v proxy-config:\/data -e SECRET=a_te_előző_hex_titkod telegrammessenger\/proxy:latest

Ellenőrizzük a statisztikát:

$ curl http:\/\/localhost:2398\/stats

curl: (7) Nem sikerült kapcsolódni a 0.0.0.0 port 2398-hoz: A kapcsolat megtagadva
A statisztika továbbra sem elérhető .!..

Kiderítjük a docker konténer azonosítóját:

$ docker ps

KONTÉNER AZONOSÍTÓ KÉP PARANCS LÉTREHOZÁS ÁLLAPOT PORTOK NEVEK
f423c209cfdc telegrammessenger\/proxy:latest «\/bin\/sh -c ‘\/bin\/ba…» Körülbelül egy órája Futtatva Körülbelül egy perce 0.0.0.0:443->443\/tcp mtproto-proxy2

Bemenjük a docker konténerbe a saját szabályainkkal:

$ sudo docker exec -it f423c209cfdc \/bin\/bash

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

A "run.sh" script utolsó sorában hozzáadjuk a kihagyott flag-et:

«—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»

Hozzáadjátok a «—http-stats»-ot, valami ilyesminek kellene lennie:

«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 (mentés\/kilépés a nano-ból\/kilépés a konténerből).

Újraindítjuk a docker konténert:

$ docker restart mtproto-proxy2

Kész, most a parancsra:

$ curl http:\/\/localhost:2398\/stats #részletes statisztikát kapunk

A statisztikában sok „szemét” van (a képen az 1/3 része), készítünk egy alias-t:

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

Megkapjuk azt, amiért políroztuk a docker konténert: a csatlakozások számát és a terhelést:

$ telega

A docker konténer működik, a statisztika forog.

Fogyasztott erőforrások

Akármennyire is jó Styuart Redman, még te is nyomsz a fenekeden. A működő Docker kép nem kicsi nyomot hagy.

A docker képek előnyeit és hátrányait részletezni nem érdemes, a docker konténer egy mini-vírus gép, amely kevesebb erőforrást fogyaszt, mint egy 'valódi' virtuális gép, például a VirtualBox, de fogyaszt.

1) Futtatva statisztikával a docker kép vagy anélkül, két kliens száguldozik vagy tíz — az erőforrások felhasználása ~ugyanolyan: a CPU teljesítményének 75%-a t2.micro-ból.

2) Nézzük meg a VPC szerver monitoringot:

A VPC erőforrás-felhasználási grafikonáról látjuk, hogy a docker konténer folyamatosan ~7,5%-át fogyasztja a teljes maximális CPU teljesítménynek, és május 28-án szándékosan/ideiglenesen leállítottam. (Megjegyzés — a szerveren fut OpenVPN & pptp is).

Miért van a 10% CPU állandó terhelése határ a szerver számára?

Mert az Amazon EC2 korlátai vannak, és ezeket kreditekben számolják:

1 CPU kredit = 1 CPU, amely 100%-os terheléssel működik egy percig, és nekünk 6 kreditünk van (tehát 100%-os CPU kihasználás a csúcsidőszakban legfeljebb 6 percig lehetséges, utána a CPU teljesítménye csökken). Más kombinációk: például 1 CPU kredit = 1 CPU, amely 50%-os terheléssel működik két percig (tehát a CPU-t 50%-os terheléssel 12 percig használhatjuk), vagy például folyamatos 10%-os CPU terheléssel az összes idő alatt, stb.

Következtetések

• Mi a „Digitális Ellenállás” részei vagyunk. Megbízható kommunikációs csatornát biztosítottunk a „szüleink” számára.
• Ha a szerveren van telepítve MtprotoProxyTelegram és OpenVPN, de nem több, akkor nem lesz késleltetés/ping/elérhetőségi probléma, de ha állandóan kísérletezel a t2/micro-val, akkor késlekedésekre számíthatsz.
• Az óceánon túli pingem ~100-250ms, a beszélgetésben nem érzékelek késleltetést.
• A teljes költség „ez”-re (beleértve a VPC erőforrásokat) = 0₽.

A saját cikkem átkonvertálása.

UPD: Köszönet néhány Hubra-olvasónak a hasznos hozzászólásokért, valóban, lehetséges (a statisztika fenntartott?), hogy vannak jobb alternatívák az Mtproto proxy Telegram hivatalos docker-képéhez.

Forrás: habr.com