DNS du point de terminaison AWS Client VPN : pourquoi épingler l'IP résolue échoue

La semaine dernière, dig +short vous a donné une adresse pour le nom du point de terminaison de votre profil AWS Client VPN, et le tunnel s'est connecté. Cette semaine, le même profil reste sur 'Connecting' sur votre portable alors que la copie intacte d'un collègue fonctionne encore. Rien n'a été bloqué et le certificat n'a pas expiré. Quelqu'un a remplacé le nom d'hôte du point de terminaison par cette adresse résolue, et le service ne répond plus là. Le nom exporté est la partie conçue pour survivre à ce changement.

Le nom de votre profil n'est peut-être pas le nom interrogé

Les profils exportés depuis Client VPN portent souvent remote-random-hostname. Avec cette option activée, le client construit une étiquette jetable, la joint au nom du point de terminaison par un point et résout le nom combiné. Un enregistrement générique dans la zone du point de terminaison répond à n'importe quelle étiquette, ce qui explique qu'un préfixe inventé se résolve encore et que l'astuce reste invisible quand vous essayez de reproduire la requête à la main.

Ainsi, quand vous collez le nom du point de terminaison dans un terminal et obtenez une réponse, vous avez résolu un nom différent de celui que le client utilise à la connexion. Cet écart n'est pas un défaut à corriger dans le profil. L'étiquette est régénérée exprès : l'option empêche les caches de conserver une réponse périmée et elle n'identifie jamais votre machine ni votre session.

J'ai rencontré le cas de compatibilité où un client ignore purement et simplement l'option. AWS documente le contournement : gardez le vrai nom du point de terminaison et préfixez-le d'une chaîne aléatoire suivie d'un point, en le traitant comme un schéma de nommage et non comme une valeur à coller. L'appliquer à un ancien client est raisonnable ; coder en dur la chaîne préfixée comme point de terminaison ne l'est pas.

Pourquoi une réponse enregistrée ne peut pas rester correcte

Les adresses des points de terminaison Client VPN sont gérées par AWS et changent avec le temps, ce que la documentation des bonnes pratiques dit clairement. Une réponse capturée est un instantané d'une résolution. Un profil qui la code en dur devient un profil visant un hôte décommissionné dès que le service bouge, et la panne ressemble rarement à du DNS : vous obtenez un délai de connexion ou une poignée de main bloquée, alors les gens courent après le routage et les certificats.

La même réponse dans /etc/hosts hérite de la même expiration avec un problème de plus. Une entrée hosts survit aux redémarrages, aux réexportations et aux réparations 'réinstaller le client', donc la panne revient chaque fois que l'adresse bouge. J'en ai vu une rester inoffensive des semaines, puis mettre hors service toutes les machines qui la portaient tandis que des installations neuves se connectaient normalement. Cette scission, un groupe en échec et un autre correct sur le même compte, est l'indice le moins cher que vous aurez.

Délimitez correctement la randomisation. Elle a lieu à chaque tentative de connexion. Un tunnel établi ne résout pas de nouveau son point de terminaison, ne change pas de serveur en cours de session, et les requêtes individuelles des applications ne choisissent pas chacune un nouvel hôte VPN. Seule la tentative suivante résout à nouveau, ce qui explique qu'une session qui fonctionne tout l'après-midi ne dit rien sur demain matin.

Ce que le service vérifie quand le tunnel monte

Client VPN exige que l'adresse à laquelle vous êtes connecté corresponde à une adresse résolue pour le nom DNS du point de terminaison. Cette seule exigence explique plusieurs pannes qui semblent sans rapport : un enregistrement DNS personnalisé pointant ailleurs, un frontend personnalisé qui transfère vers la vraie adresse du point de terminaison, et un profil réécrit vers une adresse brute. AWS documente la combinaison enregistrement personnalisé plus transfert comme une panne avec les clients récents fournis par AWS. La vérification est étroite ; ce n'est pas un verdict interdisant tout alias.

Ce n'est pas non plus une règle générale sur les protocoles VPN. Un remote numérique est parfaitement valide dans un déploiement OpenVPN ordinaire, et beaucoup fonctionnent ainsi. La contrainte vient de l'arrangement géré, pas du protocole en dessous.

Ce qui fait de l'assouplissement de la vérification du certificat le mauvais réflexe. Si un profil échoue après un changement d'adresse, désactiver la vérification du serveur déplace l'erreur au lieu de corriger la résolution ou l'exigence de correspondance d'adresse, et laisse un client qui fera confiance à n'importe quoi. Gardez l'autorité de certification exportée, la vérification du serveur et les réglages d'authentification mutuelle exactement tels qu'ils sont arrivés.

Listes d'autorisation, sortie et DNS privé sont trois problèmes distincts

Une règle de pare-feu qui doit autoriser une destination avant qu'un portable se connecte concerne l'écouteur externe. Donnez au propriétaire du réseau le nom du point de terminaison, le transport et le port configuré, puis demandez si leur contrôle peut suivre le comportement DNS du service. Une règle qui retient une adresse capturée est un instantané à l'expiration non écrite. Si le contrôle n'accepte que des destinations immuables, réglez cet écart avant le déploiement plutôt que de coder une réponse en silence.

Un partenaire qui a besoin d'une adresse source fixe pour les requêtes faites après la montée du tunnel a une autre exigence : la sortie. Ce qu'un site web observe dépend de la route de l'application et de la politique de tunnel divisé, pas de l'adresse à laquelle le client s'est connecté. Le trafic en tunnel divisé peut ne jamais toucher AWS.

Le DNS privé à l'intérieur du tunnel est une troisième couche. Le résolveur remis aux clients répond aux noms internes après la connexion ; il ne peut pas résoudre le point de terminaison public avant que le tunnel existe. Une panne de résolution du point de terminaison et une panne de résolution d'application interne surviennent à des étapes différentes, et les mélanger vous envoie au mauvais journal.

La famille d'adresses appartient à la même liste. Une réponse IPv4 ne dit rien du chemin autorisé d'un point de terminaison IPv6 ou double pile, donc un instantané pris dans une famille n'est pas une preuve pour l'autre.

Vérifiez une connexion sans épingler quoi que ce soit

Partez du profil tel qu'exporté et lisez ce qu'il demande réellement :

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Comparez ensuite trois choses : le nom du point de terminaison que porte le profil, l'adresse que le client signale pour une nouvelle tentative, et ce à quoi le nom se résout maintenant. Un nom qui se résout prouve seulement que l'enregistrement répond ; le transport et l'authentification sont distincts, et le point de terminaison n'a pas à répondre à un ping. Le journal du client est la seule source pour l'élément du milieu, alors capturez-le pendant la tentative et non après.

Une adresse qui répond aujourd'hui est une preuve sur aujourd'hui ; le nom est ce que le service maintient valide. Notez l'observation, envoyez-la au propriétaire du point de terminaison et laissez le profil pointer vers le nom.

Deux habitudes à abandonner : désactiver les contrôles de certificat pour passer une poignée de main bloquée, et empiler des étiquettes devant le nom du point de terminaison en espérant qu'une tienne. Une étiquette se résout par l'enregistrement générique, sinon le problème est ailleurs. Si un profil correctement configuré échoue encore, envoyez la requête exacte et l'événement de connexion, pas un nom d'hôte plus long.

Avant de clore : le profil porte toujours le nom exporté du point de terminaison, aucun fichier hosts n'épingle l'adresse, le remote du journal client correspond à une résolution actuelle et la règle de pare-feu nomme le point de terminaison plutôt qu'une adresse. C'est aussi l'état à transmettre à la personne suivante.