DNS geográfico y anycast: comprobar la entrada VPN que recibe

Una respuesta DNS cercana parece un problema resuelto hasta que la conexión aterriza en otro lugar. El DNS geográfico y el anycast intentan ambos acortar el camino, y toman esa decisión a partir de información distinta. Ninguno garantiza que la puerta de enlace a la que llega sea alcanzable, que presente la identidad que su cliente espera o que su sesión sobreviva a un cambio de nodo. Las comprobaciones siguientes separan esas cuatro preguntas.

Compruebe de quién es la ubicación que el resolutor informa en realidad

Un servidor autoritativo que responde a una consulta sensible a la topología normalmente ve la dirección del resolutor recursivo que preguntó, no la dirección de la persona que escribió el nombre. Un resolutor centralizado puede estar lejos de los clientes a los que sirve, y la respuesta refleja al resolutor y no a ellos. Eso no es un defecto; es como se comporta el protocolo salvo que se aporte información adicional. Especificación de EDNS Client Subnet describe tanto la limitación como el remedio opcional.

EDNS Client Subnet puede transportar información de la red de origen cuando cada participante lo admite y lo habilita. Es opcional, tiene consecuencias para la privacidad y la caché, y no es permiso para suponer que cualquier resolutor público informa de una ubicación precisa del usuario. Pregunte a los operadores de resolutores antes de diseñar en torno a ello.

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

Compruebe qué ha decidido el enrutamiento anycast

Con anycast, varias ubicaciones anuncian alcanzabilidad para una dirección de servicio, y la red entrega cada cliente al nodo que prefiere su enrutamiento. Esa elección la hacen BGP y la política del entorno, no la distancia en un mapa. La cercanía topológica tampoco equivale por lo general a mejor rendimiento de ida y vuelta, porque el camino que parece corto puede estar congestionado o ser asimétrico. La dirección que le dieron no dice nada sobre qué nodo respondió.

Confirme la ubicación de servicio desde el lado del servicio, o desde una respuesta que la nombre, y no solo desde la respuesta DNS. traceroute -n 198.51.100.20 muestra el camino que tomó y aun así no nombra el host al final, así que léalo como un camino y no como una respuesta.

Compruebe que la sesión sobrevive a un cambio de nodo

Una consulta DNS es corta y una sesión VPN es larga, y ambas tienen requisitos de estado por completo distintos. El enrutamiento puede desplazarse a mitad de sesión y, cuando lo hace, los paquetes posteriores pueden llegar a un nodo que nunca ha visto su túnel. Si eso es sobrevivible depende de la implementación: estado compartido, una reconexión deliberada o un fallo documentado. La dirección por sí sola no aporta nada de eso.

Observe el desplazamiento en lugar de suponerlo. sudo tcpdump -ni any -c 20 esp muestra los paquetes exteriores a medida que el camino cambia, y un cambio repentino en la dirección del par es el desplazamiento ocurriendo. Defina explícitamente el comportamiento previsto para la implementación que ejecuta, y luego pruébelo forzando un cambio de camino. Si el diseño supone replicación de sesión, nombre el mecanismo y nombre el fallo que no cubre.

Compruebe que la identidad sigue coincidiendo

Cada punto de entrada tiene que presentar la identidad que su perfil de cliente espera. Un certificado emitido para el nombre del servicio funciona en todos los nodos, mientras que los certificados por nodo obligan al cliente a aceptar algo nuevo, y ahí es donde los usuarios aprenden a pasar por encima de los avisos. Mantenga la identidad esperada y el perfil coherentes con el modelo de entrada.

Compruébelo desde un cliente que llegó a un nodo poco habitual, porque ese es el caso en que un certificado por nodo se hace visible. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com imprime la cadena y los nombres, que es exactamente lo que compara el cliente. Después decida si debe estrecharse el perfil o cambiarse el modelo de certificado.

Compruebe el registro, no solo la primera respuesta

Evalúe tres escenarios y escriba cuatro hechos para cada uno: entrada normal, una ubicación no disponible y el caso de recuperación acordado. Los cuatro hechos son el resolutor usado, la dirección devuelta, la ubicación que sirvió y un resultado fresco de la aplicación. Ese registro separa un problema de selección DNS de un problema de puerta de enlace, de enrutamiento o de estado de sesión. Sin él, los cuatro parecen idénticos desde el cliente.

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

Ejecute los escenarios desde redes de acceso representativas y no solo desde la oficina, porque toda la cuestión es a qué punto de entrada llegan realmente clientes distintos. Una red es una muestra de una.