Bail de secours après le retour du tunnel de site : renouveler ou attendre ?

Liaison de site active, tunnel établi, et les PC de l’agence n’atteignent toujours pas le serveur de fichiers. Deux horloges tournaient pendant la panne, et une seule des deux a fini. Le tunnel s’est rétabli quand le chemin chiffré est revenu ; l’adresse de chaque client se rétablit quand son bail actuel se termine ou est remplacé. Comparer ces deux chronologies explique l’écart plus vite que la lecture des journaux du pare-feu.

Deux horloges, et l’une d’elles n’est pas le tunnel

Avec DHCP sur VPN plus un secours local, l’équipement peut distribuer des baux locaux temporaires tant que le chemin DHCP distant est indisponible. La durée temporaire se compte généralement en minutes, assez courte pour masquer le problème et assez longue pour survivre à une brève panne. Quand le tunnel revient, le secours cesse de proposer ces baux. Il n’entre pas dans un client pour annuler le bail qu’il détient déjà. Ce client conserve son adresse, son masque, sa passerelle et son résolveur jusqu’au renouvellement ou à l’expiration, et c’est pourquoi un tunnel sain et un poste cassé peuvent coexister pendant le reste du bail.

Gardez l’implémentation et la version logicielle attachées à cette affirmation. Les noms de minuteurs et les valeurs par défaut diffèrent selon les versions de SonicOS, et une interface ancienne ne prouve pas ce que fait une plus récente.

Comparez les deux manœuvres de rétablissement

La manœuvre A consiste à attendre. Elle ne coûte rien, ne risque rien et laisse chaque client renouveler selon son propre calendrier. La manœuvre B consiste à forcer une libération et un renouvellement sur le client touché, ce qui donne immédiatement l’adresse prévue mais interrompt tout ce que le client fait. Sur un seul poste, forcer le renouvellement est généralement la voie la plus rapide et facile à justifier. Dans un laboratoire ou sur un terminal de point de vente au milieu d’une transaction, attendre est le choix le plus sûr, et un renouvellement planifié hors des heures ouvrées bat les deux.

ipconfig /all
ipconfig /release
ipconfig /renew

Lisez la sortie avant de libérer quoi que ce soit. Si l’adresse, la passerelle et le DNS correspondent déjà à l’étendue normale, le client s’est rétabli seul et le problème restant est ailleurs. Sur un client Linux, l’équivalent est une libération et un renouvellement de bail via le gestionnaire réseau plutôt qu’une adresse modifiée à la main, car sinon le gestionnaire réécrira votre changement au prochain événement.

Lisez l’offre, pas seulement l’adresse

L’adresse seule ne dit pas qui l’a fournie. Ce qui compte, c’est l’identifiant du serveur dans l’offre, la durée du bail, et si la passerelle et le résolveur correspondent à l’étendue de secours ou à la normale.

tcpdump -ni any 'port 67 or port 68'

Capturez pendant le renouvellement, car une interface silencieuse vous dit que le client n’a jamais demandé. Si l’offre vient du secours local alors que le tunnel est actif, la logique de sélection traite encore le chemin distant comme indisponible, et forcer des renouvellements sur les clients ne fera que répéter le même résultat. Corrélez la capture avec les événements du tunnel sur la même horloge. Un renouvellement de clés ou une brève coupure qui se termine quelques secondes avant la requête du client est une cause plausible ; un tunnel propre avec une réponse de secours est un problème de configuration dans le chemin de sélection.

Où la comparaison s’inverse

Si de nombreux clients sont touchés en même temps, les renouvellements par client deviennent une file d’interruptions et un appel au support. Dans ce cas, regardez l’étendue de secours et la procédure de rétablissement plutôt que les clients, car la population s’est rétablie ensemble et se rétablira encore ensemble.

Si un seul client est touché alors que ses voisins vont bien, l’inverse est vrai : le bail de ce client, sa réservation ou le comportement de son propre client DHCP est la variable, et un changement à l’échelle du site est le mauvais outil.

Les adresses statiques et les réservations demandent une troisième réponse. Un client épinglé à une adresse ne peut pas être sauvé par un renouvellement, et une réservation qui entre en collision avec l’étendue de secours produit un doublon qui ressemble à une panne de routage jusqu’à ce que vous compariez les deux plans d’adressage.

Écrivez la procédure de sortie

Décidez à l’avance à quoi sert le secours, combien de temps un client peut garder son adresse temporaire, et qui est autorisé à forcer un renouvellement pendant les heures ouvrées. Écrivez la réponse là où l’ingénieur d’astreinte la trouvera, à côté de la définition de l’étendue. Puis testez-la une fois, délibérément : coupez le tunnel, observez ce que le client reçoit, rétablissez le tunnel et notez combien de temps le client met à retrouver ses paramètres normaux. Ce seul exercice remplace la majeure partie des suppositions la prochaine fois que la liaison de site vacille.

Terminez en confirmant la ressource, pas l’adresse. Atteindre le serveur de fichiers, résoudre son nom et atteindre Internet sont trois vérifications distinctes, et seule la dernière n’a jamais fait de doute.