P_CONTROL_HARD_RESET_CLIENT_V2 in die log: is dit 'n fout?

Die reël herhaal elke paar sekondes en lyk soos die oorsaak van alles: 'n pakkie met die naam control hard reset wat van 'n kliënt kom wat nooit enige plek bereik nie. Dit is nie 'n fout nie. Dit is die eerste boodskap van 'n nuwe sessie, en die herhaling is 'n simptoom van iets anders wat verder aan misluk. Om te skei wat die etiket sê van wat die verbinding daarna gedoen het, is die hele diagnose.

Die opkode benoem 'n posisie in die protokol

OpenVPN multipleks verskeie soorte pakkies oor een sok, en die opkode vertel die ontvanger watter soort dit vashou. Hard-reset-pakkies begin 'n sessie, beheerpakkies dra handskudmateriaal, bevestigings bevestig ontvangs, en datapakkies dra die tonnelvrag. Om die eerste greep te lees, sê jou waar in daardie uitruiling die pakkie hoort, en die opstroom-pakkie-definisies noem elke familie eksplisiet.

Dit is al wat dit sê. 'n Pakkie wat as 'n aanvanklike kliënt-terugstelling gemerk is, bewys dat die pakkie jou waarnemingspunt bereik het en dat die eweknie 'n sessie wil begin. Dit bewys nie dat die kliënt jou sertifikaat vertrou het nie, dat sy geloofsbriewe aanvaar is nie, of dat 'n datakanaal ooit bruikbaar geword het nie.

Die V2-agtervoegsel is 'n protokolgenerasie-merker vir daardie pakkiefamilie, nie 'n produkweergawe nie en nie 'n instelling wat jy installeer nie. Niks in die naam verwys na die terugstel van 'n tonnel, die herbegin van 'n diens of die skoonmaak van 'n kas nie.

Wat die kliënt op daardie oomblik werklik doen

Die kliënt open 'n sessie-identifiseerder waaraan beide kante hulle daaropvolgende beheerverkeer sal heg. Met beheerkanaalbeskerming opgestel, dra daardie eerste pakkie reeds die HMAC wat die ontvanger laat besluit of hy enige moeite aan die res van die uitruiling moet spandeer. 'n Ontvanger wat dit nie kan verifieer nie, laat die pakkie stil val, en daarom lyk 'n verkeerde gedeelde sleutel soos 'n kliënt wat in 'n leemte praat.

Niks sigbaar vir die gebruiker het nog gebeur nie. Geen sertifikaat is gevalideer nie, geen gebruikersnaam is aangebied nie en geen tonneladres is toegewys nie. Die terugstelling is die handskud se inleiding, so enige oordeel oor die verbinding op hierdie punt is voortydig.

Vir 'n ledige herverbindingslus is die interval die interessante besonderheid. 'n Kliënt wat op 'n vaste siklus herprobeer sonder om te vorder, word gewoonlik verwerp voordat hy kan aanbeweeg, en die rede staan in die eweknie se log, nie in die pakkie se naam nie.

Waar die werklike fout na die terugstelling wegkruip

Lees die twee logs langs mekaar en vind die eerste gebeurtenis wat nie 'n terugstelling is nie. By die kliënt word 'n sertifikaatvalideringsfout met die spesifieke rede gerapporteer: 'n vervalde sertifikaat, 'n naamwanpassing of 'n onbekende uitreiker. By die bediener word 'n geloofsbriefverwerping as 'n verifikasiefout met sy eie rede gerapporteer. Albei is baie meer spesifiek as die bediener se herhaalde siening van nuwe pogings.

Pas een poging volgens tydstempel, eerder as om elke log afsonderlik te lees, want dieselfde fout verskyn op albei plekke met ander bewoording en ander erns. Die eweknie wat opgee, sê gewoonlik hoekom.

As nie een van die kante verwerping rapporteer nie en die uitruiling steeds vasdraai, is die grens bereikbaarheid eerder as vertroue. 'n Brandmuur wat die terugrigting laat val, 'n netwerkadresvertalingsapparaat wat die kartering laat verval, of 'n MTU-probleem wat groter handskudpakkies doodmaak, lewer almal 'n gestaakte uitruiling sonder enige verifikasiefout.

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

Daardie soektog is nie op sigself 'n diagnose nie, maar dit beweeg jou in een stap van protokolwoordeskat na 'n werklike foutklas.

Waarom die verwydering van verifikasie die verkeerde refleks is

Wanneer die terugstelling aanhou verskyn, is die vinnigste oënskynlike oplossing om sertifikaatverifikasie te deaktiveer of die beheerkanaalbeskerming te laat vaar sodat iets kan koppel. Dit ruil 'n diagnoseerbare fout vir 'n ondiagnoseerbare een, en dit laat die ontplooiing eweknieë aanvaar wat dit gebou is om te weier.

Verander eerder die grens wat werklik gefaal het. 'n Vertrouensprobleem hoort by die sertifikaatowerheid en die profiel wat daarna verwys. 'n Tydprobleem hoort by die horlosie. 'n Geloofsbriefprobleem hoort by die verifikasie-agterkant wat dit verwerp het, en 'n onbereikbare eweknie hoort by die pad tussen die twee gashere.

Die opkode is in 'n ondersteuningsgesprek vir een ding nuttig: dit sê vir jou die eweknie het ver genoeg gekom om te probeer. Wat daarna gebeur het, is wat jy moet weet, en dit staan in watter log ook al die eerste spesifieke verwerping opteken. Begin daar, en die terugstellingsreël hou op om soos 'n oorsaak te lyk en begin soos 'n tydstempel lyk.