O VPN cambiou o meu DNS? Compare antes e despois
Un perfil pode mover as súas consultas a propósito. Compare a política do resolutor e a resposta real antes e despois de que un VPN se conecte, mantendo unha soa variable.
Conecta o túnel, abre un panel privado e o nome resólvese nun enderezo que nunca viu. Ou ocorre o contrario: o navegador segue funcionando mentres unha ferramenta de liña de ordes de súpeto non resolve nada. Ambos os resultados veñen do mesmo cambio, e a xente adoita explicalo cunha soa frase sobre o VPN que "usa o seu propio DNS", que non é o bastante precisa para depurar nin para verificar. Nesa frase escóndense dúas preguntas: que consultas debe asumir este perfil e se a súa máquina realmente as enviou ao resolutor que se lle deu. Mantelas separadas é todo o método, porque unha proba que as mestura produce unha resposta equivocada e segura de si mesma en ambas as direccións.
Por que un perfil fornece un resolutor
Dentro dun túnel, os nomes detrás do extremo remoto adoitan resolverse en enderezos que só existen nesa rede. Unha zona privada como corp.internal non ten delegación pública, así que o resolutor que a responde debe ser alcanzable desde dentro do túnel. O mesmo mecanismo serve un segundo propósito: cando as consultas sairían polo seu provedor, un resolutor do lado remoto mantén a consulta dentro da ruta cifrada. Por iso o enderezo do servidor DNS chega como parte da política da conexión e non como un axuste global que vostede elixiu unha vez para a máquina.
O enderezo por si só non decide nada. Un resolutor só pode responder se hai unha ruta cara a el, e o fallo máis común é un resolutor alcanzable só mentres o túnel está activo. Cando o túnel cae e a política permanece, as consultas van a un enderezo sen ruta, e o síntoma é un tempo de espera esgotado e non un erro limpo. Esa diferenza importa cando le o seguinte resultado da proba, porque un tempo esgotado envía a xente a axustes de transporte que nunca estiveron implicados.
Compare os dous deseños antes de comparar respostas
O túnel completo e o DNS dividido producen expectativas opostas, e ningún dos dous é un mal funcionamento. Baixo un túnel completo, cada consulta pode pasar ao provedor ou ao resolutor corporativo, así que é esperable que os nomes públicos respondan distinto tras conectar. Baixo DNS dividido, só os dominios listados van ao resolutor privado mentres todo o demais permanece local; en Windows a lista de dominios vive na Name Resolution Policy Table, en macOS nos dominios de coincidencia dos axustes de DNS, e nun equipo con systemd-resolved nos dominios de enrutamento por ligazón.
Esa é a comparación que hai que facer primeiro, porque decide que conta como fallo. Con DNS dividido, un nome público que responde desde un resolutor novo é o que merece investigarse, mentres que un nome interno que responde correctamente é o sistema facendo o seu traballo. Cun túnel completo, a anomalía é un nome público que segue respondendo desde o resolutor do seu provedor. A documentación de Microsoft sobre a resolución de nomes de VPN describe a orde de Windows destas regras, incluído como se consulta unha entrada de política coincidente antes que os servidores propios do adaptador.
Hai un terceiro resolutor na sala que é fácil de esquecer. O DNS seguro do navegador resolve nomes pola súa conta e pode seguir respondendo despois de que o túnel cambiase a política do sistema operativo, así que unha páxina que carga demostra que funcionou o resolutor do navegador, non que se aplicou o perfil. Se só compara o que mostra o navegador, a metade das veces está probando a capa equivocada.
Rexistre unha liña base cunha soa variable
Cambie o túnel. Non cambie tamén o nome, a ferramenta ou o sufixo de busca no mesmo paso. Elixa un nome que teña permitido consultar, anote que aplicación usou e escriba ou ben o enderezo que volveu ou ben o erro exacto. En Windows, Get-DnsClientServerAddress -AddressFamily IPv4 imprime os servidores por adaptador e Get-DnsClientNrptPolicy imprime as entradas de política; en Linux con systemd-resolved, resolvectl status mostra os servidores DNS e os dominios de enrutamento por ligazón; en macOS, scutil --dns imprime a orde de resolutores que o sistema seguirá realmente.
Despois conéctese cos controis habituais do cliente e repita exactamente as mesmas ordes. Garde a primeira saída en lugar de recordala, porque a comparación é todo o asunto e unha segunda lectura tomada despois de baleirar a caché xa é outra medición. Se a liña base se tomou co navegador diante e a execución posterior á conexión ocorre nun terminal, está comparando dous resolutores, non dous estados dun mesmo resolutor.
Unha consulta explícita e unha busca de aplicación son probas distintas
Preguntar a un servidor concreto, con nslookup name 10.20.0.1 ou dig @10.20.0.1 name, demostra unha soa cousa: que o servidor que nomeou responde cando pode alcanzalo. Salta por completo a lóxica de selección, así que non pode dicirlle se o sistema tería elixido ese servidor para este nome. Úseo para comprobar se o resolutor asignado é alcanzable, e non o use para comprobar a política.
Unha busca a través do resolutor local si exercita a selección. resolvectl query name percorre as mesmas regras de dominios de enrutamento e informa que protocolo respondeu, Resolve-DnsName en Windows pasa pola táboa de política e a caché do cliente, e scutil --dns mostra a orde que seguiría unha busca. Execute ambos os tipos e mantéñaos en columnas separadas das súas notas. Unha consulta explícita correcta xunto a unha busca de aplicación fallida é un problema de enrutamento ou de selección, non un resolutor que se nega a funcionar.
A caché sitúase entre vostede e a resposta. O sistema operativo, o resolutor stub local, o navegador e a caché negativa gardan resultados, así que unha busca pode ter éxito sen que un só paquete saia da máquina. Rexistre o resultado antes de baleirar nada: ipconfig /flushdns, resolvectl flush-caches ou sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder en macOS. Omita o reinicio amplo de rede nesta etapa, porque destrúe a evidencia que aínda está a recoller.
Que significa a diferenza
Compare as dúas filas que rexistrou e clasifique o cambio antes de tocar un só axuste.
| 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 |
Unha fila merece énfase. Un nome que se resolve non é un servizo que funciona, e o éxito do DNS só di que se atopou un enderezo. Non di nada sobre o reenvío, as regras da devasa nin se a súa conta pode usar o servizo, así que remate probando a aplicación real en lugar de supor que o fallo se retirou só.
Restaure a liña base e verifíquea
Desconecte cos controis propios do cliente en lugar de matar o proceso, e logo volva ler as mesmas tres ordes. Os servidores por ligazón, as entradas de política e a resposta para o seu nome de proba deberían volver á liña base que escribiu antes. Unha entrada de política que queda tras unha desconexión limpa é un defecto real que paga a pena rexistrar, e tamén é a razón de que as edicións manuais dun ficheiro de resolutor xerado sexan un mal hábito: o ficheiro reescríbese e a edición desaparece, ou a edición sobrevive e fixa un resolutor que xa non ten ruta.
Percorra esta lista unha vez, en orde. Decida que deseño implementa o perfil antes de xulgar calquera resultado. Mantéña o nome, a ferramenta e o sufixo fixos nas dúas execucións. Separe a consulta explícita da busca de aplicación. Lea a política efectiva, non só a resposta. Baleire as cachés ao final, despois de escribir a comparación. Verifique coa aplicación real, logo reinicie unha vez e confirme que o estado desconectado segue limpo.