Ką atskleidžia STUN atsakymas, kai VPN veikia maršrutizatoriuje
Maršrutizatoriaus tunelio adresas nėra naršyklės vietinis adresas. Sekite, kaip kiekviena užklausa maršrutizuojama ir verčiama, prieš skaitydami, ką praneša atšvaitas.
Kai tunelis gyvena maršrutizatoriuje, naršyklę vykdančiame kompiuteryje apskritai nėra tunelio sąsajos. Paklauskite to kompiuterio vietinių adresų ir gausite privatų LAN adresą bei grįžtamąją kilpą, nieko, kas primintų VPN adresą. Vis dėlto tolimojoje pusėje esantis STUN serveris vis dar gali pranešti ką nors reikšmingo apie kelią, ir tai, ką jis praneša, visiškai priklauso nuo to, kaip ta konkreti užklausa buvo maršrutizuota ir išversta.
Būtent šioje vietoje verta sulėtinti. „Naršyklė nevaldo VPN adreso“ atsako į klausimą apie sąsajas, o atspindėtas adresas yra atsakymas apie kelią per vertimą. Sumaišius abu, gaunamos užtikrintos išvados apie atskleidimą, kurių įrodymai nepalaiko.
Du įrenginiai, du sąsajų rinkiniai
Maršrutizatoriumi pagrįstoje sąrankoje tunelis baigiasi maršrutizatoriuje, o LAN klientas siunčia įprastą srautą savo numatytajam tinklų sietuvui. Kliento sąsajų sąrašas lieka trumpas: vienas privatus adresas, galbūt antras kitam tinklui, ir grįžtamoji kilpa. Rizika ne ta, kad vienas iš jų atsitiktinai yra tunelio adresas; rizika ta, kad užklausa išeina keliu, kurio nepasirinkote.
Paklauskite kliento kokį kelią pasirinktų konkretus tikslas, o ne kokių sąsajų yra. Atsakyme įvardijama sietuva ir šaltinio adresas, kurį naudotų branduolys, ir tai jau informatyviau už bet kokį adresų sąrašą.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDokumentacijos diapazonai yra geri bandymų tikslai, nes jie niekada neišsprendžiami į realią paslaugą. Palyginkite, ką sako klientas, su tuo, ką sako maršrutizatorius, ir bet kokį neatitikimą laikykite įrodymu, kad politika pagrįstas maršrutizavimas, suskaidyto tunelio taisyklė ar antrasis numatytasis maršrutas daro tai, ko neatsižvelgėte.
Ką Binding atsakymui leidžiama sakyti
RFC 8489 apibrėžia Binding užklausą ir atsakymą, kai serveris praneša tos užklausos stebėtą šaltinio transporto adresą. Tai teiginys apie vieną penketuką vienu momentu, o ne kliento sąsajų surašymas. Todėl viskas įdomaus vyksta tarp kliento ir stebėjimo taško.
Tą tarpą užpildo maršrutizavimas ir vertimas. Maršrutizatorius, kuris išeinančiam srautui atlieka šaltinio NAT, pakeičia kliento privatų šaltinį savo adresu išėjimo sąsajoje. Jei ta sąsaja yra tunelis, atšvaitas mato tunelio adresą. Jei paketas buvo pašalintas iš tunelio, atšvaitas mato tai, ką sukūrė WAN vertimas. Tas pats klientas, tas pats atšvaitas, kitas atsakymas.
Trys atvejai, kurie atrodo panašiai ir nėra tokie
Naudingas skirtumas yra ne viešas prieš privatų, o tai, kuris vykdymo taškas apdorojo paketą. Išnagrinėkite atvejus atsidarę paties maršrutizatoriaus lenteles, nes viena naršyklė gali sukurti visus tris priklausomai nuo taisyklės, kurią pamiršote, kad parašėte.
| 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 |
Tik antrasis atvejis pažeidžia reikalavimą, kad tam tikras srautas niekada neišeitų tiesiogiai, ir tik pirmasis bei trečiasis atskleidžia identifikatorių iš tunelio pusės. Nė viena iš trijų eilučių nėra teiginys apie konkretaus teikėjo elgesį: ar privatus atšvaitas apskritai pasiekiamas, priklauso nuo maršrutizavimo, kitos pusės leidžiamų IP adresų ir abiejų galų ugniasienės politikos.
Turėti paskyrą pas tą patį teikėją nieko iš to neįrodo. Verta prisiminti ir tai, kad maršrutizuota užklausa gali išsaugoti kliento LAN šaltinį, jei niekas jo neverčia, todėl šaltinio lauką reikia sekti, o ne numanyti iš topologijos schemos.
Rinkimas nėra atranka
WebRTC renka kandidatų adresus bandymui, ir diagnozės sąraše pasirodęs kandidatas gali niekada nepernešti medijos. Sąrašo skaitymas kaip „štai ką sužinojo kita pusė“ pervertina įrodymus. Pasirinkta pora yra tai, kas iš tikrųjų pernešė sesiją, ir ji yra kitame lauke.
HTTPS išėjimo tikrintuvas atsako dar į vieną klausimą: šaltinio adresą, kurį tos užklausos metu matė žiniatinklio serveris. Tai naudinga kryžminė patikra būtent todėl, kad naudoja kitą protokolą ir dažnai kitą tikslą nei UDP atšvaitas, o neatitikimas tarp jų paprastai rodo maršrutizavimo taisyklę, o ne klaidą.
Nuspręskite politiką, tada skaitykite atsakymą
Užrašykite ketinimą prieš testuodami: kuris srautas privalo naudoti tunelį, kuris gali išeiti tiesiogiai, kurios adresų šeimos patenka į aprėptį ir kas turėtų nutikti, kai tunelis neveikia. Be šios bazinės linijos kiekvienas stebėjimas yra dviprasmis, nes negalite atskirti nuotėkio nuo kelio, kurį sąmoningai leidote.
Tada klauskite po vieną klausimą. Kokį kelią pasirenka šis tikslas. Kokį adresą praneša šis atšvaitas. Kurią kandidatų porą pasirinko sesija. Laikykite atsakymus šalia politikos ir datuokite juos, nes programinės aparatinės įrangos atnaujinimas gali pakeisti numatytąjį elgesį taip, kad tyliai panaikintų praėjusių metų išvadą.
Maršrutizatorius vis dar yra stiprus vykdymo taškas, nes mato srautą, kurio klientas negali apeiti nepersikvietęs savęs. Tai ne pažadas, kad kiekvienas laukas kiekviename taikomajame protokole nieko neatskleidžia, ir tai nepakeičia kelio, kuriuos nusprendėte leisti, užrašymo.