El VPN m’ha canviat el DNS? Compareu abans i després
Un perfil pot moure les vostres consultes a propòsit. Compareu la política del resolutor i la resposta real abans i després que un VPN es connecti, mantenint una sola variable.
Connecteu el túnel, obriu un tauler privat i el nom es resol en una adreça que no heu vist mai. O passa el contrari: el navegador continua funcionant mentre una eina de línia d’ordres de sobte no resol res. Els dos resultats vénen del mateix canvi, i la gent sol explicar-ho amb una frase sobre el VPN que "utilitza el seu propi DNS", que no és prou precisa per depurar-ho ni per verificar-ho. En aquesta frase s’amaguen dues preguntes: quines consultes ha d’assumir aquest perfil i la vostra màquina les ha enviades realment al resolutor que li han lliurat? Mantenir-les separades és tot el mètode, perquè una prova que les barreja produeix una resposta equivocada i confiada en totes dues direccions.
Per què un perfil forneix un resolutor
Dins d’un túnel, els noms darrere de l’extrem llunyà solen resoldre’s en adreces que només existeixen en aquesta xarxa. Una zona privada com corp.internal no té delegació pública, així que el resolutor que la respon ha de ser abastable des de dins del túnel. El mateix mecanisme serveix a un segon propòsit: quan les consultes sortirien pel vostre ISP, un resolutor a l’extrem llunyà manté la consulta dins del camí xifrat. Per això l’adreça del servidor DNS arriba com a part de la política de la connexió i no com un paràmetre global que vau triar una vegada per a la màquina.
L’adreça per si sola no decideix res. Un resolutor només pot respondre si hi ha una ruta cap a ell, i la fallada més comuna és un resolutor abastable només mentre el túnel és actiu. Quan el túnel cau i la política es manté, les consultes van a una adreça sense camí, i el símptoma és un temps d’espera esgotat i no un error net. Aquesta diferència importa quan llegiu el resultat de la prova següent, perquè un temps d’espera envia la gent a paràmetres de transport que mai hi van tenir res a veure.
Compareu els dos dissenys abans de comparar respostes
El túnel complet i el DNS dividit produeixen expectatives oposades, i cap dels dos no és un mal funcionament. Amb un túnel complet, cada consulta pot moure’s al proveïdor o al resolutor corporatiu, així que que els noms públics responguin diferent després de connectar és esperable. Amb DNS dividit, només els dominis llistats van al resolutor privat mentre la resta queda local; a Windows la llista de dominis viu a la Name Resolution Policy Table, a macOS als dominis de coincidència dels paràmetres DNS, i en un amfitrió amb systemd-resolved als dominis d’encaminament per enllaç.
Aquesta és la comparació que cal fer primer, perquè decideix què compta com a error. Amb DNS dividit, un nom públic que respon des d’un resolutor nou és el que val la pena investigar, mentre que un nom intern que respon correctament és el sistema fent la seva feina. Amb un túnel complet, l’anomalia és un nom públic que encara respon des del resolutor del vostre ISP. La documentació de Microsoft sobre la resolució de noms de VPN descriu l’ordre de Windows d’aquestes regles, incloent com es consulta una entrada de política coincident abans que els servidors propis de l’adaptador.
Hi ha un tercer resolutor a l’habitació que és fàcil d’oblidar. El DNS segur del navegador resol noms pel seu compte i pot continuar responent després que el túnel hagi canviat la política del sistema operatiu, així que una pàgina que carrega demostra que el resolutor del navegador ha funcionat, no que el perfil s’hagi aplicat. Si només compareu el que mostra el navegador, la meitat de les vegades esteu provant la capa equivocada.
Registreu una línia base amb una sola variable
Canvieu el túnel. No canvieu també el nom, l’eina o el sufix de cerca en el mateix pas. Trieu un nom que tingueu permís per consultar, anoteu quina aplicació heu fet servir i escriviu o bé l’adreça que ha tornat o bé l’error exacte. A Windows, Get-DnsClientServerAddress -AddressFamily IPv4 imprimeix els servidors per adaptador i Get-DnsClientNrptPolicy imprimeix les entrades de política; a Linux amb systemd-resolved, resolvectl status mostra els servidors DNS i els dominis d’encaminament per enllaç; a macOS, scutil --dns imprimeix l’ordre de resolutors que el sistema seguirà realment.
Després connecteu amb els controls habituals del client i repetiu exactament les mateixes ordres. Guardeu la primera sortida en lloc de recordar-la, perquè la comparació és tot el punt i una segona lectura presa després de buidar la memòria cau ja és un altre mesurament. Si la línia base es va prendre amb el navegador al davant i l’execució posterior a la connexió passa en un terminal, esteu comparant dos resolutors, no dos estats d’un mateix resolutor.
Una consulta explícita i una cerca d’aplicació són proves diferents
Preguntar a un servidor concret, amb nslookup name 10.20.0.1 o dig @10.20.0.1 name, demostra una sola cosa: que el servidor que heu nomenat respon quan hi podeu arribar. S’ha saltat completament la lògica de selecció, així que no us pot dir si el sistema hauria triat aquell servidor per a aquest nom. Feu-la servir per comprovar si el resolutor assignat és abastable, i no la feu servir per comprovar la política.
Una cerca a través del resolutor local sí que exerceix la selecció. resolvectl query name recorre les mateixes regles de dominis d’encaminament i informa quin protocol ha respost, Resolve-DnsName a Windows passa per la taula de política i la memòria cau del client, i scutil --dns mostra l’ordre que seguiria una cerca. Executeu tots dos tipus i manteniu-los en columnes separades de les vostres notes. Una consulta explícita verda al costat d’una cerca d’aplicació fallida és un problema d’encaminament o de selecció, no un resolutor que es nega a funcionar.
La memòria cau se situa entre vosaltres i la resposta. El sistema operatiu, el resolutor stub local, el navegador i la memòria cau negativa tots guarden resultats, així que una cerca pot tenir èxit sense que cap paquet surti de la màquina. Registreu el resultat abans de buidar res: ipconfig /flushdns, resolvectl flush-caches o sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder a macOS. Saltar-vos el reinici general de xarxa en aquesta etapa, perquè destrueix les proves que encara esteu recollint.
Què significa la diferència
Compareu les dues files que heu registrat i classifiqueu el canvi abans de tocar cap paràmetre.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Una fila mereix èmfasi. Un nom que es resol no és un servei que funciona, i l’èxit del DNS només diu que s’ha trobat una adreça. No diu res sobre el reenviament, les regles del tallafoc o si el vostre compte pot utilitzar el servei, així que acabeu provant l’aplicació real en lloc de suposar que la fallada s’ha retirat sola.
Restaureu la línia base i verifiqueu-la
Desconnecteu amb els controls propis del client en lloc de matar el procés, i després torneu a llegir les mateixes tres ordres. Els servidors per enllaç, les entrades de política i la resposta per al vostre nom de prova haurien de tornar a la línia base que vau escriure abans. Una entrada de política romanent després d’una desconnexió neta és un defecte real que val la pena registrar, i també és per això que les edicions manuals d’un fitxer de resolutor generat són un mal costum: el fitxer es reescriu i l’edició desapareix, o l’edició sobreviu i fixa un resolutor que ja no té ruta.
Recorreu aquesta llista una vegada, en ordre. Decidiu quin disseny implementa el perfil abans de jutjar cap resultat. Manteniu el nom, l’eina i el sufix fixos en les dues execucions. Separeu la consulta explícita de la cerca d’aplicació. Llegiu la política efectiva, no només la resposta. Buideu les memòries cau al final, després d’escriure la comparació. Verifiqueu amb l’aplicació real, després reinicieu una vegada i confirmeu que l’estat desconnectat encara és net.