Что происходит с VPN на МТС под блокировками
При локальных отключениях мобильного интернета и точечных ограничениях МТС не всегда «глушит» сеть полностью. Часто оператор переводит мобильный интернет в режим белого списка: наружу проходят только whitelisted-ресурсы — часть CDN, госсайты, отдельные сервисы. Всё остальное, включая VPN, который идёт напрямую на ваш сервер, просто не устанавливает соединение.
Для оператора VPN-сервиса это выглядит так: клиент подключается к ноде по её IP или домену, но пакеты до дата-центра не доходят — handshake не завершается, туннель не поднимается. Проблема не в конфиге и не в протоколе как таковом, а в том, что адрес ноды не входит в белый список сети. Значит, задача не «пробить» блокировку, а сделать вход в сервис неотличимым от обращения к разрешённому ресурсу.
МТС белый список: почему всё решает подсеть /24
Ключевой момент про мтс белый список: он привязан не к конкретным доменам, а к подсетям — как правило, к блокам /24. Если IP вашего входа лежит в подсети, которую сеть считает «белой», трафик проходит; если нет — не проходит. Отсюда прямое следствие для выбора хостинга под ноду или CDN-edge.
| Хостер | Статус в белом списке (по наблюдениям) |
|---|---|
| Selectel | подсети часто whitelisted |
| cloud.ru / SberCloud | часто НЕ попадают в белый список |
| ранее рабочие блоки (напр. часть Yandex) | могут отвалиться со временем |
Важно: статус меняется, гарантий нет, проверять нужно каждую /24 отдельно, а не «хостера вообще». Перед запуском тестируйте конкретный блок из реальной сети МТС в зоне ограничений — то, что работает у одного адреса, может не работать у соседнего. Это не разовая проверка, а регламент.
Транспорт под троттлингом: XHTTP через CDN
В режиме белого списка и под троттлингом важен и сам транспорт. Практика такая: Reality и Hysteria2 напрямую обычно НЕ проходят — edge их не пропускает. Рабочий подход — спрятать вход за whitelisted CDN-edge (например, Yandex CDN) и гонять XHTTP (mode packet-up) через CDN: оператор видит обращение к «белому» CDN, а CDN проксирует запрос на вашу ноду.
Есть неочевидный, но критичный нюанс XHTTP через CDN. Uplink-данные должны идти в теле запроса (uplinkDataPlacement: "body"), а не в кастомном заголовке вроде X-Payload. CDN-edge не доносит произвольные заголовки до origin, поэтому при uplink «в заголовке» туннель рвётся с ошибкой unexpected EOF. Session/seq-идентификаторы кладите в cookie, padding — в query-строку. Пропустив это, вы получите настроенный «по инструкции» туннель, который всё равно не работает через CDN.
Настройка ноды за CDN
За CDN нода держит обычный XHTTP-инбаунд (например, на порту 25454), а CDN-поддомен выступает фронтом. Подходят распространённые панели — Remnawave, 3x-ui, Marzban, Hiddify. Главное правило: параметры на клиенте и на ноде должны совпадать точь-в-точь. В клиентском конфиге CDN-поддомен указывается как Address / SNI / Host; path и extra на клиенте и на ноде обязаны совпадать посимвольно, иначе туннель не поднимется.
Origin (ноду) обязательно защитите: файрволом разрешите входящие только с IP gateway/CDN, а сам origin прикройте секрет-заголовком X-Cdn-Auth, чтобы сервер не отвечал на прямые обращения мимо CDN. Пошаговая последовательность — в блоке howto ниже.
Себестоимость трафика и учёт в панели
Экономику считать нужно отдельно, потому что XHTTP плодит много мелких запросов, а CDN тарифицирует не только гигабайты, но и запросы.
| Показатель | Оценка |
|---|---|
| Сырой трафик CDN | зависит от провайдера |
| С учётом платы за запросы на масштабе | зависит от провайдера |
Снизить стоимость помогает укрупнение запросов: крупные POST-ы в body уменьшают число обращений и, соответственно, кост. По учёту внутри сервиса используйте механизмы панели: множитель потребления ноды и per-user лимиты (в Remnawave это штатно). Множитель 0 на конкретной ноде удобен, когда её трафик не должен списываться с лимита пользователя, при этом нода продолжает работать.
Чего whitelist-CDN не решает
Не путайте две разные задачи. Whitelist-CDN решает устойчивость входа под троттлингом и в режиме белого списка. Он НЕ разблокирует стриминг: сервисы вроде Кинопоиска банят дата-центровые IP по репутации, и для российского контента нужен резидентный IP. Whitelist-CDN этого не даёт — это отдельная история. Если клиенты жалуются именно на стриминг, а не на «интернет вообще не работает», причина другая, и CDN-входом она не лечится.
Строить whitelisted-вход можно самому на Yandex CDN или брать его как сервис. Например, Clearway (clear-way.pro) даёт операторам готовый whitelisted CDN-edge (*.whitechannel-x1-cdn.ru) перед их нодами, без продажи серверов — проверку подсетей и совместимость с XHTTP это снимает с вашей команды. Что выбрать — вопрос объёма трафика и того, готовы ли вы держать собственный CDN-слой.