Miért irányítja át a hotspot a DNS-t, mielőtt a VPN csatlakozna?
A hotspot a saját hálózatán átírja a lekérdezéseket, és a hosztnév-végpont már azelőtt feloldódik, hogy bármilyen alagút létezne. Kövesse nyomon, melyik feloldó válaszolt az egyes lekérdezésekre.
Egy szállodai hálózathoz csatlakozva két DNS-döntés kerül elé különböző pillanatokban: a bejelentkezés közben végzett lekérdezések és azok, amelyek az alagút felállása után történnek. A hotspot az elsőket az általa vezérelt hálózaton keresztül befolyásolhatja. A másodikak magának a kliensnek a szabályzatától függenek, ami külön vizsgálandó dolog.
Járja végig a kapcsolatot sorrendben, az első DHCP-bérlettől a privát nevet feloldó lekérdezésig. Ekkor két hiba, amely egy támogatási jegyben azonosnak tűnik, tisztán elválik: az egyik az alagút előtt történt, a másik benne.
Mihez tud és mihez nem tud hozzányúlni a hotspot
A hozzáférési hálózat DHCP-ben oszt ki egy feloldócímet, és elkaphatja az 53-as portot afelé a cím felé. Ez elég ahhoz, hogy minden védelem nélküli lekérdezésre portálcímmel vagy blokkolóoldallal válaszoljon. Az is elég, hogy eltörjön egy VPN-klienst, amelynek végpontja hosztnévként van megadva.
Amit a hotspot nem tud, az az, hogy olvasson vagy átírjon egy lekérdezést, miután az egy létrejött alagúton belül utazik, feltéve hogy az alagút valóban szállítja. Az elfogás attól függ, hogy látja-e a kérdést nyílt szövegben.
A lekérdezések mégis elhagyják az alagutat, a hotspotot nem érintő okokból: a böngésző biztonságos DNS-beállítása, egy split-DNS szabály, amely a vállalati utótagot a helyi feloldón tartja, vagy egy kliens, amelyet úgy állítottak be, hogy kizárja a DNS-t az alagútból. Mindegyik kliensoldali választás, és mindegyik hotspot-zavarásnak látszik kívülről.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
A kezdeti lekérdezés az alagút előtt történik
Az a kliens, amely hosztnevet kap, először fel kell oldja azt, és abban a pillanatban semmilyen alagút nem védi a lekérdezést. Ha a hotspot portálcímmel válaszol, a tárgyalás meghiúsul vagy megakad. Ha semmivel sem válaszol, a kliens névhibát jelent, és az alagút soha nem indul el. Mindkét kimenet magyaráz egy üres alagútnaplót, amely egyébként ártatlannak tűnik.
Az operációs rendszerek saját kapcsolatellenőrzéseket és portálfelderítést is futtatnak, amelyeket az RFC 8910 és az RFC 8952 ír le, és ezek a kérések bármilyen VPN felállása előtt kimennek. Ezeket proxy naplóban látni várt viselkedés, nem szivárgás bizonyítéka.
A gyakorlati megoldás az, hogy a kliens olyan végpontot kapjon, amelyhez nem kell lekérdezés. Ha ez lehetetlen, előbb fejezze be a bejelentkezést, és utána csatlakozzon.
Derítse ki, melyik feloldó válaszolt
A rendszert kérdezze, ne a böngészőt, és futtassa a lekérdezést kétszer: egyszer azon a feloldón keresztül, amelyet az eszköz éppen használ, egyszer egy rögzített cím ellen.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Az első parancs válasza, amely eltér a harmadikétól, azt mondja, hogy a helyi feloldó valami mást ad vissza, és pontosan ezt teszi egy átirányító hotspot. A harmadik hibája az első sikerével együtt a portálra mutat: a helyi feloldó bejelentkezési címet szolgált ki, miközben a kimenő 53-as portot eldobták. Mindkettőnél az időtúllépés azt jelenti, hogy a hálózat eldobja a DNS-t, amíg a hitelesítés be nem fejeződik.
Ismételje meg csatlakozás után, és hasonlítsa össze. A gyorsítótárazott válasz túléli az átmenetet, ezért ürítse a gyorsítótárat, vagy kérdezzen új nevet a második megfigyeléshez.
Tartsa a későbbi lekérdezéseket a szándékolt úton
A teljes alagút profil, amely a DNS-t is elkapja, a legegyszerűbb elrendezés: minden alkalmazás minden lekérdezése ahhoz a feloldóhoz megy, amelyet az alagút kényszerít, és a helyi hálózat csak titkosított forgalmat lát. Bizonyítsa ezt úgy, hogy csatlakozás után felold egy belső és egy nyilvános nevet, majd mindkét választ összeveti azzal, amit az alagút feloldója magában visszaad.
A split-DNS-hez szándékkal megírt tartománylista kell: vállalati utótagok az alagúton át, minden más helyben, és a kettő között nincs átfedés.
A böngésző biztonságos DNS-e ezen a szabályzaton kívül esik, ezért ha ki kell kapcsolni ahhoz, hogy a profil kiszámíthatóan viselkedjen, akkor a profilhoz kapcsolja ki, nem a géphez. Ezt a böngésző beállításaiban tegye, ne a rendszer feloldójának szerkesztésével, hogy a változás legközelebb látható legyen. Jegyezze fel a választ, a feloldót és a kapcsolat szakaszát egy sorban tesztenként. Az a jelentés, amely szerint a DNS meghiúsult a szállodai Wi-Fi-n, legalább három különböző okú tünetet ír le.