Nome do endpoint VPN versus nome de serviço privado: dois responsáveis

Dois nomes podem descrever a mesma filial e responder a perguntas completamente diferentes. vpn.branch.example diz a um par remoto onde encontrar o endpoint VPN, e tem de ser resolvido antes de existir qualquer túnel. inventory.branch.example diz a um utilizador autorizado onde vive uma aplicação privada, e só importa depois de o túnel estar levantado. Manter um deles não faz nada pelo outro.

Nomeie os dois registos antes de depurar qualquer um deles

Anote ambos com os seus responsáveis. Para o endpoint, registe quem atualiza o endereço público e como o cliente VPN renova a sua resposta. Para o serviço, registe quem é dono do endereço privado, que zona contém o registo e que resolvers devem responder por ele.

Essa lista curta evita o diagnóstico errado mais comum nesta área: reiniciar um túnel de filial que funciona para reparar um registo que vive inteiramente dentro dele. O túnel é o transporte do nome do serviço; não é a sua autoridade.

Quando se propõe uma alteração, pergunte qual dos dois registos ela toca. Se ninguém conseguir responder, a alteração não está pronta para ser agendada.

O endpoint tem de ser resolvido antes de existir qualquer túnel

Suponha que a ligação à internet da filial recebe um novo endereço público. O atualizador do endpoint publica o novo endereço, e a implementação remota de VPN tem de conseguir ler a resposta alterada. Qualquer resolver que forneça essa resposta tem de ser alcançável sem o túnel, ou o cliente anda atrás de um nome que só consegue resolver depois de se ligar àquilo que não encontra.

Vale a pena dizer esta dependência de arranque com clareza, porque é fácil criá-la por acidente quando todos os resolvers internos estão atrás da VPN. Mantenha um caminho antes do túnel para a consulta do endpoint e confirme o comportamento de reconexão do cliente em vez de assumir que uma nova resposta é captada imediatamente.

O DNS dinâmico também tem limites que a atualização do registo não pode atravessar. Atualizar um registo não abre nenhuma porta de firewall, não cria nenhum mapeamento NAT e não prova nenhuma identidade de par. Um endereço publicado com a porta fechada dá um cliente que resolve corretamente e mesmo assim não consegue ligar-se a nada.

Por fim, um cliente em execução pode continuar a usar um endpoint em cache até se reconectar. Separe a publicação, a cache e a política de reconexão nas suas notas, para que um par obsoleto não seja confundido com um atualizador avariado.

O nome do serviço descreve onde vive a aplicação

Agora suponha que o túnel continua saudável mas o servidor de inventário passa de 172.26.14.20 para 172.26.14.35. O registo público do endpoint não é afetado, enquanto o registo privado do serviço tem de mudar. Usar um endereço reservado para esse serviço, ou uma atribuição estática, torna isto mais raro; um caminho de atualização autorizado trata das vezes em que isso é intencional.

Aqui confundem-se dois mecanismos de atualização. RFC 2136 define um protocolo para adicionar e remover registos DNS numa zona, enquanto um fornecedor comercial de DNS dinâmico pode expor uma API HTTP completamente diferente para outro fim. Usar um não implica que o outro exista no seu ambiente. Verifique que mecanismo a sua zona aceita realmente antes de escrever um atualizador contra ele.

Uma resposta privada correta é apenas a primeira condição. Para que um autor de chamadas remoto a use, o cliente precisa de um resolver que transporte a zona privada, de uma política que permita consultas a esse resolver e de encaminhamento para o endereço que volta. Um nome que resolve para um endereço que o cliente não consegue alcançar produz um tempo limite que parece uma falha do servidor.

Teste os dois caminhos em separado

Verifique o endpoint de fora do túnel e o serviço de dentro, e guarde os resultados como dois factos independentes:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Se a primeira consulta falhar, o problema é a publicação pública ou o caminho de resolução antes do túnel, e nenhuma alteração interna ajudará. Se a segunda devolver um endereço mas a terceira não mostrar nenhuma rota pelo túnel, a camada DNS está bem e a política de encaminhamento não.

Execute o par após cada alteração de endereço e anote que registo se moveu. Uma passagem de testemunho que diz apenas «o DNS foi atualizado» deixa o próximo engenheiro a adivinhar qual dos dois ciclos de vida foi realmente executado.