Я решил погрузиться в мир собственных VPN серверов, после того как очередной раз сервис, за который я платил деньги перестал качественно работать, а поддержка из-за перегруженности отвечала шаблонами, в духе "Надо подождать, мы скоро все починим".
Набрав в поиске "VDS в Германии аренда" я с удивлением обнаружил, что арендовать такой сервер можно с российской карты и за вполне вменяемые деньги. Арендовав сервер на неделю, я принялся поднимать собственный MTProto для телеги. Использовал я образ https://github.com/telemt/telemt
Я поднял свой контейнер с прокси, проверил, что все работает и обрадовался. Но сразу же встал следующий вопрос - CLI это хорошо, но хотелось бы какой-то GUI для управления прокси. Я перепробовал несколько панелей и остановился на https://github.com/MaksimTMB/mtg-adminpanel. её суть в том, что панель можно установить на любой сервер или вообще локально, а на сервер, где будет развернут прокси ставится агент, который будет выполнять команды панели. Такое решение мне понравилось, так как в будущем можно будет расширить сеть до нескольких узлов, во избежание тотальной блокировки.
Я раздал несколько ссылок на прокси своим друзьям и коллегам. Суммарно 3 ссылками пользовалось 15-20 человек. Но вернувшись к проекту после выходных я обнаружил, что с офисного wifi прокси работать перестали, спросив у других пользователей, оказалось что у кого-то они не работали дома, а у кого-то по мобильной сети. Явно ТСПУ у каких-то провайдеров определил мои прокси и внес в черные списки.
Для меня это стало неожиданностью, так как на это понадобилось меньше 4х дней. Но дальше хуже - при создании нового прокси через панель он сразу же не работал. Я решил, что мой ip сервера уже в черном списке полностью, но в этот момент, я замечаю, что из трех прокси в телеграм работает один. Тот самый, который я поднимал вручную в докер контейнере. До меня дошло, что панель создает прокси с каким-то паттерном, который легко распознался.
Недолго покопавшись в коде панели, я нашел, что все прокси создавались с одним SNI - google.com. Из-за чего распознать мое соединение, скорее всего и получилось. Так как я не нашел как сменить SNI в панели, я решил что могу создать аналогичную панель сам, добавив в нее нужные мне функции. Мое решение так же разделено на 2 части - панель и сервис-нода.
Так же я решил, что проблема может быть в нестандартном порте - прокси были на портах 4443-4447. В моей панели прокси запускаются всегда на 443 порту, а уже дальше nginx разводит соединения по разным контейнерам. Но тут появилось ограничение - обычно несколько прокси на одном сервере разделяются по портам. А как разделить их если порт и ip один и тот же. Выход нашелся - роутинг по SNI.
user nginx; worker_processes auto; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 4096; } stream { resolver 127.0.0.11 valid=10s; log_format proxy '$remote_addr [$time_local] $ssl_preread_server_name $status'; access_log /dev/stdout proxy; map $ssl_preread_server_name $backend { en.wikipedia.org mtproto-proxy-3d9d46ba:443; netflix.com mtproto-proxy-475ecb29:443; assets.msn.com mtproto-proxy-3f8875a4:443; default mtproto-proxy-3d9d46ba:443; } server { listen 443; proxy_pass $backend; ssl_preread on; proxy_connect_timeout 10s; proxy_timeout 300s; } }
Как видно на примере, nginx смотрит каким доменом прикрывается соединение и направляет его к нужному контейнеру. У этого подхода есть ограничение - для одного соединения нужно использовать один уникальный домен. Я завел пул доменов, которые вытягиваются случайным образом при создании нового прокси.
На данный момент все прокси (3) которые я создал живут уже больше недели, хотя суммарное количество устройств которые подключались к ним больше 50.
Я буду продолжать развитие панели по мере своих сил и потребностей. Этой статьей я хотел поделиться своими результатами и получить обратную связь от тех, кто делал что-то подобное.
Ссылка на репу