Шта открива 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 захтев и одговор, при чему сервер извештава изворну транспортну адресу коју је приметио за тај захтев. То је тврдња о једној петерки у једном тренутку, а не попис интерфејса клијента. Зато се све занимљиво дешава између клијента и тачке посматрања.
Тај јаз попуњавају усмеравање и превод. Рутер који ради изворни 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 рефлектора, а неслагање између њих обично указује на правило усмеравања, а не на грешку.
Одлучите политику, затим прочитајте одговор
Запишите намеру пре тестирања: који саобраћај мора да користи тунел, који сме да излази директно, које су породице адреса у обухвату и шта треба да се догоди када је тунел искључен. Без те основне линије свако посматрање је двосмислено, јер не можете да одвојите цурење од пута који сте намерно дозволили.
Затим постављајте једно питање у једном тренутку. Којим путем иде ово одредиште. Коју адресу извештава овај рефлектор. Који кандидатски пар је изабрала сесија. Држите одговоре поред политике и датирајте их, јер ажурирање фирмвера може да промени подразумевано понашање тако да тихо поништи прошлогодишњи закључак.
Рутер је и даље јака тачка спровођења, јер види саобраћај који клијент не може да заобиђе без преконфигурисања самог себе. То није обећање да свако поље у сваком апликацијском протоколу ништа не открива, и није замена за записивање путева које сте одлучили да дозволите.