VPN de bureau avec IP dynamiques : DDNS et stratégies qui ne s’effondrent pas

Ce qui casse réellement quand l’IP du bureau change

Un changement d’IP dynamique n’est pas intrinsèquement catastrophique. La catastrophe, c’est tout ce qui l’entoure : DNS obsolète, cache client, état NAT, comportement des keepalive,
et l’hypothèse humaine que « ça va se régler tout seul ».

Les éléments en mouvement qui échouent différemment

• Propagation et cache DNS : le DDNS se met à jour rapidement ; les clients souvent pas. Les caches des OS et des routeurs ignorent votre TTL quand ça leur chante.
• Mappings NAT : si votre bureau utilise du carrier-grade NAT (CGNAT), l’entrée entrante du VPN peut ne jamais fonctionner, dynamique ou pas.
• Comportement des protocoles : WireGuard est silencieux par conception. Si l’endpoint change, un pair peut ne pas le remarquer tant qu’il n’envoie pas. C’est à la fois une qualité et un piège.
• Expérience client : les utilisateurs interprètent « impossible de se connecter » comme « le VPN est en panne », même quand « le DNS pointe encore vers l’ancienne IP ». Votre helpdesk confirme leur vision.

Voici le diagnostic central : quand l’IP publique du bureau change, vous avez besoin d’un nom stable et d’un chemin fiable.
Le DDNS vous donne le nom. Il ne garantit pas le chemin, et il ne garantit certainement pas que les clients résoudront à nouveau le nom au moment critique.

Blague n°1 : Le DDNS, c’est comme laisser une adresse de réexpédition à la poste — utile, mais vos proches continueront d’envoyer du courrier à l’ancien endroit pendant des mois.

Faits intéressants et contexte historique (parce que le passé revient sur votre pager)

1. Le TTL DNS était prévu pour contrôler le cache, mais les résolveurs limitent souvent les valeurs (en particulier les résolveurs ISP « utiles » et certains routeurs domestiques).
2. Le DNS dynamique s’est popularisé à l’époque du dial-up / début du haut débit quand les ISP changeaient fréquemment les IP et que les gens hébergeaient des services malgré tout.
3. Le NAT (déployé massivement depuis les années 1990) a normalisé « pas de connectivité entrante » pour de nombreux réseaux ; le DDNS ne règle pas la politique NAT.
4. IPsec existait avant le télétravail moderne ; les outils supposent des endpoints stables et punissent les changements par des négociations lentes et des configs fragiles.
5. WireGuard (milieu des années 2010) a délibérément minimisé les échanges, améliorant performance et simplicité — mais il faut concevoir autour de la mobilité des endpoints.
6. Le CGNAT s’est étendu avec l’épuisement d’IPv4 ; beaucoup d’« IP publiques » ne sont pas vraiment publiques, ce qui rend l’accès entrant impossible sans relais.
7. Les débats sur le split tunneling sont plus anciens que la plupart des fournisseurs VPN ; les équipes sécurité aiment le full-tunnel, les réseaux aiment le split, les utilisateurs aiment « ce qui marche ».
8. DNSSEC est excellent pour l’intégrité, pas pour la disponibilité ; un enregistrement signé qui se met à jour lentement reste lent, juste cryptographiquement correct.

Principes du DDNS sans contes de fées

Le DDNS est simple : un client met à jour un enregistrement DNS quand l’IP change. Le diable se cache dans l’authentification, la fréquence des mises à jour et le comportement des résolveurs.
Si votre histoire DDNS est « configuré une fois sur le routeur », vous construisez sur du sable.

À quoi ressemble un « DDNS bien fait »

• Les mises à jour sont authentifiées avec des identifiants limités ou des clés de type TSIG ; pas votre mot de passe de registrar.
• Les mises à jour sont surveillées comme signal opérationnel : « IP modifiée » doit être un événement visible et corrélable.
• Le TTL est bas mais réaliste (par ex., 60–300 secondes). Descendre à 10 secondes ne vaincra pas les caches récalcitrants ; ça augmentera juste la charge de requêtes et le bruit.
• Vous prévoyez des clients qui ne réosent pas en rendant le point d’entrée VPN stable autrement (failover, relais, ou fronting cloud).

Où le DDNS échoue dans le monde réel

Le DDNS « fonctionne » la plupart du temps. Le reste du temps, c’est votre vie d’astreinte.
Les échecs tombent généralement dans l’une de ces catégories :

• La mise à jour n’a jamais eu lieu : bug du routeur, client obsolète, HTTPS sortant bloqué, mauvais identifiants.
• La mise à jour a eu lieu mais personne ne la voit : cache des résolveurs, cache DNS local, ou cache du client VPN.
• La mise à jour a eu lieu mais pointe vers la mauvaise IP : bureau avec double WAN ; l’updater choisit la mauvaise interface ; ou il lit une adresse privée.
• Le chemin entrant est bloqué : l’ISP bloque des ports, des règles de pare-feu en amont ont changé, le mapping NAT est perdu, ou CGNAT.

