VPN connectat, però els noms fallen: on es trenca realment el DNS

Túnel aixecat, icona verda i cada pestanya del navegador informa d'un error de resolució de noms. Tres mecanismes diferents produeixen aquesta imatge: el resolutor pot ser inabastable, el client pot estar preguntant un resolutor que no esperàveu, o només poden fallar els noms privats. Separeu-los abans de canviar res del protocol del túnel, perquè cada un es repara en un lloc diferent. L'ordre següent comença amb les observacions que separen els tres casos.

Què necessita realment una consulta

Una consulta necessita tres coses: una adreça de resolutor, una ruta fins a aquesta adreça i una resposta que coincideixi amb la pregunta. Cada una pot fallar sola, i el símptoma visible és la mateixa pàgina que no carrega. Per això la pàgina d'error no us diu gairebé res fins que sabeu quin dels tres s'ha trencat.

El client aprèn el seu resolutor del perfil VPN, del DHCP del túnel o de la seva pròpia configuració, i quina font guanya depèn de la plataforma. A Windows, ipconfig /all llista els servidors DNS per adaptador, així que podeu veure si el valor enviat ha arribat realment. Un valor enviat que mai no ha arribat al sistema operatiu és una fallada silenciosa i habitual. Llegiu el valor configurat abans de tocar el perfil.

Linux i macOS responen la mateixa pregunta amb ordres diferents, i la resposta mereix la mateixa lectura: resolvectl status i scutil --dns tots dos llisten els servidors per interfície. Compareu aquesta llista amb l'adreça que el perfil diu que envia. Una discrepància aquí explica tota la resta, així que resoleu-la abans de provar noms.

Proveu un nom públic i un de privat

Consulteu un nom d'amfitrió públic corrent i el nom d'amfitrió privat documentat des de la mateixa màquina, i anoteu quin servidor ha respost cada un. Si fallen tots dos, el resolutor o la seva ruta estan trencats. Si només falla el nom privat, el resolutor ha respost i la pregunta passa a ser la zona o l'encaminament. Feu les dues consultes amb menys d'un minut de diferència perquè un canvi de ruta no pugui explicar la diferència.

Mantingueu els noms interns fora de les captures públiques i dels resolutors públics. Un temps d'espera i una resposta de domini inexistent són observacions diferents: la primera diu que no ha tornat res, la segona que una autoritat ha respost que el nom no existeix. Tractar-los com un sol error us porta a la capa equivocada, i un avís de certificat és encara una tercera cosa, no una fallada de DNS.

nslookup mostra tant el servidor al qual ha preguntat com la resposta rebuda, i aquest és exactament el parell que necessiteu. Executeu-lo dues vegades al mateix intèrpret d'ordres i escriviu l'adreça que respon al costat de cada resposta.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Confirmeu que el client pot arribar realment a aquest servidor

Un resolutor privat enviat pel perfil només és útil si el client hi pot arribar amb el túnel aixecat. Una adreça que sembla correcta sense ruta produeix un temps d'espera, i l'estat connectat del túnel no diu res sobre aquesta ruta. La comprovació és una consulta de ruta adreçada al mateix resolutor, no al punt final del VPN.

Cada plataforma respon això en una línia, i la interfície indicada a la sortida és tota la resposta. Si assenyala l'adaptador físic mentre el resolutor és darrere del túnel, el perfil no envia cap prefix que el cobreixi.

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

En un perfil de túnel dividit, el resolutor pot quedar fora de les rutes enviades, cosa que és un problema del perfil i no del servidor. Compareu l'adreça del resolutor amb els prefixos enviats i confirmeu que un d'ells el cobreix. La mateixa discrepància explica per què el DNS funciona en una xarxa i falla en una altra amb un perfil idèntic.

Recordeu que els navegadors poden saltar-se el resolutor del sistema

Un navegador amb DNS segur activat pot enviar consultes per HTTPS a un proveïdor de la seva elecció i ignorar del tot el resolutor del sistema operatiu. Llavors el sistema sembla correcte mentre el navegador falla, o al revés. Aquesta és una qüestió de política del navegador, no del túnel.

Reviseu el paràmetre de DNS segur del navegador i qualsevol política gestionada que el controli, i proveu després una segona aplicació o navegador amb el túnel sense canvis. Si només falla una aplicació, la correcció pertany a aquesta aplicació. Una finestra privada no és una comparació neta, perquè pot desactivar extensions per defecte en un navegador i no en un altre, i mai no salta una política gestionada. Feu servir un segon perfil de navegador o una altra aplicació.

Buideu la memòria cau i torneu a provar la tasca real

Després de corregir un paràmetre, buideu la memòria cau local del resolutor perquè una resposta antiga no sobrevisqui a la correcció. Una recuperació breu seguida d'una altra fallada vol dir que la causa hi és encara, no que el buidatge hagi fallat. Trieu la línia que correspongui a la màquina on sou, perquè les tres memòries cau són separades.

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

Després repetiu la tasca original en lloc d'una consulta sintètica, perquè la tasca és el que importa a l'usuari. Torneu-vos a connectar un cop, perquè la repetició cobreixi l'estat en què l'usuari estarà realment. La referència de nslookup de Microsoft és la pàgina que cal guardar per als arguments de la consulta.

Si els noms fallen només després de desconnectar, el client no ha restaurat la configuració anterior, cosa que és un error de cicle de vida que cal informar, no un servidor DNS que cal substituir. Una consulta que funciona tampoc no és una prova de fuita, perquè el país de sortida no us diu quin resolutor ha respost.