¿Por qué un punto de acceso redirige el DNS antes de que se conecte la VPN?
Un punto de acceso reescribe las consultas en su propia red, y un extremo con nombre de host se resuelve antes de que exista cualquier túnel. Rastree qué resolutor respondió a cada consulta.
Unirse a una red de hotel le plantea dos decisiones de DNS en momentos distintos: las consultas que el dispositivo hace al iniciar sesión y las que se hacen una vez levantado el túnel. Un punto de acceso puede influir en las primeras mediante la red que controla. Las segundas dependen de la política del propio cliente, que es algo aparte que hay que inspeccionar.
Recorra la conexión en orden, desde el primer arrendamiento DHCP hasta la consulta que resolvió un nombre privado. Así dos fallos que en un ticket de soporte parecen idénticos se separan con claridad: uno ocurrió antes de que existiera el túnel y el otro ocurrió dentro de él.
Qué puede y qué no puede tocar el punto de acceso
La red de acceso entrega una dirección de resolutor por DHCP y puede interceptar el puerto 53 hacia esa dirección. Eso basta para responder a cada consulta no protegida con una dirección de portal o una página de bloqueo. También basta para romper un cliente VPN cuyo extremo está escrito como nombre de host.
Lo que el punto de acceso no puede hacer es leer o reescribir una consulta una vez que viaja dentro de un túnel establecido, suponiendo que el túnel realmente la transporta. La interceptación depende de ver la pregunta en texto plano.
Las consultas salen del túnel de todos modos por motivos ajenos al punto de acceso: el ajuste de DNS seguro del navegador, una regla de split-DNS que mantiene un sufijo corporativo en el resolutor local, o un cliente configurado para excluir el DNS del túnel. Cada una es una elección del lado del cliente, y cada una parece una interferencia del punto de acceso vista desde fuera.
| 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 inicial ocurre antes de que exista el túnel
Un cliente al que se le da un nombre de host debe resolverlo primero, y en ese instante ningún túnel protege la consulta. Si el punto de acceso responde con una dirección de portal, la negociación falla o se cuelga. Si responde con nada, el cliente informa un error de nombre y el túnel nunca arranca. Cualquiera de los dos desenlaces explica un registro de túnel vacío que por lo demás parece inocente.
Los sistemas operativos también ejecutan sus propias comprobaciones de conectividad y descubrimiento de portal, descritas en RFC 8910 y RFC 8952, y esas peticiones salen antes de que haya ninguna VPN levantada. Verlas en un registro de proxy es un comportamiento esperado y no una prueba de fuga.
La solución práctica es dar al cliente un extremo que no necesite consulta. Cuando eso es imposible, termine primero el inicio de sesión y conéctese después.
Averigüe qué resolutor respondió
Pregunte al sistema y no al navegador, y ejecute la consulta dos veces: una a través del resolutor que el dispositivo usa ahora y otra contra una dirección fija.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Una respuesta del primer comando que difiera de la tercera le dice que el resolutor local devuelve otra cosa, que es lo que hace un punto de acceso que redirige. Un fallo de la tercera junto con un éxito de la primera apunta al portal: el resolutor local sirvió una dirección de inicio de sesión mientras se descartaba el puerto 53 saliente. Los tiempos de espera en ambas significan que la red descarta el DNS hasta que se completa la autenticación.
Repita tras conectarse y compare. Una respuesta en caché sobrevive a la transición, así que vacíe la caché o consulte un nombre nuevo para la segunda observación.
Mantenga las consultas posteriores en el camino que pretendía
Un perfil de túnel completo que también capture DNS es la disposición más sencilla: cada consulta de cada aplicación va al resolutor que empuja el túnel, y la red local solo ve tráfico cifrado. Demuéstrelo resolviendo un nombre interno y uno público después de conectar, y comparando luego ambas respuestas con lo que devuelve el resolutor del túnel por sí solo.
El split-DNS necesita una lista de dominios escrita con intención: sufijos corporativos por el túnel, todo lo demás en local, y sin solapamiento entre ambos.
El DNS seguro del navegador queda fuera de esa política, así que si tiene que estar desactivado para que el perfil se comporte de forma predecible, desactívelo para ese perfil y no para la máquina. Hágalo en los ajustes del navegador, no editando el resolutor del sistema, para que el cambio sea visible la próxima vez. Anote la respuesta, el resolutor y la etapa de conexión en una línea por prueba. Un informe que dice que el DNS falló en el Wi-Fi del hotel describe un síntoma con al menos tres causas distintas.