P_CONTROL_HARD_RESET_CLIENT_V2 in het log: is het een fout?

De regel herhaalt zich elke paar seconden en lijkt de oorzaak van alles: een pakket met de naam control hard reset, afkomstig van een client die nergens aankomt. Het is geen fout. Het is het eerste bericht van een nieuwe sessie, en de herhaling is een symptoom van iets anders dat verderop mislukt. Het scheiden van wat het label zegt en wat de verbinding daarna deed, is de hele diagnose.

De opcode benoemt een positie in het protocol

OpenVPN multiplext meerdere soorten pakketten over één socket, en de opcode vertelt de ontvanger welk soort hij vasthoudt. Hard-reset-pakketten openen een sessie, controlepakketten dragen handshake-materiaal, bevestigingen bevestigen ontvangst en datapakketten dragen de payload van de tunnel. Het eerste byte lezen laat zien waar het pakket in die uitwisseling hoort, en de pakketdefinities in de broncode noemen elke familie expliciet.

Dat is alles wat het zegt. Een pakket dat als een eerste client-reset is gelabeld, bewijst dat het pakket uw observatiepunt bereikte en dat de peer een sessie wil beginnen. Het bewijst niet dat de client uw certificaat vertrouwde, dat zijn inloggegevens werden geaccepteerd, of dat een datakanaal ooit bruikbaar werd.

Het achtervoegsel V2 is een protocolgeneratiemarkering voor die pakketfamilie, geen productversie en geen instelling die u installeert. Niets in de naam verwijst naar het resetten van een tunnel, het herstarten van een dienst of het leegmaken van een cache.

Wat de client op dat moment werkelijk doet

De client opent een sessie-identificatie waaraan beide uiteinden het volgende controleverkeer koppelen. Wanneer de bescherming van het controlekanaal is geconfigureerd, draagt dat eerste pakket al de HMAC die de ontvanger laat beslissen of het de moeite loont zich met de rest van de uitwisseling bezig te houden. Een ontvanger die hem niet kan verifiëren, laat het pakket stil vallen, en daarom lijkt een verkeerde gedeelde sleutel op een client die in het niets spreekt.

Er is nog niets zichtbaars voor de gebruiker gebeurd. Er is geen certificaat gevalideerd, geen gebruikersnaam aangeboden en geen tunneladres toegewezen. De reset is de inleiding van de handshake, dus elk oordeel over de verbinding is op dit punt voorbarig.

Voor een lege herverbindingslus is het interessante detail het interval. Een client die in een vaste cyclus opnieuw probeert zonder vooruitgang wordt meestal geweigerd voordat hij verder kan, en de reden staat in het log van de peer, niet in de pakketnaam.

Waar de echte fout zich na de reset verstopt

Lees de twee logs naast elkaar en zoek de eerste gebeurtenis die geen reset is. Aan de clientkant wordt een certificaatvalidatiefout gemeld met de specifieke reden: een verlopen certificaat, een naam die niet overeenkomt of een onbekende uitgever. Aan de serverkant wordt een weigering van inloggegevens gemeld als een authenticatiefout met zijn eigen reden. Beide zijn veel specifieker dan de herhaalde blik van de server op nieuwe pogingen.

Koppel één poging op tijdstempel in plaats van elk log afzonderlijk te lezen, omdat dezelfde fout op beide plaatsen met andere bewoording en andere ernst verschijnt. De peer die opgeeft, noemt meestal waarom.

Als geen van beide kanten een weigering meldt en de uitwisseling toch stokt, is de grens bereikbaarheid en niet vertrouwen. Een firewall die de retourrichting laat vallen, een apparaat voor netwerkadresvertaling waarvan de mapping verloopt, of een MTU-probleem dat grotere handshake-pakketten doodt, leveren allemaal een stokkende uitwisseling op zonder enige authenticatiefout.

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

Die zoekopdracht is op zichzelf geen diagnose, maar ze verplaatst u in één stap van protocolvocabulaire naar een echte foutklasse.

Waarom verificatie uitschakelen de verkeerde reflex is

Wanneer de reset blijft verschijnen, is de ogenschijnlijk snelste oplossing certificaatvalidatie uitschakelen of de bescherming van het controlekanaal opgeven zodat er iets verbindt. Dat ruilt een diagnoseerbare fout in voor een niet-diagnoseerbare, en laat de uitrol peers accepteren die hij gebouwd was om te weigeren.

Wijzig in plaats daarvan de grens die werkelijk faalde. Een vertrouwensprobleem hoort bij de certificaatautoriteit en het profiel dat ernaar verwijst. Een tijdprobleem hoort bij de klok. Een inlogprobleem hoort bij de authenticatie-backend die het weigerde, en een onbereikbare peer hoort bij het pad tussen de twee hosts.

De opcode is in een supportgesprek voor één ding nuttig: hij vertelt u dat de peer ver genoeg kwam om het te proberen. Wat daarna gebeurde, is wat u moet weten, en het staat in het log dat de eerste concrete weigering vastlegt. Begin daar, en de resetregel houdt op op een oorzaak te lijken en begint op een tijdstempel te lijken.