DNS da VPN fronte a DoH do navegador: o que non che pode dicir unha proba de fugas

A páxina da proba de fugas di que o teu DNS está ben, o distintivo do navegador di seguro, e o wiki interno segue sen cargar. As tres cousas poden ser certas á vez, porque o enderezo dun resolutor non é o mesmo que a política que o escolleu nin o camiño que percorreu a consulta. O que a xente chama fuga de DNS é en realidade unha soa pregunta: que resolutor recibiu o nome, e foi intencionada esa escolla? Aclaralo esixe tres comprobacións, e só a última implica cambiar un axuste.

Mito un: o distintivo nomea o teu resolutor

Unha proba de fugas resolve un nome de sonda e informa de o enderezo que respondeu. Non informa da política que escolleu ese resolutor, e cando a consulta vai envolta en DNS sobre HTTPS, unha caixa intermedia do camiño non pode ver o nome en absoluto. Dúas máquinas moi distintas producen o mesmo distintivo tranquilizador: unha onde a VPN empurrou 10.8.0.1 e o navegador úsao, e outra onde o navegador ignorou a lista do sistema e enviou o nome polo túnel ao seu propio provedor cifrado.

A distinción importa no momento en que falla un nome privado. Na primeira configuración o resolutor da VPN responde pola zona corporativa; na segunda o navegador nunca llo preguntou, así que o nome de host curto non se resolve e o fallo parece unha VPN rota. A comprobación non é outra proba de fugas, é unha consulta a un nome que só coñece un resolutor.

Mito dous: o navegador abandona o túnel

O DNS escolle un enderezo, o encamiñamento transporta a conexión, e son dúas capas separadas. Unha consulta enviada a un provedor DoH público segue sendo TCP porto 443 cara a un enderezo encamiñable. Se a túa táboa de rutas envía a ruta predeterminada ao túnel, esa consulta tamén pasa polo túnel. A marca do resolutor non decide o camiño.

O que cambia o DoH do navegador é o destinatario dos nomes. É unha decisión real de privacidade e unha decisión real de política, pero non é unha evasión do encamiñamento. Se o teu requisito é que os nomes queden co operador da VPN, unha consulta cifrada a outro incumpre ese requisito mentres segue usando o túnel para a conexión real.

Mito tres: cada VPN anula cada navegador

O DNS seguro dun navegador ten modos, non un interruptor: desactivado, un provedor predeterminado con respaldo, un modelo personalizado ou unha política imposta polo sistema operativo ou a organización. O caso de respaldo é o que produce informes intermitentes. Cando o punto final cifrado non é accesible, o navegador pode volver ao resolutor do sistema, así que o mesmo portátil resolve correctamente un nome privado o luns e o martes non.

Ao mesmo tempo, a maioría dos clientes VPN configuran o resolutor do sistema cando a conexión sobe e restauran o anterior cando cae. Un navegador que mantén un resolutor cifrado personalizado non observa esa restauración en absoluto. Por iso o mesmo perfil compórtase distinto en dous portátiles e por iso resolv.conf parece correcto mentres o navegador segue preguntando a outro.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Executa eses comandos mentres esteas conectado, anota que dominios reclama cada resolutor e compárao co que o navegador informa sobre o seu propio modo. A documentación de DoH de Mozilla é unha descrición razoable de como deben funcionar o comportamento predeterminado e o de respaldo dun navegador.

A decisión ten tres entradas, non unha

Os nomes privados, a confianza no operador e a accesibilidade deciden a disposición correcta. Os nomes que só coñece o resolutor da VPN obrigan a un DNS dividido: o sufixo privado vai ao resolutor empurrado, e todo o demais segue a política que escolleses para os nomes públicos. A confianza no operador decide se os nomes públicos tamén deben ir a ese resolutor ou a un servizo aparte. A accesibilidade decide se o resolutor cifrado escollido é sequera utilizábel nesta rede.

Ningunha destas filas é unha recomendación universal. Un resolutor operado pola VPN concentra as observacións nese operador; un servizo aparte engade outro destinatario dos nomes consultados. Ningunha das dúas disposicións demostra nada sobre a retención a menos que leas a política.

Anota a decisión por perfil, porque estes axustes desprázanse. Un perfil que empurrou un resolutor o mes pasado quizais hoxe non empurre ningún, e o navegador manterá de bo grado un punto final personalizado antigo que aínda responde. Na nota deben constar o enderezo do resolutor, os sufixos que posúe e o modo do navegador, non a marca do servizo.

Proba a política que cres que configuraches

Proba por nome, non por distintivo. Resolve un nome público e un nome privado a través do resolutor do sistema, e despois repíteo dentro do navegador co seu propio axuste de DNS seguro no modo que pensas usar. Se o nome privado falla só no navegador, atopaches o desaxuste de destinatario sen tocar un só axuste da VPN.

Despois reconecta e comproba a restauración, porque é onde viven os erros de traspaso: desconecta, confirma que volveu o resolutor anterior, reconecta, confirma que volveu o empurrado. Por último, proba un navegador cunha política xestionada se tes un, porque ese modo pode rexeitar de todo o teu cambio e manter en silencio o resolutor anterior.

Comeza pola pregunta do espazo de nomes e evitarás a maior parte disto. Se a máquina ten que chegar a nomes internos, o resolutor cifrado do navegador é unha decisión só sobre a metade pública, e a metade privada queda co que a VPN empurrase.