Dois VPNs, um resolver: ganha quem escreveu por último

Dois clientes VPN estão conectados, um para o trabalho e outro para uma rede de laboratório, e os nomes internos só são resolvidos para o cliente que se conectou por último. Esse padrão parece um bug em um dos clientes. Normalmente é o resultado previsível de dois programas que escrevem a mesma configuração de resolvedor sem acordo sobre quem é dono de qual nome.

O mito: o VPN mais novo é dono do DNS

Não existe regra geral de que a conexão mais recente ganhe. O que acontece depende do mecanismo da plataforma e de como cada cliente o escreve. Um cliente que substitui um arquivo de resolvedor produz um resultado; um cliente que adiciona um domínio por link produz outro; um cliente que não faz nada deixa o estado anterior intacto.

Assim, o comportamento observado é uma propriedade das duas implementações, não uma prioridade documentada. Raciocinar sobre ele apenas pela ordem de inicialização às vezes acertará e às vezes falhará de maneiras difíceis de reproduzir. Em vez disso, escreva o mapeamento. Um projeto que vive em dois clientes não é um projeto.

Mapeie espaços de nomes para resolvedores

Liste os sufixos privados e o resolvedor exigido por cada rede, e então decida para onde os nomes públicos devem ir. Essa lista é o projeto. Sem ela, os clientes tomam a decisão por acidente.

Uma plataforma que oferece suporte a DNS por link ou domínios de roteamento pode expressar a divisão deliberadamente: um domínio vai para um link, outro domínio para o outro, e todo o resto segue um padrão explícito. Dois scripts simples que sobrescrevem o mesmo arquivo não conseguem preservar esse projeto, porque cada um acredita possuir toda a configuração.

No Windows, a tabela de política de resolução de nomes pode direcionar sufixos para servidores específicos, e um cliente VPN pode instalar regras ali. Verifique a política em vez da lista de adaptadores, porque não é a lista de adaptadores que resolve o nome.

Mantenha um caminho de bootstrap

Cada cliente precisa localizar seu próprio endpoint antes de poder usar o serviço que esse endpoint oferece. Se o nome de host do endpoint só pode ser resolvido pelo túnel, e o túnel precisa do nome de host resolvido, você tem uma dependência circular que aparece como timeout de conexão. Mantenha um caminho de bootstrap fora dos dois túneis. Ele não custa nada até o dia em que salva a conexão.

Olhe o caminho até cada resolvedor, não apenas o nome configurado para ele. Um resolvedor alcançável apenas pelo outro túnel se comporta como ausente, e o sintoma é um timeout em vez de um erro de roteamento.

Endereços sobrepostos não são um problema de DNS

Duas redes privadas que usam a mesma faixa de endereços não se corrigem com a ordem do DNS. Se ambos os túneis reivindicam 10.0.0.0/8, um nome resolvido corretamente ainda aponta para um endereço que o host não consegue rotear para o túnel certo. Isso exige uma solução em nível de endereço, como faixas distintas, um espaço de nomes ou tradução, não outra configuração de resolvedor. Decidir isso cedo evita um longo desvio por uma configuração de DNS que nunca funcionaria.

Compare as atribuições de endereço dos dois túneis antes de culpar a resolução de nomes. Quando os dois lados empurram o mesmo prefixo, o host mantém uma única rota para ele, e um nome resolvido pelo segundo túnel ainda cai em um endereço que o primeiro túnel possui. Faixas distintas, um espaço de nomes por rede ou tradução são as correções; depois que cada cliente se conectar, confirme que a tabela de rotas mostra o caminho pretendido.

Prove com aplicações reais

Escolha dois hosts que existem apenas dentro do próprio espaço de nomes e um nome público, e então resolva cada um pelo cliente que deveria possuí-lo. Uma resposta correta do resolvedor esperado não prova que a aplicação alcança o host, porque a rota até esse endereço ainda pode falhar. Acompanhe cada consulta com um teste de conexão a partir do programa que o usuário realmente executará.

Um cliente com sua própria opção de DNS criptografado pode contornar a política que você acabou de verificar, então confira essa configuração como parte da revisão. Depois reconecte os dois clientes na ordem suportada pelo fornecedor e repita as consultas; se as respostas se invertem quando a ordem muda, um escritor concorrente ainda possui parte da configuração. Descubra qual componente instala a regra - o cliente, o perfil do sistema operacional ou um agente de gerenciamento - antes de editar qualquer coisa. Anote a ordem e os proprietários para que a próxima pessoa não precise redescobri-los.