Rozbudowa własnego MTProxy Telegram ze statystyką

„Przejąłem ten chaos,
zaczynając od bezwstydnych Zello; LinkedIn
a kończąc na „wszystkich innych” na platformie Telegram
w moim świecie.

A potem, krztusząc się,
urzednik pośpieszył się i głośno dodał:
ale tu w IT wprowadzą porządek“
(…).

Durov słusznie uważa, że to autorytarne państwa powinny się go, kryptofanatyka, bać, podczas gdy rosyjskie nadzory i złote tarcze z ich filtrami DPI niezbyt go niepokoją“
(Technika polityczna)

Moja polityka techniczna jest prostsza, mogę tutaj rozważyć moje przemyślenia na temat lekkomyślnych blokad w runecie, ale sądzę, że postępowi obywatele nowoczesnej Rosji i użytkownicy Habr doświadczyli na własnej skórze nieprofesjonalizmu rządzącej władzy, więc ograniczę się do jednej frazy: nasza polityka techniczna to „Cyfrowy Opór”. „zapewnienie bliskim niezawodnego kanału komunikacji”.

Rozwój MTProto proxy Telegram

• Poziom złożoności technicznej — „nieskomplikowane”, jeśli na przykład postępujemy zgodnie z tym ściągawką.
• Poziom niezawodności — „powyżej średniej”: obraz docker działa stabilnie, nie trzeba go uruchamiać na nowo codziennie, jak pisali deweloperzy w swojej oficjalnej dokumentacji Telegram, ale jakieś podatności kontener z pewnością zawiera.
• Poziom oporu/zagrożenia — 10 igilistów snuje swoje spiski „krewni korzystają”, zakaz nie wpłynął na nas od RKN ani razu przez cały czas (od wiosny).
• Poziom zaufania — „publiczne dziecięce nieufność”, problem po stronie klientów (niektórzy znajomi podejrzliwie odnoszą się do mojego MtprotoProxy).
• Poziom testosteronu — „nie wzrósł”.
• Koszty finansowe — „0₽”.
• Nagroda finansowa — „nie zależy od obywatela Durova”. Zachęta — możliwość wyświetlania reklam.

Uruchomimy nasz TelegramProxy na „bezpłatnych/personalnych” zasobach Amazon-ec2: t2.micro. Użyłem tego komputera.

Ok, uruchomiliśmy nasz darmowy serwer, przechodzimy na oficjalną stronę dockerhub i pobieramy kontener docker.

Nie trzeba szukać jakiegoś obrazu, pliku, ani magicznego przycisku — „ich nie ma”, cała magia dzieje się w CLI:

$ docker pull telegrammessenger/proxy #obraz pobrany.

Ale przed „tym” zainstaluj docker do CLI:

sudo apt-get install docker.io docker

Następnie w oficjalnej dokumentacji MtprotoProxyTelegram proponują, aby zrobić mniej więcej to, co następuje:

$ sudo su && docker run -d -p443:443 --name=mtproto-proxy --restart=always -v proxy-config:/data telegrammessenger/proxy:latest #uruchamiamy nasz kontener „mtproto-proxy”.

Po tej komendzie w terminalu pojawi się ciąg HEX, ale nas to nie interesuje.

Wpisujemy w CLI:

$ docker logs mtproto-proxy

I otrzymujemy potrzebne dane:

W wyjściu tego logu pokazują nam (zamaskowane):

A) nasz adres IP serwera (zewnętrzny adres IP serwera);
B) oraz losowy sekret — losowy ciąg w HEX.

Zanim zarejestrujemy nasz MtproProxy, musimy skonfigurować główny firewall nad iptables (jakbyś nie przekierowywał ruch na tej VPC, będzie niesforny, ponieważ najważniejszy firewall w Amazon-EC2 znajduje się w interfejsie webowym i ma wyższy priorytet nad iptables).

Wchodzimy w „konsola Amazon-EC2” w Security Group i otwieramy przychodzący port 443 (logiczne maskowanie ruchu na początek).

Z loga wyciągamy nasze dane „ip i sekret” i idziemy do messengera Telegram, znajdujemy oficjalnego bota MTProxy Admin (@MTProxybot) i rejestrujemy nasz MtproProxy: uruchamiamy komendę [\/newproxy] i wprowadzamy [nasz_ip:443], a potem nasz [sekret\/HEX].

Jeśli popełnisz błąd przy wprowadzaniu danych, bot będzie zły i wyśle cię na…

