Белые списки: почему блокируют VLESS сервер в Москве и диагностика

Поведение похоже на действие операторских белых списков или DPI‑фильтрации: вне МКАД мобильный трафик попадает на другой маршрут/CGNAT и пакеты к «неразрешённым» IP/портам (ваш VLESS на Мск/НЛ) просто дропаются или блокируются по SNI/TLS, поэтому VLESS с фейковым SNI (ozon.ru) даёт тайм‑аут. Быстрая диагностика — сравнить traceroute/mtr и DNS на Wi‑Fi и на мобильной сети, запустить tcpdump на сервере и попытки с openssl s_client / curl с указанием SNI; по совпадению результатов станет понятно — IP/CIDR‑блок или SNI/DPI. Ниже — последовательные шаги, команды и интерпретация выводов, а также практические варианты, что пробовать дальше (VLESS vs WireGuard, смена SNI/портов, CDN/fronting и т.д.).

Содержание

• Почему белые списки и CIDR блокируют сервер в Москве
• Как отличить фильтрацию по SNI/TLS от блокировки по IP/портам
• Менять ли VLESS на WireGuard, менять SNI или порты — практические варианты
• Пошаговая диагностика — команды и что смотреть в выводе
• Особенности операторов за МКАД и чек‑лист быстрых проверок
• Источники
• Заключение

Почему белые списки и CIDR блокируют сервер в Москве

Операторы мобильной сети часто реализуют «белые списки» на нескольких уровнях: DNS‑редирект, фильтрация IP/CIDR на уровне ядра и DPI (анализ TLS/SNI). В условиях ограничений оператор может разрешать только набор IP/сервисов (гос‑сервисы, банки, крупные сервисы), а трафик к прочим адресам просто не маршрутизируется или «гасится» на CGNAT/пограничном узле (в ряде разборов это проявляется как редирект/тайм‑аут и встречается адрес 198.18.9.129 в качестве «черной дыры» у некоторых провайдеров) — см. разборы на Хабре и в обзорах про белый список мобильного интернета https://habr.com/ru/articles/963492/ и https://ichip.ru/sovety/ekspluataciya/belyj-spisok-mobilnogo-interneta-935522.

Почему это может давать описанную картину:

• Внутри МКАД у вас один маршрут/этаж сети с «мягче» правилами — соединения проходят.
• За МКАД трафик отдаётся другому узлу/роумингу/маршруту, где вкл. жёсткий whitelist по CIDR/AS/портам — итог: TCP SYN не доходит до сервера → тайм‑аут.
• Если вы подставляли SNI ozon.ru, но серверный IP не совпадает с реальными IP Ozon, то оператор может блокировать по несоответствию SNI→IP (т.е. SNI позволят только при реальном сопадении домена и сертификата/маршрута).

Подробнее о том, как устроена блокировка SNI/DPI — см. обзор про фильтрацию HTTPS/SNI https://vasexperts.ru/blog/roskomnadzor/filtracziya-url-v-ramkah-zakona/.

Как отличить фильтрацию по SNI/TLS от блокировки по IP/портам/маршрутизации

Краткая логика проверки (в порядке простоты): маршрут → пакетный след → TLS‑handshake. Вот набор тестов и что они означают.

1. Traceroute / mtr (маршрут)

• Команда (Linux/macOS):

traceroute -n <SERVER_IP>
traceroute -T -p 443 -n <SERVER_IP> # TCP traceroute на 443
mtr --tcp -P 443 -n <SERVER_IP>

