SSTP или IKEv2: что лучше для обхода блокировок в России

MAATRIX

Если провайдер режет VPN не по содержимому пакетов, а по портам и сигнатуре трафика, выбор протокола решает если не всё, то очень многое. SSTP и IKEv2 — два принципиально разных подхода к этой задаче: первый прячется внутри HTTPS-соединения на знакомом всем 443/TCP, второй использует специализированные UDP-порты 500 и 4500, которые DPI видит насквозь. Разберём, как это устроено на уровне протокола и какой вариант держится дольше при точечных блокировках по портам.

Как DPI ловит VPN-трафик в России

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

Первый сценарий — блокировка по номеру порта и транспорту. Самый грубый и самый дешёвый в реализации способ: если весь UDP-трафик на порт 500 или 4500 режется без разбора, IKEv2 умирает мгновенно, независимо от того, что внутри пакетов. Это не требует анализа содержимого — только заголовков IP/UDP, поэтому такой фильтр работает на скорости линии и почти ничего не стоит оператору.

Второй сценарий — анализ сигнатур протокола внутри разрешённого порта. Здесь DPI смотрит не на порт, а на паттерн: характерные байты IKE_SA_INIT, размер и частоту пакетов ESP, специфичные заголовки OpenVPN или WireGuard handshake. Такой анализ уже требует stateful-инспекции и обходится оператору дороже, поэтому применяется выборочно — обычно к протоколам, которые массово используют для обхода блокировок.

Третий сценарий — блокировка по репутации IP-адреса. Если с одного IP массово идут VPN-подключения (например, адрес известного VPN-провайдера), весь трафик на него могут ограничить или деградировать по скорости — тут уже не важно, какой протокол вы используете.

SSTP по построению обходит первый и частично третий сценарий, потому что живёт на порту 443/TCP — том же, что и обычный HTTPS-браузинг к любому сайту. IKEv2 уязвим именно к первому сценарию: UDP 500/4500 — это не порты общего назначения, блокировка по ним не задевает обычный веб-трафик пользователей, поэтому операторы режут их спокойно, не опасаясь жалоб.

SSTP: маскировка под HTTPS на 443/TCP

SSTP (Secure Socket Tunneling Protocol) — протокол Microsoft, инкапсулирующий PPP-кадры внутри HTTPS-сессии. С точки зрения сетевого оборудования между клиентом и сервером это обычное TLS-соединение на 443/TCP: тот же TLS handshake, тот же формат record layer, что и у любого HTTPS-сайта.

Ключевое преимущество — трафик визуально неотличим от похода на защищённый сайт, если DPI не делает глубокую инспекцию TLS-сертификата и паттерна трафика. Для блокировки такого соединения оператору пришлось бы резать весь 443/TCP, а это означает блокировку HTTPS как класса — то есть большей части интернета. На такое операторы не идут.

Минусы тоже прямо вытекают из архитектуры:

• TCP-в-TCP. SSTP инкапсулирует PPP (а через него зачастую IP-трафик приложений, который сам может быть TCP) внутри TCP-туннеля. При потере пакетов и повторной пересылке на внешнем уровне возникает эффект "meltdown" — задержки накапливаются, соединение может подвисать под нагрузкой или при нестабильном канале.
• Заметный TLS-отпечаток. SSTP использует специфическое расширение сертификата и последовательность байт в начале сессии (SSTP-запрос идёт как HTTPS POST на /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/). Продвинутый DPI, который умеет смотреть на TLS ClientHello и паттерн последующего трафика, теоретически может отличить SSTP от обычного HTTPS — на практике массовой блокировки именно по этому признаку в России пока не описано, но исключать нельзя.
• Только Windows "из коробки". Встроенная поддержка есть в Windows (клиент и, через RRAS, сервер). На Linux и macOS нужен сторонний клиент (обычно на базе sstp-client), готовые GUI-решения ограничены.

Поднять сервер проще всего через SoftEther, который умеет отдавать SSTP на 443 без RRAS — это разобрано в статье SSTP-сервер через SoftEther на Ubuntu 24.04. Для варианта на встроенных средствах Windows Server — RRAS VPN SSTP с нуля.

IKEv2: UDP 500/4500 и почему это узкое место

IKEv2 (Internet Key Exchange v2) — протокол согласования ключей для IPsec, обычно в паре с ESP для собственно шифрования данных. Технически это один из самых зрелых и быстрых VPN-протоколов: встроенная поддержка практически во всех современных ОС (Windows, iOS, macOS, Android через сторонние клиенты), поддержка MOBIKE для бесшовного переключения между Wi-Fi и мобильной сетью без обрыва туннеля, эффективная работа поверх UDP без проблем TCP-в-TCP.

