Per què un punt d'accés redirigeix el DNS abans que es connecti la VPN?
Un punt d'accés reescriu les consultes a la seva pròpia xarxa, i un extrem amb nom d'amfitrió es resol abans que existeixi cap túnel. Seguiu quin resolutor ha respost cada consulta.
Unir-vos a una xarxa d'hotel us posa dues decisions de DNS al davant en moments diferents: les consultes que fa el dispositiu mentre inicieu sessió, i les que es fan un cop el túnel és actiu. Un punt d'accés pot influir en les primeres a través de la xarxa que controla. Les segones depenen de la política del client, que és una cosa separada que cal inspeccionar.
Recorreu la connexió en ordre, des del primer arrendament DHCP fins a la consulta que va resoldre un nom privat. Llavors dues fallades que en un tiquet de suport semblen idèntiques se separen netament: una va passar abans que existís el túnel, i l'altra va passar a dins.
Què pot i què no pot tocar el punt d'accés
La xarxa d'accés reparteix una adreça de resolutor via DHCP i pot interceptar el port 53 cap a aquesta adreça. Això n'hi ha prou per respondre cada consulta desprotegida amb una adreça de portal o una pàgina de bloqueig. També n'hi ha prou per trencar un client VPN l'extrem del qual està escrit com a nom d'amfitrió.
El que el punt d'accés no pot fer és llegir o reescriure una consulta un cop viatja dins d'un túnel establert, suposant que el túnel realment la transporti. La intercepció depèn de veure la pregunta en text pla.
Les consultes surten del túnel igualment per motius aliens al punt d'accés: la configuració de DNS segur del navegador, una regla de split-DNS que manté un sufix corporatiu al resolutor local, o un client configurat per excloure el DNS del túnel. Cadascuna és una elecció del costat del client, i cadascuna sembla una interferència del punt d'accés quan es mira des de fora.
| 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 |
La consulta d'arrencada passa abans que existeixi el túnel
Un client al qual es dóna un nom d'amfitrió l'ha de resoldre primer, i en aquell instant cap túnel protegeix la consulta. Si el punt d'accés respon amb una adreça de portal, la negociació falla o es penja. Si respon amb res, el client informa d'un error de nom i el túnel no s'inicia mai. Qualsevol dels dos resultats explica un registre de túnel buit que d'altra manera sembla innocent.
Els sistemes operatius també fan les seves pròpies comprovacions de connectivitat i descobriment de portal, descrites a RFC 8910 i RFC 8952, i aquestes peticions surten abans que cap VPN estigui actiu. Veure-les en un registre de proxy és un comportament esperat i no una prova de fuita.
La solució pràctica és donar al client un extrem que no necessiti cap consulta. Quan això és impossible, acabeu primer l'inici de sessió i connecteu després.
Esbrineu quin resolutor ha respost
Pregunteu al sistema i no al navegador, i executeu la consulta dues vegades: una a través del resolutor que el dispositiu fa servir ara, i una contra una adreça fixa.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Una resposta de la primera ordre que difereixi de la tercera us diu que el resolutor local retorna una altra cosa, que és el que fa un punt d'accés que redirigeix. Una fallada de la tercera juntament amb un èxit de la primera assenyala el portal: el resolutor local va servir una adreça d'inici de sessió mentre el port 53 de sortida era descartat. Els temps d'espera en ambdues volen dir que la xarxa descarta el DNS fins que l'autenticació es completa.
Repetiu-ho després de connectar i compareu. Una resposta en memòria cau sobreviu a la transició, així que buideu la memòria cau o consulteu un nom nou per a la segona observació.
Mantingueu les consultes posteriors al camí que volíeu
Un perfil de túnel complet que també capturi el DNS és l'organització més senzilla: cada consulta de cada aplicació va al resolutor que el túnel empeny, i la xarxa local només veu trànsit xifrat. Demostreu-ho resolent un nom intern i un de públic després de connectar, i comparant després les dues respostes amb el que el resolutor del túnel retorna per si sol.
El split-DNS necessita una llista de dominis escrita amb intenció: sufixos corporatius pel túnel, tota la resta en local, i cap solapament entre les dues.
El DNS segur del navegador queda fora d'aquesta política, així que si ha d'estar desactivat perquè el perfil es comporti de manera previsible, desactiveu-lo per a aquest perfil i no per a la màquina. Feu-ho a la configuració del navegador, no editant el resolutor del sistema, perquè el canvi sigui visible la propera vegada. Anoteu la resposta, el resolutor i l'etapa de connexió en una línia per prova. Un informe que diu que el DNS ha fallat al Wi-Fi de l'hotel descriu un símptoma amb almenys tres causes diferents.