• Интерпретация:
• Трасса доходит до вашего сервера (последний хоп — ваш IP) — маршрут есть. Значит, проблема не в базовой маршрутизации/CIDR (по крайней мере в одну сторону).
• Трасса обрывается на узле оператора или на адресе вроде 198.18.9.129 — классическая картина IP/CIDR‑блока (см. https://habr.com/ru/articles/963492/).

2. Проверка на уровне TCP/SYN и пакетный захват (сервер)

• На сервере включите захват входящих попыток соединения (если вы не знаете IP клиента — фильтруйте по порту/ценой):

sudo tcpdump -ni any 'dst host <SERVER_IP> and dst port 443' -w /tmp/conn.pcap
# или быстрый TLS‑фильтр:
sudo tcpdump -ni eth0 "(tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)" -s 0 -A

(подробнее о tcpdump‑фильтрах и расшифровке ClientHello/SNI — https://wiki.merionet.ru/articles/zaxvat-paketov-s-tcpdump-rukovodstvo-s-primerami)

• Интерпретация:
• НЕТ входящих SYN от мобильного клиента при попытке соединения → upstream‑блокировка по IP/CIDR/маршруту.
• Входящий SYN есть, но сервер не получает ClientHello (или видно, что TCP дошёл, но payload обрублен) → возможна активная манипуляция/инспекция в сети (Middlebox), либо возврат RST/ICMP со стороны провайдера.
• ClientHello виден и содержит SNI = ozon.ru → SNI отправляется; дальше см. TLS‑проверки.

3. TLS / SNI проверка с клиента (curl / openssl)

• На клиенте (или ноуте, подключенном к мобильной точке) выполните:

# Пробуем установить TLS к IP, но с SNI нужного хоста:
openssl s_client -connect <SERVER_IP>:443 -servername ozon.ru -tlsextdebug -msg
# Быстрый HTTP тест (Host + SNI к IP):
curl -v --connect-timeout 8 --resolve ozon.ru:443:<SERVER_IP> https://ozon.ru/

(справочник по openssl s_client: https://www.howtouselinux.com/post/openssl-s_client-command-examples)

• Интерпретация:
• Соединение тайм‑аутится / не устанавливается → скорее IP/порт/маршрут блокированы.
• TLS Handshake проходит и вы видите сертификат — значит SNI/TLS прошли; если VLESS всё равно не поднимается, скорее DPI распознаёт VLESS‑паттерн уже внутри TLS.
• Handshake проходит, но вы получаете сертификат не для ozon.ru (например, ваш самоподписанный) — оператор может сопоставлять SNI и сертификат и блокировать несоответствие.

Резюмируя: если traceroute и tcpdump показывают, что пакеты просто не доходят — это IP/CIDR/маршрутизация. Если пакеты доходят и TLS Handshake тоже, но соединение разрывается на приложении — это либо обнаружение VLESS по паттерну, либо неправильная комбинация SNI/сертификат.

Стоит ли менять VLESS на WireGuard или пробовать обфускацию/смену SNI/портов? Какие варианты работают против «белых списков»

Короткий ответ: менять протокол бессмысленно до диагностики. Почему:

• Если блокировка на уровне IP/CIDR (пакеты не доходят) — любой протокол (VLESS, WireGuard, OpenVPN) с тем же IP/портом упёрется в ту же стену. Решение — изменить точку выхода (IP), то есть хостинг/CDN/узел, попадающий в разрешённый диапазон.
• Если фильтрация по SNI/TLS (DPI) — VLESS поверх TLS с фейковым SNI может детектироваться по нетипичному ClientHello/после‑TLS паттерну; в этом случае полезна обфускация TLS (мимикрия под браузер), WebSocket/HTTP2 transport или frontend через легитимный CDN/обёртку, которая даёт «реальный» SNI+сертификат. Хабровская статья подробно описывает механизм VLESS + SNI/обфускацию https://habr.com/ru/articles/963022/.
• WireGuard (UDP) не использует SNI — это может быть плюсом при DPI по SNI, но UDP чаще блокируют либо порт/диапазон, либо оператор не пропускает UDP через CGNAT/роуминговые узлы; следовательно WireGuard поможет не всегда.

Практические рекомендации:

• Сначала определите тип блокировки по шагам выше.
• Если IP‑блок: перенести точку входа на IP/хост, который оператор не блокирует (локальный российский хост или CDN с POP в России), либо использовать легитимный фронтенд (reverse proxy на разрешённом домене).
• Если SNI/DPI: попробовать TLS‑обфускацию (VLESS+ws+TLS, HTTP/2 mimic, корректный TLS fingerprint), но понимайте — операторы уже научились ловить такие схемы (см. обсуждение блокировок VLESS/SNI на Flowseal/GitHub) https://github.com/Flowseal/zapret-discord-youtube/issues/5819.

Ниже — конкретные шаги, что пробовать после диагностики.

Пошаговая диагностика — команды и что искать в их выводе

Ниже — набор команд для клиента и сервера. Совет: подключите телефон как Wi‑Fi‑точку и выполняйте команды с ноутбука, чтобы удобно запускать traceroute/openssl/tcpdump.

A) Быстрые сравнения (Wi‑Fi vs мобильная сеть)

# На клиенте (через Wi‑Fi):
dig +short ozon.ru
dig +short your.server.domain

# Переключитесь на мобильный интернет (точка доступа) и повторите:
dig +short ozon.ru
dig +short your.server.domain

Что смотреть: различается ли разрешение DNS; появились ли «локальные» IP у ozon.ru или возвращается неизвестный IP/ошибка — возможно DNS‑манипуляции.

B) Traceroute / mtr

traceroute -T -p 443 -n <SERVER_IP>
mtr --tcp -P 443 -n <SERVER_IP>

Ищите: обрыв маршрута на узле оператора (серия * * *) или hop с адресом вроде 198.18.9.129 → признак сетевого/CGNAT‑блока.

C) Проверка TCP/SYN на сервере (на сервере)

# Захватим любые попытки на 443:
sudo tcpdump -ni any 'dst host <SERVER_IP> and dst port 443' -vv -w /tmp/conn.pcap
# TLS‑фильтр в читаемом виде:
sudo tcpdump -ni eth0 "(tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)" -s 0 -A

Ищите: приходят ли SYN/ClientHello от мобильного IP. Если нет — IP/CIDR‑блок. Если да — смотрите содержимое ClientHello (SNI).

D) SNI / TLS handshake (с клиента)