Conseil tranché : considérez le DDNS comme un composant, pas comme l’architecture entière. Si votre modèle de fiabilité VPN entier repose sur « le DDNS se mettra à jour vite »,
vous finirez par apprendre ce que « à la longue » signifie.

Options d’architecture qui survivent au changement d’IP

Option A : VPN hébergé au bureau avec DDNS (acceptable si vous ajoutez des garde-fous)

Classique : serveur WireGuard ou OpenVPN au bureau, un nom DDNS pointant vers l’IP publique actuelle, et un port-forwarding sur le routeur.
Ça peut être solide si vous l’associez à de la supervision, des keepalives sensés et un chemin de récupération testé.

Utilisez ceci quand : vous avez vraiment besoin d’un accès direct aux ressources du bureau, la bande passante est suffisante, et vous avez soit une IP publique statique soit un comportement dynamique « assez bon ».

Option B : placer la « porte d’entrée » VPN dans le cloud ; le bureau devient client (recommandé)

C’est la démarche adulte. Hébergez le point d’entrée VPN sur une petite VM cloud avec une IP statique et un DNS stable. Puis faites en sorte que le routeur du bureau ou une petite machine Linux
établisse un tunnel sortant vers le cloud. Sortant est plus simple qu’entrant. Les ISP sont moins enclins à le casser.

Les utilisateurs distants se connectent au point d’entrée cloud. Le réseau du bureau est accessible via le tunnel site-vers-cloud. L’IP dynamique du bureau devient sans importance car
le bureau appelle toujours vers l’extérieur.

Inconvénient : vous introduisez une dépendance (la VM cloud). C’est acceptable — les dépendances sont normales. Ce qui compte, c’est que ce soit une dépendance que vous pouvez contrôler,
superviser et redonder si nécessaire.

Option C : utiliser un relais / réseau overlay (pragmatique quand NAT et CGNAT gagnent)

Si le bureau est derrière du CGNAT, la connectivité entrante est morte d’emblée. Vous pouvez lutter contre l’ISP, ou vous pouvez contourner.
La connectivité basée sur relais (serveur de rendez-vous, NAT traversal, relais de type TURN, ou un produit overlay) fonctionne souvent sans ports entrants.

Ce n’est pas « moins sûr » par défaut. C’est simplement un autre modèle de confiance. Vous conservez le chiffrement bout-en-bout. Vous acceptez juste que le chemin puisse être indirect.

Option D : Dual WAN avec basculement réel (bien, mais faites-le soigneusement)

Deux ISP peuvent être excellents. Deux ISP peuvent aussi vous donner deux IP dynamiques qui basculent de façon imprévisible. Si vous faites du dual WAN, faites-le délibérément :
politique sortante stable, mapping entrant stable (si possible), et un design VPN capable de gérer chaque interface.

Pour beaucoup de bureaux, dual WAN plus porte d’entrée VPN hébergée en cloud est le compromis idéal : n’importe quel ISP permet au bureau d’atteindre le hub cloud.

Mon parti pris, dit franchement

Si c’est pour une entreprise qui tient à la disponibilité, arrêtez d’héberger votre unique point d’entrée VPN sur une connexion de bureau avec IP changeante et un firmware de routeur grand public.
Placez le point d’entrée quelque part de stable (cloud ou data center), et laissez le bureau se connecter vers l’extérieur.

WireGuard avec endpoints dynamiques : approches pratiques

WireGuard est excellent pour ce problème — si vous comprenez son comportement. Il est aussi excellent pour vous faire croire que tout va bien jusqu’à ce que vous réalisiez
que la moitié de vos pairs n’ont pas handshaké depuis hier.

Points clés de comportement

• Les pairs apprennent les endpoints à partir des paquets reçus. Si l’IP du bureau change et que le client continue d’envoyer vers l’ancien endpoint, rien de magique ne se produit tant qu’il ne re‑résout pas et n’envoie pas vers la nouvelle IP.
• PersistentKeepalive n’est pas « pour la performance ». C’est pour maintenir les mappings NAT et détecter les changements de chemin plus tôt.
• Les noms DNS dans Endpoint sont résolus par les outils WireGuard à des moments précis (souvent à la mise en place de l’interface). N’imaginez pas une ré‑résolution continue.

Pattern 1 : hub cloud, bureau et utilisateurs comme spokes (recommandé)

Placez un serveur WireGuard dans le cloud avec une IP statique. Configurez la passerelle du bureau et tous les clients pour s’y connecter.
L’IP du bureau peut changer toutes les heures ; il compose quand même, et le hub apprend le nouvel endpoint quand des paquets arrivent.

Pattern 2 : endpoint hébergé au bureau avec DDNS (fonctionne si vous contrôlez le comportement client)

