Multi-hop VPN: когда цепочка из двух серверов оправдана, а когда создаёт иллюзию

Что происходит с трафиком в цепочке​

Обычный VPN-туннель — это один зашифрованный канал между клиентом и сервером провайдера. Сервер видит ваш реальный IP, знает, куда вы подключаетесь, и может сопоставить тайминги. Multi-hop добавляет второй узел: клиент шифрует пакет для первого сервера, тот расшифровывает, перешифровывает и отправляет второму, а второй уже выпускает трафик в интернет.

Ключевой момент: каждый узел в цепочке видит только своего непосредственного соседа. Первый сервер знает ваш IP, но не знает конечный пункт назначения (если используется вложенное шифрование). Второй сервер знает, куда идёт запрос, но видит только IP первого сервера, а не ваш.

Это работает при условии, что шифрование на каждом уровне независимое. Если провайдер реализует multi-hop как последовательное подключение к двум серверам с одним ключом или пробрасывает туннель без повторного шифрования, защита деградирует.

Какие угрозы закрывает двойной прыжок​

Multi-hop решает конкретную задачу: усложняет корреляцию трафика между точкой входа и точкой выхода. Это полезно в нескольких сценариях.

Компрометация одного сервера. Если злоумышленник получил доступ к первому узлу, он видит ваш IP и факт подключения, но не видит конечный ресурс. Если скомпрометирован второй узел, он видит запросы, но не ваш реальный адрес. Для полной деанонимизации нужно контролировать оба сервера одновременно.

Наблюдение на уровне дата-центра. Хостинг-провайдер или сетевой оператор, контролирующий один из узлов, не может связать входящий и исходящий трафик без доступа ко второму узлу.

Юрисдикционный риск. Если серверы находятся в разных юрисдикциях, запрос на раскрытие данных нужно направлять в обе страны. Это не абсолютная защита, но повышает стоимость деанонимизации.

Где multi-hop не помогает​

Цепочка из двух серверов не является универсальным решением. Есть классы угроз, против которых она бессильна.

Анализ таймингов. Если наблюдатель контролирует и вход, и выход цепочки (например, на уровне магистрального провайдера), он может сопоставить размеры пакетов и временные метки. Вложенное шифрование не меняет размер полезной нагрузки, а задержки коррелируют. Это фундаментальное ограничение любой цепочки без миксования трафика.

Утечки на уровне приложения. Если браузер или приложение отправляет данные в обход туннеля — через WebRTC, DNS-запросы мимо VPN, IPv6 без маршрутизации через туннель — цепочка не защищает. Трафик уходит напрямую, минуя оба сервера.

Метаданные на конечном ресурсе. Если вы авторизуетесь на сайте под своим аккаунтом, вводите персональные данные или используете уникальный fingerprint браузера, количество промежуточных узлов не имеет значения.

Компрометация клиента. Вредоносное ПО на устройстве видит трафик до шифрования. Никакой сервер, ни один, ни два, ни десять, не защитят от кейлоггера или screen capture.

Производительность: реальная цена второго прыжка​

Каждый дополнительный узел добавляет задержку и снижает пропускную способность. Механика проста:

• Пакет проходит дополнительный цикл шифрования/расшифрования на промежуточном сервере.
  
• RTT увеличивается минимум на время прохождения между двумя узлами.
  
• Если серверы находятся на разных континентах, задержка может вырасти на 100–300 мс.
  

Для WireGuard это особенно заметно: протокол оптимизирован для минимальной задержки и работает в пространстве ядра через интерфейс wg0. Добавление второго узла означает, что пакет должен быть обработан дважды — на каждом сервере выполняется полный цикл: приём UDP-датаграммы, расшифровка, проверка подлинности, перешифровка, отправка. Это не «просто пересылка», а полноценная криптографическая операция на каждом хопе.

Практическое следствие: для стриминга, VoIP и интерактивных сессий multi-hop часто делает соединение непригодным. Для загрузки файлов или чтения веб-страниц задержка менее критична.

Реализации: как провайдеры строят цепочки​

Существует два принципиально разных подхода.

Последовательные туннели (каскад)​

Клиент устанавливает туннель к первому серверу, а внутри него — второй туннель ко второму серверу. Каждый туннель использует собственный набор ключей. Это наиболее распространённая реализация в коммерческих VPN-сервисах.

