Какой адрес источника видит STUN с VPN на роутере?
Маршрут, выбор источника и трансляция решают, какой адрес сообщает отражатель. Три факта, которые стоит записать, затем один запрос, чтобы подтвердить, какой путь побеждает.
Вопрос звучит как одна проверка, а на деле это три решения. Какой маршрут выберет binding request, какой источник ядро выберет для этого маршрута и не перепишет ли что-нибудь этот источник по дороге. Измените любое из трёх — и адрес, который сообщает STUN-сервер, изменится вместе с ним. Поэтому утверждение, что VPN стоит на роутере, само по себе почти ничего не говорит.
Решение опирается на три факта
Во-первых, маршрут: правила политики и таблица маршрутизации решают, выйдет ли запрос через туннель или через обычный WAN, а исключённое назначение выбирает второй путь даже при поднятом туннеле. Во-вторых, источник: ядро выбирает источник для выбранного маршрута, и этот выбор зависит от предпочтительного источника маршрута и от любого совпавшего правила. В-третьих, трансляция: NAT по дороге заменяет выбранный источник. Отражённый адрес — это произведение всех трёх, а не свойство туннеля.
Измените одно из трёх — и ответ изменится, хотя каждый компонент в своём журнале по-прежнему выглядит здоровым. Это обычная причина, по которой такая диагностика заходит в тупик.
Запишите три факта для потока, который тестируете, до начала работы. Интерфейса, маршрута и правила трансляции достаточно, чтобы предсказать результат, и именно предсказание делает неожиданность информативной. Если один из трёх заполнить не удаётся, этот пробел и есть настоящая находка.
Проследите один binding request по пути
STUN binding request просит сервер сообщить наблюдённый адрес транспорта источника. Ответ описывает путь, который прошёл запрос, а не перечень интерфейсов на клиентской машине. Два запроса по двум путям честно сообщат два разных адреса.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
Читайте эту таблицу как набор условий, а не как меню провайдеров. Средняя строка требует, чтобы частный отражатель был доступен при собственной маршрутизации и peer-политике туннеля; это конфигурационный факт, который можно проверить, а не что-то, что подразумевает уровень аккаунта. Нижняя строка обычно важна для политики, потому что этот трафик должен был остаться в туннеле. Между ними — обычный случай, когда выход транслирует, а отражатель видит только выход.
Кандидаты хоста и серверно-рефлексивные кандидаты происходят из разных механизмов, поэтому список кандидатов не говорит, какой путь медиа фактически использовали. Читайте выбранную пару, а не журнал сбора, когда хотите понять, куда ушла сессия.
Чем адрес туннеля роутера не является
Адрес туннеля, назначенный роутеру, принадлежит интерфейсу на роутере. Браузер на хосте в LAN имеет собственные адреса интерфейсов и не видит туннельный интерфейс роутера напрямую. Если обращаться с ними как с взаимозаменяемыми, получаются уверенные неверные ответы о том, что может узнать веб-страница.
Пересылка — это то, что их связывает. Запрос проходит через роутер как маршрутизируемый трафик, и его источник — то, что создали маршрутизация и трансляция.
Если путь через туннель сохраняет источник LAN, частный отражатель может узнать этот LAN-адрес, что является настоящим раскрытием и отличается от адреса туннеля. Если путь транслирует в адрес туннеля, отражатель узнаёт вместо этого адрес туннеля. Оба исхода совместимы с одним и тем же браузером на одном и том же хосте, поэтому наблюдение нужно привязывать к конкретному потоку. Спросите ядро, какой источник оно использовало бы, прежде чем винить приложение.
Раскрытие против обхода: две находки, две правки
Отражённый адрес туннеля раскрывает внутренний идентификатор по пути, который вы разрешили. Запрос напрямую через WAN обходит путь, который вы хотели требовать. Первое — вопрос информации, второе — вопрос принуждения, и исправляются они в разных местах. Если слить их в одно слово, получится правка, которая не решает ни одного из них.
WebRTC делает это заметнее, не делая это неправильным, ведь собрать кандидата — не то же самое, что выбрать его.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showВыполните запрос маршрута для каждого разрешённого адреса отражателя с источником, который, по вашему ожиданию, несёт этот поток, затем выполните его снова для исключённых диапазонов, чтобы увидеть, что выберет резервный вариант. Сравните два ответа с политикой, которую записали. Когда они расходятся так, как вы не задумывали, вы нашли точку правки, даже не пытаясь толковать список кандидатов браузера.