Mit árul el egy STUN-válasz, amikor a VPN a routeren fut
A router alagútcíme nem a böngésző helyi címe. Kövesse nyomon, hogyan útvonalazódik és fordul le minden kérés, mielőtt elolvassa, mit jelent egy reflektor.
Amikor az alagút a routeren él, a böngészőt futtató gépnek egyáltalán nincs alagút-interfésze. Kérdezze meg azt a gépet a helyi címeiről, és privát LAN-címet meg egy visszacsatolót kap, semmit, ami VPN-címre emlékeztetne. Mégis, a túloldali STUN-kiszolgáló továbbra is jelenthet valami értelmeset az útvonalról, és hogy mit jelent, az teljes mértékben attól függ, hogyan útvonalazódott és fordult le az a konkrét kérés.
Ez az a rész, amelynél érdemes lelassítani. A „a böngésző nem birtokolja a VPN-címet” egy interfészekre vonatkozó kérdésre válaszol, míg a tükrözött cím egy fordításen átvezető útvonalra adott válasz. A kettő összekeverése magabiztos következtetéseket szül a felfedésről, amelyeket a bizonyítékok nem támasztanak alá.
Két eszköz, két interfészkészlet
Routeralapú elrendezésben az alagút a routeren végződik, és a LAN-kliens a szokásos forgalmat az alapértelmezett átjárójára küldi. A kliens interfészlistája rövid marad: egy privát cím, esetleg egy második egy másik hálózat számára, és a visszacsatoló. A kockázat nem az, hogy valamelyik véletlenül az alagút cím; hanem az, hogy a kérés olyan útvonalon lép ki, amelyet nem választott.
Kérdezze meg a klienstől melyik útvonalat venné egy adott cél ahelyett, hogy azt kérdezné, milyen interfészek léteznek. A válasz megnevez egy átjárót és a forráscímet, amelyet a kernel használna, ami már informatívabb bármely címlistánál.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsA dokumentációs tartományok jó tesztcélok, mert soha nem oldódnak fel valódi szolgáltatásra. Hasonlítsa össze, mit mond a kliens azzal, mit mond a router, és minden eltérést kezeljen bizonyítékként arra, hogy a házirend-alapú útvonalválasztás, egy osztott alagút szabály vagy egy második alapértelmezett útvonal olyat tesz, amire nem számított.
Mit mondhat egy Binding-válasz
Az RFC 8489 definiálja a Binding kérést és választ, amelyben a kiszolgáló jelenti az adott kérésnél megfigyelt forrás-transzportcímet. Ez egy ötösről szóló állítás egyetlen pillanatban, nem a kliens interfészeinek összeírása. Ezért minden érdekes dolog a kliens és a megfigyelési pont között történik.
Ezt a rést útvonalválasztás és fordítás tölti ki. Az a router, amely a kimenő forgalmon forrás-NAT-ot végez, a kliens privát forrását a saját címére cseréli a kimenő interfészen. Ha ez az interfész az alagút, a reflektor az alagút címét látja. Ha a csomag kimaradt az alagútból, a reflektor azt látja, amit a WAN-fordítás létrehozott. Ugyanaz a kliens, ugyanaz a reflektor, más válasz.
Három eset, amely hasonlónak látszik, és nem az
A hasznos megkülönböztetés nem a nyilvános kontra privát, hanem hogy melyik kényszerítési pont kezelte a csomagot. Dolgozza végig az eseteket a router saját tábláival nyitva, mert egyetlen böngésző mindhármat előállíthatja attól függően, milyen szabályt felejtett el megírni.
| 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 |
Csak a második eset sérti meg azt a követelményt, hogy bizonyos forgalom soha ne lépjen ki közvetlenül, és csak az első és a harmadik fed fel az alagút oldaláról származó azonosítót. A három sor egyike sem állítás egy adott szolgáltató viselkedéséről: hogy egy privát reflektor egyáltalán elérhető-e, az útvonalválasztástól, a másik fél engedélyezett IP-címeitől és a tűzfal házirendjétől függ mindkét végén.
Ugyanannál a szolgáltatónál lévő fiók ezek közül semmit nem bizonyít. Érdemes azt is megjegyezni, hogy egy útvonalazott kérés megtarthatja a kliens LAN-forrását, ha semmi nem fordítja le, ezért a forrásmezőt nyomon kell követni, nem pedig a topológiai ábrából feltételezni.
A gyűjtés nem kiválasztás
A WebRTC jelöltcímeket gyűjt kipróbálásra, és előfordulhat, hogy egy diagnosztikai listán megjelenő jelölt soha nem visz médiát. A lista „ezt tanulta meg a másik fél” olvasata túlértékeli a bizonyítékot. A kiválasztott pár az, amely ténylegesen vitte a munkamenetet, és az egy másik mezőben él.
Egy HTTPS-kilépésvizsgáló még egy kérdésre válaszol: arra a forráscímre, amelyet egy webkiszolgáló látott a kérésnél. Éppen azért hasznos keresztellenőrzés, mert más protokollt és gyakran más célt használ, mint egy UDP-reflektor, és a kettő közötti eltérés általában útvonalválasztási szabályra, nem hibára utal.
Döntse el a házirendet, aztán olvassa el a választ
Írja le a szándékot a tesztelés előtt: melyik forgalomnak kell az alagutat használnia, melyik léphet ki közvetlenül, mely címcsaládok tartoznak a hatókörbe, és mi történjen, amikor az alagút nem működik. E bázisvonal nélkül minden megfigyelés kétértelmű, mert nem tudja elválasztani a szivárgást egy szándékosan engedélyezett útvonaltól.
Aztán egyszerre egy kérdést tegyen fel. Melyik útvonalat veszi ez a cél. Melyik címet jelenti ez a reflektor. Melyik jelöltpárt választotta a munkamenet. Tartsa a válaszokat a házirend mellett, és lássa el dátummal őket, mert egy firmware-frissítés olyan módon változtathatja meg az alapértelmezett viselkedést, amely csendben érvényteleníti a tavalyi következtetést.
A router továbbra is erős kényszerítési pont, mert olyan forgalmat lát, amelyet egy kliens nem kerülhet meg anélkül, hogy önmagát újrakonfigurálná. Ez nem ígéret arra, hogy minden alkalmazási protokoll minden mezője semmit nem fed fel, és nem helyettesíti azoknak az útvonalaknak a leírását, amelyeket engedélyezni választott.