Si vous devez héberger au bureau, configurez les clients pour qu’ils ré‑résolvent périodiquement en recyclant l’interface en cas d’échec, ou utilisez un watchdog local.
Réglez aussi un keepalive raisonnable (par ex., 25 secondes) pour les clients itinérants derrière un NAT.

Pattern 3 : endpoints multiples (pas natif, mais possible avec du glue opérationnel)

WireGuard ne gère pas le multi-endpoint failover dans le protocole lui‑même. Vous pouvez l’approximer avec :

• Deux configurations de tunnel et un superviseur qui bascule entre elles.
• Un nom DNS stable que vous mettez à jour (mais alors vous retombez sur le comportement DNS).
• Une IP de fronting (cloud LB/anycast) qui garde l’adresse stable pendant que vous déplacez le backend.

Blague n°2 : La redondance est formidable jusqu’à ce que vous réalisiez que vous avez doublé le nombre de choses que vous pouvez mal configurer.

OpenVPN et IPsec : ce qui change et ce qui reste pénible

OpenVPN avec IP dynamiques

OpenVPN tolère assez bien les IP serveur dynamiques si les clients ré‑résolvent. Certains clients mettent agressivement en cache le DNS.
Le pansement courant est d’utiliser un intervalle de reconnexion plus court et de s’assurer que le client refait bien une requête DNS, pas seulement le même IP.

Force : écosystème client mature, authentification basée TLS, beaucoup de réglages.
Faiblesse : ces réglages peuvent devenir une carrière.

IPsec (IKEv2) avec IP dynamiques

IKEv2 supporte des fonctionnalités de mobilité (MOBIKE) qui aident quand un endpoint change de réseau. En pratique, l’interopérabilité entre fournisseurs peut être inégale,
et les modes d’échec sont moins transparents que WireGuard. Quand ça plante, vous avez souvent « no proposal chosen » et un mal de tête.

Si votre bureau utilise un appliance qui veut IPsec, vous pouvez quand même le fiabiliser : encore une fois, préférez « le bureau compose vers un hub statique ».
Laissez le côté statique être le répondant. Laissez le côté dynamique être l’initiateur.

Sécurité : le DDNS n’a pas à être une cible facile

L’IP dynamique n’est pas une stratégie de sécurité. « Ils ne peuvent pas nous trouver parce que l’IP change » est de la sécurité par météo.
Traitez votre point d’entrée VPN comme découvrable. Construisez-le comme s’il allait être scanné. Parce que ce sera le cas.

Checklist de durcissement (courte, pointue)

• Utilisez une authentification forte : clés WireGuard, certificats, ou accès avec MFA si vous utilisez une passerelle de plus haut niveau.
• Limitez l’exposition : seulement les ports nécessaires ; évitez l’interface de gestion exposée publiquement.
• Rate limit et logging : rejetez le bruit évident tôt ; centralisez les logs.
• Séparez les identifiants de mise à jour : le token du updater DDNS ne devrait rien pouvoir faire d’autre dans le DNS.
• N’exécutez pas votre updater DDNS sur la même machine fragile qui redémarre quand une imprimante éternue.

Une citation fiabilité (idée paraphrasée)

Idée paraphrasée — Gene Kim : « Améliorer la fiabilité, c’est généralement améliorer les boucles de feedback et rendre le travail visible, pas des actes héroïques. »

Cela s’applique ici. Un VPN qui « se reconnecte la plupart du temps » n’est pas fiable. Un VPN qui vous dit pourquoi il ne s’est pas reconnecté, l’est.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont les vérifications que je lance vraiment quand quelqu’un dit « le DDNS est OK » et que je n’ai pas envie de parier mon après-midi sur cette affirmation.
Chaque tâche inclut : commande, sortie exemple, ce que la sortie signifie, et la décision à prendre.

1) Confirmer l’IP publique du bureau depuis le réseau du bureau

cr0x@server:~$ curl -s https://ifconfig.me; echo
203.0.113.48

Signification : C’est l’IP que l’Internet voit pour le trafic sortant.

Décision : Si elle diffère de celle pointée par votre enregistrement DDNS, votre updater est cassé ou met à jour la mauvaise interface.

2) Vérifier ce que résout votre nom DDNS (vue autoritaire via dig)

cr0x@server:~$ dig +noall +answer office-vpn.example.net A
office-vpn.example.net. 60 IN A 203.0.113.12

Signification : Le DNS dit que le point d’entrée VPN est 203.0.113.12 avec TTL 60 secondes.

Décision : Si ce n’est pas votre IP publique actuelle, corrigez l’updater. Si c’est correct mais que les clients échouent, concentrez‑vous sur le cache/chemin.

3) Comparer les réponses DNS depuis plusieurs résolveurs (détecter le cache et les résolveurs « utiles »)

