VPN bloqué après un redémarrage du routeur : trois choses qui ont changé

Le routeur termine son démarrage, l’ordinateur portable rejoint le même SSID, et le VPN reste sur connecté sans que rien ne bouge. Le profil enregistré est intact. Ce qui a expiré en dessous, c’est le chemin, et le client tient encore l’état qu’il avait construit pour l’ancien.

Trois conditions décident de la correction. Vérifiez-les dans l’ordre, car les suivantes sont du travail perdu si la première explique déjà le blocage.

Première condition : l’adresse locale a changé

Un redémarrage peut attribuer à la machine une adresse différente. Un VPN configuré avec un point de terminaison local fixe continue alors d’utiliser un attachement qui n’existe plus. Il en va de même pour un client qui a lié son socket à l’ancienne adresse. L’interface du tunnel peut rester active alors que chaque paquet qu’elle produit part dans un endroit inutile.

Comparez l’adresse qu’utilise le client avec celle que l’interface détient actuellement. Une route par défaut qui pointe vers une passerelle également modifiée est la même classe de problème sous un autre nom.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Deuxième condition : le mapping traduit a disparu

Les routeurs domestiques traduisent les flux sortants, et ces mappings vivent en mémoire. Un redémarrage efface chacun d’eux. C’est inoffensif pour une nouvelle connexion et fatal pour un tunnel qui croit que son flux existant est encore valide. Le pair ne voit alors rien, si bien que le client ne reçoit jamais d’erreur sur laquelle agir.

C’est là qu’un tunnel sans keepalives se bloque silencieusement au lieu d’échouer bruyamment. Les limitations documentées de WireGuard décrivent la même forme de défaillance. Un état de point de terminaison erroné produit des paquets rejetés plutôt qu’un diagnostic.

Un keepalive persistant de 25 secondes est l’atténuation habituelle, car il rafraîchit le mapping avant qu’un délai d’inactivité puisse expirer. Il ne répare pas un mapping déjà disparu. Associez le keepalive à une logique de reconnexion au lieu de le traiter comme un correctif.

Troisième condition : l’adresse publique a changé

Si l’adresse externe du routeur lui-même a changé, tout ce qui, de l’autre côté, filtre par adresse source voit désormais un pair différent. Le tunnel peut monter et le serveur peut toujours rejeter le trafic, ce qui ressemble à un client défaillant et relève en réalité d’une politique à l’autre extrémité.

Notez l’adresse externe avant et après le redémarrage. Quand les deux diffèrent, la question passe du client à celui qui tient la liste d’autorisation, et réinitialiser les identifiants sur l’ordinateur portable ne peut pas aider.

Récupérez dans le bon ordre

Terminez d’abord toute connexion obligatoire au portail captif, puis laissez le client se reconnecter via sa procédure prise en charge plutôt que de tuer le processus. Observez si l’identité et le trafic de données reviennent tous les deux, car ce sont deux étapes différentes de la même connexion.

Une page en cache ne prouve rien, pas plus qu’une application de messagerie qui s’est reconnectée seule. Testez le point de terminaison qui vous importe réellement avec une requête neuve. Maintenez la politique de trafic direct pendant l’interruption, car une tentative de reconnexion n’est pas un blocage.

Quand cela se répète après chaque redémarrage, le relevé compte plus que la nouvelle tentative. Notez l’adresse locale, la passerelle, l’adresse externe et l’état du client avant et après, puis comparez les deux colonnes. Cela transforme une plainte vague en bogue de cycle de vie que quelqu’un peut corriger, et cela évite que les certificats soient remplacés une troisième fois à cause d’un délai d’expiration du mapping.