Un enregistrement DDNS obsolète face à un point de terminaison VPN cassé : comment les distinguer

De l’extérieur, un nom d’hôte obsolète et un VPN cassé se ressemblent trait pour trait. Le client résout un nom, le nom pointe quelque part, et la connexion expire ou est refusée. L’une est un problème de mise à jour DNS, l’autre un problème d’authentification ou de redirection, et la différence ne devient évidente que lorsque vous comparez l’adresse publiée à l’adresse que votre ligne possède réellement.

Deux pannes qui se présentent de la même façon

La première panne, c’est que l’enregistrement liste encore l’adresse WAN d’hier. La seconde, c’est que l’enregistrement est correct et que le tunnel vous refuse pour ses propres raisons. Les deux produisent le même message côté client, et la tentation est de commencer à régénérer des certificats.

L’ordre compte ici. Vérifier le DNS prend une minute et se défait. Régénérer une AC ne fait ni l’un ni l’autre.

Comparez les adresses avant tout le reste

Demandez au propriétaire du réseau quelle adresse la ligne possède actuellement, puis demandez au DNS ce qu’il publie. dig +short vpn.example.com donne la réponse que votre client obtiendra, et dig @1.1.1.1 vpn.example.com montre si un autre résolveur voit autre chose. Si les deux ne sont pas d’accord, vous regardez le comportement du cache et non un actualiseur cassé.

Une réponse récursive peut retarder une mise à jour de son TTL, alors gardez l’enregistrement faisant autorité et ce que votre portable a mis en cache dans des boîtes séparées.

Ce qu’est vraiment l’identifiant de l’actualiseur

Les appareils DDNS anciens s’authentifient souvent avec le mot de passe du compte lui-même, ce qui explique qu’un changement de ce mot de passe les casse en silence. Ils continuent de réessayer avec l’ancienne valeur et ne signalent rien d’utile. Le guide des mots de passe d’appareil de No-IP documente exactement ce problème de compatibilité sur le matériel ancien, et la réponse sensée est un identifiant de mise à jour à portée limitée plutôt qu’un mot de passe de compte plus faible.

Les mécanismes plus récents émettent un jeton ou une clé de mise à jour distinct avec son propre cycle de vie. C’est la valeur à faire tourner dans le routeur, et celle à consigner dans votre inventaire d’identifiants. Ce n’est pas non plus la valeur à coller dans un fil de discussion pendant que vous déboguez.

Examinez l’état non secret de l’actualiseur : heure du dernier succès, catégorie de réponse et le nom d’hôte qu’il croit posséder. Un rejet d’identifiant et une panne de connectivité demandent des correctifs différents.

Ce qu’une correction DNS ne peut pas faire

Corriger l’enregistrement ne crée pas de joignabilité entrante. Si la ligne se trouve derrière un NAT de niveau opérateur, aucun nom d’hôte ne fera fonctionner une connexion entrante. Cela n’ouvre pas non plus une règle de pare-feu et ne redirige pas un port. Et ce n’est jamais une raison de désactiver la vérification du serveur côté client, ce qui est le geste que l’on fait lorsqu’on décide que le certificat doit être le problème.

À l’inverse, un changement de mot de passe VPN n’est pas un correctif pour un DNS obsolète. Il ajoute simplement une seconde panne au même ticket.

Reconnectez et prouvez-le de bout en bout

Une fois l’enregistrement faisant autorité correct, le client peut encore conserver une ancienne résolution. Utilisez sa reconnexion ou son rafraîchissement de point de terminaison pris en charge et laissez-lui un instant au lieu de marteler la connexion. Prouvez ensuite le chemin en quatre étapes : résolvez le nom, confirmez l’adresse, vérifiez que l’écouteur est joignable, et authentifiez-vous. Quatre résultats distincts, quatre réponses distinctes.

Gardez l’actualiseur dans la liste de rotation à côté du compte VPN. Un propriétaire d’enregistrement prévu, un identifiant valide et un succès observable sont ce qui évite la prochaine version de ce ticket.