Что раскрывает ответ STUN, когда VPN работает на роутере
Адрес туннеля на роутере — не локальный адрес браузера. Проследите, как каждый запрос маршрутизируется и транслируется, прежде чем читать, что сообщает отражатель.
Когда туннель живёт на роутере, на машине с браузером вообще нет туннельного интерфейса. Спросите у этой машины её локальные адреса и получите частный адрес LAN и петлю, ничего похожего на адрес VPN. И всё же STUN-сервер на той стороне по-прежнему может сообщить что-то значимое о пути, и то, что он сообщает, целиком зависит от того, как именно этот запрос был маршрутизирован и транслирован.
Именно на этой части стоит замедлиться. «Браузер не владеет адресом VPN» отвечает на вопрос об интерфейсах, тогда как отражённый адрес — это ответ о пути через трансляцию. Смешение двух вещей порождает уверенные выводы о раскрытии, которых доказательства не поддерживают.
Два устройства, два набора интерфейсов
В конфигурации с роутером туннель заканчивается на роутере, а клиент LAN отправляет обычный трафик на свой шлюз по умолчанию. Список интерфейсов клиента остаётся коротким: один частный адрес, возможно второй для другой сети, и петля. Риск не в том, что один из них случайно окажется адресом туннеля; риск в том, что запрос уходит путём, который вы не выбирали.
Спросите клиент какой путь выберет конкретный адресат вместо того, чтобы спрашивать, какие интерфейсы существуют. Ответ называет шлюз и адрес источника, который использовало бы ядро, и это уже информативнее любого перечня адресов.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsДиапазоны документации — хорошие цели для тестов, потому что они никогда не разрешаются в реальную службу. Сравните, что говорит клиент, с тем, что говорит роутер, и любое расхождение считайте доказательством того, что маршрутизация по политике, правило раздельного туннеля или второй маршрут по умолчанию делают то, что вы не учли.
Что разрешено сообщать ответу Binding
RFC 8489 определяет запрос и ответ Binding, в которых сервер сообщает наблюдаемый адрес транспорта источника для этого запроса. Это утверждение об одном пятёрном наборе в один момент, а не перепись интерфейсов клиента. Поэтому всё интересное происходит между клиентом и точкой наблюдения.
Этот разрыв заполняют маршрутизация и трансляция. Роутер, выполняющий трансляцию источника для исходящего трафика, заменяет частный источник клиента своим адресом на исходящем интерфейсе. Если этот интерфейс — туннель, отражатель видит адрес туннеля. Если пакет исключён из туннеля, отражатель видит то, что создала трансляция WAN. Тот же клиент, тот же отражатель, другой ответ.
Три случая, которые выглядят одинаково и не являются такими
Полезное различие не между публичным и частным, а в том, какая точка принуждения обработала пакет. Разберите случаи с открытыми собственными таблицами роутера, потому что один браузер может создать все три в зависимости от правила, которое вы забыли, что написали.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Только второй случай нарушает требование, чтобы некоторый трафик никогда не выходил напрямую, и только первый и третий раскрывают идентификатор со стороны туннеля. Ни одна из трёх строк не является утверждением о поведении конкретного провайдера: доступность частного отражателя вообще зависит от маршрутизации, разрешённых IP-адресов противной стороны и политики межсетевого экрана на обоих концах.
Наличие учётной записи у того же провайдера ничего из этого не доказывает. Стоит помнить и о том, что маршрутизированный запрос может сохранить источник LAN клиента, если ничто его не транслирует, поэтому поле источника нужно прослеживать, а не предполагать по схеме топологии.
Сбор — это не выбор
WebRTC собирает адреса-кандидаты для проверки, и кандидат, появившийся в диагностическом списке, может никогда не нести медиа. Читать список как «вот что узнала другая сторона» — значит переоценивать доказательства. Выбранная пара — это то, что действительно несло сеанс, и она находится в другом поле.
Проверка выхода по HTTPS отвечает ещё на один вопрос: адрес источника, который веб-сервер увидел для этого запроса. Это полезная перекрёстная проверка именно потому, что используется другой протокол и часто другой адресат, чем у UDP-отражателя, а расхождение между ними обычно указывает на правило маршрутизации, а не на ошибку.
Определите политику, затем читайте ответ
Запишите намерение до тестирования: какой трафик должен использовать туннель, какой может выходить напрямую, какие семейства адресов входят в область, и что должно происходить, когда туннель не работает. Без этой базовой линии любое наблюдение неоднозначно, потому что вы не можете отделить утечку от пути, который сознательно разрешили.
Затем задавайте по одному вопросу. Какой путь выбирает этот адресат. Какой адрес сообщает этот отражатель. Какую пару кандидатов выбрал сеанс. Держите ответы рядом с политикой и датируйте их, потому что обновление прошивки может изменить поведение по умолчанию так, что прошлогодний вывод тихо утратит силу.
Роутер остаётся сильной точкой принуждения, потому что он видит трафик, который клиент не может обойти, не перенастроив сам себя. Это не обещание, что каждое поле в каждом прикладном протоколе ничего не раскрывает, и это не замена записи путей, которые вы решили разрешить.