Retour arrière de rejeu OpenVPN dans le journal : ce que la ligne ne prouve pas

La ligne dit PID_ERR replay-window backtrack occurred, et tous les résultats de recherche l'expliquent comme des paquets perdus et un tunnel cassé. Dans le chemin UDP de Community OpenVPN 2.6, ce message est écrit pendant que la fonction de réception décide encore quoi faire du paquet. Elle enregistre un nouveau maximum de retour arrière, puis la même fonction compare la distance à la fenêtre et à l'état enregistré avant d'accepter ou de rejeter. Lire l'étiquette du journal comme le verdict est l'erreur que cette liste de contrôle existe pour éviter.

Étape un : identifiez ce qu'est la ligne

C'est un diagnostic sur la distance de séquence, pas une décision sur une connexion. Il apparaît dans l'implémentation de l'ID de paquet au point où un maximum de retour arrière récemment observé est noté. Ce point se situe avant la branche d'acceptation ou de rejet, ce qui explique qu'un paquet qui le déclenche puisse encore être livré.

Confirmez quel hôte l'a écrit et avec quel niveau de détail. Un serveur et un client peuvent tous deux émettre des messages d'ID de paquet, et un message d'un côté ne dit rien de l'état de réception de l'autre.

Étape deux : trouvez le résultat pour ce paquet

Lisez les lignes qui suivent le diagnostic plutôt que le diagnostic seul. La même fonction poursuit vers ses contrôles de fenêtre et de doublons, si bien que le résultat pour ce paquet précis est décidé quelques instructions plus tard et peut fort bien être l'acceptation. Un extrait de journal qui s'arrête à la ligne effrayante ne vous dit rien du résultat. Cherchez une fenêtre autour d'elle, pas la ligne elle-même :

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

Si le journal ne montre aucun rejet pour ce pair à ce moment-là, cessez de traiter cette ligne comme la cause de la panne. Passez au chemin de l'application, car c'est là que la plupart des rapports connecté mais sans trafic se terminent réellement.

Étape trois : décidez si la réorganisation est réelle

La réorganisation est une propriété du chemin, et un diagnostic n'en est qu'un seul échantillon. Cherchez des messages répétés pour le même pair sur une courte fenêtre et comparez-les à une capture aux deux extrémités avant de conclure que le réseau réorganise agressivement.

Une poignée de messages pendant une reconnexion n'a rien d'extraordinaire. Un flux continu accompagné de vrais délais d'expiration applicatifs mérite une enquête, et cette combinaison est une preuve, pas une étiquette.

Étape quatre : les paramètres de fenêtre, et ce qu'ils ne sont pas

replay-window prend une taille de séquence et une valeur de temps facultative, si bien que l'élargir change deux tolérances différentes à la fois. Augmenter le nombre admet des paquets plus éloignés de l'ordre ; la valeur de temps borne combien de temps un paquet peut encore être pris en compte. L'élargissement est un changement de politique avec un coût de sécurité, et il ne renforce pas un chiffrement ni ne désactive la détection des doublons. Les deux tolérances bougent ensemble, que vous l'ayez voulu ou non.

Un ancien paquet authentifié peut encore être une répétition indésirable, c'est pourquoi le récepteur conserve ces contrôles. Accepter plus de réorganisation signifie accepter davantage de ce risque.

Mettre l'avertissement en sourdine avec mute change ce que vous voyez, pas ce que fait le démon. Si l'objectif est un journal plus calme pendant un événement connu, c'est un choix opérationnel légitime ; si l'objectif est de réparer un tunnel, la sourdine cache la preuve.

mute 20
replay-window 64 15

Passer le transport externe à TCP change le comportement de livraison et de récupération et ajoute ses propres coûts de blocage en tête de file. C'est une décision de conception, pas une première réponse à une étiquette de journal. Réinstaller le serveur est pire, car cela efface la distinction entre une statistique et la frontière qui a réellement échoué.

Étape cinq : testez le chemin qui compte pour l'utilisateur

Tunnel connecté, lancez le test propre à l'application et lisez sa route sélectionnée, son état de transfert et son chemin de retour. Un tunnel qui ne transporte des paquets que dans un sens ne produit aucun message de retour arrière, et c'est bien plus courant qu'une réorganisation sévère.

Notez ce que vous avez mesuré à chaque étape. L'enregistrement est ce qui empêche le rapport suivant de recommencer à la ligne effrayante et de travailler vers l'extérieur depuis là.

L'implémentation de l'ID de paquet montre l'ordre de la statistique et de la décision, et le manuel décrit la portée de séquence et de temps de la fenêtre. Lire les deux ensemble est ce qui transforme une ligne de journal effrayante en une grandeur connue. Aucune des deux ne dit quoi que ce soit de votre chemin précis, c'est pourquoi les mesures ci-dessus comptent encore.