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

„Наследих тази бъркотия,
започвайки с безсрамните Zello; LinkedIn
и завършвайки с „всички останали“ на платформата Telegram
в моя свят.
А след това, след като изкех,
чиновникът бързо и нагласно добави:
но аз ще внеса ред (тук в IT)“
(…).

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

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

Разгръщане на 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) Неуспешно свързване с локалния порт 2398: Връзката беше отказана»

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

Можем да се заемем с нещата за червеногледите: да проверим

$ netstat -an | grep 2398 и...

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

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

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

"Ние блокирахме част от публичните проксита на нашите сървъри, използвайки базите на проекта firehol. Този проект следи списъците с публични проксита и създава бази с тях.
От този момент (тоест почти два дни) не е бил блокиран нито един IP адрес на нашия руски прокси.
3. Показваме как да направите почти неуязвим прокси за Роскомнадзор и споделяме скрипт за блокиране на публични проксита.
- Обновете docker контейнера (или демона) MTProto proxy до последната версия: РКН изчислява старите версии по порта на статистиката, който е бил свързан на 0.0.0.0 и ясно се идентифицирал за целия интернет. А още по-добре — отворете нужните портове с iptables, а останалите — затворете (помнете, че в случая с docker контейнера следва да се използва правилото FORWARD).
- Роскомнадзор отдавна е научил как да следи трафика: те виждат заявките вътре в HTTP и SOCKS5 проксита, а също така виждат старата версия на обфускацията MTProto proxy.
Когато клиентите на някои доставчици, при които са инсталирани такива следящи устройства, правят заявки към Telegram чрез такива проксита, РКН вижда тези заявки и веднага блокира тези проксита. Същото важи и за MTProto proxy със стара обфускация.
Решение: раздавайте на клиентите, които се свързват с проксито, secret само с dd в началото (не е нужно да посочвате допълнителните букви dd в настройките на самия mtproto proxy). Това ще включи версия на обфускацията, която не могат да идентифицират следящите устройства.
И никакви 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 от нея), създаваме alias:

$ 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) Стартиран със статистика docker-образ или без нея, два клиента да се разпускат или десет — ресурсите се утилизирани ~еднакво: 75% от цялата производителност на CPU t2.micro.

2) Гледаме мониторинга на VPC-сервера:

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

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

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

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

Изводи

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

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

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

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