Что такое туннель VPN и где заканчивается защита
Туннель надевает второй конверт на выбранные пакеты поверх канала, который у вас уже был. Проследите один запрос и увидите, какой адрес сайт действительно фиксирует.
Клиент сообщает «подключено», замок закрыт, а сайт всё равно фиксирует адрес вашей квартиры. Ничего не сломалось. Туннель не заменяет Wi-Fi или мобильное соединение; он надевает второй конверт на выбранные пакеты и отправляет этот конверт по сети, которая у вас уже была. Понять трюк — значит в основном проследить один запрос и заметить, где конверт вскрывается, потому что почти каждый непонятный симптом, от утечки домашнего адреса до застрявшей большой загрузки, происходит именно от этой границы.
Два конверта, один физический канал
Ноутбук сохраняет обычное соединение с роутером, а роутер сохраняет обычное соединение с провайдером. На этом пути ничего не меняется, когда поднимается туннель. Меняется то, что выбранные пакеты передаются виртуальному интерфейсу, заворачиваются в новый пакет с адресом VPN-партнёра и отправляются как обычный трафик по физическому каналу.
Принимающая сторона — устройство, которое вскрывает конверт и передаёт исходный пакет к его назначению. Между двумя концами наблюдатель видит внешний заголовок и ничего о внутреннем, если только протокол его не шифрует, что делают большинство потребительских протоколов и чего общая техника не требует.
Поэтому виртуальный интерфейс одновременно реален и обманчив. Он существует как объект ядра с адресом и максимальной единицей передачи, и операционная система направляет в него трафик, как в любой другой интерфейс. Это не кабель, и его существование доказывает лишь то, что компонент установлен. Использует ли его ваш браузер, решают маршруты, а не то, что интерфейс поднят.
Проследите один запрос в пути
Выберите назначение и спросите ядро, какой интерфейс оно будет использовать. Эта единственная команда решает большинство споров о том, делает ли туннель хоть что-нибудь:
ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0Если вывод маршрута называет интерфейс туннеля, пакет будет завёрнут. Если он называет физический интерфейс, этого не произойдёт, и никакой перезапуск клиента этого не изменит. Вторая команда показывает оба интерфейса рядом, и именно так вы замечаете туннель, поднявшийся без адреса или с адресом из неверного семейства.
Затем посмотрите на первый шаг изнутри конверта и сравните его с первым шагом снаружи:
traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5Внутри туннеля первый шаг — это внутренний адрес партнёра, а не ваш роутер. Запись на интерфейсе туннеля показывает внутренние пакеты, то есть трафик, который приложение считает отправляемым. Одновременная запись на физическом интерфейсе показывает внешние пакеты, и вместе они дают самое ясное доказательство того, что туннель действительно делает.
Три адреса, и сайт видит только один
Люди постоянно их путают, и путаница порождает ложные отчёты об утечках. Это разные поля в разных заголовках с разным временем жизни.
| Address | Where it appears | Who can see it |
|---|---|---|
| Endpoint address | Outer header, the peer you connect to | Your access network and the path to it |
| Inner tunnel address | Inside the envelope, on the virtual interface | The peer, and anything the peer routes to |
| Exit address | Source of the packet that reaches the website | The website and its upstream |
Число рядом с виртуальным адаптером — это вторая строка. Оно не является адресом, который фиксирует сайт, и выдавать его за ваш публичный IP просто неверно. Адрес, который видит сайт, назначает выход, а в туннеле к частной сети публичного выхода может не быть вовсе, потому что назначение находится внутри организации, а не в интернете.
Туннель между площадками — тот же механизм с другими конечными точками. Два роутера заворачивают трафик между сетями, и ни на одном отдельном устройстве клиент не установлен. Конверт в принципе идентичен, административная граница — нет.
Где конверт вскрывается и что его переживает
Туннель заканчивается на своём партнёре. Если собственное шифрование приложения идёт дальше, оно переживает эту границу, что обычно для HTTPS: сеанс браузера заканчивается на сайте, поэтому выход передаёт шифротекст, который не может прочитать.
Больше ничего по умолчанию не переживает. Незашифрованный запрос читается на выходе точно так же, как читался в Wi-Fi кафе, и туннель не добавляет защиты, которой у приложения никогда не было. Точно так же правила брандмауэра и политика пересылки на выходе решают, что будет дальше; успешное рукопожатие — это факт о соединении с партнёром, а не об остальной части пути.
Накладные расходы — другое видимое следствие. Каждый пакет несёт дополнительный заголовок, а внешний транспорт может добавить свой, поэтому полезная нагрузка на пакет уменьшается. На пути с фиксированной максимальной единицей передачи именно поэтому туннель может пропустить ping и остановить большую загрузку.
Проверьте путь, который приложение действительно прошло
Последний шаг — подтвердить конкретное приложение, а не машину вообще. Разрешите назначение, посмотрите маршрут для этого адреса, а затем наблюдайте за соединением, пока оно открыто:
getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'Если маршрут называет туннель, но список сокетов показывает соединение с адресом источника с физического интерфейса, приложение привязано к чему-то конкретному, либо второй туннель конкурирует за маршрут по умолчанию. Это вопрос маршрутизации, и ответить на него можно по этим трём выводам, а не по экрану состояния клиента.
Архитектура безопасности RFC 4301 описывает версию этого заворачивания на уровне IP для IPsec, и та же логика уровней применима к WireGuard и OpenVPN. Как только вы можете указать на внутренний пакет и внешний пакет как на отдельные объекты, большая часть поведения туннеля перестаёт быть загадочной и превращается в таблицу маршрутизации, которую можно прочитать.