Le VPN a déménagé : pourquoi votre client OpenVPN compose encore l’ancienne IP

Le fournisseur a changé votre adresse publique, vous avez mis à jour l’enregistrement DNS dynamique et le client ne peut toujours pas se connecter. De l’extérieur, on croit que l’enregistrement n’a pas propagé. La plupart du temps, l’enregistrement est correct et le client compose l’adresse qu’il a résolue avant le déménagement, car un tunnel actif et un profil enregistré ont chacun leur idée de l’endroit où vit le serveur. Trois couches doivent s’accorder, et elles se mettent à jour selon des calendriers différents.

Regardez ce que compose le profil, pas ce que dit le DNS

Ouvrez la connexion que vous utilisez réellement et lisez la ligne remote. Une adresse numérique n’y suit jamais une mise à jour de nom d’hôte, aussi correct que devienne l’enregistrement.

Vérifiez ensuite si le profil que vous avez modifié est celui que le client a chargé. Les profils importés sont courants : un gestionnaire a pu prendre une copie il y a des mois et garder sa propre version, si bien que le fichier de votre dossier de téléchargements et l’entrée de l’application peuvent diverger. Comparez le point de terminaison dans les détails de connexion du client lui-même avant même de déboguer le DNS.

Deux fichiers, un point de terminaison : c’est le constat habituel ici.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Lisez la prochaine tentative de connexion du client

Redémarrez la connexion avec une journalisation détaillée et lisez la ligne où figure l’adresse qu’il contactera. C’est cette valeur qui compte, pas celle que votre navigateur a résolue.

Le cache du résolveur peut encore contenir la réponse précédente, et certains réseaux la gardent plus longtemps que ne l’exige le TTL de l’enregistrement. Interrogez le résolveur que le client utilise réellement, plutôt qu’un résolveur public testé depuis ailleurs.

Si le journal montre la nouvelle adresse et que la connexion échoue toujours, le problème s’est déplacé : le paquet part quelque part et personne ne répond. C’est une question d’écouteur, de pare-feu ou de redirection de port, et elle se situe côté serveur plutôt que dans le chemin de résolution du client. Tenez ces deux échecs séparés, car traiter un écouteur injoignable comme un problème DNS vous fait parcourir deux fois la même boucle.

Sachez quel redémarrage vous faites

Tous les redémarrages ne préservent pas le même état, ce qui explique qu’un changement d’adresse puisse se comporter différemment selon la façon dont le processus est recyclé. Un redémarrage doux déclenché par un signal conserve davantage le contexte de la session précédente, tandis qu’un arrêt et un démarrage complets repartent de la configuration. Si vous testez si le client résout à nouveau, vous voulez le chemin qui part de la configuration.

Les réglages de persistance comptent aussi, car ils sont conçus pour conserver ce qui a été authentifié plutôt que pour courir après de nouvelles adresses.

Le test le plus propre est un démarrage à neuf depuis le profil prévu, suivi d’un coup d’œil à la ligne de journal qui nomme le point de terminaison. Tout ce que vous apprenez d’une session partiellement conservée est une affirmation sur cette session.

Les quatre options et leurs tâches distinctes

remote avec un nom d’hôte est le réglage qui rend la nouvelle résolution possible ; une adresse littérale sur cette ligne l’exclut. resolv-retry contrôle ce qui se passe quand une recherche échoue, et la 2.6 le met déjà à l’infini par défaut. L’ajouter ne change donc rien, et il ne planifie jamais de vérification périodique d’une autre réponse. Quiconque dit qu’il interroge de nouvelles adresses a confondu la reprise avec la fraîcheur.

persist-remote-ip relève de la continuité plutôt que de la fraîcheur : il réutilise le point de terminaison qui s’est authentifié en dernier, à travers les redémarrages doux qu’il prend en charge. Pendant que vous testez un déménagement, c’est l’inverse de ce que vous voulez. Désactivez-le pour le test si votre build l’active, puis rétablissez-le une fois le nouveau point de terminaison prouvé. Laissé actif, une reconnexion réussie peut ne rien vous dire sur le DNS.

float accepte un pair authentifié dont l’adresse a changé en cours de session, et seulement dans les configurations qui le prennent en charge. Il ne rafraîchit pas le DNS et ne suivra pas un changement de fournisseur de lui-même. Traitez-le comme une fonction de résilience pour les pairs itinérants, non comme un mécanisme d’adresse dynamique pour les serveurs.

Confirmez le nouveau point de terminaison avant d’accuser le client

Depuis l’extérieur de votre réseau, vérifiez que la nouvelle adresse a un écouteur sur le port configuré et que la redirection du fournisseur pointe vers elle. Un enregistrement A correct pour une machine sans port ouvert produit exactement le symptôme que les gens attribuent au cache.

Reconnectez-vous ensuite et vérifiez deux choses : le client s’est authentifié auprès du certificat de serveur attendu, et la session atteint la ressource que vous visiez. Un changement d’adresse n’abaisse pas les exigences d’identité, et une connexion qui réussit vers le mauvais point de terminaison est pire qu’une qui échoue. Le manuel OpenVPN 2.6 liste les quatre options avec leur portée propre, et c’est la liste de contrôle à garder à côté du profil.

Gardez un accès hors bande au serveur avant de redémarrer le tunnel qui porte votre accès d’administration. Cette seule précaution évite la plupart des incidents que ce scénario produit.