DNS géographique et anycast : vérifier l’entrée VPN que vous obtenez

Une réponse DNS proche semble un problème résolu jusqu’à ce que la connexion atterrisse ailleurs. Le DNS géographique et l’anycast tentent tous deux de raccourcir le chemin, et ils prennent cette décision à partir d’informations différentes. Ni l’un ni l’autre ne garantit que la passerelle que vous atteignez est joignable, qu’elle présente l’identité attendue par votre client, ou que votre session survit à un changement de nœud. Les vérifications ci-dessous séparent ces quatre questions.

Vérifiez de qui le résolveur rapporte réellement la position

Un serveur autoritaire qui répond à une requête sensible à la topologie voit normalement l’adresse du résolveur récursif qui a interrogé, et non l’adresse de la personne qui a saisi le nom. Un résolveur centralisé peut se trouver loin des clients qu’il sert, et la réponse reflète le résolveur plutôt que ces clients. Ce n’est pas un défaut ; c’est ainsi que le protocole se comporte sauf si des informations supplémentaires sont fournies. Spécification d’EDNS Client Subnet décrit à la fois la limitation et le remède facultatif.

EDNS Client Subnet peut transporter des informations sur le réseau d’origine lorsque chaque participant le prend en charge et l’active. Il est facultatif, il a des conséquences sur la vie privée et la mise en cache, et ce n’est pas la permission de supposer qu’un résolveur public rapporte une position précise de l’utilisateur. Interrogez les exploitants de résolveurs avant de concevoir autour de cela.

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

Vérifiez ce que le routage anycast a décidé

Avec anycast, plusieurs emplacements annoncent la joignabilité d’une même adresse de service, et le réseau achemine chaque client vers le nœud que son routage préfère. Ce choix est fait par BGP et la politique environnante, non par la distance sur une carte. La proximité topologique n’équivaut pas non plus en général à de meilleures performances aller-retour, car le chemin qui semble court peut être congestionné ou asymétrique. L’adresse qui vous a été donnée ne dit rien sur le nœud qui a répondu.

Confirmez l’emplacement de service du côté du service, ou à partir d’une réponse qui le nomme, plutôt qu’à partir de la seule réponse DNS. traceroute -n 198.51.100.20 affiche le chemin que vous avez suivi et ne nomme toujours pas l’hôte à son extrémité, alors lisez-le comme un chemin et non comme une réponse.

Vérifiez que la session survit à un changement de nœud

Une requête DNS est courte et une session VPN est longue, et les deux ont des exigences d’état totalement différentes. Le routage peut se déplacer en cours de session, et quand cela arrive, les paquets ultérieurs peuvent atteindre un nœud qui n’a jamais vu votre tunnel. Que ce soit survivable dépend de l’implémentation : état partagé, reconnexion délibérée ou défaillance documentée. L’adresse seule n’en fournit aucun.

Observez le déplacement au lieu de le supposer. sudo tcpdump -ni any -c 20 esp montre les paquets extérieurs à mesure que le chemin change, et un changement soudain de l’adresse du pair est le déplacement lui-même. Définissez explicitement le comportement visé pour l’implémentation que vous exploitez, puis testez-le en forçant un changement de chemin. Si la conception suppose une réplication de session, nommez le mécanisme et nommez la défaillance qu’il ne couvre pas.

Vérifiez que l’identité correspond toujours

Chaque point d’entrée doit présenter l’identité attendue par votre profil client. Un certificat émis pour le nom du service fonctionne sur tous les nœuds, tandis que des certificats par nœud forcent le client à accepter quelque chose de nouveau, et c’est là que les utilisateurs apprennent à cliquer sur les avertissements. Maintenez l’identité attendue et le profil cohérents avec le modèle d’entrée.

Vérifiez-le depuis un client qui a atteint un nœud inhabituel, car c’est le cas où un certificat par nœud devient visible. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com imprime la chaîne et les noms, ce qui est exactement ce que le client compare. Décidez ensuite si le profil doit être resserré ou le modèle de certificat modifié.

Vérifiez l’enregistrement, pas seulement la première réponse

Évaluez trois scénarios et notez quatre faits pour chacun : entrée normale, un emplacement indisponible et le cas de rétablissement convenu. Les quatre faits sont le résolveur utilisé, l’adresse renvoyée, l’emplacement qui a servi et un résultat applicatif frais. Cet enregistrement sépare un problème de sélection DNS d’un problème de passerelle, de routage ou d’état de session. Sans lui, les quatre se ressemblent depuis le client.

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

Exécutez les scénarios depuis des réseaux d’accès représentatifs et pas seulement depuis le bureau, car toute la question porte sur le point d’entrée que différents clients atteignent réellement. Un réseau est un échantillon de un.