OpenVPN-uppspelning bakåt i loggen: vad raden inte bevisar

Raden säger PID_ERR replay-window backtrack occurred, och alla sökresultat förklarar den som tappade paket och en trasig tunnel. I UDP-vägen för Community OpenVPN 2.6 skrivs meddelandet medan mottagningsfunktionen fortfarande avgör vad den ska göra med paketet. Den registrerar ett nytt maximum för bakåtspårning, sedan jämför samma funktion avståndet med fönstret och det registrerade tillståndet innan den accepterar eller avvisar. Att läsa loggetiketten som domen är felet som den här checklistan finns för att förhindra.

Stopp ett: identifiera vad raden är

Det är en diagnos om sekvensavstånd, inte ett beslut om en anslutning. Den visas i paket-ID-implementeringen vid punkten där ett nytt observerat maximum för bakåtspårning noteras. Den punkten ligger före grenen för acceptera eller avvisa, vilket är varför ett paket som utlöser den fortfarande kan levereras.

Bekräfta vilken värd som skrev den och med vilken detaljnivå. En server och en klient kan båda sända paket-ID-meddelanden, och ett meddelande från ena sidan säger ingenting om mottagningsläget på den andra.

Stopp två: hitta resultatet för det paketet

Läs raderna efter diagnosen i stället för bara diagnosen. Samma funktion fortsätter till sina fönster- och dubblettkontroller, så resultatet för just det paketet avgörs några instruktioner senare och kan mycket väl vara acceptans. Ett loggutdrag som slutar på den skrämmande raden säger ingenting om resultatet. Sök i ett fönster runt den, inte själva raden:

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

Om loggen inte visar någon avvisning för den peeren vid den tiden, sluta behandla den här raden som orsaken till avbrottet. Gå vidare till appens väg, för det är där de flesta rapporterna om ansluten men ingen trafik faktiskt slutar.

Stopp tre: avgör om omordning är verklig

Omordning är en egenskap hos vägen, och en diagnos är ett enda prov på den. Leta efter upprepade meddelanden för samma peer i ett kort fönster, och jämför med en inspelning i båda ändarna innan du drar slutsatsen att nätverket ordnar om aggressivt.

En handfull meddelanden under en återanslutning är inget märkvärdigt. Ett ständigt flöde tillsammans med verkliga app-timeouts är värt att undersöka, och den kombinationen är bevis, inte en etikett.

Stopp fyra: fönsterparametrarna, och vad de inte är

replay-window tar en sekvensstorlek och ett valfritt tidsvärde, så att bredda den ändrar två olika toleranser på en gång. Att höja talet tillåter paket som ligger längre utanför ordningen; tidsvärdet begränsar hur länge ett paket fortfarande får beaktas. Breddning är en policyändring med en säkerhetskostnad, och den förstärker inte ett chiffer och stänger inte av dubblettdetektering. De två toleranserna rör sig tillsammans, vare sig du avsåg det eller inte.

Ett gammalt autentiserat paket kan fortfarande vara en oönskad upprepning, därför behåller mottagaren dessa kontroller. Att acceptera mer omordning innebär att acceptera mer av den risken.

Att dämpa varningen med mute ändrar vad du ser, inte vad daemonen gör. Om målet är en tystare logg under en känd händelse är det ett legitimt driftval; om målet är att reparera en tunnel döljer dämpningen beviset.

mute 20
replay-window 64 15

Att byta den yttre transporten till TCP ändrar leverans- och återhämtningsbeteende och lägger till egna kostnader för blockering av köhuvudet. Det är ett designbeslut, inte ett första svar på en loggetikett. Att installera om servern är värre, eftersom det suddar ut skillnaden mellan en statistik och den gräns som faktiskt misslyckades.

Stopp fem: testa vägen användaren bryr sig om

Med tunneln ansluten, kör appens eget test och läs dess valda rutt, vidarebefordringstillstånd och returväg. En tunnel som bara bär paket i en riktning producerar inga meddelanden om bakåtspårning alls, och det är mycket vanligare än allvarlig omordning.

Skriv ner vad du mätte vid varje stopp. Registreringen är det som hindrar nästa rapport från att börja om vid den skrämmande raden och arbeta utåt därifrån.

Paket-ID-implementeringen visar ordningen för statistiken och beslutet, och handboken beskriver fönstrets sekvens- och tidsomfång. Att läsa de två tillsammans är det som förvandlar en skrämmande logglinje till en känd storhet. Ingen av dem säger något om din specifika väg, därför är mätningarna ovan fortfarande viktiga.