Jeśli oba wiersze zostaną wypełnione poprawnie, otrzymasz zatwierdzenie i działający link do twojego aktywnego MtprotoProxyTelegram, którym możesz podzielić się z kimkolwiek.

Także przez tego bota możesz dodać swój kanał sponsorski (ale nie czat), gdzie będziesz narzucać swoje poglądy użytkownikom, którzy połączyli się z twoim serwera, a możesz nie „spamować” i nie niepokoić swoich potencjalnych klientów, nie pokazując kanału w przypiętej liście messengera.

Jeszcze kilka słów o bocie, tam można żądać statystyk, ale „też bułka”. Wyraźnie „statystyka” jest dostępna, gdy za tobą Makhachkala „tłum pasożytów”.

Monitoring

Ile użytkowników możemy połączyć z naszym serwerem? I w ogóle, kto/co tam? Co? I ile?

Sprawdzamy, co mówi oficjalna dokumentacja… Aha, to zrób tak:

$ curl http:\/\/localhost:2398\/stats lub tak $ docker exec mtproto-proxy curl http:\/\/localhost:2398\/stats # i otrzymamy statystyki bezpośrednio w CLI.

„Trzymaj kieszeń szeroko” Po proponowanych komendach zawsze będziemy otrzymywać podobny błąd:

«curl: (7) Nie udało się połączyć z portem localhost 2398: Połączenie odrzucone»

Nasz proxy będzie działać. Ale! Bułka, a nie statystyki otrzymamy.

Można zająć się sprawami dla czerwonych oczu: sprawdzić

$ netstat -an | grep 2398 i...

Na początku pomyślałem, że to kolejny błąd deweloperów Telegrama (i wciąż tak myślę), potem znalazłem tymczasowe, niezłe rozwiązanie: wypolerować Docker-Kontener pilnikiem.

Później natknąłem się na informację:

o państwowych działaniach Roskomnadzoru wokół „statystyki”.

„Zablokowaliśmy na naszych serwerach część publicznych serwerów proxy, korzystając z baz projektu firehol. Ten projekt monitoruje listy publicznych serwerów proxy i tworzy bazy z nimi.

Od tego momentu (czyli już prawie dwa dni) nie zablokowano żadnego adresu IP naszego rosyjskiego proxy.

3. Opowiadamy, jak stworzyć prawie nieodporne na Roskomnadzor proxy i dzielimy się skryptem blokady publicznych serwerów proxy.

— Zaktualizuj docker-kontener (lub demona) MTProto proxy do najnowszej wersji: RKN oblicza stare wersje po porcie statystyki, który był związany z 0.0.0.0 i jednoznacznie identyfikował się w całym internecie. A najlepiej — otwórz potrzebne porty za pomocą iptables, a inne — zamknij (pamiętaj, że w przypadku docker-kontenera powinno się używać reguły FORWARD).

— Roskomnadzor od dawna nauczył się przechwytywać ruch: widzą zapytania wewnątrz HTTP- i SOCKS5-proxy, a także dostrzegają starą wersję obfuskacji MTProto proxy.

Kiedy klienci niektórych dostawców, u których zainstalowane są takie przechwytywacze, zwracają się do Telegrama przez takie proxy, RKN widzi te zapytania i natychmiast blokują te proxy. To samo dotyczy MTProto proxy ze starą obfuskacją.

Rozwiązanie: dostarczaj klientom, którzy łączą się z proxy, secret tylko z dd na początku (nie trzeba podawać dodatkowych liter dd w ustawieniach samego mtproto proxy). To włączy wersję obfuskacji, którą przechwytywacze nie potrafią zidentyfikować.

I żadnych HTTP- i SOCKS5-proxy.

— Kieszonkowe, dzięki któremu każdy właściciel serwera proxy Telegrama, który regularnie jest blokowany przez RKN, może całkowicie (lub prawie całkowicie) zatrzymać blokady (a przy okazji upewnić się, że RKN kłamie).

Skrypt, który blokuje publiczne serwery proxy i krótki poradnik do niego”.

→ Źródło

Nasze proxy jest zachodnie, nie napotkałem żadnych problemów/blokad wiosną ani w chłodne letnie dni, więc nie angażowałem się w twórcze zadania i nie dodawałem prefiksu dd* do klucza.

Instrukcja „uzyskiwania statystyk / monitorowanie” z oficjalnej dokumentacji MtprotoProxyTelegram — nieaktualna / przestarzała, trzeba naprawić obraz dockera.

Naprawiamy.

Kontener wciąż działa:

