Привет! 👋 После прошлого поста несколько человек решили попробовать развернуть MTProto на mtg. И почти сразу появился интересный кейс с траблшутингом, которым хочу поделиться. ✅ Сервис был поднят, systemd показывал active (running), порт слушался, ufw его пропускал 〰️ но Telegram упорно висел на соединение…. 😔 Сначала казалось, что проблема в сервере или файерволле. 🔵 Проверил базово systemctl status mtg ss -lntp journalctl -u mtg ufw status verbose 🔵 Выяснилось mtg живой, порт открыт, процесс слушает сокет, сервер ходит наружу. То есть это уже не история про сервис не стартует. ✅ FakeTLS и домен Дальше начал проверять FakeTLS-secret и домен внутри него. Напомню, как это работает, в режиме FakeTLS Telegram делает вид, что идёт обычный HTTPS-трафик к какому-то домену. Для DPI это выглядит как TLS-соединение с SNI этого домена. ❗️ Поэтому просто вписать любой домен 〰️ плохая идея❗️ По рекомендациям автора mtg сейчас лучший вариант 〰️ свой домен, который реально указывает на IP прокси. Тогда 🔵 SNI совпадает с доменом 🔵 DNS указывает на тот же сервер 🔵 IP реально связан с этим доменом Для сети всё выглядит правдоподобно. Тут же было так 🔵 домен доступный.хостер выглядел подозрительно 🔵 домен домен.ру не совпадал с IP сервера ✔️ с доменом подходящий.домен прокси в итоге заработал Ориентировался на 🔵 README mtg 🔵 BEST_PRACTICES mtg 🔵 russia-mobile-internet-whitelist ❓ Как же лучше подобрать домен❓ Для поиска домена для FakeTLS полезен проект RealiTLScanner Он проверяет реальные TLS-серверы и показывает 🔵 CERT_DOMAIN 🔵 CERT_ISSUER 🔵 TLS-версию 🔵 ALPN 🔵 IP и гео Это помогает выбрать домен, у которого TLS-профиль выглядит естественно для конкретного IP. Почему это важно 🔵 SNI, DNS, сертификат и IP должны совпадать 🔵 если домен выглядит чужеродно 〰️ DPI может заметить несоответствие 👻 ✅ Запуск простой wget https://github.com/XTLS/RealiTLScanner/releases/download/v0.2.1/RealiTLScanner-linux-64 chmod +x RealiTLScanner-linux-64 ./RealiTLScanner-linux-64 --addr X.X.X.X # IP сервера ⚠️ Стоит быть аккуратным, так как активное сканирование внутри сети VPS может вызвать вопросы. ✅ Домен оказался не единственной проблемой Я ещё долго смотрел на секрет В mtg можно использовать два представления 🔵 hex 🔵 base64url И вот это оказался ключевой момент❗️ В моём случае Telegram-клиент заработал только с обычным base64 секретом, а с hex зависал на подключении. На сервере это выглядело так 🔵 порт открыт 🔵 трафик приходит 🔵 клиент не коннектится ✅ Как проверял трафик Чтобы понять, доходит ли подключение до сервера, поставил tcpdump apt-get update && apt-get install -y tcpdump 👀 И посмотрел трафик на порт прокси. Это сразу дало ответ, пакеты от клиента доходят до сервера. Значит проблема не в ufw, не в маршруте и не в закрытом порте. ✅ Дебаг mtg После этого запустил mtg в debug и увидел cannot read client hello incorrect client random Это означает, что клиент присылает не тот FakeTLS-handshake, который ожидает сервер. То есть соединение доходит, но рукопожатие невалидно для данного секрета. ✅ Что помогло в итоге По пути ещё 🔵 временно переводил прокси на 443 🔵 проверял prefer-ipv4 🔵 поправил systemd (mtg иногда зависал на рестарте) Но, если Telegram не подключается к mtg 1️⃣ Не начинайте с мысли это только firewall 2️⃣ Проверьте systemd, сокет и ufw 3️⃣ Убедитесь через tcpdump, что трафик доходит 4️⃣ Посмотрите debug-логи mtg 5️⃣ Не используйте случайный домен в FakeTLS 6️⃣ Лучше использовать домен, который реально указывает на IP прокси 7️⃣ Проверьте оба формата секрета 8️⃣ Обновите Telegram. Устаревшая версия не сможет работать корректно с mtg. В моём случае прокси заработал с подходящий.домен и обычным секретом Иногда прокси не работает не потому, что сломался сервер. А потому что сеть видит то, что мы пытаемся от неё скрыть. 😏 В следующий раз расскажу 🔵 про то как траблшутил с tcpdump 🔵 почему КВН и MTProto работая на одном сервере или разных, КВН ломает работу MTProto. Причина почти всегда связана с маршрутизаци