cr0x@server:~$ dig +short @1.1.1.1 office-vpn.example.net A
203.0.113.48
cr0x@server:~$ dig +short @8.8.8.8 office-vpn.example.net A
203.0.113.12

Signification : Différents résolveurs sont en désaccord ; l’un est obsolète.

Décision : Baisser le TTL ne résoudra pas instantanément cela. Implémentez la stabilité d’endpoint (hub cloud) ou le comportement client de ré‑résolution.

4) Vérifier le comportement du cache du résolveur local sur un client Linux (systemd-resolved)

cr0x@server:~$ resolvectl query office-vpn.example.net
office-vpn.example.net: 203.0.113.12
                     -- link: eth0
                 (DNS cache)

Signification : Le client utilise des données en cache.

Décision : Videz le cache ou forcez la ré‑résolution sur reconnexion ; envisagez de placer le point d’entrée dans le cloud pour éviter la sensibilité au cache.

5) Vider le cache systemd-resolved (quand il faut prouver un point)

cr0x@server:~$ sudo resolvectl flush-caches
cr0x@server:~$ resolvectl query office-vpn.example.net
office-vpn.example.net: 203.0.113.48
                     -- link: eth0

Signification : Après vidage, la résolution est correcte.

Décision : Si le vidage « répare » le VPN, le problème est le cache client ou un résolveur obsolète, pas le démon VPN.

6) Confirmer la joignabilité des ports (UDP 51820 pour WireGuard, exemple)

cr0x@server:~$ nc -uvz office-vpn.example.net 51820
nc: connect to office-vpn.example.net (203.0.113.48) port 51820 (udp) succeeded!

Signification : Au moins la reachabilité UDP de base existe vers cette IP/port.

Décision : Si échec, dépannez firewall/NAT/blocs ISP avant de toucher aux configs WireGuard.

7) Capturer le trafic sur le serveur pour voir si des paquets arrivent (ne pas deviner)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
5 packets captured

Signification : Des paquets atteignent l’interface.

Décision : Si des paquets arrivent mais pas de handshake, concentrez-vous sur keys/AllowedIPs/routage WireGuard. Si aucun paquet, c’est DNS/NAT/firewall/chemin.

8) Vérifier l’état de handshake et les endpoints WireGuard sur le serveur

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 7G2n...redacted...
  listening port: 51820

peer: b9mK...redacted...
  endpoint: 198.51.100.77:54213
  allowed ips: 10.10.10.2/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 120.34 MiB received, 98.10 MiB sent

Signification : Le peer est vivant ; le serveur a appris son endpoint et échange du trafic.

Décision : Si « latest handshake » date de plusieurs heures, le peer est hors ligne, bloqué sur l’ancien endpoint, ou bloqué par NAT.

9) Vérifier l’état de l’interface et des routes WireGuard côté client

cr0x@server:~$ ip -brief addr show wg0
wg0             UNKNOWN        10.10.10.2/32
cr0x@server:~$ ip route show table main | grep 10.10.10
10.10.10.0/24 dev wg0 proto kernel scope link

Signification : L’interface existe et les routes sont présentes.

Décision : Si l’interface manque ou que les routes n’existent pas, le problème est local (config/bring-up), pas DDNS.

10) Confirmer que le hostname est re‑résolu quand le tunnel redémarre

cr0x@server:~$ sudo wg-quick down wg0
[#] ip link delete dev wg0
cr0x@server:~$ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.10.10.2/32 dev wg0
[#] ip link set mtu 1420 up dev wg0

Signification : La recréation de l’interface déclenche typiquement la résolution DNS pour les hostnames Endpoint.

Décision : Si « bouncer l’interface » répare, implémentez un watchdog automatisé ou déplacez l’endpoint vers une IP stable.

11) Valider que votre updater DDNS tourne réellement (unit systemd)

cr0x@server:~$ systemctl status ddns-update.service --no-pager
● ddns-update.service - DDNS updater
     Loaded: loaded (/etc/systemd/system/ddns-update.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2025-12-28 08:11:23 UTC; 2h 3min ago
   Main PID: 1421 (ddns-update)
     Tasks: 1
     Memory: 4.2M
     CGroup: /system.slice/ddns-update.service
             └─1421 /usr/local/bin/ddns-update

Signification : L’updater est en cours d’exécution.

Décision : S’il est inactif ou plante, corrigez‑le en premier. Une configuration VPN parfaite ne rattrapera pas un updater mort.

12) Inspecter les logs de l’updater pour erreurs d’auth ou boucles « no change »

cr0x@server:~$ journalctl -u ddns-update.service -n 20 --no-pager
Dec 28 09:14:01 officegw ddns-update[1421]: current_ip=203.0.113.48 dns_ip=203.0.113.12
Dec 28 09:14:01 officegw ddns-update[1421]: updating A record for office-vpn.example.net
Dec 28 09:14:02 officegw ddns-update[1421]: update succeeded; ttl=60

Signification : Il a détecté un écart et mis à jour avec succès.

Décision : Si vous voyez des échecs répétés (401/403), faites tourner les identifiants et réduisez les privilèges ; si vous voyez « dns_ip » qui ne change jamais, votre fournisseur met en cache/est lent.

13) Rechercher du CGNAT (le problème silencieux « jamais d’entrant »)

