Как трафик проходит от клиента до интернета через разделённую цепочку компонентов, где каждый знает только то, что ему необходимо.
Каждый узел выполняет строго ограниченную задачу. Компрометация любого из них не раскрывает информацию об остальных — это принципиально отличает NavLink от классических прокси-решений с единой точкой отказа.
Приложение на устройстве пользователя. Перехватывает весь IP-трафик через виртуальный сетевой интерфейс и направляет его в туннель.
Региональный прокси первого прыжка. Принимает соединение от клиента и прозрачно пробрасывает его до exit-узла. Содержимое трафика не видит.
Терминирует зашифрованный туннель и устанавливает соединение с целевым ресурсом. Трафик покидает сеть с IP-адреса exit-узла.
Центральный сервер управления. Выдаёт ключи доступа, управляет реестром узлов, ведёт биллинг. Клиент с ним напрямую не общается.
От момента открытия сайта до получения ответа — каждый шаг туннельного протокола NavLink.
Клиентское приложение поднимает виртуальный сетевой интерфейс — WinTun на Windows, NEPacketTunnelProvider на macOS, VpnService на Android. Весь IP-трафик захватывается и передаётся в tun2socks, который эмулирует TCP-стек поверх TUN-адаптера.
Каждый IP-адрес сверяется с набором CIDR-диапазонов, загруженных при подключении. Адреса целевой страны уходят напрямую через физический интерфейс. Все остальные — через туннель.
RUUSCNIREUКлиент открывает TLS-соединение к control-узлу с браузерным отпечатком — Chrome, Firefox, Safari или Edge, случайно выбираемым на каждое соединение. В поле TLS Session ID встраивается channel byte: 0x00 — основной туннель, 0x01 — relay API, 0x02 — сигнальный канал NAT.
Session ID[0] = 0xA7 Session ID[1] = channelControl-узел не расшифровывает TLS и не анализирует содержимое. Он пробрасывает байтовый поток напрямую к exit-узлу, выбранному по гео-политике: исключаются exit-узлы в стране клиента и в стране самого control-узла. Из оставшихся выбирается по RTT и нагрузке.
Exit-узел видит входящий поток как chunked HTTP POST на статично выглядящий путь. Декодирует обфускацию, проверяет X-Session токен через локальный кеш и устанавливает TCP-соединение с целевым хостом.
X-Session X-Target X-ConnОтвет от целевого сервера проходит тот же путь в обратном направлении: exit, затем control, затем клиент. HTTP-обфускатор применяется и к исходящим данным — для внешнего наблюдателя весь обмен выглядит как стандартный HTTPS.
Ключ доступа NavLink — не просто пара логин/пароль. Это зашифрованная структура с вшитыми адресами узлов и цифровой подписью арбитра.
Клиент расшифровывает key-string и извлекает: логин, пароль, список control-узлов, публичный ключ арбитра и цифровую подпись Ed25519. Ключи V2 используют XChaCha20-Poly1305 с BLAKE2b-производным ключом шифрования.
XChaCha20-Poly1305 BLAKE2b-256 Ed25519POST /api/auth/login проксируется через exit-узел на арбитр. Клиент с арбитром напрямую никогда не общается. Арбитр проверяет пароль и возвращает непрозрачный SNC-токен, зашифрованный ChaCha20-Poly1305.
Каждый туннельный запрос несёт заголовок X-Session. Exit проверяет токен через локальный кеш или запрашивает арбитр. Устаревший кеш хранится 3 часа на случай временной недоступности арбитра.
кеш: 1 мин stale: 3 чЕсли один и тот же ключ используется одновременно с двух разных устройств в течение 10 секунд — это признак утечки. После трёх таких событий аккаунт автоматически блокируется.
окно: 10 с 3 события = blockedКлючевое свойство архитектуры: данные об инфраструктуре разделены между компонентами. Ни один узел не обладает полной картиной.
| Данные | Client | Control | Exit | Arbiter |
|---|---|---|---|---|
| Адреса control-узлов | Yes | Yes | No | Yes |
| Адреса exit-узлов | No | Yes | Yes | Yes |
| Полная топология сети | No | No | No | Yes |
| Реальный IP клиента | Yes | Yes | No | No |
| Целевой хост | Yes | No | Yes | No |
| Содержимое трафика | Yes | No | No | No |
Exit видит целевой хост только в заголовке X-Target — для установки исходящего TCP-соединения. Содержимое трафика он не расшифровывает. Control видит IP клиента, но не знает, куда тот идёт.