Проблема для обхода блокировок ровно одна, но фундаментальная: сигнатура транспорта. IKE_SA_INIT всегда стартует на UDP 500. Если на пути обнаруживается NAT (а в мобильных и большинстве домашних сетей в России он есть почти всегда), протокол переключается на NAT-T и уходит на UDP 4500. Оба порта — не общеупотребимые, обычный пользовательский трафик по ним не ходит, поэтому оператору достаточно поставить фильтр на эти два UDP-порта, чтобы вырубить весь IKEv2-трафик, не трогая ничего больше в сети. Это ровно тот "первый сценарий" блокировки, о котором шла речь выше — самый дешёвый и самый безопасный для оператора с точки зрения побочных эффектов.

На практике это означает: там, где блокировки применяются точечно и вручную (например, по жалобе или во время локальных ограничений), IKEv2 может работать без проблем неделями. Но там, где оператор системно фильтрует известные VPN-порты, IKEv2 отваливается одним из первых — вместе с L2TP/IPsec, который использует те же порты.

Частично проблему смягчает то, что порт 4500 иногда используется и легитимными приложениями (некоторые VoIP- и игровые сервисы задействуют UDP в этом диапазоне), поэтому грубая блокировка "весь UDP 500/4500" не везде применяется без разбора — но полагаться на это как на стратегию не стоит.

Разворачивание сервера на strongSwan описано в серии инструкций: IKEv2 strongSwan на Ubuntu 24.04, для Debian 12 — IKEv2 strongSwan на Debian 12. Сертификаты для клиентов при multi-user сценарии — в статье IKEv2 multi-user: сертификаты strongSwan.

Сравнение устойчивости к блокировкам

Таблица показывает классический компромисс: SSTP выигрывает там, где блокировка построена на фильтрации портов и грубом анализе транспорта, а IKEv2 выигрывает в скорости, стабильности и переносимости между сетями — но проигрывает, как только оператор целенаправленно режет его порты.

Производительность и стабильность соединения

С точки зрения задержки и throughput IKEv2/IPsec в среднем работает быстрее SSTP: шифрование ESP обычно легче по накладным расходам, чем TLS-инкапсуляция PPP, а работа поверх UDP исключает проблему двойной ретрансмиссии. На стабильном канале разница может быть небольшой, но на нестабильном мобильном соединении с потерями пакетов SSTP просаживается заметнее — тот самый эффект TCP meltdown, когда TCP-туннель пытается ретранслировать поверх уже ретранслирующего нижележащего TCP-соединения.

MOBIKE — отдельный практический плюс IKEv2: при переключении с Wi-Fi на мобильную сеть (или между сотами) туннель не разрывается, клиент просто перерегистрирует новый IP у сервера. SSTP на смену сети реагирует разрывом сессии и переподключением с нуля, что заметно на телефоне при перемещении.

Оговорка по цифрам: точные значения задержки и просадки скорости сильно зависят от маршрута до сервера, загрузки канала оператора и конкретной реализации клиента — приводить "средние проценты" без реального теста на вашем маршруте было бы нечестно. Ориентируйтесь на собственные измерения через iperf3 или обычный спидтест на обоих протоколах в вашей сети.

Что выбрать под конкретный сценарий

Однозначного победителя нет — выбор определяется тем, какая блокировка вам реально угрожает.

Берите SSTP, если:

• Провайдер (или корпоративный/общественный Wi-Fi) блокирует нестандартные порты, но не трогает 443/TCP.
• Клиенты преимущественно на Windows — там SSTP работает без установки дополнительного ПО.
• Важнее пройти через жёсткий периметр (гостиничный, офисный Wi-Fi), чем добиться максимальной скорости.

Берите IKEv2, если:

• Порты 500/4500 у вашего оператора пока не блокируются — тогда вы получаете лучшую скорость и стабильность без компромиссов.
• Нужна поддержка на iOS/macOS "из коробки" и бесшовное переключение сетей (актуально для мобильных сценариев).
• Планируете несколько клиентов с индивидуальными сертификатами — инфраструктура PKI под IKEv2 отлажена лучше, чем под SSTP.

Практичный компромисс — держать оба варианта на одном сервере одновременно (SoftEther умеет отдавать и SSTP, и L2TP/IPsec, а рядом можно поднять отдельный strongSwan под чистый IKEv2) и переключаться в зависимости от того, что в моменте режет конкретная сеть. Общие принципы настройки портов и файрвола для VPN-протоколов разобраны в статье Windows Firewall: порты для VPN-протоколов. Если же оба протокола у вас режутся системно, а не по портам, а по глубокому анализу трафика — это уже сценарий для протоколов, специально спроектированных против DPI, вроде VLESS+Reality, разобранных в статье Xray и VLESS Reality на сервере в России.

Частые вопросы