cr0x@server:~$ ip route | awk '/default/ {print $3}'
100.64.0.1

Signification : Une gateway par défaut dans 100.64.0.0/10 suggère fortement du CGNAT en amont.

Décision : Arrêtez d’essayer de faire du port-forward inbound. Passez au hub cloud ou à l’accès par relais.

14) Vérifier NAT/port-forward sur l’edge (exemple : nftables sur une passerelle Linux)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    udp dport 51820 accept
  }
}
table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    udp dport 51820 dnat to 192.168.10.10:51820
  }
}

Signification : Le pare-feu autorise UDP 51820 ; le NAT redirige vers le serveur VPN interne.

Décision : Si manquant, corrigez les règles. Si présent mais aucun paquet n’arrive en interne, votre routeur en amont ne forwarde pas vraiment ou l’ISP bloque l’entrant.

15) Confirmer que le serveur VPN écoute

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0           0.0.0.0:51820      0.0.0.0:*    users:(("wireguard",pid=931,fd=6))

Signification : Le serveur est lié à UDP 51820 et prêt.

Décision : Si non à l’écoute, le service n’est pas up ou est lié à la mauvaise interface.

16) Vérifier les problèmes de MTU (commun quand « ça se connecte mais rien ne marche »)

cr0x@server:~$ ping -M do -s 1380 10.10.10.1 -c 2
PING 10.10.10.1 (10.10.10.1) 1380(1408) bytes of data.
1388 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=29.2 ms
1388 bytes from 10.10.10.1: icmp_seq=2 ttl=64 time=28.9 ms

--- 10.10.10.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Signification : Les gros paquets passent avec DF set. Le MTU est probablement OK à cette taille.

Décision : Si cela échoue mais que des pings plus petits fonctionnent, réduisez le MTU WireGuard (par ex., 1420 → 1380) et retestez.

Playbook de diagnostic rapide

C’est la séquence « vous avez 10 minutes avant que la réunion devienne un tribunal ».
L’objectif est de trouver le goulot d’étranglement : résolution de nom, chemin réseau, ou état de session VPN.

Première étape : le nom pointe‑t‑il au bon endroit ?

• Depuis un réseau neutre (hotspot téléphone), résolvez le nom DDNS avec dig.
• Comparez avec l’IP sortante actuelle du bureau (curl ifconfig depuis le bureau).
• Si écart : problème d’updater / fournisseur DNS.

Deuxième étape : pouvez‑vous atteindre le port sur cette IP ?

• Testez la reachabilité UDP (nc -uvz) et/ou capturez les paquets sur le serveur (tcpdump).
• Si pas de reachabilité : firewall, NAT, blocage ISP, ou CGNAT. Ne touchez pas encore aux configs VPN.

Troisième étape : le VPN fait‑il réellement le handshake ?

• Sur WireGuard : wg show pour « latest handshake ».
• Sur OpenVPN : logs serveur et client ; cherchez des reconnexions répétées vers la même IP.
• Si pas de handshake mais des paquets arrivent : keys, AllowedIPs, mauvais subnet, ou routage.

Quatrième étape : est‑ce « connecté mais inutile » ?

• Vérifiez routes, push DNS et MTU.
• Faites un test MTU avec ping DF.
• Cherchez un routage asymétrique (le trafic entre, les réponses sortent par l’autre WAN).

Erreurs courantes : symptôme → cause → correctif

1) « Le VPN est en panne après la maintenance ISP »

Symptôme : Les clients ne peuvent pas se connecter. L’enregistrement DDNS affiche encore l’ancienne IP.

Cause racine : L’updater DDNS ne s’est pas lancé après la coupure ou le reboot du routeur ; identifiants expirés ; updater lié à la mauvaise interface.

Correctif : Exécutez l’updater sur une machine stable (petit Linux VM/NUC), transformez‑le en service avec logs, alertez sur échec de mise à jour, et validez que la résolution correspond à curl ifconfig.

2) « Certains utilisateurs se connectent, d’autres non, pendant des heures »

Symptôme : Succès mixtes ; le helpdesk voit du « aléatoire ».

Cause racine : Différences de cache des résolveurs. Certains clients ré‑résolvent, d’autres gardent l’ancienne IP ; certains réseaux utilisent des forwarders DNS obsolètes.

Correctif : Utilisez un hub à IP statique. Si impossible, implémentez une reconnexion client qui force le refresh DNS (bounce interface) et gardez un TTL modéré (60–300s).

