Каждый уровень — независимый механизм защиты от обнаружения. Ни одного диагностического признака, ни одной утечки отпечатка.
TLS ClientHello — это первый пакет, который DPI-системы анализируют для классификации трафика. Стандартные библиотеки (Go crypto/tls, OpenSSL) генерируют ClientHello с предсказуемым набором шифров, расширений и их порядком, который немедленно идентифицируется как нестандартный клиент.
NavLink использует uTLS — библиотеку, которая клонирует реальные ClientHello-отпечатки браузеров. На каждое соединение случайно выбирается один из четырёх профилей. Chrome получает удвоенный вес, поскольку является самым распространённым браузером.
Поверх одного TLS-соединения к control-узлу работают несколько логических каналов: основной туннель, relay API, NAT-сигнальный канал и другие. Классическим решением была бы отдельная HTTP-маршрутизация с кастомными заголовками — но это немедленно выдало бы нестандартный протокол.
Вместо этого NavLink прячет channel byte в стандартное поле TLS Session ID. Байт 0 всегда равен 0xA7 (magic), байт 1 задаёт канал. Для DPI это выглядит как 32 байта случайных данных — именно так Session ID и должен выглядеть.
| Байт | Канал |
|---|---|
| 0x00 | Основной туннель |
| 0x01 | Relay tracker API |
| 0x02 | NAT relay (yamux) |
| 0x03 | NAT relay data path |
| 0x04 | Para-exit (yamux) |
Туннельный трафик внутри TLS выглядит как обычная загрузка файла через браузер — chunked POST-запрос на статично выглядящий API-путь. Размер чанков, паддинг и задержки между записями выбираются случайно в каждом соединении.
Это делает статистические атаки на паттерн трафика значительно сложнее: наблюдатель видит прерывистый поток данных неравномерного размера с реалистичными заголовками User-Agent. Именно так выглядит загрузка медиафайла в браузере.
Даже с правильным TLS-отпечатком и HTTP-обфускацией продвинутый DPI может заметить аномалию: хост, к которому постоянно идут соединения, но никогда не запрашивает CSS, JavaScript или изображения. Типичный браузер никогда так себя не ведёт.
Для решения этой проблемы NavLink генерирует параллельные uTLS-соединения к реальным CDN-хостам. Эти запросы реальные — CDN возвращает реальные файлы. Статистика трафика становится неотличима от обычной браузерной сессии.
Туннельный трафик по своей природе неравномерен: видео и большие файлы генерируют всплески, которые статистически выделяются на фоне обычного веб-браузинга. Резкие смены ритма — характерный признак туннеля.
Адаптивный пейсинг сглаживает всплески, удерживая паттерн трафика в пределах нормального диапазона веб-браузинга. Комбинируется с джиттером HTTP-обфускатора (уровень 3) и ложным трафиком (уровень 4) для полной маскировки временного профиля.
Активное зондирование — распространённая техника выявления прокси-серверов: сканер отправляет аномальные HTTP-запросы и анализирует ответы. VPN-сервер вернёт 401 или 403. CONNECT-прокси — 200 на CONNECT. Shadowsocks — зависнет на произвольных байтах.
NavLink возвращает 404 на любой запрос, который не соответствует ожидаемому протоколу. Нет заголовков VPN, нет поддержки CONNECT, нет отличительных ответов. Для сканера — это обычный веб-сервер с несуществующим ресурсом.
Блокировка по IP-адресам — последний рубеж сетевой цензуры. Классические VPN публикуют список серверов, и провайдер просто вносит эти IP в чёрный список. Shadowsocks- и V2Ray-серверы обнаруживаются активным зондированием.
В NavLink клиент знает только адреса control-узлов. Control знает адреса exit-узлов, но не раскрывает их клиенту. Exit не знает адрес арбитра. Каждый узел видит в манифесте не более 12 случайных соседей — полная топология никому недоступна. Блокировка одного exit-узла не позволяет обнаружить остальные.
Как работает архитектура
Детальный разбор четырёхузловой схемы и пути данных.
К обзору Архитектура Сравнение