Kaj razkrije odgovor STUN, ko VPN teče na usmerjevalniku
Naslov tunela na usmerjevalniku ni lokalni naslov brskalnika. Sledite, kako se vsaka zahteva usmerja in prevaja, preden preberete, kaj poroča odsevnik.
Ko tunel živi na usmerjevalniku, računalnik, na katerem teče brskalnik, sploh nima vmesnika tunela. Vprašajte ta računalnik za njegove lokalne naslove in dobili boste zasebni naslov LAN in zanko, nič, kar bi spominjalo na naslov VPN. Kljub temu lahko strežnik STUN na drugi strani še vedno poroča nekaj smiselnega o poti, in kar poroča, je v celoti odvisno od tega, kako je bila ta konkretna zahteva usmerjena in prevedena.
Prav ta del si zasluži upočasnitev. „Brskalnik ne poseduje naslova VPN“ odgovarja na vprašanje o vmesnikih, medtem ko je odsevan naslov odgovor o poti skozi prevod. Mešanje obojega ustvari samozavestne sklepe o razkritju, ki jih dokazi ne podpirajo.
Dve napravi, dva niza vmesnikov
V postavitvi z usmerjevalnikom se tunel konča na usmerjevalniku, odjemalec LAN pa pošilja običajen promet na svoj privzeti prehod. Seznam vmesnikov odjemalca ostane kratek: en zasebni naslov, morda drugi za drugo omrežje, in zanka. Tveganje ni v tem, da bi bil eden od njih po naključju naslov tunela; tveganje je v tem, da zahteva odide po poti, ki si je niste izbrali.
Vprašajte odjemalca katero pot bi prevzel določen cilj, namesto da sprašujete, kateri vmesniki obstajajo. Odgovor navede prehod in izvorni naslov, ki bi ga uporabilo jedro, in to je že bolj informativno od katerega koli seznama naslovov.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDokumentacijska območja so dobre testne destinacije, ker se nikoli ne razrešijo v resnično storitev. Primerjajte, kaj pravi odjemalec, s tem, kar pravi usmerjevalnik, in vsako neskladje obravnavajte kot dokaz, da usmerjanje po pravilniku, pravilo razdeljenega tunela ali druga privzeta pot dela nekaj, česar niste upoštevali.
Kaj sme povedati odgovor Binding
RFC 8489 določa zahtevo in odgovor Binding, pri katerih strežnik poroča izvorni transportni naslov, ki ga je opazil pri tej zahtevi. To je trditev o enem peterčku v enem trenutku, ne popis odjemalčevih vmesnikov. Zato se vse zanimivo dogaja med odjemalcem in točko opazovanja.
To vrzel zapolnita usmerjanje in prevod. Usmerjevalnik, ki na odhodnem prometu izvaja izvorni NAT, zamenja zasebni izvor odjemalca z lastnim naslovom na odhodnem vmesniku. Če je ta vmesnik tunel, odsevnik vidi naslov tunela. Če je bil paket izključen iz tunela, odsevnik vidi, kar je ustvaril prevod WAN. Isti odjemalec, isti odsevnik, drugačen odgovor.
Trije primeri, ki so si podobni in niso
Koristna razlika ni javno proti zasebnemu, ampak katera točka uveljavljanja je obravnavala paket. Predelajte primere z odprtimi lastnimi tabelami usmerjevalnika, saj lahko en brskalnik ustvari vse tri glede na pravilo, za katero ste pozabili, da ste ga napisali.
| 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 |
Samo drugi primer krši zahtevo, da določen promet nikoli ne odide neposredno, in samo prvi in tretji razkrijeta identifikator s strani tunela. Nobena od treh vrstic ni trditev o vedenju določenega ponudnika: ali je zasebni odsevnik sploh dosegljiv, je odvisno od usmerjanja, dovoljenih naslovov IP druge strani in politike požarnega zidu na obeh koncih.
Imeti račun pri istem ponudniku ne dokaže nič od tega. Vredno je zapomniti tudi, da lahko usmerjena zahteva obdrži izvor LAN odjemalca, če ga nič ne prevede, zato je treba polje izvora izslediti, ne pa ga domnevati iz diagrama topologije.
Zbiranje ni izbiranje
WebRTC zbira kandidatne naslove za preizkus, in kandidat, ki se pojavi na diagnostičnem seznamu, morda nikoli ne prenaša medijev. Branje seznama kot „to se je druga stran naučila“ precenjuje dokaze. Izbrani par je tisti, ki je resnično prenašal sejo, in je v drugem polju.
Preverjevalnik izhoda HTTPS odgovarja na še eno vprašanje: izvorni naslov, ki ga je spletni strežnik videl za to zahtevo. To je koristno navzkrižno preverjanje prav zato, ker uporablja drug protokol in pogosto drug cilj kot odsevnik UDP, in neskladje med njima običajno kaže na pravilo usmerjanja, ne na napako.
Določite politiko, nato preberite odgovor
Zapišite namero pred testiranjem: kateri promet mora uporabljati tunel, kateri lahko odide neposredno, katere družine naslovov so v obsegu in kaj naj se zgodi, ko tunel ni dosegljiv. Brez te osnovne črte je vsako opazovanje dvoumno, ker ne morete ločiti uhajanja od poti, ki ste jo namerno dovolili.
Nato postavite eno vprašanje naenkrat. Katero pot prevzame ta cilj. Kateri naslov poroča ta odsevnik. Kateri kandidatni par je izbrala seja. Odgovore imejte ob politiki in jih datirajte, ker lahko posodobitev strojne programske opreme spremeni privzeto vedenje tako, da tiho razveljavi lanskoletni sklep.
Usmerjevalnik je še vedno močna točka uveljavljanja, ker vidi promet, ki se mu odjemalec ne more izogniti, ne da bi prekonfiguriral samega sebe. To ni obljuba, da nobeno polje v nobenem aplikacijskem protokolu ničesar ne razkrije, in ni nadomestilo za zapis poti, ki ste se jih odločili dovoliti.