OpenVPN-Rücksprung im Protokoll: Was die Zeile nicht beweist

Die Zeile lautet PID_ERR replay-window backtrack occurred, und alle Suchergebnisse erklären sie als verworfene Pakete und einen defekten Tunnel. Im UDP-Pfad von Community OpenVPN 2.6 wird diese Meldung geschrieben, während die Empfangsfunktion noch entscheidet, was mit dem Paket geschehen soll. Sie verzeichnet einen neuen Höchstwert des Rücksprungs, dann vergleicht dieselbe Funktion den Abstand mit dem Fenster und dem aufgezeichneten Zustand, bevor sie annimmt oder verwirft. Das Log-Etikett als Urteil zu lesen ist der Fehler, den diese Checkliste verhindern soll.

Station eins: Bestimmen Sie, was die Zeile ist

Sie ist eine Diagnose zum Sequenzabstand, keine Entscheidung über eine Verbindung. Sie erscheint in der Paket-ID-Implementierung an der Stelle, an der ein neu beobachteter Höchstwert des Rücksprungs vermerkt wird. Diese Stelle liegt vor der Verzweigung zum Annehmen oder Verwerfen, weshalb ein Paket, das sie auslöst, dennoch zugestellt werden kann.

Bestätigen Sie, welcher Host sie geschrieben hat und mit welcher Ausführlichkeit. Ein Server und ein Client können beide Paket-ID-Meldungen ausgeben, und eine Meldung von einer Seite sagt nichts über den Empfangszustand der anderen aus.

Station zwei: Finden Sie das Ergebnis für dieses Paket

Lesen Sie die Zeilen nach der Diagnose statt nur die Diagnose. Dieselbe Funktion läuft weiter in ihre Fenster- und Duplikatprüfungen, sodass das Ergebnis für genau dieses Paket wenige Anweisungen später entschieden wird und durchaus Annahme sein kann. Ein Protokollauszug, der bei der erschreckenden Zeile endet, sagt nichts über das Ergebnis. Durchsuchen Sie ein Fenster darum herum, nicht die Zeile selbst:

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

Wenn das Protokoll zu diesem Zeitpunkt keine Ablehnung für diesen Peer zeigt, hören Sie auf, diese Zeile als Ursache des Ausfalls zu behandeln. Gehen Sie weiter zum Pfad der Anwendung, denn dort enden die meisten Berichte über verbunden, aber ohne Verkehr tatsächlich.

Station drei: Entscheiden Sie, ob Umsortierung real ist

Umsortierung ist eine Eigenschaft des Pfades, und eine Diagnose ist eine einzelne Stichprobe davon. Suchen Sie nach wiederholten Meldungen für denselben Peer in einem kurzen Fenster und vergleichen Sie sie mit einem Mitschnitt an beiden Enden, bevor Sie schließen, dass das Netzwerk aggressiv umsortiert.

Eine Handvoll Meldungen während einer Wiederverbindung ist unauffällig. Ein fortlaufender Strom neben echten Anwendungs-Zeitüberschreitungen ist eine Untersuchung wert, und diese Kombination ist ein Beweis, kein Etikett.

Station vier: Die Fensterparameter und was sie nicht sind

replay-window nimmt eine Sequenzgröße und einen optionalen Zeitwert, sodass eine Erweiterung zwei verschiedene Toleranzen zugleich verändert. Eine höhere Zahl lässt Pakete zu, die weiter außer der Reihe sind; der Zeitwert begrenzt, wie lange ein Paket noch berücksichtigt werden darf. Erweiterung ist eine Richtlinienänderung mit Sicherheitskosten, und sie stärkt weder eine Verschlüsselung noch deaktiviert sie die Duplikaterkennung. Die beiden Toleranzen bewegen sich zusammen, ob beabsichtigt oder nicht.

Ein altes authentifiziertes Paket kann noch eine unerwünschte Wiederholung sein, deshalb behält der Empfänger diese Prüfungen. Mehr Umsortierung zu akzeptieren bedeutet, mehr von diesem Risiko zu akzeptieren.

Die Warnung mit mute stumm zu schalten ändert, was Sie sehen, nicht was der Daemon tut. Ist das Ziel ein ruhigeres Protokoll während eines bekannten Ereignisses, ist das eine legitime Betriebsentscheidung; geht es um die Reparatur eines Tunnels, verdeckt Stummschalten den Beweis.

mute 20
replay-window 64 15

Den äußeren Transport auf TCP umzustellen ändert Zustell- und Wiederherstellungsverhalten und fügt eigene Kosten für das Blockieren des Warteschlangenkopfes hinzu. Das ist eine Designentscheidung, keine erste Reaktion auf ein Protokolletikett. Den Server neu zu installieren ist schlimmer, weil es den Unterschied zwischen einer Statistik und der Grenze verwischt, die tatsächlich versagt hat.

Station fünf: Prüfen Sie den Pfad, der dem Benutzer wichtig ist

Führen Sie bei verbundenem Tunnel den eigenen Test der Anwendung aus und lesen Sie ihre gewählte Route, ihren Weiterleitungszustand und ihren Rückweg. Ein Tunnel, der Pakete nur in eine Richtung befördert, erzeugt überhaupt keine Rücksprungmeldungen, und das ist weit häufiger als starke Umsortierung.

Notieren Sie, was Sie an jeder Station gemessen haben. Der Bericht ist es, der den nächsten Bericht daran hindert, wieder bei der erschreckenden Zeile zu beginnen und sich von dort nach außen zu arbeiten.

Die Paket-ID-Implementierung zeigt die Reihenfolge von Statistik und Entscheidung, und das Handbuch beschreibt den Sequenz- und Zeitbereich des Fensters. Beides zusammen zu lesen macht aus einer erschreckenden Protokollzeile eine bekannte Größe. Keines von beiden sagt etwas über Ihren konkreten Pfad, weshalb die obigen Messungen weiterhin zählen.