openssl s_client -connect <SERVER_IP>:443 -servername ozon.ru -tlsextdebug -msg
curl -v --connect-timeout 8 --resolve ozon.ru:443:<SERVER_IP> https://ozon.ru/

Интерпретация:

• connect: Connection timed out → пакет не дошёл (IP/маршрут).
• TLS handshake виден, сертификат приходит → SNI/ TLS прошли, дальше смотреть приложение (VLESS).
• Handshake завершается, но сертификат не соответствует ozon.ru → оператор может детектировать несоответствия SNI→сертификат.

E) Проверка AS/WHOIS (узнать, не попадает ли IP в «странный» AS)

whois <SERVER_IP>
# или
curl -s https://ipinfo.io/<SERVER_IP>/org

Ищите: принадлежность IP (хостер в Нидерландах или «черный» диапазон). Если ваш сервер меняет AS/провайдера внутри роуминга — это важно для решений.

F) Дополнительно — симулировать браузерный ClientHello
(если хотите проверить, пропускают ли «браузерный» TLS): используйте инструмент, который умеет имитировать browser TLS fingerprint (например, curl с http2 и default UserAgent), или настройте VLESS/XTLS с browser‑like ALPN/ClientHello. Здесь полезна документация по SNI и TLS‑handshake https://www.ssldragon.com/ru/blog/server-name-indication/ и практики VLESS‑обфускации https://habr.com/ru/articles/963022/.

G) Что фиксировать и присылать для анализа

• Вывод traceroute (Wi‑Fi vs мобильный).
• Логи tcpdump (пару пакетов) с отметкой времени попыток.
• Вывод openssl s_client (ошибка тайм‑аута или сертификат).
  Эти файлы позволяют точно сказать: «IP не доходит» или «TLS проходит, но VLESS БД».

Особенности операторов за МКАД и чек‑лист первых настроек

Что учитывать и что перепроверить сначала:

• APN и режим роуминга: при переходе за МКАД телефон иногда переходит в другой профиль/маршрут оператора (домашний/региональный роуминг) с иными правилами фильтрации. Проверьте APN, профиль оператора и остаточные настройки (две сим, VPN/профили).
• IP‑адрес клиента: сравните public IP внутри и вне МКАД (curl ifconfig.me или сайт‑сервис). Разные IP → разные NAT/CGNAT и разные правила.
• Сертификаты и SNI на сервере: убедитесь, что TLS‑сертификат корректен, VLESS настроен на прослушивание 0.0.0.0 и порт 443, и что нет привязки по сети/iface.
• Firewall/iptables на сервере: ss -tnlp | grep 443 и sudo iptables -L -n — проверьте, что сервер принимает соединения со всех IP.
• Логи сервера VLESS/Xray: включите детальный лог и смотрите, приходят ли попытки подключения; если нет — upstream блок.
• Если хотите быстро попробовать обходные варианты (после диагностики): тестируйте сервер с публичным IP, который реально попадает в «белый список» (например, крупный CDN), либо разверните легитимный фронтенд (reverse proxy) с настоящим сертификатом и посмотрите, пройдёт ли SNI+TLS.

Известные материалы по тому, как устроены белые списки и фильтрация SNI: https://ichip.ru/sovety/ekspluataciya/belyj-spisok-mobilnogo-interneta-935522, https://habr.com/ru/articles/963492/ и обзор возможностей DPI по HTTPS/SNI https://vasexperts.ru/blog/roskomnadzor/filtracziya-url-v-ramkah-zakona/.

Источники

1. Обход белых списков через VLESS и SNI: Как работает технология — Buzz VPN
2. Реальность в белоснежных списках — Хабр
3. Протокол VLESS: Как он обходит цензуру в России и почему это работает — Хабр
4. Что такое SNI (индикация имени сервера)? — SSL Dragon
5. 10 Useful Examples of Openssl s_client Command — HowToUseLinux
6. Захват пакетов с tcpdump: руководство с примерами — Merionet Wiki
7. Как выполнить трассировку: подробное руководство — АдминВПС
8. Белый список мобильного интернета: как работает у операторов — iChip
9. DPI и фильтрация URL/HTTPS — VasExperts
10. Обсуждение блокировок VLESS/SNI — Flowseal / GitHub issue

Заключение

Коротко: скорее всего вы столкнулись с операторским белым списком / CIDR‑фильтрацией или с DPI по SNI — отличие выясняется простыми тестами: traceroute/mtr + tcpdump на сервере + openssl/curl с SNI. Если пакеты не доходят — менять только протокол бесполезно, нужно менять точку выхода (IP/хост, попадающий в разрешённый диапазон). Если TLS/SNI проходит, а VLESS всё равно падает — пробуйте обфускацию TLS/микси под браузерный трафик или фронтенд через легитимный прокси/CDN; но учтите, что операторы постепенно ищут и блокируют такие обходы. Начните с трассировки и tcpdump: пришлите выводы — помогу интерпретировать результаты и предложу целевой план обхода/переноса сервера.