Разгръщане на собствен MTProxy Telegram със статистика

„Наследих тези безредици,
започвайки с безсрамни Zello; LinkedIn
и завършвайки с „всички останали“ на платформата Telegram
в моя свят.

А след като въздъхна,
чиновникът бързо и шумно добави:
но ще възвърна (тук в ИТ) реда“
(…).

Дуров справедливо счита, че авторитарните държави трябва да се страхуват от него, шифропанка, а роскомнадзорите и златните щитове с техните DPI-филтри не го притесняват много“
(Политическа техника)

Моята техническа политика е по-проста, мога да опиша разсъжденията си относно непрофесионалните блокировки в рунета, но смятам, че прогресивните граждани на Modern Russian и потребителите на Хабра са усетили на собствената си кожа непрофесионализма на действащата власт, така че ще се огранича до една единствена фраза: нашата техническа политика е „Цифрово Съпротивление“. „осигуряване на близките и роднините устойчив канал за връзка“.

Разгръщане на MTProto прокси Telegram

• Нивото на техническа сложност е „не сложно“, ако, например, следвате този шприц.
• Нивото на надеждност е „над средното“: docker-образът работи стабилно, не е нужно да го рестартирате всеки ден, както са писали разработчиците в официалната документация на Telegram, но определено има уязвимости в контейнера.
• Нивото на съпротивление/тревога — 10 игилци плетат своите заговори „роднините ползват“, забрана от РКН не е идва, нито веднъж през всичкото време (от пролетта).
• Нивото на доверие е „обществена недоверчивост“, проблемът е на страната на клиентите (някои приятели се отнасят подозрително към моя MtprotoProxy).
• Нивото на тестостерон е „повече не стана“.
• Финансовите разходи са „0₽“.
• Финансовото възнаграждение е „не зависи от гражданина Дуров“. Поощрението е възможност за налагане на реклама.

Ще развиваме нашия TelegramProxy на „безплатни/лични“ мощност на Amazon-ec2: t2.micro. Използвах тази машина.

Окей, разгръщам собствените си безплатни сървър, преминаваме на официалния сайт dockerhub и изтегляме docker-контейнера.

Не е нужно да търсите образ, файл или вълшебен бутон — „няма ги“, цялата магия се случва в CLI:

$ docker pull telegrammessenger/proxy #образът е изтеглен.

Но преди „това“ инсталирайте docker за CLI:

sudo apt-get install docker.io docker

След това, в официалната документация на MtprotoProxyTelegram ни предлагат да направите следното, правим:

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

След тази команда в изхода на терминала ще се появи HEX-стрека, но това не ни интересува.

Пишем в CLI:

$ docker logs mtproto-proxy

И получаваме нужните данни:

В изхода на този лог ни показват (замазах):

А) нашия ip на сървъра (външен ip на сървъра);
Б) и произволен секрет — произволна стринга в HEX.

Преди да регистрираме нашия MtproProxy, трябва да настроим главния файрвол над iptables (както и да пренасочвате трафика на този VPC, той ще бъде непослушен, тъй като най-важният файрвол в Amazon-EC2 се намира в уеб-интерфейса и има по-висок приоритет от iptables).

Влизаме в «конзолата Amazon-EC2» в Security Group и отваряме входящия 443 порт (логична маскировка на трафика за времето на конфигурация).

Вземаме от лога нашите данни «ip и секрет» и отиваме в мессенджера Telegram, намираме официалния MTProxy Admin Bot (@MTProxybot) и регистрираме нашия MtproProxy: стартираме командата [\/newproxy] и въвеждаме [наш_ip:443], а след това и нашия [секрет\/HEX].

Ако направите грешка при въвеждането на данните, ботът ще се ядоса и ще ви изпрати на…

Ако попълните двете линии без грешки, ще получите одобрение и работна връзка към вашия работещ MtprotoProxyTelegram, който можете да споделите с когото и да е.

Също така, през този бот можете да добавите вашия спонсорски канал (но не чат), където ще налагате вашите възгледи на потребителите, които се свързват с вашия сървъра, или можете да не «спамите» и да не притеснявате бъдещите си клиенти, без да показвате канала в закрепения списък на мессенджера.

Още няколко думи за бота, там може да се запитате за статистика, но «тъй като има проблем». Явно «статистиката» е достъпна, когато имаш много хора наоколо от Махачкала.

Мониторинг

А колко потребители можем да свържем на нашия сървър? И изобщо, кой\/какво е там? Какво? И колко?

Нека видим какво пише в официалната документация… А, ето, направете така:

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

«Дръжте кармана широко» По предложените команди винаги ще получаваме подобна грешка:

«curl: (7) Не успя да се свърже с localhost порт 2398: Връзката беше отказана»

Нашият прокси ще работи. Но! Проблем, а не статистика ще получим.

Можем да свършим някои задачи за проверка: проверете

$ netstat -an | grep 2398 и...

Първоначално си помислих, че това е пореден проблем на разработчиците на Telegram (и все още мисля така), след което намерих временно разумно решение: да шлифовам Docker-контейнера с пила.

По-късно ми попадна информация:

за държавните действия на Роскомнадзор около "статистиката".

„Ние блокирахме част от публичните прокси на своите сървъри, използвайки базите на проекта firehol. Този проект следи списъци с публични прокси и създава бази с тях.

От този момент (тоест вече почти два дни) не е блокиран нито един IP адрес на нашето руско прокси.

