Miks suunab hotspot DNS-i ümber enne, kui VPN ühendub?
Hotspot kirjutab oma võrgus päringud ümber ja hostinime lõpp-punkt lahendatakse enne, kui ükskõik milline tunnel olemas on. Jälgige, milline resoluutija igale päringule vastas.
Hotellivõrguga liitumine seab teie ette kaks DNS-otsust erinevatel hetkedel: päringud, mida seade sisselogimise ajal teeb, ja päringud, mis tehakse pärast tunneli püstitamist. Hotspot saab esimesi mõjutada võrgu kaudu, mida ta kontrollib. Teised sõltuvad kliendi enda poliitikast, mis on eraldi uuritav asi.
Käige ühendus järjekorras läbi, esimesest DHCP-rendist kuni päringuni, mis lahendas privaatse nime. Siis eralduvad selgelt kaks tõrget, mis tugipiletis ühesugused välja näevad: üks juhtus enne, kui tunnel olemas oli, ja teine selle sees.
Mida hotspot puutuda saab ja mida mitte
Juurdepääsuvõrk jagab DHCP kaudu resoluutija aadressi ja võib selle aadressi suunas porti 53 pealt kuulata. Sellest piisab, et vastata igale kaitsmata päringule portaali aadressi või blokeerimislehega. Sellest piisab ka VPN-kliendi lõhkumiseks, mille lõpp-punkt on kirjutatud hostinimena.
Mida hotspot teha ei saa, on päringut lugeda või ümber kirjutada, kui see liigub juba loodud tunneli sees, eeldusel, et tunnel seda tõesti kannab. Pealtkuulamine sõltub küsimuse nägemisest lihttekstina.
Päringud lahkuvad tunnelist ikkagi hotspotiga mitteseotud põhjustel: brauseri turvalise DNS-i seade, split-DNS-i reegel, mis hoiab ettevõtte sufiksit kohalikus resoluutijas, või klient, mis on seadistatud DNS-i tunnelist välja jätma. Igaüks on kliendipoolne valik ja igaüks näeb väljast vaadates välja nagu hotspoti sekkumine.
| 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 |
Algne päring toimub enne, kui tunnel olemas on
Klients, kellele antakse hostinimi, peab selle esmalt lahendama ja sel hetkel ei kaitse päringut ükski tunnel. Kui hotspot vastab portaali aadressiga, nurjub läbirääkimine või jääb rippuma. Kui ta ei vasta millegagi, teatab klient nimeveast ja tunnel ei käivitu kunagi. Kumbki tulemus seletab tühja tunnelilogi, mis muidu süütuna tundub.
Operatsioonisüsteemid teevad ka oma ühenduvuskontrolle ja portaalituvastust, mida kirjeldavad RFC 8910 ja RFC 8952, ning need päringud väljuvad enne, kui ükski VPN püsti on. Nende nägemine puhverserveri logis on oodatud käitumine, mitte lekkimise tõestus.
Praktiline lahendus on anda kliendile lõpp-punkt, mis ei vaja päringut. Kui see on võimatu, lõpetage esmalt sisselogimine ja ühenduge seejärel.
Tehke kindlaks, milline resoluutija vastas
Küsige süsteemilt, mitte brauserilt, ja käivitage päring kaks korda: üks kord läbi selle resoluutija, mida seade praegu kasutab, ja üks kord fikseeritud aadressi vastu.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Esimese käsu vastus, mis erineb kolmandast, ütleb, et kohalik resoluutija tagastab midagi muud, mida ümbersuunav hotspot teebki. Kolmanda tõrge koos esimese õnnestumisega osutab portaalile: kohalik resoluutija serveeris sisselogimisaadressi, samal ajal kui väljuv port 53 visati kõrvale. Mõlema puhul tähendab aegumine, et võrk loobub DNS-ist, kuni autentimine lõpeb.
Korrake pärast ühendamist ja võrrelge. Vahemällu salvestatud vastus elab ülemineku üle, seega tühjendage vahemälu või küsige teise vaatluse jaoks uut nime.
Hoidke hilisemad päringud kavatsetud teel
Täistunneli profiil, mis haarab ka DNS-i, on kõige lihtsam lahendus: iga rakenduse iga päring läheb resoluutijale, mille tunnel ette annab, ja kohalik võrk näeb ainult krüpteeritud liiklust. Tõestage seda, lahendades pärast ühendamist ühe sisemise ja ühe avaliku nime ning võrreldes seejärel mõlemat vastust sellega, mida tunneli resoluutija ise tagastab.
Split-DNS vajab kavatsusega kirjutatud domeenide loendit: ettevõtte sufiksid läbi tunneli, kõik muu kohapeal ja nende kahe vahel ei mingit kattumist.
Brauseri turvaline DNS jääb sellest poliitikast väljapoole, nii et kui see peab profiili prognoositava käitumise huvides väljas olema, lülitage see välja selle profiili jaoks, mitte masina jaoks. Tehke seda brauseri seadetes, mitte süsteemi resoluutijat muutes, et muudatus oleks järgmisel korral nähtav. Kirjutage vastus, resoluutija ja ühenduse etapp ühele reale iga testi kohta. Aruanne, mis ütleb, et DNS ebaõnnestus hotelli Wi-Fi-s, kirjeldab sümptomit vähemalt kolme erineva põhjusega.