Zakaj hotspot preusmeri DNS, preden se VPN poveže?
Hotspot prepisuje poizvedbe v svojem omrežju, končna točka z imenom gostitelja pa se razreši, preden obstaja kakršen koli tunel. Sledite, kateri razreševalnik je odgovoril na vsako poizvedbo.
Pridružitev hotelskemu omrežju pred vas postavi dve odločitvi o DNS ob različnih trenutkih: poizvedbe, ki jih naprava izvede med prijavo, in poizvedbe, izvedene po vzpostavitvi tunela. Hotspot lahko vpliva na prve prek omrežja, ki ga nadzoruje. Druge so odvisne od politike samega odjemalca, kar je treba preveriti ločeno.
Pojdite skozi povezavo po vrsti, od prvega najema DHCP do poizvedbe, ki je razrešila zasebno ime. Takrat se dve napaki, ki sta v zahtevku za podporo videti enaki, jasno ločita: ena se je zgodila pred tunelom, druga znotraj njega.
Česa se hotspot lahko in česa ne more dotakniti
Dostopovno omrežje dodeli naslov razreševalnika prek DHCP in lahko prestreže vrata 53 proti temu naslovu. To zadostuje, da se na vsako nezaščiteno poizvedbo odgovori z naslovom portala ali stranjo za blokiranje. Zadostuje tudi za zlom odjemalca VPN, katerega končna točka je zapisana kot ime gostitelja.
Česar hotspot ne more, je brati ali prepisovati poizvedbe, ko ta že potuje znotraj vzpostavljenega tunela, ob predpostavki, da jo tunel resnično nosi. Prestrezanje je odvisno od videnja vprašanja v odprtem besedilu.
Poizvedbe vseeno zapustijo tunel iz razlogov, ki niso povezani s hotspotom: nastavitev varnega DNS v brskalniku, pravilo split-DNS, ki ohrani podjetniško pripono na lokalnem razreševalniku, ali odjemalec, nastavljen tako, da DNS izključi iz tunela. Vsaka je izbira na strani odjemalca in vsaka od zunaj izgleda kot vmešavanje hotspota.
| 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 |
Začetna poizvedba se zgodi, preden tunel obstaja
Odjemalec, ki dobi ime gostitelja, ga mora najprej razrešiti, in v tistem trenutku noben tunel ne ščiti poizvedbe. Če hotspot odgovori z naslovom portala, pogajanje propade ali se zatakne. Če ne odgovori z ničimer, odjemalec sporoči napako imena in tunel se nikoli ne zažene. Kateri koli od obeh izidov pojasni prazen dnevnik tunela, ki sicer izgleda nedolžno.
Operacijski sistemi izvajajo tudi lastne preveritve povezljivosti in odkrivanje portala, opisane v RFC 8910 in RFC 8952, in te zahteve odidejo, preden je vzpostavljen kateri koli VPN. Videti jih v dnevniku proxyja je pričakovano vedenje in ne dokaz o uhajanju.
Praktična rešitev je odjemalcu dati končno točko, ki ne potrebuje poizvedbe. Ko to ni mogoče, najprej dokončajte prijavo in se šele nato povežite.
Ugotovite, kateri razreševalnik je odgovoril
Vprašajte sistem in ne brskalnik, ter poizvedbo izvedite dvakrat: enkrat prek razreševalnika, ki ga naprava zdaj uporablja, enkrat proti fiksnemu naslovu.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Odgovor prvega ukaza, ki se razlikuje od tretjega, vam pove, da lokalni razreševalnik vrača nekaj drugega, kar počne prav preusmerjajoči hotspot. Napaka tretjega skupaj z uspehom prvega kaže na portal: lokalni razreševalnik je postregel z naslovom za prijavo, medtem ko so bila odhodna vrata 53 zavržena. Časovna omejitev pri obeh pomeni, da omrežje zavrže DNS, dokler se preverjanje ne zaključi.
Ponovite po povezavi in primerjajte. Shranjeni odgovor preživi prehod, zato izpraznite predpomnilnik ali za drugo opazovanje vprašajte po novem imenu.
Ohranite poznejše poizvedbe na predvideni poti
Profil polnega tunela, ki zajame tudi DNS, je najpreprostejša ureditev: vsaka poizvedba vsake aplikacije gre k razreševalniku, ki ga vsiljuje tunel, in lokalno omrežje vidi le šifriran promet. Dokažite to tako, da po povezavi razrešite notranje in javno ime, nato pa oba odgovora primerjate s tem, kar razreševalnik tunela vrne sam.
Split-DNS potrebuje seznam domen, napisan z namenom: podjetniške pripone skozi tunel, vse ostalo lokalno in brez prekrivanja med obema.
Varni DNS brskalnika stoji zunaj te politike, zato ga, če mora biti izklopljen, da se profil obnaša predvidljivo, izklopite za ta profil in ne za stroj. To storite v nastavitvah brskalnika, ne z urejanjem sistemskega razreševalnika, da bo sprememba naslednjič vidna. Zapišite odgovor, razreševalnik in fazo povezave v eno vrstico na test. Poročilo, da je DNS spodletel v hotelskem Wi-Fi, opisuje simptom z vsaj tremi različnimi vzroki.