Keepalive ist kein Reconnect: Wählen Sie nach dem Fehlerbild

Keepalives und Reconnects werden im selben Atemzug konfiguriert und lösen unterschiedliche Probleme, weshalb das Justieren des einen das andere selten repariert. Ein Keepalive sendet kleinen Verkehr, um einen Zustandseintrag am Leben zu halten oder um zu bemerken, dass ein Peer nicht mehr antwortet. Ein Reconnect reißt ab, was kaputt ist, und baut die Beziehung neu auf, einschließlich Schlüsseln, Adressen und Routen. Wählen Sie den Mechanismus, der zum Fehlerbild passt, nicht den, dessen Regler Sie schon kennen. Zwei Fragen entscheiden es: Ist der Pfad tot, oder vergisst etwas zwischen den Peers ihn?

Wenn die Zuordnung das Problem ist

Ein Tunnel, der erst nach Minuten der Stille stirbt, verliert meist einen Übersetzungseintrag und nicht einen Peer. WireGuards PersistentKeepalive existiert für NAT- und Firewall-Zustand, und die eigenen Notizen des Projekts beschreiben es genau so und nicht als Gesundheitsprüfung. Ein Intervall von einigen zehn Sekunden hält einen Eintrag warm, während ein Paket pro Sekunde eine Batterieentscheidung ist und keine Zuverlässigkeitsentscheidung. OpenVPN kommt über ping und ping-restart zum selben Ergebnis, die zuerst die Stille bemerken und dann darauf reagieren.

Diese Einstellungen sind auch nicht zwischen Protokollen austauschbar. Eine IKEv2-Richtlinie für tote Peers, ein OpenVPN-Ping-Timer und ein WireGuard-Keepalive beantworten dieselbe Frage mit drei verschiedenen Syntaxen und drei verschiedenen Standardwerten, sodass das Kopieren einer Zahl zwischen ihnen Raten ist, das sich als Tuning verkleidet.

Wenn die Beziehung weg ist

Wenn der Peer die Adresse wechselt, die Berechtigung abläuft oder die Gegenseite neu startet, sind kleine Pakete nicht die Reparatur. Der Reconnect muss Zustand neu aufbauen : eine Adresse beziehen, Routen neu installieren, Schlüssel neu verhandeln und in manchen Umgebungen einen Benutzer erneut authentifizieren.

Clients, die unbeaufsichtigt neu verbinden, halten ein Zertifikat oder ein gespeichertes Geheimnis. Ein Client, der einen Menschen fragen würde, scheitert genau dann, wenn niemand da ist, und das ist das Szenario, in dem der Reconnect zählte. Das ist eine Designentscheidung von vor Monaten und keine Einstellung, die Sie während einer Störung ändern können.

Was keines von beiden beweist

Ein Tunnel kann neu verbunden, verschlüsselt und geroutet sein, während der Dienst dahinter ausgefallen ist, und ein Keepalive kann eine Zuordnung für eine Sitzung offen halten, deren Server seit Stunden weg ist. Beide Mechanismen können Erfolg melden, während das, worum es Ihnen eigentlich geht, nicht verfügbar ist.

Deshalb endet der Test bei einer echten Anfrage. Senden Sie nach dem Intervall, das Ihnen wichtig ist, etwas durch den Tunnel und lösen Sie dann getrennt den Fehler aus, für den Sie entworfen haben: eine Leerlaufphase für den Zuordnungsfall, einen Neustart oder eine Adressänderung für den Reconnect-Fall.

Direkten Verkehr zu blockieren ist eine eigene Entscheidung

Eine Reconnect-Schleife kann völlig gesund sein, während eine Anwendung still die gewöhnliche Route nutzt, und das ist ein Leck und kein Fehler. Wenn die Anforderung lautet, dass nichts außerhalb des Tunnels hinausgeht, sagen Sie das ausdrücklich in der Client-Konfiguration und beweisen Sie es, indem Sie den Tunnel abbauen und beobachten, was sich noch verbindet. Keiner der Mechanismen impliziert dieses Verhalten, und keine Wiederholungsdisziplin etabliert es.

Halten Sie fest, welcher Mechanismus lief und ob danach eine neue Anfrage erfolgreich war. Diese beiden Fakten braucht der nächste Ingenieur, und keines davon ist in einem Statussymbol sichtbar. Eine Logzeile, die sagt, der Client habe sich neu verbunden, ist nicht dasselbe wie eine Anfrage, die funktioniert hat.

Schreiben Sie die Richtlinie, nicht nur die Zahl

Fassen Sie das Paar in einen Satz: das Leerlaufintervall, die Liveness-Schwelle, was einen Neuaufbau auslöst , und was der Client tut, während er es erneut versucht. Ohne diesen Satz eröffnet jeder künftige Vorfall dieselbe Debatte, ob das Keepalive zu kurz oder der Reconnect zu langsam ist.

WireGuards Hinweise zu Einschränkungen sind eine nützliche Erinnerung, dass das Keepalive ein Umweg für Middleboxes ist und kein allgemeines Liveness-Design. Lesen Sie diese Einschränkung, bevor Sie die Frequenz als Antwort auf ein Problem erhöhen, das sie nicht lösen kann.