L’IP WAN a changé et le tunnel est tombé : les vérifications dans l’ordre

Le tunnel tombe, le routeur enregistre une reconnexion, et rien sur le LAN n’a bougé. Une nouvelle adresse WAN invalide la connexion extérieure sans rien changer à l’intérieur : l’adresse source du client a changé, l’ancien état NAT pointe vers une source qui n’existe plus, et le pair distant peut encore envoyer à l’adresse précédente. La récupération est un comportement normal, et la question utile est quel état n’a pas été mis à jour.

Nommez l’événement avant de lire le journal

Vérifiez ce qui s’est réellement passé au niveau de l’accès. Un renouvellement de bail chez le fournisseur est un événement. Une session PPPoE qui s’est reconnectée en est un autre. Un modem fibre qui a redémarré, ou un basculement WAN d’un lien vers un autre, change l’adresse extérieure ou son chemin d’une troisième manière. Ce ne sont pas les mêmes événements et ils ne laissent pas les mêmes résidus.

Une ligne de reconnexion dans le journal du VPN ne prouve pas non plus un changement de WAN. Un délai d’inactivité, un intervalle de réauthentification et la détection de pair mort produisent tous des reconnexions sans aucun changement d’adresse. Comparez les horodatages du journal d’accès avec ceux du journal du VPN avant de conclure quoi que ce soit, et gardez la fenêtre de comparaison assez large pour attraper un changement survenu pendant la nuit.

L’itinérance et la reconnexion sont des protocoles différents

WireGuard intègre l’itinérance authentifiée au protocole : lorsqu’un pair reçoit un paquet correctement authentifié depuis une nouvelle adresse source, il met à jour le point de terminaison de ce pair. Le démarrage rapide de WireGuard décrit la configuration du pair qui rend cela possible, et c’est pourquoi un client sur une adresse changeante se rétablit souvent sans redémarrage visible.

OpenVPN se comporte différemment par défaut. Une session UDP peut se terminer et se reconnecter, et le comportement float facultatif permet à un pair authentifié de continuer depuis une nouvelle adresse là où la configuration l’autorise. Les tunnels basés sur TCP sont plus stricts, car la connexion elle-même est liée à la paire d’adresses. Cette différence décide si la récupération semble invisible ou s’annonce dans le journal à chaque fois.

Aucun des deux comportements ne dit quoi que ce soit sur les applications à l’intérieur. Un tunnel rétabli ne restaure pas une session TCP que le pair considérait déjà comme morte.

L’état que le tunnel ne possède pas

L’état de traduction et de routage survit à la reconnexion de façons qui surprennent. Une entrée conntrack créée pour l’ancienne source garde le chemin de réponse ancré sur une adresse qui n’existe plus, et elle expire selon son propre calendrier, pas quand le tunnel est revenu. Redémarrer le service du tunnel ne raccourcit pas cette attente, si bien qu’un lien réparé peut encore sembler cassé un moment.

Les routes et les règles de politique peuvent référencer l’ancienne passerelle ou interface. Un jeu de règles correct avant un basculement WAN peut pointer vers un appareil désormais hors service, ce qui produit un tunnel qui se déclare connecté et un trafic qui ne va nulle part. Le DNS dynamique pour un serveur que vous hébergez est un problème distinct de celui d’un client qui obtient une nouvelle source. L’enregistrement doit être mis à jour pour que les clients distants vous trouvent, et aucune configuration côté client ne compense une adresse que la traduction en amont ne transmettra pas.

Ordonnez les vérifications de l’extérieur vers l’intérieur

L’ordre ci-dessous va de la connexion extérieure vers l’intérieur, et s’arrêter à la première étape défaillante est ce qui le rend utile : chaque passe élimine la couche au-dessus. Gardez cet ordre même lorsque la panne semble évidente.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

La première commande montre le point de terminaison actuel et l’âge de la poignée de main pour chaque pair. La deuxième et la troisième montrent si l’interface extérieure et la route vers le point de terminaison ont encore un sens. Le nombre de conntrack est une vérification grossière de l’état restant de l’adresse précédente, et le journal est l’endroit où la raison de la reconnexion est consignée.

Testez ensuite depuis un client du LAN plutôt que depuis le routeur. Un ping émis par le routeur lui-même emprunte un chemin différent du trafic transféré, donc un ping réussi depuis le routeur prouve que le tunnel existe et rien sur la joignabilité du client.

Décidez le comportement attendu et écrivez-le

Se reconnecter est le bon comportement pour la plupart des déploiements, l’objectif n’est donc pas de l’empêcher. Décidez plutôt ce qui doit arriver au trafic pendant la coupure : l’arrêter, le retenir ou basculer vers un autre chemin. Cette décision relève du pare-feu et de la politique de routage, pas du profil VPN.

Consignez ensemble les événements d’accès et les heures de reconnexion pendant une semaine. Des changements répétés sans événement d’accès correspondant pointent vers le service d’accès, et remplacer le profil VPN ne corrigera pas un lien qui renégocie sans cesse. Une seule paire d’entrées dans la même minute tranche la question pour cet incident et donne une base au suivant.