Яку адресу джерела бачить 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Виконайте запит маршруту для кожної дозволеної адреси відбивача з джерелом, яке, за вашим очікуванням, несе цей потік, потім виконайте його знову для виключених діапазонів, щоб побачити, що вибере резервний варіант. Порівняйте дві відповіді з політикою, яку записали. Коли вони розходяться так, як ви не задумували, ви знайшли точку правки, навіть не намагаючись тлумачити список кандидатів браузера.