$ docker stop mtproto-proxy # zatrzymujemy nasz uruchomiony kontener docker i uruchamiamy nowy obraz z pominiętym flagą statystyk.

$ docker run --net=host --name=mtproto-proxy2 -d -p443:443 -v proxy-config:/data -e SECRET=twój_poprzedni_sekret_hex telegrammessenger/proxy:latest

Sprawdzimy statystyki:

$ curl http://localhost:2398/stats

curl: (7) Nie udało się połączyć z 0.0.0.0 port 2398: Połączenie odrzucone.
Statystyki wciąż niedostępne .!..

Sprawdzamy identyfikator kontenera dockera:

$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f423c209cfdc telegrammessenger/proxy:latest „/bin/sh -c ‘/bin/ba…’” Około godzinę temu Działa Około minutę 0.0.0.0:443->443/tcp mtproto-proxy2

Wchodzimy do kontenera docker z naszym regulaminem:

$ sudo docker exec -it f423c209cfdc /bin/bash

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

A w ostatniej linii skryptu „run.sh” dodajemy pominiętą flagę:

«--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”

Dodajemy „--http-stats”, coś podobnego powinno się udać:

„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 (zapisz / wyjdź z nano / wyjdź z kontenera).

Restartujemy nasz kontener docker:

$ docker restart mtproto-proxy2

Wszystko, teraz na polecenie:

$ curl http://localhost:2398/stats # otrzymujemy szczegółowe informacje o statystyce.

W statystykach jest dużo „śmieci” (na zrzucie 1/3 jej część), tworzymy alias:

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

Otrzymujemy to, dla czego polerowaliśmy kontener docker: liczba połączeń i obciążenie:

$ telega

Kontener docker działa, statystyki się kręcą.

Wykorzystane zasoby

Niezależnie od tego, jak bardzo jesteś świetny, Stuart Redman, nawet ty zostawiasz ślad od gówna na swoich majtkach. Działający obraz docker zostawia niemały ślad.

Nie ma sensu opisywać zalet i wad obrazów docker, kontener docker — to mini-maszyna wirtualna, która zużywa zasoby mniej niż „prawdziwa” maszyna wirtualna, na przykład VirtualBox, ale jednak zużywa.

1) Uruchomiony z statystyką obraz docker czy bez niej, dwóch klientów szaleje czy dziesięciu — zasoby są wykorzystywane ~jednakowo: 75% z całej wydajności CPU t2.micro.

2) Sprawdzamy monitorowanie serwera VPC:

Z wykresu utylizacji zasobów na VPC widzimy, że kontener docker stale zużywa około 7,5% maksymalnej wydajności CPU, a 28 maja został przeze mnie zamierzony/tymczasowo zatrzymany. (Uwaga — na serwerze działają również OpenVPN & pptp).

Dlaczego 10% stałego obciążenia CPU to limit dla tego serwera?

Ponieważ istnieją ograniczenia ze strony Amazon EC2, które są obliczane w kredytach:

1 kredyt CPU = 1 CPU działający z 100% obciążeniem przez jedną minutę, a mamy 6 kredytów (co oznacza, że w szczytach 100% utylizacja CPU jest możliwa przez 6 minut, a potem moc CPU zostanie zmniejszona). Inne kombinacje: na przykład 1 kredyt CPU = 1 CPU działający z 50% obciążeniem przez dwie minuty (co oznacza, że możemy korzystać z CPU z 50% obciążeniem przez 12 minut), lub przykład stałego 10% obciążenia CPU przez cały czas itd.

Wnioski

• Jesteśmy częścią „Cyfrowego Oporu”. Zapewniamy naszym „tatusiom i mamusiom” niezawodny kanał komunikacji.
• Jeśli na serwerze uruchomisz MtprotoProxyTelegram i OpenVPN, ale nie więcej, nie będzie opóźnień/pingów/awarii, ale jeśli ciągle eksperymentujesz z t2/micro, przygotuj się na spowolnienia w komunikacji.
• Mój ping transatlantycki wynosi ~100-250ms, opóźnień w komunikacji głosowej nie odczuwam.
• Koszty finansowe związane ze wszystkim „tym” (w tym zasobami VPC) = 0₽.

Reprodukcja własnego artykułu.

UPD: Dziękuję niektórym użytkownikom Habr za pomocne komentarze, rzeczywiście, możliwe (statystyki są wspierane?), że istnieją lepsze odpowiedniki oficjalnego obrazu dockera Mtproto proxy Telegram.

Źródło: habr.com