L’IP publique a changé et le VPN a cessé d’acheminer le trafic

Une reconnexion du fournisseur ou un changement dans la traduction en amont modifie la source publique d’une session VPN, tandis que l’adresse privée locale du client reste généralement exactement telle qu’elle était. Le tunnel paraît alors connecté alors que rien d’utile ne le traverse. Les deux observations sont vraies en même temps, et c’est précisément ce qui rend le rapport déroutant.

Passez les quatre vérifications dans l’ordre et arrêtez-vous à la première qui échoue.

Quelle adresse a réellement changé

Comparez l’état de l’interface locale avec la source qu’un point de terminaison distant observe, à un endroit où vous êtes autorisé à regarder. Une nouvelle adresse publique n’implique pas une nouvelle passerelle locale, et un changement d’interface locale ne garantit pas non plus que la source publique a bougé. La traduction entre les deux signifie qu’il s’agit de deux faits indépendants. Notez le chemin exact et l’heure à laquelle vous l’avez observé, car une étiquette de géolocalisation recopiée d’un ancien rapport répond à une autre question.

Demandez précisément si la source extérieure a changé, l’adresse intérieure du tunnel a changé, ou les deux. Seule la première explique un pair qui continue d’envoyer vers un chemin qui n’existe plus.

Laissez le protocole gérer le déplacement

Les protocoles diffèrent dans la façon dont ils apprennent qu’un pair s’est déplacé, et cette différence compte pour savoir si vous devez intervenir. WireGuard met à jour le point de terminaison d’un pair lorsqu’il reçoit un paquet qui s’authentifie avec la clé de ce pair, ce qui explique qu’un changement d’adresse puisse être absorbé sans aucune configuration. IKEv2 dispose de MOBIKE pour le même usage là où les deux extrémités le prennent en charge. Les conceptions plus anciennes se rétablissent en reconstruisant le tunnel.

Ce que vous ne devez pas faire, c’est accepter un message non authentifié comme preuve que l’identité d’un pair s’est déplacée. Falsifier un datagramme prétendant une nouvelle adresse est trivial, et un client qui croit qu’on peut le diriger vers le point de terminaison d’un attaquant. Le protocole authentifié est le mécanisme ; une notification ne l’est pas.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Effacer la liaison extérieure obsolète

Lorsque le protocole prend en charge l’itinérance et que le trafic échoue encore, l’obstacle est souvent un équipement à état au milieu ou une politique à l’extrémité distante. Un pare-feu qui suivait l’ancien flux peut conserver l’entrée obsolète, et une règle d’accès côté serveur liée à l’ancienne source écartera la nouvelle en silence. Nettoyer la table de correspondance et revérifier la règle est plus rapide que remplacer les identifiants.

Maintenez le blocage nécessaire pendant l’investigation. Ouvrir largement la politique pour tester si le tunnel se rétablit ne vous apprend rien sur la cause et laisse le déploiement pire que vous ne l’avez trouvé.

Retestez avec une nouvelle requête

Une session applicative établie avant le changement n’y survit pas, car le quadruplet sur lequel elle reposait n’existe plus. Générez une nouvelle requête après le rétablissement et confirmez qu’elle aboutit, au lieu de regarder un ancien téléchargement rester à zéro et de conclure que le tunnel est toujours cassé. Cette seule distinction résout une grande part de ces rapports.

Notez ensuite les deux moitiés du diagnostic : ce qui a changé en amont et quelle étape de rétablissement prise en charge a restauré le flux. La prochaine occurrence sera plus rapide, et la note est ce qui la rend plus rapide.

Si une nouvelle requête réussit et que l’ancienne ne reprend jamais, le tunnel a été réparé et l’application a simplement besoin de se reconnecter.