3) « Ça se connecte mais les ressources internes timeoutent »

Symptôme : Le VPN montre connecté, mais SMB/RDP/HTTP vers des hôtes du bureau échoue de façon intermittente.

Cause racine : MTU blackholing ou routage asymétrique (dual WAN sans policy routing).

Correctif : Baissez le MTU du tunnel ; implémentez du policy-based routing pour que le trafic de retour sorte par le même WAN ; testez avec des pings DF.

4) « Le DDNS se met à jour, mais il pointe vers une IP privée »

Symptôme : L’enregistrement DNS devient 192.168.x.x ou 10.x.x.x.

Cause racine : L’updater lit l’adresse de l’interface locale, pas l’adresse publique, ou il se trouve derrière un NAT en amont.

Correctif : Utilisez un updater qui interroge un service externe « what is my IP » ; exécutez l’updater sur le véritable edge ; vérifiez que les logs montrent l’IP publique.

5) « Le port‑forward est correct mais rien n’arrive »

Symptôme : Pare‑feu local et règles NAT semblent corrects ; tcpdump ne montre rien.

Cause racine : CGNAT ou filtrage entrant ISP, ou le routeur n’est pas le vrai bord Internet.

Correctif : Confirmez que l’IP WAN du routeur correspond à l’IP publique. Si non, vous êtes derrière un CGNAT/double NAT. Utilisez un hub cloud ou un design par relais.

6) « Les pairs WireGuard n’affichent pas de handshake tant que l’utilisateur n’essaie deux fois »

Symptôme : Première tentative échoue ; la seconde fonctionne.

Cause racine : Endpoint changé ; le client a mis en cache l’ancienne résolution ; pas de keepalive ; mapping NAT mort.

Correctif : Ajoutez PersistentKeepalive = 25 pour les clients itinérants. Implémentez un script de reconnexion qui reset l’interface en cas d’échec. Préférez un endpoint hub statique.

7) « Après activation d’une ‘optimisation’, la latence a empiré »

Symptôme : Accès plus lent après « TTL plus court » ou « mises à jour plus fréquentes ».

Cause racine : Tempêtes de requêtes DNS, limites de taux des résolveurs, ou throttling du fournisseur DDNS.

Correctif : Gardez un TTL sensé ; ne mettez à jour qu’en cas de changement ; ajoutez du jitter/backoff ; concentrez‑vous sur la stabilité architecturale plutôt que sur une forte churn DNS.

Listes de vérification / plan pas à pas

Pas à pas : rendre un VPN hébergé au bureau survivable (fiabilité minimale viable)

1. Confirmez que vous avez une véritable IP publique. Comparez l’IP WAN du routeur à curl ifconfig. Si différente, considérez le double NAT/CGNAT et arrêtez de planifier un VPN entrant.
2. Choisissez une approche DDNS que vous pouvez opérer. Préférez des tokens API avec les moindres privilèges et un updater avec logs.
3. Réglez le TTL à 60–300 secondes. Plus bas n’est pas une baguette magique ; c’est juste plus de requêtes.
4. Mettez en place de la supervision : alertez si l’enregistrement A diffère de l’IP publique observée pendant plus de quelques minutes.
5. Keepalives WireGuard : les clients itinérants ont PersistentKeepalive = 25 ; les serveurs généralement n’en ont pas besoin.
6. Sanity firewall : autorisez inbound UDP 51820 (ou votre port). Loggez les drops pendant les incidents.
7. Runbook et propriété : qui gère la config du routeur edge, et qui peut la modifier à 2h du matin sans deviner ?
8. Testez les événements de défaillance : forcez une reconnexion WAN (ou changez l’IP) en heures calmes et observez la récupération des clients.

Pas à pas : design recommandé « hub cloud » (ennuyeux, stable, scalable)

1. Créez une petite VM cloud avec une IP statique et une surface d’attaque minimale.
2. Installez WireGuard et configurez‑le comme hub.
3. La passerelle du bureau devient un client qui se connecte en outbound au hub. Aucun port entrant requis au bureau.
4. Les utilisateurs distants se connectent au hub en utilisant un nom DNS stable pointant vers l’IP statique.
5. Routez les sous‑réseaux du bureau via le peer bureau ; gardez AllowedIPs précis.
6. Supervisez la fraîcheur des handshakes sur le hub et le peer bureau ; alertez sur la vétusté.
7. Redondance optionnelle : second hub dans une autre région ; les clients ont deux configs ; le bureau compose vers les deux (ou basculement supervisé).

Checklist opérationnelle (hebdomadaire et après changements)

• Validez la résolution DNS depuis au moins deux résolveurs.
• Validez la reachabilité inbound (si hébergé au bureau) depuis un réseau externe.
• Vérifiez wg show pour des peers avec handshakes obsolètes.
• Revoyez les logs de l’updater pour échecs d’auth, throttling, ou oscillations d’IP.
• Contrôlez ponctuellement le MTU avec des pings DF si les utilisateurs signalent « se connecte mais lent ».
• Confirmez que le firmware du routeur et les sauvegardes de config existent.

