ddclient publie la sortie VPN : corrigez la source de découverte

Votre nom DNS résout désormais vers une adresse de fournisseur VPN, et le journal de mise à jour semble parfaitement sain. Cette combinaison est normale. Une sonde de découverte basée sur le web demande à un service externe quelle source il voit, et lorsque la requête sort par un VPN en tunnel complet, la réponse est la sortie VPN et non votre adresse WAN domestique. Le programme de mise à jour a fait son travail ; le travail visait une observation erronée.

Confirmez ce que le nom doit atteindre

Un nom public pour un service domestique entrant a besoin d'une adresse par laquelle des connexions entrantes approuvées peuvent atteindre ce service. Publier une sortie partagée du fournisseur n'organise pas de redirection entrante là-bas, et aucune configuration DNS ne crée cette redirection. Décidez cela avant de toucher au programme de mise à jour, car cela détermine quelle adresse est correcte.

Un nom privé pour l'adresse de tunnel d'un client VPN est un autre problème avec une autre réponse : il appartient au DNS privé et n'a pas du tout besoin d'un service de découverte public. Mélanger les deux exigences, c'est ainsi qu'une configuration qui fonctionne commence à publier une adresse que personne n'a demandée.

Les adresses d'interface demandent aussi une interprétation. L'adresse d'un portable derrière un routeur domestique n'est pas l'adresse WAN publique, et même l'adresse WAN du routeur peut se trouver derrière un NAT opérateur, où la publier ne peut pas produire d'accessibilité entrante.

Reproduisez la valeur avant de changer quoi que ce soit

Observez les deux chemins séparément. Tunnel actif, une sonde rapporte la sortie ; tunnel coupé, ou sonde liée à l'interface physique, elle rapporte l'adresse du domicile : curl --interface eth0 https://ifconfig.me. Si ces deux réponses diffèrent, vous avez reproduit le défaut sans toucher au programme de mise à jour.

Exécutez ensuite le client dans un mode qui vérifie la configuration sans effectuer de mise à jour, par exemple ddclient -verbose -noexec, et lisez quelle méthode de découverte il a choisie. La sortie détaillée nomme la méthode et la valeur obtenue, et c'est le fait dont vous avez besoin avant toute modification.

Dirigez la découverte vers le chemin choisi

Si le nom doit publier l'adresse WAN domestique, la découverte doit observer cette adresse. Trois options fonctionnent, dans un ordre de préférence approximatif : laissez le routeur publier via son propre programme de mise à jour pris en charge ; utilisez la découverte d'état du routeur de ddclient contre une page que le routeur sert réellement ; ou gardez une sonde web mais liez-la à l'interface physique pour qu'elle sorte hors du tunnel.

Pour la voie de l'état du routeur, les versions récentes de ddclient utilisent la famille d'options usev4 et fwv4, avec un motif d'omission facultatif pour le texte environnant de la page. Consultez le README de votre version installée, car les anciennes versions écrivent la même idée avec use et fw, et un nom d'option copié depuis la mauvaise version échoue au démarrage.

Si vous gardez la découverte web, rappelez-vous que router la sonde et router l'appel d'API de mise à jour sont deux décisions distinctes. L'appel de mise à jour livre l'enregistrement ; la sonde décide de la valeur livrée.

Tenez les secrets et les versions en ordre

Les identifiants du routeur et les jetons du fournisseur vont dans un fichier de configuration protégé, pas sur une ligne de commande qui finit dans l'historique du shell. Les traces détaillées peuvent contenir les deux, alors masquez-les avant de les coller dans un ticket. Une méthode de découverte qui exige d'extraire une page de routeur authentifiée exige aussi de maintenir cet identifiant fonctionnel au fil des mises à jour de firmware. Gardez-le avec le même soin que le jeton du fournisseur.

Le ddclient README documente les approches de découverte et leurs noms d'option. Ne mélangez pas les résultats IPv4 et IPv6 dans un même enregistrement, et ne supposez pas qu'une option présente dans une version existe dans une autre.

Vérifiez la valeur, puis l'accessibilité

Comparez l'adresse proposée au point de terminaison prévu avant d'autoriser une mise à jour en direct, puis vérifiez le DNS faisant autorité après une mise à jour autorisée et tenez compte des caches des résolveurs. Un TTL bas raccourcit l'attente ; il ne rend pas correcte une valeur fausse.

Ce n'est qu'une fois l'enregistrement correct que vous devriez tester le service entrant depuis un réseau indépendant, avec le pare-feu et la redirection requis déjà approuvés. Un enregistrement A correct ne prouve pas un service accessible, et un bail VPN statique peut simplifier le nommage privé sans réparer un nom d'hôte public qui pointe vers le mauvais WAN.