Por que nomes DNS privados falham nos clientes VPN e onde verificar

Você abre um notebook num quarto de hotel, inicia o cliente, digita o nome do servidor de arquivos interno e não recebe nada. O túnel diz conectado, e um ping para um endereço na mesma sub-rede ainda responde, então o transporte em si está bem. Só o nome falha, e essa lacuna reduz o problema a dois lugares: qual resolvedor o cliente consultou e se a resposta que ele obteve consegue voltar pelo túnel. Acerte um e ignore o outro, e a falha simplesmente muda de lugar.

Antes de editar qualquer perfil, confirme o que o cliente faz com o nome. No Linux, resolvectl query files.corp.example mostra qual enlace e qual resolvedor produziram a resposta. No Windows, Resolve-DnsName files.corp.example mostra o servidor que respondeu e o endereço que ele devolveu.

Leia a resposta antes de mudar qualquer coisa

Se o nome volta como NXDOMAIN em poucos milissegundos, a consulta nunca chegou à sua zona e algum resolvedor público ou do hotel respondeu no lugar. Se volta depois de uma pausa longa, algo está descartando a porta UDP 53 no caminho e o cliente acabou recorrendo a outro. Se responde com o endereço certo mas a conexão continua travada, a consulta está boa e o seu problema é o roteamento ou o próprio serviço.

Essa divisão em três economiza uma hora de adivinhação. Ela também diz se você deve mexer na VPN: um nome que resolve para o endereço privado correto já provou o caminho do resolvedor, então o trabalho que sobra está no caminho dos dados.

Entregue o resolvedor de dentro do túnel

Os clientes se dividem em dois grupos. Um grupo pode receber um resolvedor do servidor durante o estabelecimento da conexão; o outro mantém a configuração num arquivo local que nenhum gateway consegue mudar remotamente.

OpenVPN está no primeiro grupo. No servidor, push "dhcp-option DNS 10.8.0.53" e push "dhcp-option DOMAIN corp.example" descem pelo canal de controle, mas só se a configuração do cliente ainda tiver pull ativado. Um cliente editado à mão com pull-filter ignore "dhcp-option" nunca os verá, e essa única linha explica um número surpreendente de casos de «o servidor empurra, mas meu notebook discorda».

WireGuard está no segundo grupo, porque o protocolo não tem negociação de opções nenhuma. O resolvedor e o domínio de busca vão no bloco [Interface] do próprio cliente como DNS = 10.8.0.53, corp.example. O wg-quick aplica isso via resolvconf ou systemd-resolved, e no Windows o cliente oficial instala regras NRPT que só existem enquanto o túnel está de pé: Get-DnsClientNrptPolicy as lista, o que faz dele um jeito rápido de ver se o cliente algum dia aplicou o seu arquivo.

IPsec/IKEv2 fica no meio. O plugin attr do strongSwan pode devolver um servidor DNS tirado de um pool, e um cliente Windows normalmente aceita, mas um perfil que fixa o próprio servidor de nomes vence o que o gateway oferecer. Num cliente Linux o passo manual equivalente é resolvectl dns wg0 10.8.0.53 seguido de resolvectl domain wg0 '~corp.example'; os dois somem junto com a interface, que é exatamente o que você quer para um ajuste limitado ao túnel.

Delimite o sufixo em vez de engolir cada consulta

Apontar toda a lista de resolvedores do cliente para o seu servidor interno é fácil e quase sempre errado. Aí todo nome público resolve pela saída do seu data center, as CDNs devolvem endereços distantes e uma queda do resolvedor leva junto a navegação do usuário.

Mande para dentro só o sufixo privado. No systemd-resolved, um domínio que começa com ~ serve só para roteamento, então ~corp.example significa que as consultas sob esse sufixo vão para os servidores desse enlace enquanto todo o resto continua usando a rede física. O Windows faz o mesmo com regras NRPT delimitadas a um namespace, e o macOS com um arquivo de resolvedor suplementar em /etc/resolver/.

Nomes multicast merecem resposta própria. Nomes .local são link-local por projeto (RFC 6762) e uma interface tun ponto a ponto não transporta esse grupo multicast, então adicionar um resolvedor público não os publica e perguntar por eles a um resolvedor interno unicast devolve NXDOMAIN. Um refletor como o avahi em modo refletor consegue ligar dois segmentos, mas isso é uma decisão do lado do servidor que nenhum cliente pode pedir. Se uma impressora ou um NAS precisa ser alcançável por nome, dê a ele um registro A na sua zona.

Prove que a resposta consegue voltar

Uma resposta correta apontando para um endereço inalcançável parece exatamente um problema de resolvedor até você verificar a rota. Pergunte ao kernel para onde a resposta iria: ip route get 10.20.5.20 nomeia a interface e, mais útil, o endereço de origem que ela usaria.

Observe o endereço do resolvedor em si. Um cliente com DNS = 10.8.0.53 ao lado de AllowedIPs = 10.20.0.0/16 manda suas consultas pela NIC física, onde elas morrem em silêncio, porque o resolvedor não está dentro de nenhum prefixo que o túnel reivindique. Essa divergência é a falha de causa única mais comum em toda essa área, e ela é invisível a menos que você compare a configuração de DNS com os prefixos permitidos linha por linha.

Faixas sobrepostas causam a falha oposta. A resposta está certa, a rota existe e aponta para o host errado, porque 192.168.0.0/24 em casa é mais específica que a rota do túnel para a mesma faixa. Renumere um lado ou empurre uma rota mais estreita, depois confirme o firewall e o caminho de volta do host do serviço; as notas do strongSwan sobre encaminhamento cobrem o lado sysctl desse caminho.

Certificados são uma verificação de identidade à parte que as pessoas culpam o DNS. Se o navegador relata uma divergência de nome em vez de um erro de resolução, a consulta já funcionou e o que precisa ser corrigido é o SAN do certificado. Teste HTTPS contra o nome, nunca contra o IP puro.

Teste de novo a partir do cliente, não do gateway

Teste dentro do aplicativo de que o usuário reclama, porque uma consulta na linha de comando não prova que o navegador segue o mesmo caminho. O DNS seguro do Chrome e o network.trr.mode do Firefox podem ignorar o resolvedor do sistema por completo, e quando fazem isso um nome privado falha ou vaza para um resolvedor público. Comparar resolvectl query com um dig @10.8.0.53 files.corp.example executado à mão diz qual dos dois aconteceu.

Depois desconecte e reconecte antes de dar por resolvido. Ajustes aplicados à mão numa interface somem junto com a interface, e um perfil que só parecia correto por causa de uma edição local esquecida vai falhar no próximo boot.

Uma lista curta para a próxima máquina: o nome resolve pelo resolvedor do túnel, o sufixo está delimitado em vez de global, o endereço do resolvedor fica dentro dos prefixos permitidos, o host da resposta responde na porta do serviço e o certificado cobre o nome que o usuário digitou.