Trois mini-récits d’entreprise du terrain

Incident causé par une fausse hypothèse : « TTL signifie que les clients basculeront en 60s »

Une entreprise de taille moyenne avait un serveur OpenVPN hébergé au bureau derrière un routeur pour PME. Le TTL DDNS était réglé à 60 secondes.
Ils croyaient avoir conçu une récupération maximale d’une minute en cas de changement d’IP. La diapositive du design disait littéralement « temps d’indisponibilité max : 60s ».

Puis l’ISP fit de la maintenance. L’IP du bureau changea. L’updater DDNS s’exécuta et mit rapidement à jour. Le serveur VPN écoutait.
Pourtant, les utilisateurs distants échouèrent pendant des heures — certains pour le reste de la journée. Pendant ce temps, quelques utilisateurs se connectèrent, rendant l’incident « aléatoire »
et encourageant tout le monde à changer différentes choses en même temps.

La cause racine fut la moins glamour : une partie des utilisateurs étaient sur des réseaux utilisant des forwarders avec un cache obstiné.
Certains routeurs domestiques gardaient l’ancien enregistrement A et ignoraient le TTL ; certains Wi‑Fi invités d’entreprise faisaient de même. Quelques clients OpenVPN gardaient l’IP résolue
tant que le processus n’était pas relancé.

La correction n’a pas été « mettre le TTL à 10 ». Ils ont déplacé le point d’entrée VPN sur une VM cloud à IP statique, et ont fait en sorte que le bureau initie un tunnel site‑vers‑cloud.
Le DDNS est devenu sans importance pour le chemin critique. Les débats sur le TTL sont retournés là où ils appartiennent : arguments académiques dans les fils de commentaires.

Optimisation qui s’est retournée contre eux : « mises à jour DDNS plus fréquentes »

Une autre organisation avait un endpoint WireGuard dans une succursale avec IP dynamique. Quelqu’un remarqua des délais occasionnels après des changements d’IP et décida « d’optimiser »
en exécutant l’updater DDNS toutes les 10 secondes, forçant des mises à jour même si l’IP n’avait pas changé. Ils avaient aussi réglé le TTL à 30 secondes parce que « plus rapide c’est mieux ».

Ça a marché une semaine. Puis une vague de bizarreries : échecs intermittents de résolution, certains résolveurs retournant SERVFAIL, et le fournisseur DDNS servant parfois l’enregistrement précédent plus longtemps que prévu.
Le helpdesk voyait des « problèmes DNS » et escaladait au réseau, qui voyait des « problèmes VPN » et renvoyait l’affaire. Tout le monde a exercé ses étapes.

Ce qui s’est passé : le fournisseur a limité le taux de mises à jour et a parfois retardé la propagation en interne. Le rythme agressif a créé du bruit qui masquait les changements d’IP réels.
Et le TTL bas a augmenté le volume de requêtes durant l’heure de pointe, poussant certains résolveurs vers des comportements dégradés.

Ils sont revenus à « mettre à jour uniquement en cas de changement » avec backoff exponentiel sur échecs, ont remis le TTL à 120 secondes, et—plus important—ont ajouté un watchdog
qui détecte quand l’enregistrement A résolu diffère de l’IP publique observée de la succursale. L’optimisation n’était pas la vitesse ; c’était l’observabilité.

Pratique ennuyeuse mais correcte qui a sauvé la journée : « On teste la panne chaque mois »

Une entreprise régulée avec plusieurs petits sites exécutait un design hub cloud WireGuard. Chaque mois, quelqu’un dans l’IT faisait un test contrôlé :
forcer la reconnexion du routeur de la succursale, observer la nouvelle IP publique, vérifier que le tunnel se réétablit, et confirmer la reachabilité des applications.
Ils vérifiaient aussi que les alertes se déclenchaient comme prévu et se résolvaient après récupération.

Un mois, un site ne se rétablit pas. Le test a échoué rapidement : la passerelle de la succursale était derrière un dispositif NAT en amont introduit lors d’un échange d’équipement de l’ISP.
L’équipe locale ne l’avait pas remarqué parce que la navigation normale fonctionnait. Le tunnel VPN ne pouvait pas s’établir de façon fiable car le trafic de retour prenait un chemin différent.

Comme cela a été détecté pendant un test planifié, ils n’ont pas débogué sous pression pendant une échéance critique de paie.
Ils ont basculé la succursale sur un autre port WAN, ajusté le policy routing, et confirmé la stabilité. Le changement a été documenté et intégré à la config standard.

Personne n’a envoyé d’email de victoire. C’est la preuve d’une bonne ingénierie. La journée a été sauvée par une checklist et un rappel calendrier — deux outils qui ont survécu à la plupart des fournisseurs VPN.

