Пару статей назад я устал возиться с кучей VPN и поставил Xray на роутер. Дома проблема закрылась: все устройства сами ходят куда надо — локальные и российские сервисы напрямую (без лишнего крюка и потери скорости), остальное через мой собственный сервер, реклама режется на лету. Красота.

А потом я поехал. И выяснилось, что весь этот уют остаётся дома.

В отеле — чужой Wi-Fi, которому я не доверяю ни на грамм. Симка в роуминге даёт IP, от которого у банка дёргается глаз, и он на всякий случай просит «подтвердить вход» третий раз за день. Хочется то полностью в туннель, то наоборот напрямую — чтобы пройти captive-портал в аэропорту. Таскать с собой ноутбук ради ssh в роутер — так себе развлечение в очереди на посадку.

Мне нужен был карманный роутер, у которого режимы переключаются пальцем, без веб-морды и SSH. Я взял GL.iNet Mudi 7 (GL-E5800) — и, забегая вперёд, довёл его до состояния «достал из кармана, ткнул нужный профиль на экране, поехал». Семь профилей-тумблеров, сквозной kill switch и даже выход через домашний IP без белого IP дома.

Но сначала — обзор самого железа, потому что на Хабре я его не нашёл, а зверь любопытный.

От HAProxy до VLESS+Reality: все грабли одного MTProto-прокси

Если вы когда-нибудь поднимали свой MTProto-прокси для Telegram и он у вас "работает, но как-то не очень" — эта статья для вас. Я прошёл путь от "просто добавить relay" до "переписать всю цепочку на VLESS+Reality с нуля", и по дороге собрал приличную коллекцию граблей. Расскажу всё по порядку, чтобы вам не пришлось наступать на те же.

Исходная ситуация

Была задача простая на первый взгляд: поднять MTProto проксю для Telegram на сервере в РФ. Причина стандартная — хочется, чтобы телега работала

Взял mtg (ghcr.io/9seconds/mtg:2 — отличная реализация MTProto-прокси с поддержкой fake-TLS), поднял на сервере — и оно не работает. Точнее, работает, но еле-еле: то подключается, то нет, на мобильном интернете почти всегда фейл.

Первая мысль, которая приходит в голову почти всем в такой ситуации: "провайдер блокирует адреса Telegram". И это отчасти правда — но, как выяснилось, правда не вся.

Первая попытка: спрятать Telegram за релеем

Логика была такая: раз провайдер режет соединения именно к IP Telegram, то уберу эти IP из виду. Арендую второй сервер за границей, туда ставлю настоящий mtg, а на RU-сервере — просто TCP-релей (HAProxy или голый iptables DNAT), который прозрачно перекидывает байты дальше.

Клиент → RU-сервер (HAProxy, чистый TCP passthrough) → Зарубежный сервер (mtg) → Telegram

Казалось бы, логично: сервер в РФ теперь физически ничего не знает про Telegram, он просто гоняет байты во внешний IP. Провайдер не должен видеть ничего подозрительного.

Многие сервисы сегодня выдают клиенту не один конкретный конфиг для подключения, а VLESS/Trojan-подписку — ссылку, за которой стоит целый пул из десятков серверных конфигураций сразу. Провайдеру это удобно (не нужно вручную вести отдельный конфиг под каждого клиента), но у пользователя тут же встаёт главная практическая проблема: подключить роутер именно через такую подписку так, чтобы соединение работало стабильно. Один конкретный сервер из пула сегодня быстрый, завтра перегружен, послезавтра вообще не отвечает — а подписка в целом при этом продолжает исправно работать, просто нужно каждый раз заново находить, какой именно из десятков серверов сейчас реально живой.

Решает это балансировщик — механизм, который сам, постоянно, в фоне проверяет каждый сервер пула подписки и автоматически выбирает самый быстрый живой, без участия человека.

Об этом и статья: что такое точечная (доменная) маршрутизация на роутере, зачем нужна автоматическая балансировка между серверами одной VLESS/Trojan-подписки, и как это устроено в нашем универсальном проекте SmartRoute — для роутеров на OpenWrt и KeenticOS (через xkeen), который умеет и то, и другое из коробки.