DNS dividido e VPN: as regras de domínio não são rotas IP

O seu portátil resolve intranet.corp pelo túnel enquanto o gitlab.com continua a ir para o resolvedor do fornecedor, e essa é a disposição que funciona como foi projetada. Duas decisões separadas produziram-na: uma regra de correspondência de nomes escolheu o resolvedor e uma rota trouxe a resposta de volta. Quebre qualquer uma delas e o navegador mostra uma falha que, de fora, parece a mesma. A maioria dos relatos de DNS dividido descreve a segunda falha enquanto cita provas sobre a primeira.

As duas metades vivem em sítios diferentes e normalmente são editadas por pessoas diferentes. Uma é a política de DNS ligada ao perfil de VPN, a outra é uma rota que o túnel instala ou retém. A depuração para quando ninguém estabelece qual metade se moveu realmente.

Duas decisões escondidas num único pedido

A metade do nome é um objeto de política, não uma rota. No Windows é uma política de resolução de nomes no perfil de VPN; nas plataformas Apple, um conjunto de domínios de correspondência num objeto de configurações de DNS; no Linux, um domínio de encaminhamento, uma linha de resolvedor dividido ou a ordem do comutador de serviços de nomes. A metade do caminho é encaminhamento comum, instalado pelo túnel ou à mão, e não faz ideia do que é um nome de anfitrião. Um perfil que admite um sufixo decide apenas quem responde; nunca torna a resposta alcançável.

Um teste rápido de sintomas separa-as: substitua o nome por um endereço. Se o endereço funcionar, o caminho está bem e a regra errada. Se o endereço também falhar, a regra pode estar certa e faltar o caminho.

Como cada plataforma exprime a mesma regra de nome

A intenção é idêntica e os nomes dos campos não. Um exemplo copiado de um cliente para outro é analisado corretamente e nunca corresponde. As três formas são assim:

Um domínio de correspondência ou de encaminhamento é um teste de sufixo, pelo que intranet.corp cobre git.intranet.corp e não cobre corp.intranet, e inverter isso é o erro mais comum de toda a configuração. O Windows transporta o mapeamento como política de resolução de nomes ligada ao perfil, com a sua própria ordem de precedência face a qualquer lista de sufixos que a interface já tivesse. As plataformas Apple ligam os domínios de correspondência ao objeto de configurações de DNS da extensão de rede, e o sistema aplica-os por cada resolvedor delimitado. Nenhuma destas formas é uma rota, e nenhuma pode tornar alcançável um endereço inalcançável. A referência política de resolução de nomes do Windows enumera os nomes de campos e as regras de precedência para essa plataforma, e não são as que os documentos da Apple ou do systemd usam.

Uma resposta correta ainda precisa de um caminho

A resposta de um resolvedor é apenas um endereço, e a aplicação ainda tem de lá chegar. Um desenho de túnel dividido empurra muitas vezes 10.20.0.0/16 e retém a rota predefinida, pelo que o nome interno se resolve e a ligação depois fica pendurada. O caso oposto é igualmente comum: a rota existe, um resolvedor público responde ao nome privado com NXDOMAIN e a falha fica registada como problema de encaminhamento. Testar o caminho primeiro deixa-o a olhar para rotas por um nome que nunca se ia resolver.

Há também uma terceira porta que nenhuma metade cobre. Uma ACL na gateway, uma regra de firewall ou uma política do lado do cliente podem deixar cair a ligação depois de ambas as decisões estarem certas. Quando o nome se resolve, a rota existe e a ligação continua a expirar, pare de testar DNS.

Testar nomes e caminhos numa ordem fixa

Escolha uma ordem e mantenha-a, ou vai perseguir o passo que falhou mais recentemente. Resolva o nome interno completo documentado, confirme que a resposta é um endereço que a tabela de rotas pode transportar, e depois repita com um nome público para provar que o túnel não capturou tudo. Num anfitrião systemd a consulta e o domínio de encaminhamento do resolvedor estão a um comando de distância:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Um cliente Windows faz as mesmas duas perguntas com outros cmdlets. O segundo relata a interface que o sistema usaria realmente:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Se a pesquisa devolver um endereço e a verificação do caminho nomear a interface física, a regra de nomes funcionou e a rota não. Se o nome curto falhar enquanto o nome completo se resolve, a lista de sufixos está errada e não o resolvedor.

Onde a comparação costuma correr mal

O primeiro erro é perguntar a um resolvedor público não relacionado por um nome privado e ler a recusa como prova sobre a VPN. O segundo é assumir que uma pesquisa pública que funciona prova o caminho do resolvedor do túnel. O terceiro é tratar o túnel dividido e o DNS dividido como uma única decisão de desenho, quando uma implementação pode estar correta num e quebrada no outro. Cada erro produz conclusões confiantes a partir de um teste que nunca exercitou a parte acusada.

Um navegador com o seu próprio DNS seguro também pode contornar a regra do sistema, e é por isso que um navegador falhar enquanto outro consegue não é uma contradição. Compare o resolvedor que respondeu, não o navegador que se queixou.

Assim que ambas as metades estão visíveis, a pergunta restante é de política e não técnica: que espaços de nomes pertencem à organização, quem detém cada resposta e quais deles devem sair da máquina. Escreva isso ao lado do perfil, porque a próxima pessoa que mexer na regra vai precisar disso.