DNS geográfico e anycast: verificando o ponto de entrada VPN que você recebe

Uma resposta DNS próxima parece um problema resolvido até a conexão aterrissar em outro lugar. O DNS geográfico e o anycast tentam encurtar o caminho, e tomam essa decisão a partir de informações diferentes. Nenhum dos dois garante que o gateway alcançado seja acessível, que apresente a identidade que seu cliente espera ou que sua sessão sobreviva a uma troca de nó. As verificações abaixo separam essas quatro perguntas.

Verifique qual localização o resolvedor realmente informa

Um servidor autoritativo que responde a uma consulta sensível à topologia normalmente vê o endereço do resolvedor recursivo que perguntou, não o endereço da pessoa que digitou o nome. Um resolvedor centralizado pode ficar longe dos clientes que atende, e a resposta reflete o resolvedor, e não eles. Isso não é um defeito; é assim que o protocolo se comporta, a menos que informações extras sejam fornecidas. A especificação do EDNS Client Subnet descreve tanto a limitação quanto a solução opcional.

O EDNS Client Subnet pode transportar informações da rede de origem quando cada participante o suporta e habilita. É opcional, tem consequências de privacidade e cache, e não é permissão para supor que qualquer resolvedor público informe uma localização precisa do usuário. Pergunte aos operadores do resolvedor antes de projetar em torno disso.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Verifique o que o roteamento anycast decidiu

Com anycast, várias localizações anunciam acessibilidade para um endereço de serviço, e a rede entrega cada cliente ao nó que seu roteamento prefere. Essa escolha é feita pelo BGP e pela política ao redor, não pela distância no mapa. Proximidade topológica também geralmente não equivale a melhor desempenho de ida e volta, porque o caminho que parece curto pode estar congestionado ou assimétrico. O endereço que você recebeu não diz nada sobre qual nó respondeu.

Confirme a localização que atende pelo lado do serviço, ou por uma resposta que a nomeie, em vez de apenas pela resposta DNS. traceroute -n 198.51.100.20 mostra o caminho percorrido e ainda não nomeia o host no final dele, então leia como caminho e não como resposta.

Verifique se a sessão sobrevive a uma troca de nó

Uma consulta DNS é curta e uma sessão VPN é longa, e as duas têm requisitos de estado completamente diferentes. O roteamento pode mudar no meio da sessão e, quando isso acontece, pacotes posteriores podem chegar a um nó que nunca viu seu túnel. Se isso é sobrevivível depende da implementação: estado compartilhado, reconexão deliberada ou falha documentada. O endereço sozinho não fornece nada disso.

Observe a mudança em vez de supor. sudo tcpdump -ni any -c 20 esp mostra os pacotes externos enquanto o caminho muda, e uma mudança súbita no endereço do par é a mudança acontecendo. Defina explicitamente o comportamento pretendido para a implementação que você opera e depois teste-o forçando uma mudança de caminho. Se o projeto pressupõe replicação de sessão, nomeie o mecanismo e nomeie a falha que ele não cobre.

Verifique se a identidade ainda corresponde

Cada ponto de entrada precisa apresentar a identidade que o perfil do seu cliente espera. Um certificado emitido para o nome do serviço funciona entre nós, enquanto certificados por nó obrigam o cliente a aceitar algo novo, e é aí que os usuários aprendem a clicar pelos avisos. Mantenha a identidade esperada e o perfil consistentes com o modelo de entrada.

Verifique isso a partir de um cliente que chegou a um nó incomum, porque é o caso em que um certificado por nó se torna visível. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com imprime a cadeia e os nomes, exatamente o que o cliente compara. Depois decida se o perfil deve ser restringido ou se o modelo de certificado deve mudar.

Verifique o registro, não apenas a primeira resposta

Avalie três cenários e escreva quatro fatos para cada um: entrada normal, uma localização indisponível e o caso de recuperação acordado. Os quatro fatos são o resolvedor usado, o endereço retornado, a localização que atendeu e um resultado novo da aplicação. Esse registro separa um problema de seleção de DNS de um problema de gateway, de roteamento ou de estado de sessão. Sem ele, os quatro parecem idênticos do cliente.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Execute os cenários a partir de redes de acesso representativas, e não apenas do escritório, porque toda a questão é qual ponto de entrada clientes diferentes realmente alcançam. Uma rede é uma amostra de uma.