Le VPN tombe après un renouvellement DHCP ? Comparez les adresses

Le renouvellement du bail et la panne du VPN apparaissent ensemble dans les journaux assez souvent pour que les gens concluent que l'un cause l'autre. La coïncidence temporelle est réelle ; la causalité ne l'est généralement pas. Un renouvellement est une requête unicast au serveur qui a émis le bail, demandant à continuer d'utiliser la même liaison, et le serveur peut la prolonger sans que le client change une seule adresse. Examiner les valeurs propres du client autour de l'événement sépare un bail renouvelé en silence d'un réseau qui a réellement changé sous un tunnel en fonctionnement.

Partez du client qui a décroché

Ouvrez d'abord le journal de connexion du client et notez l'heure de la coupure à la seconde. Ouvrez ensuite le journal réseau du système d'exploitation pour la même minute et lisez dans l'ordre ce que l'interface a fait. Cet ordre est toute l'enquête : un événement DHCP avant la déconnexion, une déconnexion avant l'événement DHCP et deux événements sans rien entre eux sont trois constats différents. Une ligne de journal qui ne mentionne le bail que pendant que le tunnel se reconnectait déjà est une décoration, pas une preuve.

Écrivez la chronologie au fur et à mesure au lieu de la garder en mémoire. Les horodatages d'outils différents coïncident rarement parfaitement, et le décalage lui-même est parfois l'explication.

Comparez les quatre valeurs autour de l'événement

Quatre valeurs décrivent le côté local d'une connexion assez bien pour détecter un vrai changement : l'adresse de l'interface, la passerelle par défaut, la liste des résolveurs et l'état opérationnel de l'interface. Capturez-les dans la minute qui suit la coupure et comparez-les à une capture prise lorsque le tunnel était sain.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Une adresse inchangée avec une passerelle inchangée et une liste de résolveurs modifiée oriente vers la résolution de noms plutôt que vers le routage, et le tunnel a pu survivre pendant que les applications cessaient de trouver les hôtes. Une passerelle modifiée signifie que le chemin de sortie du réseau local a bougé, ce qui suffit à invalider une route qui pointait vers la précédente. Si les quatre valeurs correspondent à la capture saine, le bail n'est pas votre cause et la logique de reconnexion du client devient le sujet. Capturez la comparaison pendant que le défaut est visible, car une capture saine prise après un redémarrage a un historique d'adresses différent et ne correspondra pas.

Ce qu'un renouvellement peut et ne peut pas changer

RFC 2131 décrit le renouvellement comme une requête au serveur d'origine à la moitié du temps de bail, avec reliaison à n'importe quel serveur aux sept huitièmes si la première tentative reste sans réponse. Aucune des deux étapes n'exige que le client obtienne une adresse différente, et un serveur coopératif prolonge normalement la liaison existante. Un vrai changement d'adresse arrive généralement par un autre chemin : un serveur qui refuse le renouvellement, un client qui a perdu son état et recommencé, ou un réseau qui a déplacé l'appareil vers un autre segment.

Le côté public de la connexion peut changer sans aucune modification locale. Derrière une traduction de niveau opérateur, l'adresse que voit le pair VPN peut être réattribuée indépendamment de ce que le bail local a fait, et cette réattribution ressemble, de l'intérieur du client, à une panne de réseau local. Comparer une adresse rapportée localement à une observation côté pair est le seul moyen de les séparer.

Quand le client ne s'adapte pas

Un client qui a lié son transport à l'ancienne adresse, mis en cache une route obsolète vers le pair ou enregistré une identité d'interface peut continuer à réessayer un chemin qui n'existe plus. C'est un défaut d'adaptation, et il se voit comme des retransmissions répétées vers une adresse que l'hôte ne peut plus atteindre. Certains clients le gèrent par conception : WireGuard, par exemple, met à jour le point de terminaison d'un pair lorsqu'un paquet correctement authentifié arrive d'une nouvelle source.

Un redémarrage manuel qui rétablit le service est un indice sur l'endroit où l'adaptation a échoué, pas une preuve que les baux et les tunnels sont incompatibles. Gardez la politique de blocage en place pendant le test, sinon le test lui-même devient une panne avec une autre cause. Notez si le client s'est rétabli seul, combien de temps cela a pris et quelle adresse il a réessayée ; cette séquence vous en dit plus que le motif de déconnexion affiché dans l'interface.

Répétez l'événement avant de l'accuser

Reproduisez la condition au lieu d'attendre le calendrier : libérez et renouvelez le bail, ou forcez l'événement contrôlé équivalent, et observez si le tunnel survit. Sur un réseau géré, coordonnez tout changement d'adresse avec le propriétaire du réseau, car une attribution statique arbitraire peut entrer en collision avec un appareil qui détient déjà cette adresse.

Après un correctif pris en charge, répétez le même événement puis testez une application et une résolution de nom, car un tunnel qui se reconnecte mais casse le DNS passe un test plus faible que celui qui compte. Signalez le changement précis que vous avez observé, avec son horodatage, au lieu de désigner le bail planifié comme la cause. La différence entre ces deux rapports est de savoir si la personne suivante peut reproduire la panne ou seulement la rumeur.