VPN conectada pero os nomes fallan: onde se rompe realmente o DNS

Túnel activo, icona verde e cada lapela do navegador informa dun fallo de resolución de nomes. Tres mecanismos distintos producen esa imaxe: o resolutor pode ser inalcanzable, o cliente pode estar a preguntar a un resolutor que non esperaba, ou só poden fallar os nomes privados. Sepáraos antes de cambiar nada no protocolo do túnel, porque cada un se repara nun lugar distinto. A orde seguinte comeza polas observacións que separan os tres casos.

Que necesita realmente unha consulta

Unha consulta necesita tres cousas: un enderezo de resolutor, unha ruta ata ese enderezo e unha resposta que coincida coa pregunta. Cada unha pode fallar por separado, e o síntoma visible é a mesma páxina que non carga. Por iso a páxina de erro non lle di case nada ata que sabe cal dos tres se rompeu.

O cliente aprende o seu resolutor do perfil VPN, do DHCP do túnel ou da súa propia configuración, e que fonte gaña depende da plataforma. En Windows, ipconfig /all enumera os servidores DNS por adaptador, así que pode ver se o valor enviado chegou realmente. Un valor enviado que nunca chegou ao sistema operativo é un fallo silencioso e habitual. Lea o valor configurado antes de tocar o perfil.

Linux e macOS responden á mesma pregunta con comandos distintos, e a resposta merece a mesma lectura: resolvectl status e scutil --dns ambos enumeran os servidores por interface. Compare esa lista co enderezo que o perfil di enviar. Unha discrepancia aquí explica todo o demais, así que resólvaa antes de probar nomes.

Probe un nome público e un privado

Consulte un nome de host público corrente e o nome de host privado documentado desde a mesma máquina, e anote que servidor respondeu a cada un. Se fallan ambos, o resolutor ou a súa ruta están rotos. Se só falla o nome privado, o resolutor respondeu e a pregunta pasa a ser a zona ou o encamiñamento. Execute as dúas consultas cun minuto de diferenza como máximo para que un cambio de ruta non poida explicar a diferenza.

Manteña os nomes internos fóra das capturas públicas e dos resolutores públicos. Un tempo de espera e unha resposta de dominio inexistente son observacións distintas: a primeira di que non volveu nada, a segunda que unha autoridade respondeu que o nome non existe. Tratalos como un único erro lévao á capa equivocada, e un aviso de certificado é outra terceira cousa, non un fallo de DNS.

nslookup mostra tanto o servidor ao que preguntou como a resposta recibida, e ese é exactamente o par que necesita. Execúteo dúas veces no mesmo intérprete de ordes e escriba o enderezo que responde xunto a cada resposta.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Confirme que o cliente pode chegar realmente a ese servidor

Un resolutor privado enviado polo perfil só é útil se o cliente pode alcanzalo co túnel activo. Un enderezo que parece correcto sen ruta produce un tempo de espera, e o estado conectado do túnel non di nada sobre esa ruta. A comprobación é unha consulta de ruta dirixida ao propio resolutor, non ao extremo do VPN.

Cada plataforma responde iso nunha liña, e a interface indicada na saída é toda a resposta. Se apunta ao adaptador físico mentres o resolutor está detrás do túnel, o perfil non envía un prefixo que o cubra.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Nun perfil de túnel dividido o resolutor pode quedar fóra das rutas enviadas, o que é un problema do perfil e non do servidor. Compare o enderezo do resolutor cos prefixos enviados e confirme que un deles o cubre. A mesma discrepancia explica por que o DNS funciona nunha rede e falla noutra cun perfil idéntico.

Lembre que os navegadores poden saltar o resolutor do sistema

Un navegador con DNS seguro activado pode enviar consultas por HTTPS a un provedor da súa elección e ignorar por completo o resolutor do sistema operativo. Entón o sistema parece correcto mentres o navegador falla, ou ao revés. Iso é unha cuestión de política do navegador, non do túnel.

Revise o axuste de DNS seguro do navegador e calquera política xestionada que o controle, e despois probe unha segunda aplicación ou navegador co túnel sen cambios. Se só falla unha aplicación, a corrección pertence a esa aplicación. Unha ventá privada non é unha comparación limpa, porque pode desactivar extensións de forma predeterminada nun navegador e non noutro, e nunca evita unha política xestionada. Use no seu lugar un segundo perfil de navegador ou outra aplicación.

Baleire a caché e volva probar a tarefa real

Despois de corrixir un axuste, baleire a caché local do resolutor para que unha resposta antiga non sobreviva á corrección. Unha recuperación breve seguida doutro fallo significa que a causa segue aí, non que o baleirado fallase. Escolla a liña que corresponda á máquina na que está, porque as tres cachés son independentes.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Logo repita a tarefa orixinal en lugar dunha consulta sintética, porque a tarefa é o que lle importa ao usuario. Vólvase conectar unha vez, para que a repetición cubra o estado no que o usuario estará realmente. A referencia de nslookup de Microsoft é a páxina que convén gardar para os argumentos da consulta.

Se os nomes fallan só tras desconectar, o cliente non restaurou a configuración anterior, o que é un erro de ciclo de vida que hai que informar, non un servidor DNS que hai que substituír. Unha consulta que funciona tampouco é unha proba de fuga, porque o país de saída non lle di que resolutor respondeu.