Por que un punto de acceso redirixe o DNS antes de que se conecte a VPN?
Un punto de acceso reescribe as consultas na súa propia rede, e un extremo con nome de host resólvese antes de que exista calquera túnel. Rastree que resolutor respondeu a cada consulta.
Unirse a unha rede de hotel expón dúas decisións de DNS en momentos distintos: as consultas que o dispositivo fai mentres inicia sesión e as que se fan unha vez levantado o túnel. Un punto de acceso pode influír nas primeiras mediante a rede que controla. As segundas dependen da política do propio cliente, que é algo aparte que hai que inspeccionar.
Percorra a conexión en orde, desde o primeiro arrendamento DHCP ata a consulta que resolveu un nome privado. Así dous fallos que nun ticket de soporte parecen idénticos sepáranse con claridade: un ocorreu antes de que existise o túnel e o outro ocorreu dentro del.
Que pode e que non pode tocar o punto de acceso
A rede de acceso entrega un enderezo de resolutor por DHCP e pode interceptar o porto 53 cara a ese enderezo. Iso abonda para responder a cada consulta non protexida cun enderezo de portal ou unha páxina de bloqueo. Tamén abonda para romper un cliente VPN cuxo extremo está escrito como nome de host.
O que o punto de acceso non pode facer é ler ou reescribir unha consulta unha vez que viaxa dentro dun túnel establecido, supoñendo que o túnel realmente a transporta. A interceptación depende de ver a pregunta en texto plano.
As consultas saen do túnel de todos os xeitos por motivos alleos ao punto de acceso: o axuste de DNS seguro do navegador, unha regra de split-DNS que mantén un sufixo corporativo no resolutor local, ou un cliente configurado para excluír o DNS do túnel. Cada unha é unha elección do lado do cliente, e cada unha parece unha interferencia do punto de acceso vista desde fóra.
| 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 consulta inicial ocorre antes de que exista o túnel
Un cliente ao que se lle dá un nome de host debe resolvelo primeiro, e nese instante ningún túnel protexe a consulta. Se o punto de acceso responde cun enderezo de portal, a negociación falla ou colga. Se responde con nada, o cliente informa un erro de nome e o túnel nunca arrinca. Calquera dos dous desenlaces explica un rexistro de túnel baleiro que por outra parte parece inocente.
Os sistemas operativos tamén executan as súas propias comprobacións de conectividade e descubrimento de portal, descritas en RFC 8910 e RFC 8952, e esas peticións saen antes de que haxa ningunha VPN levantada. Velas nun rexistro de proxy é un comportamento esperado e non unha proba de fuga.
A solución práctica é dar ao cliente un extremo que non necesite consulta. Cando iso é imposible, termine primeiro o inicio de sesión e conéctese despois.
Averigüe que resolutor respondeu
Pregunte ao sistema e non ao navegador, e execute a consulta dúas veces: unha a través do resolutor que o dispositivo usa agora e outra contra un enderezo fixo.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Unha resposta do primeiro comando que difira da terceira dille que o resolutor local devolve outra cousa, que é o que fai un punto de acceso que redirixe. Un fallo da terceira xunto cun éxito da primeira apunta ao portal: o resolutor local serviu un enderezo de inicio de sesión mentres se descartaba o porto 53 saínte. Os tempos de espera en ambas significan que a rede descarta o DNS ata que se completa a autenticación.
Repita tras conectarse e compare. Unha resposta en caché sobrevive á transición, así que baleire a caché ou consulte un nome novo para a segunda observación.
Manteña as consultas posteriores no camiño que pretendía
Un perfil de túnel completo que tamén capture DNS é a disposición máis sinxela: cada consulta de cada aplicación vai ao resolutor que empurra o túnel, e a rede local só ve tráfico cifrado. Demóstree resolvendo un nome interno e un público despois de conectar, e comparando logo ambas as respostas co que devolve o resolutor do túnel por si só.
O split-DNS necesita unha lista de dominios escrita con intención: sufixos corporativos polo túnel, todo o demais en local, e sen solapamento entre ambos.
O DNS seguro do navegador queda fóra desa política, así que se ten que estar desactivado para que o perfil se comporte de forma previsible, desactíveo para ese perfil e non para a máquina. Fágao nos axustes do navegador, non editando o resolutor do sistema, para que o cambio sexa visible a próxima vez. Anote a resposta, o resolutor e a etapa de conexión nunha liña por proba. Un informe que di que o DNS fallou no Wi-Fi do hotel describe un síntoma con polo menos tres causas distintas.