DNS xeográfico e anycast: comprobar a entrada VPN que recibe

Unha resposta DNS próxima parece un problema resolto ata que a conexión aterra noutro lugar. O DNS xeográfico e o anycast intentan ambos acurtar o camiño, e toman esa decisión a partir de información distinta. Ningún garante que a pasarela á que chega sexa alcanzable, que presente a identidade que o seu cliente espera ou que a súa sesión sobreviva a un cambio de nodo. As comprobacións seguintes separan esas catro preguntas.

Comprobe de quen é a localización que o resolutor informa en realidade

Un servidor autoritativo que responde a unha consulta sensible á topoloxía normalmente ve o enderezo do resolutor recursivo que preguntou, non o enderezo da persoa que escribiu o nome. Un resolutor centralizado pode estar lonxe dos clientes aos que serve, e a resposta reflicte o resolutor e non eles. Iso non é un defecto; é como se comporta o protocolo salvo que se achegue información adicional. Especificación de EDNS Client Subnet describe tanto a limitación como o remedio opcional.

EDNS Client Subnet pode transportar información da rede de orixe cando cada participante o admite e o activa. É opcional, ten consecuencias para a privacidade e a caché, e non é permiso para supor que calquera resolutor público informa dunha localización precisa do usuario. Pregunte aos operadores de resolutores antes de deseñar arredor diso.

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

Comprobe que decidiu o encamiñamento anycast

Con anycast, varias localizacións anuncian alcanzabilidade para un enderezo de servizo, e a rede entrega cada cliente ao nodo que prefire o seu encamiñamento. Esa elección fan BGP e a política da contorna, non a distancia nun mapa. A proximidade topolóxica tampouco equivale por regra xeral a un mellor rendemento de ida e volta, porque o camiño que parece curto pode estar conxestionado ou ser asimétrico. O enderezo que lle deron non di nada sobre que nodo respondeu.

Confirme a localización de servizo desde o lado do servizo, ou desde unha resposta que a nomee, e non só desde a resposta DNS. traceroute -n 198.51.100.20 mostra o camiño que tomou e aínda así non nomea o host ao final, así que lea como un camiño e non como unha resposta.

Comprobe que a sesión sobrevive a un cambio de nodo

Unha consulta DNS é curta e unha sesión VPN é longa, e ambas teñen requisitos de estado completamente distintos. O encamiñamento pode desprazarse a metade da sesión e, cando o fai, os paquetes posteriores poden chegar a un nodo que nunca viu o seu túnel. Se iso é sobrevivible depende da implementación: estado compartido, unha reconexión deliberada ou un fallo documentado. O enderezo por si só non achega nada diso.

Observe o desprazamento en lugar de supoñelo. sudo tcpdump -ni any -c 20 esp mostra os paquetes exteriores a medida que o camiño cambia, e un cambio repentino no enderezo do par é o desprazamento a suceder. Defina explicitamente o comportamento previsto para a implementación que executa e despois probeo forzando un cambio de camiño. Se o deseño supón replicación de sesión, nomee o mecanismo e nomee o fallo que non cobre.

Comprobe que a identidade segue coincidindo

Cada punto de entrada ten que presentar a identidade que o seu perfil de cliente espera. Un certificado emitido para o nome do servizo funciona en todos os nodos, mentres que os certificados por nodo obrigan o cliente a aceptar algo novo, e aí é onde os usuarios aprenden a pasar por riba dos avisos. Manteña a identidade esperada e o perfil coherentes co modelo de entrada.

Compróbeo desde un cliente que chegou a un nodo pouco habitual, porque é o caso no que un certificado por nodo se fai visible. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com imprime a cadea e os nomes, que é exactamente o que compara o cliente. Despois decida se se debe estreitar o perfil ou cambiar o modelo de certificado.

Comprobe o rexistro, non só a primeira resposta

Avalíe tres escenarios e escriba catro feitos para cada un: entrada normal, unha localización non dispoñible e o caso de recuperación acordado. Os catro feitos son o resolutor usado, o enderezo devolto, a localización que serviu e un resultado fresco da aplicación. Ese rexistro separa un problema de selección DNS dun problema de pasarela, de encamiñamento ou de estado de sesión. Sen el, os catro parecen idénticos desde o 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 escenarios desde redes de acceso representativas e non só desde a oficina, porque toda a cuestión é a que punto de entrada chegan realmente clientes distintos. Unha rede é unha mostra de unha.