Що розкриває відповідь 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-відбивача, а розбіжність між ними зазвичай указує на правило маршрутизації, а не на помилку.
Визначте політику, потім читайте відповідь
Запишіть намір до тестування: який трафік має використовувати тунель, який може виходити напряму, які родини адрес входять до області, і що має відбуватися, коли тунель не працює. Без цієї базової лінії кожне спостереження неоднозначне, бо ви не можете відокремити витік від шляху, який свідомо дозволили.
Далі ставте по одному питанню. Який шлях обирає цей адресат. Яку адресу повідомляє цей відбивач. Яку пару кандидатів обрала сесія. Тримайте відповіді поряд із політикою й датуйте їх, бо оновлення прошивки може змінити поведінку за замовчуванням так, що торішній висновок тихо втратить чинність.
Маршрутизатор залишається сильною точкою примусу, бо бачить трафік, який клієнт не може обійти, не переналаштувавши себе. Це не обіцянка, що кожне поле в кожному прикладному протоколі нічого не розкриває, і це не заміна запису шляхів, які ви вирішили дозволити.