Сцепка двух VPN: что она скрывает и во что обходится

Два вложенных туннеля не делают вас анонимным. Они делят наблюдения между двумя провайдерами, так что ни один из них не видит ваш домашний адрес и вашу точку назначения одновременно. Это реальное, но узкое преимущество, и оно приходит с проблемами маршрутизации, DNS и MTU, которые проявляются в первый же раз, когда вы на него полагаетесь.

1. Решите, зачем нужен второй прыжок

Сформулируйте цель одним предложением, прежде чем что-либо настраивать. Если цель в том, чтобы ваш провайдер не видел, какие сайты вы посещаете, хватит одного туннеля. Если в том, чтобы ни один провайдер не мог связать ваш адрес с вашим трафиком, нужно два. Если в том, чтобы никто не мог вас идентифицировать, никакое число прыжков туда не приведёт.

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

2. Сделайте внутреннюю конечную точку достижимой через внешний туннель

Обычный сбой состоит в том, что внутренний туннель не поднимается вовсе. Внешнее подключение в режиме полного туннеля владеет маршрутом по умолчанию, поэтому попытка внутреннего клиента достучаться до своей конечной точки поглощается внешним туннелем и отбрасывается или зацикливается. Внутренней конечной точке нужен явный маршрут через внешний интерфейс, установленный до запуска внутреннего клиента. Иначе рукопожатие соревнуется с маршрутом и проигрывает.

WireGuard показывает тот же конфликт с другой стороны. У каждого пира AllowedIPs решает, какие адресаты входят в этот туннель, поэтому внутренний интерфейс, претендующий на все адреса, претендует и на внешнюю конечную точку, если не победит более конкретный маршрут. Пересекающиеся AllowedIPs на двух интерфейсах — это конфигурация, в которой одна сторона молча проигрывает.

Сцепка контейнеров делает разделение явным, а ловушку очевидной. Контейнер со своим пространством имён, своим маршрутом по умолчанию и клиентом внутри пересылает то, что присылает ему хост; хост сам не начинает пользоваться этим путём. Включите пересылку, добавьте маршрут для туннеля контейнера и направьте службу на адрес контейнера.

3. Держите DNS на том же пути

DNS должен ехать туда, куда едет трафик. Если внутренний провайдер навязывает свои резолверы, а хост по-прежнему спрашивает локальные, эти запросы выдают ровно те сайты, которые туннель должен был скрыть. Проверяйте перехватом на каждом интерфейсе туннеля, а не доверяйте панели состояния клиента. Утечка здесь незаметна при обычном просмотре и очевидна в перехвате.

Схемы с раздельным DNS усложняют это, потому что запрос локального имени может законно относиться к пространству вне туннеля. Пишите список исключений осознанно, а не обнаруживайте его по тому, какой резолвер случайно ответил.

4. Задайте MTU до того, как пользователи узнают о проблеме за вас

MTU — вторая предсказуемая жертва. Две инкапсуляции вычитают два заголовка, а внешний туннель, уже снизивший MTU пути, оставляет внутри меньше места. Симптомы знакомы: небольшие запросы проходят, крупные передачи и рукопожатия TLS встают.

ip link set dev wg1 mtu 1280 — грубое решение, а ограничение MSS на форвардере — более аккуратное. Повтор соединения вообще не решение.

5. Проверьте именно тот отказ, который получите

Намеренно сломайте внешний туннель и посмотрите, что будет. Цепочка, которая молча откатывается на прямой путь, когда внешний прыжок умирает, хуже отсутствия цепочки, потому что она течёт ровно в тот момент, когда вы считали себя защищённым. Kill switch, останавливающий весь трафик, — то поведение, к которому стоит стремиться. Запишите результат: вы не захотите выяснять это заново посреди инцидента.

Задержка и вторая точка отказа — постоянные издержки. Два прыжка означают и две очереди поддержки, когда что-то ломается в неудобный час.