Porque o nslookup resolve pela VPN mas o navegador não

O nslookup envia uma consulta ao servidor que indicar e imprime a resposta, por isso pode ter sucesso enquanto cada separador do navegador falha. O navegador pede ao sistema operativo que resolva, e o sistema pondera os resolvedores de cada interface, as regras de política de resolução de nomes e a localização de rede do adaptador. Depois o navegador pode acrescentar o seu próprio DNS cifrado por cima. Três caminhos diferentes, um sintoma, e o túnel normalmente não é a parte avariada.

As verificações abaixo seguem esses caminhos do sistema para fora. Não edite o perfil da VPN antes de saber que caminho respondeu e qual falhou.

Três políticas decidem a resposta

Cada interface tem a sua própria lista de resolvedores e sufixos de pesquisa. Um adaptador VPN acrescenta servidores enquanto o adaptador físico mantém os seus, e o sistema pode escolher o que responder primeiro, pelo que uma consulta pode ser servida fora do túnel sem que ninguém o tenha escolhido. As regras da tabela de política de resolução de nomes podem enviar domínios escolhidos para servidores escolhidos, que é como o DNS dividido se exprime normalmente no Windows. E o cliente ou a gateway da VPN podem empurrar um endereço de resolvedor que só existe dentro da rede privada.

Estes três interagem de formas que, vistos do navegador, parecem arbitrárias. Um resolvedor empurrado num endereço privado sem rota pelo túnel dividido faz cada consulta bloquear e depois falhar. Uma regra de política que cobre o sufixo interno e aponta para um servidor em baixo produz o mesmo erro visível que uma rota em falta. Um sufixo de pesquisa em falta no adaptador da VPN transforma um nome curto numa consulta pública para o domínio errado. Cada um exige uma reparação diferente.

Porque o navegador faz outra pergunta

O nslookup emite a sua própria consulta para o servidor que escolhe e não segue nem a política do espaço de nomes nem a definição de DNS cifrado do navegador. É por isso que uma consulta manual a um resolvedor público responde enquanto o navegador informa que o site não existe. Está a comparar dois programas, não dois estados de um programa.

A preferência de família de endereços explica atraso e não falha. Um navegador que pede primeiro registos IPv6 num túnel que só transporta IPv4 espera que o tempo limite expire antes de recuar. O Firefox tem tido uma preferência precisamente para isto, e desativá-la é um passo de diagnóstico, não uma reparação.

Leia a lista de resolvedores e as regras

No Windows, despeje o que o sistema guarda antes de teorizar. O Get-DnsClientServerAddress mostra os servidores por interface, o Get-DnsClientNrptRule lista as regras do espaço de nomes e o Resolve-DnsName responde ao nome exato pelo caminho do sistema. Compare essa resposta com uma consulta direta ao servidor da VPN por endereço. Quando o Resolve-DnsName falha e a consulta direta tem sucesso, o suspeito é a lista de resolvedores ou uma regra do espaço de nomes.

Verifique também o nome em si. Um nome curto interno pode precisar do sufixo privado que só o adaptador VPN fornece, enquanto o nome totalmente qualificado resolve bem. Um aviso de certificado após uma consulta bem-sucedida pertence a outro problema.

O resolvedor empurrado inalcançável

A gateway ou o cliente podem empurrar um endereço de resolvedor, e esse endereço tem de ser alcançável pelo túnel. Num túnel dividido, o intervalo privado que contém o resolvedor pode não estar entre as rotas incluídas, o que produz uma consulta que nunca recebe resposta. Confirme que a rota existe e depois consulte esse endereço em concreto, pelo túnel. Esta é a falha por trás de um erro de domínio no navegador enquanto um resolvedor público ainda responde.

Se o resolvedor for inalcançável, a reparação é uma rota ou uma sub-rede incluída, não outro servidor DNS.

O DNS cifrado contorna todo o caminho

Os navegadores com DNS-over-HTTPS resolvem os nomes eles próprios através de uma ligação HTTPS a um fornecedor escolhido. Com isso ativo, o resolvedor do sistema e as regras de DNS dividido são totalmente contornados para essas consultas, pelo que os nomes internos falham no navegador enquanto o sistema operativo os resolve corretamente. Também acontece o contrário: nomes internos têm sucesso no navegador através de um fornecedor que nunca os devia ver, e isso é um problema de política e não de conectividade.

Decida deliberadamente se o DNS cifrado é permitido em dispositivos geridos e depois configure-o através da superfície de gestão do navegador para que a escolha seja visível. Deixá-lo à preferência individual produz um parque em que a mesma VPN se comporta de forma diferente em cada portátil.

Reparações que correspondem à falha

Se a VPN empurra o seu resolvedor, faça com que o túnel transporte tráfego até ele e com que a mesma definição esteja visível nos adaptadores que participam na resolução. Se os sites locais deixarem de resolver enquanto está ligado, acrescente exceções explícitas de espaço de nomes ou um reencaminhador condicional em vez de substituir o resolvedor por completo. Se o DNS cifrado do navegador contornar a política, é essa a definição a alterar. Nunca acrescente um resolvedor público para corrigir um nome interno: liberta consultas privadas e não resolve o nome.

Depois separe a consulta da ligação. Um nome que resolve para o endereço certo mas recusa uma ligação é um problema de serviço, firewall ou certificado, e alterações de DNS não o corrigem.

Registe que caminho respondeu, qual falhou e o que alterou. O próximo relatório do mesmo sintoma custará então um comando em vez de uma tarde.