FAQ

Ai‑je besoin du DDNS si j’utilise un hub VPN hébergé en cloud ?

Généralement non pour le côté bureau. Le hub cloud a une IP statique ; le bureau compose vers l’extérieur. Vous pouvez toujours utiliser un DNS normal pour le nom du hub,
mais il s’agit d’un DNS stable, pas dynamique.

WireGuard peut‑il utiliser un hostname dans le champ Endpoint en toute sécurité ?

Oui, mais n’imaginez pas qu’il re‑résolve en continu. Beaucoup d’installations résolvent à la mise en place de l’interface. Prévoyez une ré‑résolution au reconnect, ou évitez le problème avec une IP hub statique.

Quel TTL devrais‑je définir pour mon enregistrement DDNS ?

60–300 secondes est la plage pratique. Un TTL plus bas ne bat pas les caches récalcitrants et peut augmenter la charge DNS et le throttling fournisseur.

Comment savoir si je suis derrière du CGNAT ?

Si l’IP WAN de votre routeur diffère de ce que rapportent les services externes, ou si votre gateway upstream est dans 100.64.0.0/10, supposez du CGNAT/double NAT.
L’hébergement d’un VPN entrant au bureau devient une cause perdue ; utilisez un hub ou un relais.

Pourquoi « DDNS mis à jour » ne répare pas immédiatement la connectivité des utilisateurs ?

Parce que le DNS est mis en cache à plusieurs niveaux : résolveurs récursifs, routeurs domestiques, caches OS, et parfois le client VPN lui‑même. Certains caches ignorent le TTL.
Concevez pour cela plutôt que de discuter.

Le split tunneling est‑il acceptable pour un VPN de bureau ?

Ça dépend de votre modèle de menace. Le split tunneling réduit la bande passante et évite le hairpinning du trafic SaaS via le bureau.
Le full tunnel centralise le contrôle et les logs mais augmente la surface d’impact quand le VPN a des soucis. La plupart des entreprises finissent par adopter du split tunneling
avec des routes strictes pour les sous‑réseaux internes.

Quelle est la configuration la plus simple et fiable pour un petit bureau ?

Une petite VM cloud comme hub VPN (IP statique), WireGuard, la passerelle du bureau comme client, les utilisateurs distants comme clients.
Ça évite le port‑forward entrant, la fragilité DDNS et la plupart des bizarreries ISP.

Puis‑je faire en sorte que le dual WAN « marche simplement » avec un endpoint VPN au bureau ?

Oui, mais il faut gérer le routage asymétrique et le mapping entrant. Sans policy routing et health checks soignés, cela devient des échecs intermittents
qui ressemblent à des problèmes utilisateurs. Si vous avez dual WAN, c’est encore plus de raisons de mettre le point d’entrée dans le cloud et de laisser le bureau composer vers l’extérieur.

Comment surveiller pour savoir avant les utilisateurs ?

Supervisez trois signaux : (1) enregistrement A vs IP publique observée, (2) reachabilité de port depuis l’extérieur, (3) fraîcheur des handshakes VPN et compteurs de trafic.
Alertez sur un écart soutenu ou des handshakes obsolètes, pas sur un seul blip.

Le DDNS est‑il un risque de sécurité ?

Le risque n’est pas le DDNS lui‑même ; c’est des identifiants updater faibles et des surfaces de gestion exposées. Utilisez des tokens least‑privilege, protégez la machine updater,
et traitez le point d’entrée VPN comme une infrastructure exposée au public (parce que c’est le cas).

Prochaines étapes qui ne reposent pas sur l’espoir

Si vous ne faites qu’une chose : déplacez la « porte d’entrée » VPN vers un endpoint stable (VM cloud avec IP statique) et faites en sorte que le bureau se connecte en outbound.
Vous transformez le problème d’IP dynamique d’une surprise hebdomadaire en non‑événement.

Si vous devez garder le VPN au bureau, arrêtez de traiter le DDNS comme une case à cocher. Instrumentez‑le. Surveillez‑le. Testez‑le.
Construisez un comportement de reconnexion client qui force la ré‑résolution. Et confirmez que vous n’êtes pas derrière du CGNAT avant de passer une autre heure à peaufiner des port forwards.

Prochaines étapes pratiques pour cette semaine :

• Exécutez une fois la séquence « Playbook de diagnostic rapide » pendant les heures calmes et notez ce à quoi ressemble le « normal ».
• Ajoutez une alerte « enregistrement A DNS != IP publique observée depuis 10 minutes » (si hébergé au bureau).
• Vérifiez les handshakes WireGuard et identifiez les peers qui ne se reconnectent jamais sans intervention manuelle.
• Décidez si votre entreprise veut gérer un edge Internet de bureau comme infrastructure de production. Si non, déplacez le point d’entrée.