SNI-фильтрация: почему VPN-туннели детектятся по TLS ClientHello

Механика SNI: откуда берётся утечка

SNI — это поле в TLS ClientHello, которое содержит имя хоста в открытом виде. Браузер отправляет его до установки зашифрованного соединения. Провайдер видит это поле и решает: пропустить трафик или заблокировать.

VPN-туннель шифрует весь трафик. Но сам факт установки VPN-соединения — это тоже сетевой поток. Если вы подключаетесь к VPN-серверу по IP-адресу без SNI — фильтр видит просто TLS-соединение с неизвестным хостом. Если по домену — домен в SNI палится мгновенно.

Пример: ваш OpenVPN-сервер на `vpn.example.com:443`. Клиент отправляет ClientHello с SNI `vpn.example.com`. DPI-система видит это поле и сверяет с базой известных VPN-доменов. Всё, туннель помечен.

```bash

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com 2>/dev/null | head -20

```

Как DPI анализирует ClientHello

Глубокий анализ пакетов (DPI) не просто смотрит на SNI. Он разбирает структуру ClientHello по байтам. Смотрит на:

- порядок cipher suites

- версию TLS

- длину полей

- наличие расширений и их порядок

Каждый VPN-клиент оставляет характерный след. OpenVPN с TLS-обёрткой, WireGuard с маскировкой под TLS, Shadowsocks с собственным протоколом — всё это имеет уникальные сигнатуры.

Пример: OpenVPN 2.6 использует cipher suite `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` в определённом порядке. Браузер Chrome 120 использует другой набор. DPI сравнивает: если порядок cipher suites не похож на браузерный — вероятность VPN высокая.

Реальные цифры задержек

Когда VPN-туннель детектирован, провайдер может:

- разорвать соединение (RST)

- замедлить трафик до 1-5 Мбит/с

- подменить HTTP-ответы

Замеры на практике: при нормальном VPN-соединении RTT до сервера 40-60 мс. После детекции и замедления — 300-500 мс. Пакеты начинают теряться, TCP retransmission растёт с 0.1% до 5-10%.

Кейс: блокировка по SNI в реальной сети

Проблема: пользователь подключается к корпоративному VPN через OpenVPN на порту 443. Провайдер начал DPI-фильтрацию. VPN работает ровно 3 минуты, потом соединение рвётся.

Причина: DPI-система обнаружила SNI `vpn.corp.internal` в ClientHello. База сигнатур сработала. Провайдер отправил RST-пакеты с поддельным адресом сервера.

Решение: перейти на подключение по IP-адресу без SNI. Но это не панацея — DPI смотрит на весь ClientHello, а не только на SNI.

Маскировка ClientHello: техника и ограничения

Самый распространённый способ обхода — подмена ClientHello под браузерный. Инструменты вроде `uTLS` (Go-библиотека) собирают ClientHello из реальных браузерных сигнатур.

```go

import "github.com/refraction-networking/utls"

uConn := tls.UClient(conn, &tls.Config{ServerName: "example.com"}, tls.HelloChrome_Auto)

err := uConn.Handshake()

```

uTLS берёт реальную сигнатуру Chrome 120 и подставляет в ClientHello. Порядок cipher suites, расширения, всё совпадает с браузерным. DPI видит обычный браузерный трафик.

Но есть нюанс: после ClientHello идёт TLS-хендшейк. Сертификат, key exchange — всё это тоже анализируется. VPN-сервер должен вести себя как настоящий веб-сервер. Иначе DPI заметит аномалию.

Кейс: WireGuard с маскировкой под TLS

Проблема: WireGuard не использует TLS вообще. Его пакеты легко детектить по характерным полям. Провайдер блокирует протокол на уровне DPI.

Причина: WireGuard отправляет первый пакет с фиксированным типом сообщения (1 — handshake initiation). DPI видит этот байт и блокирует.

Решение: обернуть WireGuard в TLS-туннель. Инструмент `wireguard-tls` создаёт TLS-обёртку, которая выглядит как обычный HTTPS-трафик. ClientHello подменяется на браузерный, внутри идёт WireGuard.

```bash

wg-quick up wg0

wireguard-tls --listen 443 --target 127.0.0.1:51820 --cert server.crt --key server.key

```

Детекция по таймингам и размерам пакетов

SNI — не единственный маркер. DPI анализирует:

- размеры TLS-записей

- интервалы между пакетами

- направление трафика

Браузер отправляет запросы с интервалом 50-200 мс. VPN-туннель — равномерный поток 1-2 Мбит/с. Статистический анализ выявляет аномалии.

Пример: при просмотре веб-страницы браузер отправляет 20-30 запросов в течение 5 секунд. VPN-туннель передаёт непрерывный поток данных. DPI считает соотношение входящего и исходящего трафика. У браузера оно примерно 1:1. У VPN — 1:10 или 1:20.

Кейс: Shadowsocks с TLS-маскировкой

Проблема: Shadowsocks использует собственный протокол с фиксированной структурой пакетов. DPI детектит его по заголовку.

Причина: первый байт пакета Shadowsocks — это длина пакета (2 байта) + тип шифрования. DPI знает эти сигнатуры.

Решение: использовать `shadowsocks-rust` с плагином `v2ray-plugin`. Плагин оборачивает трафик в TLS с подменой ClientHello.

```bash

ss-server -s 0.0.0.0 -p 443 -k password -m aes-256-gcm --plugin v2ray-plugin --plugin-opts "server;tls;host=example.com"

```

Практические советы по защите

1. Используйте порт 443 — нестандартные порты палятся сразу.

2. Подключайтесь по IP-адресу, а не по домену — SNI не будет в ClientHello.

3. Используйте инструменты с uTLS-подменой ClientHello.

4. Меняйте сигнатуры периодически — DPI-базы обновляются.

Ограничения и риски

Ни один метод не даёт 100% гарантии. DPI-системы эволюционируют. Новые алгоритмы машинного обучения анализируют поведение трафика, а не только заголовки.

Если провайдер использует активное зондирование — отправляет запросы на подозрительные порты и анализирует ответы — TLS-маскировка не спасёт. VPN-сервер должен отвечать на нестандартные запросы как настоящий веб-сервер.

Заключение

SNI-фильтрация — это только верхушка айсберга. DPI анализирует весь TLS-хендшейк, тайминги, размеры пакетов. VPN-туннели детектятся по совокупности признаков.

Для обхода нужно маскировать не только SNI, но и весь ClientHello, и поведение трафика. Инструменты вроде uTLS и v2ray-plugin решают часть проблем, но не все.

Если вы используете VPN для обхода блокировок — комбинируйте методы. Меняйте протоколы, порты, сигнатуры. И помните: DPI-системы тоже развиваются.