Por que nslookup resolve pola VPN pero o navegador non

nslookup envía unha consulta ao servidor que vostede nomea e imprime a resposta, por iso pode ter éxito mentres todas as pestanas do navegador fallan. O navegador pide ao sistema operativo que resolva, e o sistema pondera os resolutores de cada interface, as regras de política de resolución de nomes e a localización de rede do adaptador. Despois o navegador pode engadir o seu propio DNS cifrado por riba. Tres camiños distintos, un síntoma, e o túnel normalmente non é a parte avariada.

As comprobacións seguintes seguen eses camiños desde o sistema cara a fóra. Non edite o perfil da VPN ata saber que camiño respondeu e cal fallou.

Tres políticas deciden a resposta

Cada interface leva a súa propia lista de resolutores e os seus sufixos de busca. Un adaptador de VPN engade servidores mentres o adaptador físico conserva os seus, e o sistema pode tomar o que responda primeiro, así que unha consulta pode servirse fóra do túnel sen que ninguén o escollese. As regras da táboa de política de resolución de nomes poden enviar dominios seleccionados a servidores seleccionados, que é como normalmente se expresa o DNS dividido en Windows. E o cliente ou a pasarela da VPN poden empuxar un enderezo de resolutor que só existe dentro da rede privada.

Eses tres interactúan de xeitos que desde un navegador parecen arbitrarios. Un resolutor empuxado nun enderezo privado sen ruta polo túnel dividido fai que cada consulta se atore e despois falle. Unha regra de política que cobre o sufixo interno e apunta a un servidor caído produce o mesmo erro visible que unha ruta ausente. Un sufixo de busca que falta no adaptador da VPN converte un nome curto nunha consulta pública polo dominio equivocado. Cada un precisa unha reparación distinta.

Por que o navegador fai outra pregunta

nslookup emite a súa propia consulta ao servidor que escolle e non segue nin a política de espazo de nomes nin o axuste de DNS cifrado do navegador. Por iso unha consulta manual contra un resolutor público responde mentres o navegador informa de que o sitio non existe. Vostede compara dous programas, non dous estados dun programa.

A preferencia de familia de enderezos explica un atraso, non un fallo. Un navegador que pide primeiro rexistros IPv6 nun túnel que só transporta IPv4 espera a que venza o tempo de espera antes de retroceder. Firefox levou unha preferencia precisamente para isto, e desactivala é un paso de diagnóstico, non unha reparación.

Lea a lista de resolutores e as regras

En Windows, volque o que o sistema garda antes de teorizar. Get-DnsClientServerAddress mostra os servidores por interface, Get-DnsClientNrptRule enumera as regras de espazo de nomes e Resolve-DnsName responde o nome exacto pola ruta do sistema. Compare esa resposta cunha consulta directa ao servidor da VPN por enderezo. Cando Resolve-DnsName falla e a consulta directa ten éxito, o sospeitoso é a lista de resolutores ou unha regra de espazo de nomes.

Comprobe tamén o nome en si. Un nome curto interno pode precisar o sufixo privado que só fornece o adaptador da VPN, mentres que o nome totalmente cualificado se resolve ben. Un aviso de certificado tras unha consulta correcta pertence a outro problema.

O resolutor empuxado inalcanzable

A pasarela ou o cliente poden empuxar un enderezo de resolutor, e ese enderezo debe ser alcanzable polo túnel. Nun túnel dividido, o rango privado que contén o resolutor pode non estar entre as rutas incluídas, o que produce unha consulta que nunca recibe resposta. Confirme que a ruta existe e logo consulte ese enderezo en concreto, polo túnel. Este é o fallo detrás dun erro de dominio no navegador mentres un resolutor público aínda responde.

Se o resolutor é inalcanzable, a reparación é unha ruta ou unha subrede incluída, non outro servidor DNS.

O DNS cifrado evita todo o camiño

Os navegadores con DNS-over-HTTPS resolven os nomes eles mesmos mediante unha conexión HTTPS a un provedor escollido. Con iso activado, o resolutor do sistema e as regras de DNS dividido evítanse por completo para esas consultas, así que os nomes internos fallan no navegador mentres o sistema operativo os resolve correctamente. Tamén ocorre o contrario: nomes internos teñen éxito no navegador a través dun provedor que nunca debería velos, e iso é un problema de política, non de conectividade.

Decida deliberadamente se se permite o DNS cifrado en dispositivos xestionados e logo configúreo mediante a superficie de xestión do navegador para que a elección sexa visible. Deixalo á preferencia individual produce un parque onde a mesma VPN se comporta distinto en cada portátil.

Reparacións que encaixan co fallo

Se a VPN empuxa o seu resolutor, faga que o túnel leve tráfico cara a el e que o mesmo axuste sexa visible nos adaptadores que participan na resolución. Se os sitios locais deixan de resolverse mentres está conectado, engada excepcións explícitas de espazo de nomes ou un reenviador condicional en lugar de substituír o resolutor por completo. Se o DNS cifrado do navegador evita a política, ese é o axuste que hai que cambiar. Nunca engada un resolutor público para arranxar un nome interno: filtra consultas privadas e non resolve o nome.

Logo separe a consulta da conexión. Un nome que se resolve no enderezo correcto pero rexeita unha conexión é un problema de servizo, cortafuegos ou certificado, e os cambios de DNS non o arranxarán.

Rexistre que camiño respondeu, cal fallou e que cambiou. O seguinte informe do mesmo síntoma custará entón un comando en lugar dunha tarde.