Avez-vous besoin d’un DNS dynamique pour un serveur VPN domestique ?

Le DNS dynamique corrige le nom, pas le chemin d’entrée. Trois vérifications décident si un nom d’hôte suffit pour un serveur VPN domestique ou si la route d’entrée est cassée.

La plupart des pannes de VPN domestique qu’on me décrit ne sont pas des pannes DNS, et pourtant les gens achètent d’abord un abonnement DNS dynamique. Avant de configurer quoi que ce soit, décidez si le nom d’hôte est la partie réellement cassée. Un updater réécrit un enregistrement quand l’adresse fournie par votre FAI bouge ; il ne peut pas ouvrir un port, traverser le NAT de l’opérateur ni faire qu’une session WireGuard active remarque que son point de terminaison a changé. Trois conditions décident si le DNS dynamique est toute la solution ou seulement une de ses lignes.

Condition un : votre adresse bouge vraiment

Les adresses résidentielles bougent pour des raisons banales : le modem se resynchronise après une coupure de courant, le FAI rééquilibre un pool, un nouveau bail arrive après une longue panne. Elles bougent aussi rarement sur certaines lignes, et j’ai vu la même adresse survivre un an ; les offres professionnelles incluent souvent une adresse fixe. Si rien n’a changé en douze mois, un seul enregistrement A que vous éditez à la main, c’est un démon de moins à maintenir en vie.

Mesurez plutôt que de deviner. Lisez l’adresse WAN sur la page d’état du routeur, puis comparez-la à ce que voit le monde extérieur. Lancez ceci depuis une machine du LAN :

curl -fsS https://api.ipify.org; echo

Si les deux valeurs diffèrent, quelque chose traduit devant votre routeur et aucune mise à jour de nom d’hôte n’y remédiera. Une adresse dans 100.64.0.0/10 est la plage partagée du NAT opérateur, et c’est la raison habituelle pour laquelle un nom correctement mis à jour expire quand même depuis l’extérieur.

Condition deux : les clients résolvent à nouveau le nom

Le TTL court est la partie que les gens sautent. Les résolveurs récursifs respectent le TTL de l’enregistrement, mais les piles client mettent en cache séparément, et un tunnel déjà monté ne résout rien à nouveau. Réglez l’enregistrement sur 60-300 secondes pendant le débogage ; cela raccourcit la fenêtre où une réponse périmée est servie, et cela ne migre pas une session connectée.

OpenVPN résout à nouveau la ligne remote vpn.example.net 1194 à chaque reconnexion, et resolv-retry infinite le fait réessayer au lieu de quitter quand la résolution échoue. Sur le serveur, float permet à une session établie de suivre un pair dont l’adresse source a changé. WireGuard est plus direct : wg-quick up résout l’Endpoint au moment où la configuration est appliquée, et le client le résout à nouveau quand il reconstruit le tunnel, si bien qu’une poignée de main qui réussit encore vers l’ancienne adresse continue de réussir jusqu’à ce qu’elle s’arrête.

Cette différence façonne le plan. Si les clients se connectent à la demande, un changement d’adresse coûte une reconnexion. S’ils gardent une session ouverte des jours, attendez-vous à ce que le tunnel meure à la prochaine poignée de main, et faites réessayer le client au lieu de supposer qu’il reste en place.

Condition trois : le chemin d’entrée est toujours ouvert

Le DNS dynamique ne change que l’endroit où pointe le nom, et rien d’autre. La redirection de port sur le routeur, la règle de pare-feu sur l’hôte VPN et l’autorisation des paquets entrants par le FAI doivent tous exister avant que l’enregistrement compte. Regardez ce que cible la redirection : si elle est épinglée à une adresse WAN plutôt qu’à l’interface, un changement d’adresse casse la redirection en silence et l’enregistrement porte le blâme.

Testez depuis l’extérieur. Un téléphone en données mobiles avec le Wi-Fi coupé est le test honnête le moins cher ; un portable sur le même LAN ne l’est pas. Quand le nom résout vers votre adresse publique et que le routeur n’a pas de boucle NAT, un test intérieur échoue alors que l’enregistrement est parfaitement correct, ce qui envoie la plupart des gens éditer un enregistrement qui n’a jamais été faux.

Quoi exécuter quand les trois tiennent

ddclient est l’updater le moins surprenant pour un petit hôte. Une configuration minimale publie l’adresse que voit le fournisseur, ce qui évite l’erreur du double NAT :

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Lancez-le depuis un minuteur systemd toutes les quelques minutes plutôt que dans une boucle shell, et journalisez la réponse du fournisseur au lieu de supposer le succès. Traitez l’identifiant comme une clé, car il décide où chaque client est envoyé : utilisez un jeton de mise à jour limité plutôt qu’un mot de passe de compte, gardez le fichier en mode 0600 et envoyez les mises à jour en HTTPS.

Vérifiez avant de vous engager

Une requête vous dit ce que voit le reste du monde, et elle imprime le TTL qu’il faut attendre après un changement :

dig +noall +answer vpn.example.net @1.1.1.1

Comparez cette adresse à l’adresse WAN du routeur. Si elles correspondent, le nom fait son travail et ce qui échoue encore relève de l’accessibilité entrante, d’une clé ou d’un client qui n’a pas résolu à nouveau. Si elles diffèrent, l’updater publie la mauvaise interface, souvent parce qu’il tournait sur l’hôte VPN derrière le routeur au lieu du routeur lui-même.

Gardez un retour arrière qui prend une minute : notez la dernière adresse fonctionnelle et le TTL précédent, pour pouvoir publier les deux à la main pendant que le fournisseur passe un mauvais après-midi.

Quand la réponse est non

Si la condition un ou trois échoue, c’est la décision qui change, pas la configuration. Derrière le NAT de l’opérateur, vos options pratiques sont de demander une adresse publique au FAI, de déplacer le point d’entrée vers un petit VPS à l’adresse stable, ou d’utiliser une couche superposée qui garde son propre rendez-vous. Si l’adresse est fixe, sautez l’updater : un enregistrement A, un enregistrement AAAA si vous faites de l’IPv6, la même redirection de port.

Si l’adresse change alors que les clients restent connectés, le correctif honnête vit dans le client : logique de reconnexion et intervalle de réessai, pas un updater plus rapide. Ajouter un second fournisseur ne fait que masquer l’intervalle.

Avant de continuer, confirmez quatre choses dans l’ordre :

  • L’adresse publiée par l’updater correspond à l’adresse WAN du routeur.
  • Le TTL de l’enregistrement est assez court pour qu’un changement apparaisse en quelques minutes.
  • La redirection de port est liée à l’interface, pas à une adresse fixe.
  • Un vrai client s’est reconnecté et a fait passer du trafic depuis le dernier changement.

Si les quatre tiennent, laissez l’installation tranquille ; votre prochaine panne est une clé ou une règle de pare-feu, pas un problème de nommage. Si l’une échoue, corrigez cette ligne avant d’ajouter une pièce mobile de plus. RFC 2136 décrit le mécanisme de mise à jour lui-même, si vous voulez voir ce que le démon met sur le fil.

Articles similaires