Зчеплення двох 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, що зупиняє весь трафік, — це поведінка, до якої варто прагнути. Запишіть результат, бо ви не захочете з'ясовувати це наново посеред інциденту.

Затримка й друга точка відмови — постійні витрати. Два стрибки означають і дві черги підтримки, коли щось ламається в незручну годину.