P_CONTROL_HARD_RESET_CLIENT_V2 i loggen: er det en fejl?

Linjen gentages hvert par sekunder og ligner årsagen til alt: en pakke med navnet control hard reset, der kommer fra en klient, som aldrig når nogen steder hen. Det er ikke en fejl. Det er den første meddelelse i en ny session, og gentagelsen er et symptom på noget andet, der svigter længere fremme. At skelne mellem hvad etiketten siger, og hvad forbindelsen gjorde bagefter, er hele diagnosen.

Opkoden angiver en placering i protokollen

OpenVPN multiplekser flere slags pakker over én socket, og opkoden fortæller modtageren, hvilken slags den holder. Hard-reset-pakker åbner en session, kontrolpakker bærer handshake-materiale, bekræftelser bekræfter modtagelse, og datapakker bærer tunnellens nyttelast. At læse den første byte viser, hvor i den udveksling pakken hører til, og pakkedefinitionerne i kildekoden navngiver hver familie eksplicit.

Det er alt, den siger. En pakke mærket som et indledende klient-reset beviser, at pakken nåede dit observationspunkt, og at modparten vil begynde en session. Den beviser ikke, at klienten stolede på dit certifikat, at dens login blev accepteret, eller at en datakanal nogensinde blev brugbar.

Endelsen V2 er en protokolgenerationsmarkør for den pakkefamilie, ikke en produktversion og ikke en indstilling, du installerer. Intet i navnet handler om at nulstille en tunnel, genstarte en tjeneste eller tømme en cache.

Hvad klienten faktisk gør i det øjeblik

Klienten åbner en sessionsidentifikator, som begge ender vil knytte den efterfølgende kontroltrafik til. Når beskyttelse af kontrolkanalen er konfigureret, bærer den første pakke allerede HMAC'en, som lader modtageren afgøre, om der skal bruges kræfter på resten af udvekslingen. En modtager, der ikke kan verificere den, dropper pakken lydløst, og derfor ligner en forkert delt nøgle en klient, der taler ud i tomheden.

Intet brugersynligt er sket endnu. Intet certifikat er valideret, intet brugernavn er tilbudt, og ingen tunneladresse er tildelt. Reset er handshakens indledning, så enhver dom om forbindelsen på dette tidspunkt er forhastet.

For en ledig genopkoblingsløkke er den interessante detalje intervallet. En klient, der prøver igen i en fast cyklus uden at komme videre, bliver normalt afvist, før den kan avancere, og årsagen står i modpartens log og ikke i pakkens navn.

Hvor den egentlige fejl gemmer sig efter reset

Læs de to logge side om side og find den første hændelse, der ikke er et reset. På klienten rapporteres en certifikatvalideringsfejl med den konkrete årsag: et udløbet certifikat, et navnemismatch eller en ukendt udsteder. På serveren rapporteres en afvisning af login som en godkendelsesfejl med sin egen årsag. Begge er langt mere konkrete end serverens gentagne syn på nye forsøg.

Match ét forsøg på tidsstemplet i stedet for at læse hver log isoleret, for den samme fejl optræder begge steder med forskellig ordlyd og forskellig alvor. Den modpart, der giver op, angiver normalt hvorfor.

Hvis ingen af siderne rapporterer afvisning, og udvekslingen stadig går i stå, er grænsen nåbarhed og ikke tillid. En firewall, der dropper returretningen, en enhed til netværksadresseoversættelse, hvis mapping udløber, eller et MTU-problem, der dræber større handshakepakker, giver alle en fastlåst udveksling helt uden godkendelsesfejl.

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

Den søgning er ikke en diagnose i sig selv, men den flytter dig fra protokolordforråd til en faktisk fejlklasse i ét trin.

Hvorfor det er den forkerte refleks at fjerne verifikationen

Når reset fortsætter med at dukke op, er den hurtigste tilsyneladende rettelse at slå certifikatvalidering fra eller opgive beskyttelsen af kontrolkanalen, så noget kan forbinde. Det bytter en diagnosticerbar fejl for en udiagnosticerbar og efterlader udrulningen med at acceptere modparter, den blev bygget til at afvise.

Ændr i stedet den grænse, der faktisk svigtede. Et tillidsproblem hører til certifikatmyndigheden og den profil, der henviser til den. Et tidsproblem hører til uret. Et loginproblem hører til den godkendelsesbackend, der afviste det, og en unåelig modpart hører til vejen mellem de to værter.

Opkoden er nyttig i en supportssamtale til én ting: den fortæller, at modparten kom langt nok til at prøve. Hvad der skete bagefter, er det, du har brug for at vide, og det står i den log, der registrerer den første konkrete afvisning. Start der, og reset-linjen holder op med at ligne en årsag og begynder at ligne et tidsstempel.