Чтобы понять, почему один и тот же сервис на мобильном интернете работает у одних пользователей и не работает у других, полезно представить себе путь пакета от телефона до сервера в интернете. Это десяток узлов, на каждом из которых происходит маршрутизация, тарификация, логирование и — в случае РФ 2026 года — whitelist-фильтрация. Этот материал — технический обзор инфраструктуры мобильных операторов и того, как именно реализована двухслойная фильтрация трафика.
Сразу оговоримся: ничего из описанного ниже не является инструкцией. Это образовательный материал для тех, кто хочет понять, как устроена мобильная сеть в современной России. Он дополняет наш обзорный материал «Что такое белые списки в интернете РФ в 2026».
Архитектура мобильной сети LTE/5G
Когда вы открываете браузер на телефоне и вводите домен, ваш запрос проходит примерно такой путь:
- UE (User Equipment) — ваш телефон. Формирует IP-пакет и отправляет его через радиоинтерфейс.
- eNodeB (LTE) / gNodeB (5G) — базовая станция. Это «вышка», которая обслуживает данную ячейку. Принимает радиосигнал, преобразует его в IP-пакеты, отправляет дальше.
- S-GW (Serving Gateway) — обслуживающий шлюз. Маршрутизирует пакеты внутри сети оператора, отслеживает, к какой соте подключён абонент, и обеспечивает плавный handover при перемещении.
- P-GW (Packet Gateway) — пакетный шлюз. Это ключевой узел, через который весь мобильный интернет-трафик уходит во внешний мир. Именно здесь применяются политики QoS, тарификация, NAT и — в РФ — whitelist-фильтрация.
- MME (Mobility Management Entity) — управляет сессиями и аутентификацией. К пакетному трафику прямого отношения не имеет, но участвует в установлении соединения.
- Internet — после P-GW пакет попадает в магистральную сеть оператора и далее в публичный интернет через пиринги, IXP и upstream-провайдеров.
В 5G некоторые элементы переименованы (UPF вместо P-GW, AMF/SMF вместо MME), но логика остаётся той же: P-GW (или UPF в 5G) — точка, где пакетная сеть оператора соединяется с интернетом, и именно там применяется whitelist.
Как именно работает whitelist на P-GW
Whitelist в РФ 2026 года реализован как двухслойная политика. Когда пакет приходит на P-GW:
Слой 1: IP/CIDR-фильтрация
P-GW проверяет destination IP пакета по списку разрешённых подсетей (CIDR-блоков). Это самая быстрая операция — простое сопоставление по таблице маршрутизации. Если IP не входит ни в один whitelist-CIDR, пакет дропается на этом этапе.
Whitelist-CIDR хранится в специальной структуре (LPM — Longest Prefix Match), которая позволяет за O(1) или O(log n) проверять, входит ли IP в любой из тысяч разрешённых блоков. На современном P-GW это занимает менее 100 наносекунд на пакет.
Слой 2: SNI inspection
Если IP в whitelist, P-GW дополнительно смотрит на содержимое первого пакета TLS-handshake (TLS ClientHello). В нём в открытом виде передаётся SNI (Server Name Indication) — имя сервера, к которому идёт подключение. Например, yandex.ru, vk.com, sberbank.ru.
P-GW сравнивает SNI с whitelist-доменами. Если SNI присутствует в реестре — соединение разрешается, и дальше P-GW не лезет в содержимое (TLS-канал зашифрован). Если SNI отсутствует — пакет дропается, или TCP-соединение принудительно сбрасывается RST-пакетом.
Эта двухслойность принципиальна: SNI-инспекция нужна, чтобы избежать «слишком широкого» whitelist по IP. На одном IP в Yandex Cloud может работать сотня разных сервисов — некоторые в whitelist, другие нет. SNI позволяет различать их.
Что такое SNI и почему он виден
SNI — это поле в TLS ClientHello, расширение, которое клиент использует, чтобы сообщить серверу, к какому конкретному сайту он хочет подключиться (потому что на одном IP может хоститься множество HTTPS-сайтов с разными сертификатами).
До массового внедрения ECH (Encrypted Client Hello) SNI передаётся в открытом виде, в plaintext. Любой узел между клиентом и сервером — провайдер, оператор, прокси — может его прочитать. Это стандартное поведение TLS 1.2 и TLS 1.3, не баг и не уязвимость.
SNI был введён в стандарт TLS в 2003 году именно как способ для CDN и hosting-провайдеров обслуживать несколько сайтов на одном IP. Анонимизация SNI не была частью замысла — это поздняя задача, которую сейчас решают через ECH.
ECH (Encrypted Client Hello) в РФ
ECH — это расширение TLS 1.3, описанное в черновиках IETF (на 2026 год — draft-ietf-tls-esni-23 и далее). Идея: SNI шифруется ключом, который сервер заранее опубликовал в DNS (через HTTPS RR — DNS-запись типа HTTPS).
Состояние ECH на начало 2026 года:
- Cloudflare поддерживает ECH на серверной стороне с 2023 года.
- Firefox — поддерживает с 2023 года, по умолчанию выключен.
- Chrome / Chromium — поддержка через флаг (--enable-features=EncryptedClientHello).
- Российские серверы (Яндекс, VK, Mail.ru, банки) — ECH не используют. Это сознательное решение: при whitelist-фильтрации на P-GW открытый SNI помогает, а не мешает легитимным пользователям.
Если бы российские whitelisted-сервисы внезапно включили ECH, операторы потеряли бы возможность фильтрации по SNI на этих доменах — и whitelist пришлось бы строить только по IP, что менее точно. Поэтому сложилось своеобразное равновесие.
QUIC и UDP в whitelist-режиме
Современный веб всё активнее использует QUIC — транспортный протокол поверх UDP, на котором работает HTTP/3. У QUIC своя инспекция:
- QUIC Initial Packet — первый пакет handshake. В нём, как и в TLS ClientHello, передаётся SNI. P-GW может его читать.
- 0-RTT и 1-RTT — последующие пакеты зашифрованы. Они для P-GW неотличимы от любого другого UDP.
Тем не менее UDP-трафик в РФ часто rate-лимитируется на P-GW: операторы намеренно ограничивают объём UDP, потому что он используется не только для QUIC, но и для VPN (WireGuard, OpenVPN UDP), голос/видео (RTP), DNS, BitTorrent и так далее. Поэтому стабильность QUIC через мобильный интернет в РФ часто ниже, чем у TCP+TLS.
Это, кстати, одна из причин, почему сервисы вроде Discord или Google Meet могут «лагать» именно на мобильном интернете — RTP/QUIC встречает узкое место на P-GW. С Wi-Fi (через домашний провайдер) такой проблемы обычно нет.
DPI: что умеет, что нет
DPI (Deep Packet Inspection) — общий термин для глубокого анализа содержимого пакетов. На современном P-GW (или специализированном инспекторе типа RDP-3 или СОРМ-3) DPI умеет:
- Парсить TLS handshake — извлекать SNI, версию TLS, набор cipher suites, расширения.
- Парсить QUIC Initial — то же самое для UDP-сценариев.
- Распознавать сигнатуры протоколов — отличать обычный HTTPS от OpenVPN, WireGuard, IKEv2, Tor — даже когда содержимое зашифровано. Многие из этих протоколов имеют характерные паттерны (длина пакетов, тайминг, заголовки).
- Применять политики QoS — снижать приоритет определённого трафика, ограничивать скорость.
Чего DPI не может (без MitM):
- Прочитать содержимое HTTPS-сессии после установки TLS-канала.
- Расшифровать VPN-туннель.
- Видеть, какой именно URL внутри домена запрашивает пользователь.
В РФ массовый MitM на уровне оператора не применяется (это потребовало бы установки операторских CA в каждом устройстве — что технически непрактично и юридически проблемно). Поэтому фильтрация работает на уровне «разрешить/запретить TCP-сессию», но не «фильтровать внутри сессии».
BGP black-holing vs whitelist
Стоит различать два разных механизма ограничения доступа:
BGP black-holing
Это техника, при которой провайдер на уровне BGP объявляет более специфичный маршрут к нежелательному IP, направляющий трафик «в чёрную дыру» (на null-интерфейс). Применяется для DDoS-mitigation и для блокировки конкретных IP по требованию регулятора. Это «черный список» — всё разрешено, кроме явно запрещённого.
Whitelist на P-GW
Это инверсная логика — всё запрещено, кроме явно разрешённого. Применяется именно к whitelist-режиму на конкретных тарифах (нулевой баланс, спец-тарифы, отдельные SIM-категории).
В нормальном «обычном» тарифе мобильный интернет в РФ работает по модели blacklist+selective whitelist: весь трафик разрешён, кроме блокированных Роскомнадзором ресурсов и некоторых протоколов. В режиме whitelist (например, для нулевого тарифа) логика инвертируется.
Логирование и retention
По «закону Яровой» и связанному регулированию операторы связи в РФ обязаны хранить метаданные о соединениях абонентов (СОРМ-3): кто, когда, к какому IP/домену подключался, сколько передано данных. Сами содержимое (тело HTTPS) операторы НЕ хранят и не могут расшифровать.
Сроки хранения:
- Метаданные (IP, время, объём, SNI) — до 3 лет.
- «Голос» — до 6 месяцев (звонки, SMS).
- Тело трафика — на практике не хранится, потому что объёмы петабайтные и стоимость нерациональна. Хранятся выборочно по индивидуальным запросам через СОРМ.
Это технический фон, на котором работает whitelist-фильтрация: оператор знает, к чему подключался абонент, но не знает, что именно он там делал.
Различия между операторами
Хотя логика whitelist в основе одинакова у всех крупных операторов РФ (МТС, МегаФон, Билайн, Tele2, Yota), детали реализации различаются:
- МТС — самая глубокая и подробная whitelist-таблица, чаще обновляется. Иногда чуть строже на UDP.
- МегаФон — близкий к МТС подход, но более лояльный к нестандартному трафику.
- Билайн (VEON / Вымпелком) — традиционно один из самых открытых операторов, whitelist чуть шире.
- Tele2 — после интеграции в Ростелеком унифицированы политики, но в whitelist-режиме поведение мягкое.
- Yota — «дочка» МегаФона, использует ту же инфраструктуру.
На практике whitelist-список совпадает у всех операторов на 95–99%. Различия — в редких корпоративных доменах и в порядке обновления реестра.
Как обрабатывается VPN-трафик
Стандартные VPN-протоколы (OpenVPN, IKEv2/IPsec, WireGuard) имеют характерные сигнатуры на уровне DPI:
- OpenVPN — на UDP/1194 классически, плюс характерный handshake. DPI может опознать.
- WireGuard — UDP/51820, минимальный handshake, тоже опознаётся.
- IKEv2 — UDP/500, UDP/4500, стандартизированный.
- L2TP/PPTP — устаревшие, легко опознаются.
В whitelist-режиме на мобильном интернете эти протоколы обычно не работают: их IP-адреса не в whitelist (если только VPN не размещён на whitelisted-инфраструктуре), а UDP-сигнатуры могут rate-лимитироваться.
Современная архитектурная практика (за пределами whitelist-темы — это общая тема для VPN в условиях DPI) — использовать TLS-tunneling через стандартный TCP/443: трафик упаковывается в обычные HTTPS-пакеты с легитимным SNI и идёт через стандартный 443 порт. Для DPI это выглядит как обычный визит на сайт. Этим способом работают, например, протоколы VLESS+Reality, Shadowsocks с TLS-обёрткой и подобные. Подробнее об этом — в материале «VPN-протоколы: VLESS, Hysteria, Shadowsocks».
5G и SA/NSA
В 2026 году 5G в РФ всё ещё развёртывается медленно (преимущественно NSA — Non-Standalone, использующий LTE-ядро). Архитектурно 5G NSA принципиально не отличается от LTE с точки зрения whitelist: P-GW тот же, фильтрация та же.
Когда операторы в перспективе перейдут на 5G SA (Standalone) с независимым ядром, появится UPF (User Plane Function) и SMF (Session Management Function), и whitelist-логика будет реализована на UPF. Принцип остаётся тем же — двухслойная фильтрация по IP+SNI.
Связанные материалы
Эта статья — часть нашей серии о whitelist-фильтрации:
- «Что такое белые списки в интернете РФ в 2026» — обзор.
- «Яндекс и белые списки» — про инфраструктуру Яндекса.
- «Банки в белом списке мобильного интернета».
- «Мобильный интернет РФ и белые списки».
- «Белые списки в России: история».
- «Какие сайты в белом списке РФ».
- «Почему вводят белые списки в РФ».
- «VPN-протоколы: VLESS, Hysteria, Shadowsocks» — про современные протоколы.
QQ NET: технический контекст маршрутизации
Раз уж мы говорили про маршрутизацию и whitelist — упомянем технический подход, который использует QQ NET. Сервис размещает свои LTE-узлы (LTE-1 и LTE-2) в Yandex Cloud, чьи IP стабильно входят в whitelist российских операторов. Это значит, что соединение с VPN-сервером — стандартный TLS-handshake к whitelisted IP, без каких-либо ухищрений с маршрутизацией.
На транспортном уровне используется VLESS поверх XHTTP с Reality — это современная архитектура, при которой:
- Соединение устанавливается на TCP/443 (стандартный HTTPS-порт).
- SNI в TLS ClientHello — это легитимный домен (cover-domain), который входит в whitelist.
- TLS-handshake выполняется к реальному серверу cover-домена, что для DPI неотличимо от обычного посещения сайта.
- После handshake устанавливается VLESS-туннель внутри легитимной TLS-сессии.
Это не «обход фильтрации», а архитектурное решение, которое следует современной практике конструирования транспортных протоколов. Подробнее — в материале «QQ NET и мобильные сети РФ» и «Лучший VPN для России в 2026».
Если вам нужно стабильное подключение через мобильный интернет в РФ — попробуйте QQ NET 3 дня бесплатно через страницу тарифов или подключитесь напрямую через Telegram-бот @qq_netbot.
Итого: техническая модель whitelist в РФ
Сводка ключевых технических фактов о маршрутизации мобильного трафика в РФ 2026 года:
- Фильтрация происходит на P-GW (LTE) или UPF (5G SA) — точке выхода мобильного трафика во внешний мир.
- Whitelist двухслойный: IP/CIDR + SNI inspection в TLS ClientHello.
- Открытый SNI — стандартное поведение TLS 1.2/1.3 без ECH; в РФ ECH практически не используется.
- QUIC/UDP трафик может rate-лимитироваться, поэтому TCP+TLS обычно стабильнее.
- DPI умеет читать TLS handshake и QUIC Initial, но не может расшифровать содержимое сессии.
- Логика whitelist примерно одинакова у всех крупных операторов РФ.
- BGP black-holing и whitelist — разные механизмы; в обычных тарифах работает blacklist, в whitelist-режиме — инверсная логика.
- «Закон Яровой» обеспечивает retention метаданных, но не содержимого зашифрованных сессий.
Понимание этой архитектуры помогает разбираться в том, почему одни сервисы работают «всегда», а другие — нет, и почему стабильность мобильного интернета зависит от конкретного протокола, домена, IP и оператора.