Какво разкрива отговорът на 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, при които сървърът съобщава адреса на транспорта на източника, който е наблюдавал за тази заявка. Това е твърдение за една петица в един момент, а не преброяване на интерфейсите на клиента. Затова всичко интересно се случва между клиента и точката на наблюдение.
Тази празнина се запълва от маршрутизиране и преобразуване. Рутер, който прави source-NAT на изходящия трафик, заменя частния източник на клиента със своя адрес на изходящия интерфейс. Ако този интерфейс е тунелът, рефлекторът вижда адреса на тунела. Ако пакетът е изключен от тунела, рефлекторът вижда каквото е произвело преобразуването в 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 рефлектор, а разминаването между двете обикновено сочи към правило за маршрутизиране, а не към грешка.
Решете политиката, после четете отговора
Запишете намерението преди тестване: кой трафик трябва да използва тунела, кой може да излиза директно, кои семейства адреси са в обхвата и какво трябва да се случи, когато тунелът е недостъпен. Без тази базова линия всяко наблюдение е двусмислено, защото не можете да отделите изтичане от път, който съзнателно сте разрешили.
След това задавайте по един въпрос. Кой маршрут поема тази дестинация. Кой адрес съобщава този рефлектор. Коя кандидат двойка избра сесията. Пазете отговорите до политиката и ги датирайте, защото актуализация на фърмуера може да промени поведението по подразбиране по начини, които тихо обезсмислят миналогодишното заключение.
Рутерът все още е силна точка на прилагане, защото вижда трафик, който клиентът не може да заобиколи, без да преконфигурира самия себе си. Това не е обещание, че всяко поле във всеки приложен протокол не разкрива нищо, и не е заместител на записването на пътищата, които сте решили да разрешите.