Le VPN du routeur semble correct après une coupure ? Testez ces quatre couches

Un routeur qui s’allume après une coupure a restauré sa configuration, pas sa connectivité. Après une coupure de courant, un routeur peut restaurer son profil VPN enregistré avant que les dépendances dont ce profil a besoin soient prêtes : le modem en amont peut encore s’entraîner, l’horloge peut être fausse et l’authentification peut ne pas être terminée. Le voyant du tableau de bord et la configuration enregistrée décrivent une intention, pas un tunnel qui fonctionne. Vérifiez les quatre couches ci-dessous dans l’ordre plutôt que de remplacer le profil, car c’est ce que les gens font en second et regrettent en premier.

Tout ici suppose que vous êtes sur place ou que vous disposez d’un accès qui ne dépend pas du tunnel que vous testez. Sinon, organisez-le avant la prochaine coupure.

Première couche : le WAN est-il vraiment revenu

Commencez par le modem, pas par le tableau de bord du routeur. Un routeur qui termine son démarrage avant que son modem se soit entraîné affiche une interface saine sans rien derrière, et le tunnel n’a aucun pair à joindre. Confirmez que le modem transmet réellement, puis confirmez que le routeur a repris les paramètres WAN que vous attendez. Vérifiez aussi si l’adresse WAN a changé : une adresse dynamique qui revient différente peut invalider une règle basée sur l’adresse ou une liste d’autorisations distante, et de l’intérieur du réseau cela ressemble à une panne du VPN.

Certains réseaux d’accès exigent aussi une nouvelle étape d’admission après une coupure. Lisez le journal du client pour la première étape de défaillance au lieu de deviner : la première erreur nomme la couche, et tout ce qui suit est une conséquence. Notez l’adresse et le résultat d’admission dans le ticket, car les deux décident si le même profil fonctionnera demain. Une adresse changée est une correction de cinq minutes et un mystère de deux heures.

Deuxième couche : vérifiez l’horloge avant le certificat

Une horloge fausse interfère avec la validité du certificat et avec tout ce qui dépend du temps, et un appareil embarqué qui démarre sans source de temps fonctionnelle peut rester sur une date ancienne un moment. La validation du certificat échoue alors pour une raison qui n’a rien à voir avec l’identifiant. Une erreur de validité dont les dates sont décalées de plusieurs années désigne l’horloge ; la même erreur avec des dates actuelles désigne le certificat.

date -u
chronyc tracking

Utilisez le processus de récupération de temps pris en charge et confirmez l’horloge du routeur avant de toucher au profil. Désactiver la validation pour contourner l’erreur transforme un problème temporaire d’ordre en un affaiblissement permanent, et c’est la mauvaise correction la plus courante dans ce scénario. Si l’appareil n’a pas d’horloge à pile, l’ordre de démarrage compte : il a besoin d’un accès réseau avant de pouvoir synchroniser l’heure, et de l’heure avant de pouvoir valider un tunnel. C’est cet ordre qu’il faut corriger si la même défaillance se répète après chaque coupure.

Troisième couche : lisez ce que dit le tunnel

Vérifiez l’état propre du tunnel et le résultat de sa poignée de main ou de son authentification, plutôt que le fait que l’interface soit active. Une interface peut exister sans pair établi, et un client peut afficher connecté alors que le renouvellement des clés échoue. Séparez les délais d’attente de transport des refus explicites : un délai d’attente suggère que le chemin ou le pair n’est pas encore joignable, tandis qu’un refus signifie que l’extrémité distante a répondu et refusé, le plus souvent pour des identifiants, un certificat ou une identité de pair qui ne correspond plus. Envoyer l’utilisateur réinitialiser son mot de passe pour un délai d’attente fait perdre l’après-midi à tout le monde.

Gardez la dernière configuration bonne connue à portée de main pour comparer les champs au lieu de les reconstruire. Si un champ a changé, ce changement est la trouvaille. Comparez-le champ par champ avec la configuration restaurée au lieu de lire seulement la restaurée. La plupart des surprises après une coupure sont un champ revenu silencieusement à une valeur par défaut de modèle.

Quatrième couche : testez depuis un appareil en aval

Ouvrez une ressource autorisée et inoffensive depuis un client derrière le routeur, puis confirmez quelle sortie ou route privée le trafic a réellement utilisée. Vérifiez le DNS et chaque famille d’adresses que vous prétendez couvrir, car la sonde du routeur lui-même peut réussir alors que la politique du client est encore fausse — la sonde utilise souvent une autre source, une autre table ou un autre chemin de résolution.

curl -s https://ifconfig.me
nslookup example.com

Si le tunnel est en panne et pas seulement mal configuré, décidez si les clients touchés doivent être bloqués ou peuvent utiliser une solution de repli approuvée. Ce choix relève du plan de basculement avant une coupure, pas d’un fil de discussion pendant celle-ci. Écrivez la sortie et le résolveur observés dans le ticket de coupure. Deux lignes maintenant épargnent à la personne suivante une heure de conjectures sur le chemin qui était actif pendant la fenêtre.

Quoi corriger pour que la prochaine coupure soit plus courte

Si la défaillance se répète, la correction est l’ordre, pas la configuration : montez le WAN, puis l’heure, puis le tunnel, puis la politique du client. La plupart des routeurs l’expriment comme une dépendance ou un délai, et un court délai délibéré vaut mieux qu’une réécriture du profil.

Répétez ensuite le test de redémarrage habituel une fois modifié, y compris la vérification côté client. Un test de redémarrage qui ne regarde que le tableau de bord du routeur teste la couche la moins informative des quatre.