P_CONTROL_HARD_RESET_CLIENT_V2 i loggen: er det en feil?

Linjen gjentas hvert par sekunder og ser ut som årsaken til alt: en pakke kalt control hard reset, som kommer fra en klient som aldri når noe sted. Det er ikke en feil. Det er den første meldingen i en ny økt, og gjentakelsen er et symptom på at noe annet svikter lenger fremme. Å skille det etiketten sier fra det tilkoblingen gjorde etterpå er hele diagnosen.

Opkoden navngir en posisjon i protokollen

OpenVPN multiplekser flere pakketyper over én socket, og opkoden forteller mottakeren hvilken type den holder. Hard-reset-pakker åpner en økt, kontrollpakker bærer håndtrykksmateriale, bekreftelser bekrefter mottak, og datapakker bærer tunnelens nyttelast. Å lese den første byten viser hvor pakken hører hjemme i den utvekslingen, og pakkedefinisjonene i kildekoden navngir hver familie eksplisitt.

Det er alt den sier. En pakke merket som en innledende klient-reset beviser at pakken nådde observasjonspunktet ditt og at motparten vil starte en økt. Den beviser ikke at klienten stolte på sertifikatet ditt, at påloggingsinformasjonen ble godtatt, eller at en datakanal noen gang ble brukbar.

Endelsen V2 er en protokollgenerasjonsmarkør for den pakkefamilien, ikke en produktversjon og ikke en innstilling du installerer. Ingenting i navnet viser til å nullstille en tunnel, starte en tjeneste på nytt eller tømme en hurtigbuffer.

Hva klienten faktisk gjør i det øyeblikket

Klienten åpner en øktidentifikator som begge ender vil knytte den videre kontrolltrafikken til. Når beskyttelse av kontrollkanalen er konfigurert, bærer den første pakken allerede HMAC-en som lar mottakeren avgjøre om det er verdt å bruke krefter på resten av utvekslingen. En mottaker som ikke kan verifisere den, slipper pakken stille, og derfor ser en feil delt nøkkel ut som en klient som snakker ut i tomrommet.

Ingenting brukervisibelt har skjedd ennå. Ingen sertifikater er validert, ingen brukernavn er tilbudt og ingen tunneladresse er tildelt. Reset er håndtrykkets forord, så enhver dom om tilkoblingen på dette punktet er forhastet.

For en ledig gjenoppkoblingssløyfe er den interessante detaljen intervallet. En klient som prøver på nytt i fast syklus uten fremgang, blir vanligvis avvist før den kan komme videre, og grunnen står i motpartens logg, ikke i pakkenavnet.

Hvor den egentlige feilen skjuler seg etter reset

Les de to loggene side om side og finn den første hendelsen som ikke er en reset. Hos klienten rapporteres en sertifikatvalideringsfeil med den konkrete grunnen: et utløpt sertifikat, et navneavvik eller en ukjent utsteder. Hos serveren rapporteres en avvisning av påloggingsinformasjon som en autentiseringsfeil med sin egen grunn. Begge er langt mer konkrete enn serverens gjentatte syn på nye forsøk.

Match ett forsøk etter tidsstemplet i stedet for å lese hver logg isolert, fordi den samme feilen dukker opp begge steder med ulik ordlyd og ulik alvorlighet. Motparten som gir opp, oppgir vanligvis hvorfor.

Hvis ingen av sidene rapporterer avvisning og utvekslingen likevel stopper, er grensen nåbarhet og ikke tillit. En brannmur som slipper returretningen, en enhet for nettverksadresseoversettelse der kartleggingen utløper, eller et MTU-problem som dreper større håndtrykkspakker, gir alle en fastlåst utveksling helt uten autentiseringsfeil.

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

Det søket er ikke en diagnose i seg selv, men det flytter deg fra protokollordforråd til en faktisk feilklasse i ett trinn.

Hvorfor det å slå av verifiseringen er den gale refleksen

Når reset fortsetter å dukke opp, er den tilsynelatende raskeste rettelsen å slå av sertifikatvalidering eller gi opp beskyttelsen av kontrollkanalen slik at noe kobler til. Det bytter en diagnostiserbar feil mot en udiagnostiserbar, og lar utrullingen godta motparter den ble bygget for å avvise.

Endre i stedet grensen som faktisk sviktet. Et tillitsproblem hører til sertifikatmyndigheten og profilen som refererer til den. Et tidsproblem hører til klokken. Et påloggingsproblem hører til autentiserings-backenden som avviste det, og en utilgjengelig motpart hører til veien mellom de to vertene.

Opkoden er nyttig i en støttesamtale for én ting: den forteller at motparten kom langt nok til å prøve. Det som skjedde etterpå, er det du trenger å vite, og det står i den loggen som registrerer den første konkrete avvisningen. Begynn der, og reset-linjen slutter å se ut som en årsak og begynner å se ut som et tidsstempel.