Nomes internos falham na VPN enquanto sites públicos resolvem bem

Um usuário relata que o nome do host da intranet não resolve pela VPN. Um segundo relato, do mesmo notebook, diz que um teste de vazamento ainda mostra consultas respondidas pelo resolvedor local. Parecem um único problema e são dois, com evidências diferentes, e o reparo habitual do primeiro piora o segundo. Separe-os antes de mexer em qualquer configuração.

Dois sintomas que não são uma única falha

Falhar ao resolver um nome interno significa que a pergunta foi para algum lugar que não tem resposta para ela. Consultas saindo do túnel significam que a pergunta foi para o lugar errado mesmo quando a resposta estava disponível. São falhas opostas: uma é uma resposta ausente, a outra é um destino extra.

A armadilha é que adicionar o resolvedor do escritório em toda parte corrige a primeira e garante a segunda. Adicionar um resolvedor público em toda parte faz o contrário.

Anote as duas observações com um carimbo de data e hora e depois percorra as quatro verificações abaixo em ordem.

Qual resolvedor de adaptador recebe a pergunta

No Windows, o cliente DNS escolhe servidores conforme a ordem de associação dos adaptadores, e o adaptador do túnel não é automaticamente o primeiro. Abra as configurações avançadas do adaptador e mova a conexão de acesso remoto acima do adaptador físico, depois reconecte para que a mudança valha para uma sessão nova.

A ordem de associação é só a primeira metade. O cliente também precisa saber quais nomes pertencem àquele adaptador, e isso é uma questão de sufixo, não de ordenação.

Coloque o ipconfig /all da máquina que funciona ao lado do do notebook, ambos obtidos com o túnel ativo. A máquina que funciona mostrará um sufixo DNS específico da conexão no adaptador do escritório, e o notebook pode não mostrar nenhum no túnel. Essa diferença explica toda uma classe de relatos de que o servidor está bem ali e o nome ainda falha, porque sem sufixo o nome curto nunca é completado para a zona que o resolvedor do escritório atende.

Um nome curto precisa de sufixo antes de precisar de rota

Digitar um nome de host não qualificado pede ao resolvedor que adivinhe um domínio. A adivinhação vem da lista de sufixos ligada à conexão, e se essa lista estiver vazia a consulta sai como um único rótulo que nenhuma zona privada vai casar.

Copie o sufixo da máquina que funciona para as propriedades IPv4 do adaptador da VPN, na aba DNS, e reconecte. No Linux o equivalente é o domínio de busca no link do túnel, que o systemd-resolved expõe por link e não globalmente.

Mantenha as duas definições separadas nas suas notas. Um sufixo muda o que é perguntado; o endereço do resolvedor muda a quem se pergunta. Corrigir uma com a outra errada produz um resultado que parece aleatório.

Pergunte ao resolvedor diretamente, depois ao nome

Uma consulta direta ao resolvedor do escritório separa um problema de nome de um problema de caminho, porque contorna por completo a seleção de resolvedor do cliente.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

O primeiro comando pergunta a um servidor específico por um nome totalmente qualificado. Se ele responder, o resolvedor e a rota até ele estão bons e a falha está na seleção ou no sufixo. Se der tempo esgotado, o endereço está errado ou inalcançável e o problema é de roteamento, não de DNS. O segundo comando mostra o que acontece com o nome curto, e o terceiro imprime a configuração de resolvedor por link num host systemd.

Atenção às respostas curinga, que algumas redes devolvem para nomes desconhecidos. Uma resposta plausível não prova que o servidor pretendido respondeu, então compare o endereço devolvido com o que o serviço interno realmente usa. Se o endereço pertence a uma página de estacionamento ou a um proxy, o resolvedor respondeu, mas a resposta nunca foi sua. Essa distinção poupa uma hora de perseguição a um túnel que estava a funcionar o tempo todo.

No Linux, um cliente VPN que reescreve o /etc/resolv.conf substitui os resolvedores locais por completo. O vpnc expõe DNSUpdate no para impedir isso, e o systemd-resolved pode encaminhar apenas os domínios listados para o link do túnel. Ambas as abordagens mantêm os nomes públicos no resolvedor local enquanto enviam os nomes internos para o escritório.

Vazamentos são uma regra, não uma caixa de seleção

A resolução de nomes é uma troca UDP para a porta 53, então um túnel que carrega tráfego web mas não UDP deixa a consulta no caminho físico. Prove isso capturando na placa física enquanto um nome público é resolvido. Uma consulta visível nessa interface em forma legível significa que o túnel não a está carregando.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Se a consulta aparecer naquela interface em forma legível, o túnel não a está transportando. O reparo é uma regra que permite a porta 53 apenas para o resolvedor que a VPN enviou e descarta outros destinos, mais uma configuração de cliente que não descarte silenciosamente a opção enviada.

Essa última parte importa mais do que parece. Inicie o OpenVPN com route-nopull e a opção DNS enviada desaparece junto com as rotas, a menos que o filtro de pull seja ampliado para mantê-la. E um cliente que ignora dhcp-option DNS continuará usando o que tinha antes. Qualquer mudança do lado do servidor precisa de uma sessão nova para valer, já que a lista de resolvedores é entregue quando o túnel sobe e uma sessão antiga continua mostrando o estado velho.

Registre qual falha você realmente observou antes de fechar o ticket. Uma resposta interna ausente e uma consulta escapando do túnel exigem reparos diferentes, e uma mudança de sufixo que corrige a primeira pode piorar a segunda em silêncio. Quem pegar o ticket a seguir vai confiar no rótulo, então faça o rótulo corresponder à verdade.