3. Разказваме как да направим почти неуязвимо за Роскомнадзор прокси и споделяме скрипт за блокиране на публични прокси.

— Актуализирайте docker-контейнера (или демона) на MTProto прокси до последната версия: РКН изчислява старите версии по порта за статистика, който се свързва на 0.0.0.0 и ясно се идентифицира за целия интернет. А по-добре — отворете необходимите портове с помощта на iptables, а останалите — затворете (помнете, че при docker-контейнера трябва да използвате правилото FORWARD).

— Роскомнадзор отдавна е научил как да анализира трафика: те виждат запитванията вътре в HTTP и SOCKS5 прокситата, както и виждат старата версия на обфускацията на MTProto прокси.

Когато клиентите на някои доставчици, при които са инсталирани такива анализатори, се свързват с Telegram чрез такива проксита, РКН вижда тези запитвания и незабавно блокира тези проксита. Същото важи и за MTProto прокси със стара обфускация.

Решение: давайте на клиентите, които се свързват с проксито, secret само с dd в началото (не е нужно да посочвате допълнителни букви dd в настройките на самото mtproto прокси). Това ще включи версия на обфускация, която анализаторите не могат да определят.

И никакви HTTP и SOCKS5 проксита.

— Подобрение, с помощта на което всеки собственик на телеграм-прокси, който редовно е блокиран от РКН, може напълно (или почти напълно) да прекрати блокировките (а наред с това и да се увери, че РКН лъже).

Скрипт, който блокира публични проксита и малък мануал към него.

→ Източник

Нашето прокси е прозападно, не срещнах никакви проблеми/блокировки през пролетните и прохладни летни дни, не беше нужно да се занимавам с загуба на темпо и не добавях префикс dd* към ключа.

Ръководство „получаване на статистика/мониторинг“ по официалната инструкция MtprotoProxyTelegram — неработещо/остаряло, ще трябва да поправим docker образа.

Поправяме.

Контейнерът все още е активен:

$ 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

Проверяваме статистиката:

$ curl http://localhost:2398/stats

curl: (7) Не може да се свърже с 0.0.0.0 порт 2398: Свързването е отказано
Статистиката все още е недостъпна .!..

Узнаваме идентификатора на docker контейнера:

$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f423c209cfdc telegrammessenger/proxy:latest "/bin/sh -c ‘/bin/ba…" Преди около час Работи От около минута 0.0.0.0:443->443/tcp mtproto-proxy2

Влизаме в docker контейнера с нашите условия:

$ sudo docker exec -it f423c209cfdc /bin/bash

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

И в последния ред на скрипта „run.sh“ добавяме пропуснатия флаг:

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

Добавяте "--http-stats", нещо подобно трябва да изглежда:

"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 (записваме/излизаме от nano/излизаме от контейнера).

Рестартираме нашия docker контейнер:

$ docker restart mtproto-proxy2

Сега по команда:

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

В статистиката има много „мръсотия“ (на екрана 1/3 от нея), създаваме псевдоним:

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

Получаваме това, за което полирахме docker контейнера: брой на свързванията и натоварването:

$ telega

Docker контейнерът работи, статистиката се обновява.

Изразходвани ресурси

Каквото и да си мислиш, Стюарт Редман, дори и ти оставяш следи от гъзове на своите гащи. Работещият Docker образ оставя значителни следи.

Няма смисъл да се описват предимствата и недостатъците на docker образите, docker контейнерът е мини-виртуална машина, консумираща ресурси по-малко от „реална“ виртуална машина, например VirtualBox, но все пак консумира.

1) Запуска се със статистика или без, двама клиенти се натискат или десет — ресурсите се утилизира тъй като ~еднакво: 75% от цялата производителност на CPU t2.micro.

2) Наблюдаваме мониторинг на VPC сървъра:

От графика на VPC виждаме, че docker-контейнерът постоянно потребява ~7,5% от общата макс. производителност на CPU и на 28 май беше спирателно/временно спрян от мен. (Забележка — на сървъра работят също OpenVPN & pptp).

Защо 10% постоянна натовареност на CPU е лимит за този сървър?

Защото има ограничения от страна на Amazon EC2, които се измерват в кредити:

1 кредит CPU = 1 CPU, работещ на 100% натовареност за една минута, а при нас са 6 кредита (т.е. в пикове 100%-на натовареност на CPU е възможна за 6 минути, а след това производителността на CPU ще намалее). Други комбинации: например, 1 кредит CPU = 1 CPU, работещ на 50% натовареност за две минути (т.е. можем да използваме CPU с 50% натовареност за 12 минути), или пример, постоянна 10%-на натовареност на CPU през всичкото време и прочие.

Изводи

• Ние сме част от „Цифрово Съпротивление“. Осигурихме на нашите „татковци и майки“ надежден канал за комуникация.
• Ако на сървъра имате разположен MtprotoProxyTelegram и OpenVPN, но не повече, закъснения/пингове/събития няма да има, но ако постоянно експериментирате с t2/micro, то очаквайте забавяния в комуникацията.
• Моят пинг оттатък океана е ~100-250ms, без забавяния в речевата комуникация.
• Финансовите разходи за всичко „това“ (включително ресурсите на VPC) = 0₽.

Препечатка на своята статия.

UPD: Благодаря на някои хабраюзери за полезните коментари, наистина, възможно е (поддържа се статистика?), да има по-добри аналози на официалния docker-образ на Mtproto proxy Telegram.

Източник: habr.com