P_CONTROL_HARD_RESET_CLIENT_V2 im Log: ein Fehler?

Die Zeile wiederholt sich alle paar Sekunden und sieht wie die Ursache von allem aus: ein Paket namens control hard reset, das von einem Client kommt, der nirgendwo ankommt. Es ist kein Fehler. Es ist die erste Nachricht einer neuen Sitzung, und die Wiederholung ist ein Symptom dafür, dass weiter hinten etwas anderes scheitert. Zu trennen, was das Etikett sagt, von dem, was die Verbindung danach tat, ist die ganze Diagnose.

Der Opcode benennt eine Position im Protokoll

OpenVPN bündelt mehrere Paketarten über einen Socket, und der Opcode sagt dem Empfänger, welche Art er in der Hand hat. Hard-Reset-Pakete eröffnen eine Sitzung, Kontrollpakete tragen Handshake-Material, Bestätigungen bestätigen den Empfang, und Datenpakete tragen die Nutzlast des Tunnels. Das erste Byte zu lesen zeigt, wohin das Paket in diesem Austausch gehört, und die Paketdefinitionen im Quellcode benennen jede Familie ausdrücklich.

Das ist alles, was er sagt. Ein als anfänglicher Client-Reset bezeichnetes Paket beweist, dass das Paket Ihren Beobachtungspunkt erreicht hat und dass der Peer eine Sitzung beginnen will. Es beweist nicht, dass der Client Ihrem Zertifikat vertraut hat, dass seine Anmeldedaten akzeptiert wurden oder dass je ein Datenkanal nutzbar wurde.

Das Suffix V2 ist eine Protokollgenerationsmarke für diese Paketfamilie, keine Produktversion und keine Einstellung, die Sie installieren. Nichts im Namen bezieht sich auf das Zurücksetzen eines Tunnels, den Neustart eines Dienstes oder das Leeren eines Caches.

Was der Client in diesem Moment tatsächlich tut

Der Client eröffnet eine Sitzungskennung, an die beide Seiten den weiteren Kontrollverkehr hängen. Ist der Schutz des Kontrollkanals konfiguriert, trägt dieses erste Paket bereits den HMAC, der den Empfänger entscheiden lässt, ob er für den Rest des Austauschs Aufwand investiert. Ein Empfänger, der ihn nicht prüfen kann, verwirft das Paket still, weshalb ein falscher gemeinsamer Schlüssel wie ein Client aussieht, der ins Leere spricht.

Für den Benutzer sichtbar ist noch nichts passiert. Kein Zertifikat wurde validiert, kein Benutzername angeboten und keine Tunneladresse zugewiesen. Der Reset ist die Präambel des Handshakes, also ist jedes Urteil über die Verbindung an dieser Stelle verfrüht.

Bei einer untätigen Wiederverbindungsschleife ist das Interesse weckende Detail der Abstand. Ein Client, der in festem Takt ohne Fortschritt erneut versucht, wird meist abgewiesen, bevor er weiterkommt, und der Grund steht im Log des Peers, nicht im Paketnamen.

Wo der eigentliche Fehler nach dem Reset steckt

Lesen Sie die beiden Logs nebeneinander und finden Sie das erste Ereignis, das kein Reset ist. Beim Client wird ein Zertifikatsprüfungsfehler mit dem konkreten Grund gemeldet: ein abgelaufenes Zertifikat, eine Namensabweichung oder ein unbekannter Aussteller. Beim Server wird eine Ablehnung der Anmeldedaten als Authentifizierungsfehler mit eigenem Grund gemeldet. Beides ist weit konkreter als die wiederholte Sicht des Servers auf neue Versuche.

Gleichen Sie einen Versuch über den Zeitstempel ab, statt jedes Log isoliert zu lesen, denn derselbe Fehler erscheint an beiden Stellen mit anderer Formulierung und anderer Schwere. Der Peer, der aufgibt, nennt meist den Grund.

Wenn keine Seite eine Ablehnung meldet und der Austausch trotzdem stockt, ist die Grenze die Erreichbarkeit und nicht das Vertrauen. Eine Firewall, die die Rückrichtung verwirft, ein Netzwerkadressübersetzer, dessen Zuordnung abläuft, oder ein MTU-Problem, das größere Handshake-Pakete tötet, erzeugen alle einen stockenden Austausch ganz ohne Authentifizierungsfehler.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

Diese Suche ist für sich genommen keine Diagnose, aber sie bringt Sie in einem Schritt vom Protokollvokabular zu einer tatsächlichen Fehlerklasse.

Warum das Abschalten der Prüfung der falsche Reflex ist

Wenn der Reset weiter erscheint, ist die scheinbar schnellste Lösung, die Zertifikatsprüfung abzuschalten oder den Schutz des Kontrollkanals fallenzulassen, damit sich etwas verbindet. Das tauscht einen diagnostizierbaren Fehler gegen einen nicht diagnostizierbaren und lässt die Installation Peers annehmen, für deren Ablehnung sie gebaut wurde.

Ändern Sie stattdessen die Grenze, die tatsächlich versagt hat. Ein Vertrauensproblem gehört zur Zertifizierungsstelle und zum Profil, das sie referenziert. Ein Zeitproblem gehört zur Uhr. Ein Anmeldedatenproblem gehört zum Authentifizierungs-Backend, das es abgelehnt hat, und ein unerreichbarer Peer gehört zum Pfad zwischen den beiden Hosts.

Der Opcode ist in einem Supportgespräch für eine Sache nützlich: Er sagt Ihnen, dass der Peer weit genug gekommen ist, um es zu versuchen. Was danach geschah, ist das, was Sie wissen müssen, und es steht in dem Log, das die erste konkrete Ablehnung festhält. Fangen Sie dort an, und die Reset-Zeile hört auf, wie eine Ursache auszusehen, und beginnt, wie ein Zeitstempel auszusehen.