De ce un hotspot redirecționează DNS înainte ca VPN-ul să se conecteze?
Un hotspot rescrie interogările în propria rețea, iar un punct final scris ca nume de gazdă este rezolvat înainte de a exista vreun tunel. Urmăriți ce resolver a răspuns la fiecare interogare.
Conectarea la o rețea de hotel pune două decizii DNS în fața dumneavoastră în momente diferite: interogările pe care dispozitivul le face la autentificare și interogările făcute după ce tunelul este ridicat. Un hotspot poate influența primele prin rețeaua pe care o controlează. Celelalte depind de politica clientului însuși, ceea ce este un lucru separat de verificat.
Parcurgeți conexiunea în ordine, de la primul lease DHCP până la interogarea care a rezolvat un nume privat. Atunci două defecțiuni care într-un tichet de suport arată identic se separă curat: una s-a produs înainte de a exista tunelul, cealaltă în interiorul lui.
Ce poate și ce nu poate atinge hotspotul
Rețeaua de acces distribuie o adresă de resolver prin DHCP și poate intercepta portul 53 către acea adresă. Este suficient pentru a răspunde la fiecare interogare neprotejată cu o adresă de portal sau o pagină de blocare. Este suficient și pentru a rupe un client VPN al cărui punct final este scris ca nume de gazdă.
Ce nu poate hotspotul este să citească sau să rescrie o interogare odată ce aceasta circulă în interiorul unui tunel stabilit, presupunând că tunelul o transportă cu adevărat. Interceptarea depinde de vederea întrebării în text simplu.
Interogările părăsesc totuși tunelul din motive fără legătură cu hotspotul: setarea de DNS securizat a browserului, o regulă split-DNS care păstrează un sufix corporativ la resolverul local sau un client configurat să excludă DNS-ul din tunel. Fiecare este o alegere din partea clientului și fiecare pare o interferență a hotspotului când este privită din exterior.
| 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 |
Interogarea inițială are loc înainte de a exista tunelul
Un client căruia i se dă un nume de gazdă trebuie să îl rezolve mai întâi, iar în acel moment niciun tunel nu protejează interogarea. Dacă hotspotul răspunde cu o adresă de portal, negocierea eșuează sau se blochează. Dacă răspunde cu nimic, clientul raportează o eroare de nume și tunelul nu pornește niciodată. Oricare dintre cele două rezultate explică un jurnal de tunel gol care altfel pare inocent.
Sistemele de operare rulează și propriile verificări de conectivitate și descoperirea portalului, descrise în RFC 8910 și RFC 8952, iar acele cereri pleacă înainte ca vreun VPN să fie ridicat. A le vedea într-un jurnal de proxy este un comportament așteptat, nu o dovadă a unei scurgeri.
Soluția practică este să dați clientului un punct final care nu are nevoie de interogare. Când acest lucru este imposibil, terminați mai întâi autentificarea și conectați-vă după aceea.
Aflați ce resolver a răspuns
Întrebați sistemul, nu browserul, și rulați interogarea de două ori: o dată prin orice resolver folosește dispozitivul acum, o dată către o adresă fixă.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Un răspuns al primei comenzi diferit de al treilea vă spune că resolverul local returnează altceva, ceea ce face exact un hotspot care redirecționează. O eroare a celei de-a treia împreună cu un succes al primei indică portalul: resolverul local a servit o adresă de autentificare în timp ce portul 53 de ieșire era aruncat. Expirarea timpului la ambele înseamnă că rețeaua aruncă DNS până când autentificarea se încheie.
Repetați după conectare și comparați. Un răspuns din cache supraviețuiește tranziției, așa că goliți cache-ul sau întrebați un nume nou pentru a doua observație.
Păstrați interogările ulterioare pe calea intenționată
Un profil de tunel complet care capturează și DNS este cea mai simplă aranjare: fiecare interogare din fiecare aplicație merge la resolverul impus de tunel, iar rețeaua locală vede doar trafic criptat. Dovediți-o rezolvând un nume intern și unul public după conectare, apoi comparând ambele răspunsuri cu ceea ce returnează resolverul tunelului de unul singur.
Split-DNS are nevoie de o listă de domenii scrisă cu intenție: sufixe corporative prin tunel, tot restul local și fără suprapunere între cele două.
DNS-ul securizat al browserului stă în afara acelei politici, așa că dacă trebuie să fie oprit pentru ca profilul să se comporte previzibil, opriți-l pentru acel profil, nu pentru mașină. Faceți asta în setările browserului, nu editând resolverul sistemului, ca schimbarea să fie vizibilă data viitoare. Notați răspunsul, resolverul și etapa conexiunii pe o linie pentru fiecare test. Un raport care spune că DNS-ul a eșuat pe Wi-Fi-ul hotelului descrie un simptom cu cel puțin trei cauze diferite.