Преимущество: даже если один из серверов скомпрометирован, атакующий не получает ключи от второго уровня.

Недостаток: клиент должен доверять реализации провайдера. Если клиентское ПО неправильно настраивает маршруты или использует общий ключ для обоих хопов, защита иллюзорна.

Прокси-цепочка на стороне сервера​

Клиент подключается к одному серверу, а тот на своей стороне перенаправляет трафик через второй узел. С точки зрения клиента это выглядит как обычное подключение.

Преимущество: простота настройки на клиенте.

Недостаток: первый сервер видит и ваш IP, и конечный адрес назначения (если не применяется дополнительное шифрование между узлами). Доверие к первому серверу становится критическим.

Как проверить, что трафик действительно идёт через два узла​

Если вы используете multi-hop, стоит убедиться, что цепочка работает как заявлено.

Проверка IP-адреса​

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

Проверка маршрута через traceroute​

traceroute -n example.com

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

Проверка DNS​

nslookup example.com

DNS-запрос должен уходить через туннель. Если резолвер отвечает мгновенно и показывает адрес вашего локального DNS-сервера, значит запросы идут мимо VPN.

Проверка утечек через сетевой монитор​

На Linux можно отследить, куда реально уходят пакеты:

sudo tcpdump -i any -n port 51820

Для WireGuard стандартный порт — 51820 (хотя может быть изменён в конфигурации). Если вы видите исходящие UDP-пакеты на этот порт только в адрес первого сервера, а не напрямую в интернет — туннель работает. Если появляются соединения на другие порты или адреса вне туннеля, возможна утечка.

Когда multi-hop оправдан​

Цепочка из двух серверов имеет смысл, если выполняется хотя бы одно условие:

• Вы не доверяете ни одному серверу провайдера по отдельности и хотите снизить риск компрометации одного узла.
  
• Вам нужна защита от наблюдения на уровне хостинг-провайдера одного из серверов.
  
• Вы работаете в среде, где один из серверов может быть принуждён к выдаче логов по запросу местных органов, и хотите усложнить эту процедуру.
  
• Вы используете self-hosted серверы в разных юрисдикциях и контролируете оба.
  

Когда это иллюзия безопасности​

Multi-hop не добавляет реальной защиты в следующих случаях:

• Оба сервера принадлежат одному провайдеру в одной юрисдикции и управляются одной командой. Компрометация одного с высокой вероятностью означает компрометацию второго.
  
• Провайдер ведёт логи на обоих узлах. В этом случае цепочка лишь усложняет маршрутизацию, но не мешает корреляции.
  
• Вы используете цепочку для защиты от угроз, которые она не закрывает (fingerprinting, утечки на уровне приложений, компрометация устройства).
  
• Задержка делает соединение нестабильным, и вы периодически отключаетесь, оставляя трафик незащищённым.
  

Альтернативы и дополнения​

Если задача — защита от корреляции трафика, существуют более эффективные механизмы:

• Tor — многоузловая цепочка с миксованием трафика и луковой маршрутизацией. Устойчивее к анализу таймингов, чем простая цепочка из двух серверов, но медленнее.
  
• Mix-сети — протоколы, которые задерживают и перемешивают пакеты от множества пользователей, разрушая временную корреляцию. Пока не получили массового распространения в коммерческих VPN.
  
• Разделение задач — для разных типов трафика использовать разные каналы: один туннель для браузера, другой для мессенджера. Это не заменяет multi-hop, но снижает объём данных, которые видит один сервер.
  

Практический чек-лист перед включением multi-hop​

1. Убедитесь, что оба сервера находятся в разных юрисдикциях и управляются независимо.
   
2. Проверьте, что провайдер не ведёт логи на обоих узлах одновременно.
   
3. После подключения проверьте IP через внешний сервис — он должен совпадать с выходным узлом.
   
4. Проверьте отсутствие DNS-утечек.
   
5. Оцените, приемлема ли задержка для ваших задач. Если нет — цепочка создаёт дискомфорт без реальной выгоды.
   
6. Если используете self-hosted WireGuard для построения цепочки, убедитесь, что на каждом сервере настроен отдельный интерфейс (wg0, wg1) с независимыми ключами, а маршрутизация между узлами не обходит туннель.
   

Источники​

• WireGuard: fast, modern, secure VPN tunnel