P_CONTROL_HARD_RESET_CLIENT_V2 i loggen: är det ett fel?

Raden upprepas med några sekunders mellanrum och ser ut som orsaken till allt: ett paket som heter control hard reset, som kommer från en klient som aldrig når någonstans. Det är inte ett fel. Det är det första meddelandet i en ny session, och upprepningen är ett symptom på att något annat misslyckas längre fram. Att skilja vad etiketten säger från vad anslutningen gjorde efteråt är hela diagnosen.

Opkoden namnger en position i protokollet

OpenVPN multiplexar flera typer av paket över en socket, och opkoden talar om för mottagaren vilken typ den håller i. Hårdåterställningspaket öppnar en session, kontrollpaket bär handskakningsmaterial, bekräftelser bekräftar mottagande och datapaket bär tunnelns nyttolast. Att läsa den första byten visar var paketet hör hemma i det utbytet, och paketdefinitionerna i källkoden namnger varje familj uttryckligen.

Det är allt den säger. Ett paket märkt som en inledande klientåterställning bevisar att paketet nådde din observationspunkt och att motparten vill inleda en session. Det bevisar inte att klienten litade på ditt certifikat, att dess inloggningsuppgifter godtogs eller att en datakanal någonsin blev användbar.

Ändelsen V2 är en markör för protokollgeneration för den paketfamiljen, inte en produktversion och inte en inställning du installerar. Ingenting i namnet handlar om att återställa en tunnel, starta om en tjänst eller tömma en cache.

Vad klienten faktiskt gör i det ögonblicket

Klienten öppnar en sessionsidentifierare som båda ändar knyter den fortsatta kontrolltrafiken till. När skyddet för kontrollkanalen är konfigurerat bär det första paketet redan HMAC som låter mottagaren avgöra om det är värt att lägga kraft på resten av utbytet. En mottagare som inte kan verifiera den släpper paketet tyst, och därför ser en felaktig delad nyckel ut som en klient som talar ut i tomma luften.

Ingenting användarsynligt har hänt ännu. Inget certifikat har validerats, inget användarnamn har erbjudits och ingen tunneladress har tilldelats. Återställningen är handskakningens förord, så varje bedömning av anslutningen är förhastad här.

För en ledig återanslutningsslinga är den intressanta detaljen intervallet. En klient som försöker igen i fast cykel utan framsteg avvisas vanligen innan den kan komma vidare, och orsaken står i motpartens logg, inte i paketnamnet.

Var det verkliga felet gömmer sig efter återställningen

Läs de två loggarna sida vid sida och hitta den första händelsen som inte är en återställning. Hos klienten rapporteras ett certifikatvalideringsfel med det konkreta skälet: ett utgånget certifikat, ett namn som inte stämmer eller en okänd utfärdare. Hos servern rapporteras ett avvisande av inloggningsuppgifter som ett autentiseringsfel med sitt eget skäl. Båda är långt mer konkreta än serverns upprepade blick på nya försök.

Matcha ett försök efter tidsstämpeln i stället för att läsa varje logg isolerat, eftersom samma fel dyker upp på båda ställena med olika ordalydelse och olika allvar. Motparten som ger upp anger vanligen varför.

Om ingen av sidorna rapporterar avvisande och utbytet ändå stoppar är gränsen nåbarhet och inte tillit. En brandvägg som släpper returriktningen, en enhet för nätverksadressöversättning vars mappning löper ut, eller ett MTU-problem som dödar större handskakningspaket ger alla ett fastlåst utbyte helt utan autentiseringsfel.

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

Den sökningen är inte en diagnos i sig, men den flyttar dig från protokollvokabulär till en faktisk felklass i ett steg.

Varför avstängd verifiering är fel reflex

När återställningen fortsätter att dyka upp är den till synes snabbaste åtgärden att stänga av certifikatvalidering eller ge upp skyddet för kontrollkanalen så att något ansluter. Det byter ett diagnostiserbart fel mot ett odiagnostiserbart och lämnar driftsättningen att acceptera motparter den byggdes för att avvisa.

Ändra i stället den gräns som faktiskt svek. Ett tillitsproblem hör till certifikatmyndigheten och den profil som refererar till den. Ett tidsproblem hör till klockan. Ett inloggningsproblem hör till autentiseringsbackenden som avvisade det, och en onåbar motpart hör till vägen mellan de två värdarna.

Opkoden är nyttig i ett supportssamtal för en sak: den säger att motparten kom tillräckligt långt för att försöka. Det som hände efteråt är det du behöver veta, och det står i den logg som registrerar det första konkreta avvisandet. Börja där, och återställningsraden slutar se ut som en orsak och börjar se ut som en tidsstämpel.