OpenVPN-bagudsporing i loggen: hvad linjen ikke beviser

Linjen siger PID_ERR replay-window backtrack occurred, og alle søgeresultater forklarer det som tabte pakker og en brudt tunnel. I Community OpenVPN 2.6's UDP-sti skrives den besked, mens modtagefunktionen stadig beslutter, hvad den skal gøre med pakken. Den registrerer et nyt maksimum for bagudsporing, og derefter sammenligner samme funktion afstanden med vinduet og den registrerede tilstand, før den accepterer eller afviser. At læse logetiketten som dommen er den fejl, denne tjekliste findes for at forhindre.

Stop et: identificer, hvad linjen er

Det er en diagnosticering af sekvensafstand, ikke en beslutning om en forbindelse. Den optræder i pakke-ID-implementeringen på det punkt, hvor et nyligt observeret maksimum for bagudsporing noteres. Det punkt ligger før forgreningen for accept eller afvisning, og derfor kan en pakke, der udløser det, stadig blive leveret.

Bekræft, hvilken vært der skrev den, og med hvilken detaljeringsgrad. En server og en klient kan begge udsende pakke-ID-beskeder, og en besked fra den ene side siger intet om den anden sides modtagetilstand.

Stop to: find resultatet for den pakke

Læs linjerne efter diagnosticeringen i stedet for kun diagnosticeringen. Samme funktion fortsætter til sine vindues- og dubletkontroller, så resultatet for netop den pakke afgøres få instruktioner senere og er meget vel accept. Et loguddrag, der slutter ved den skræmmende linje, fortæller intet om resultatet. Søg i et vindue omkring den, ikke selve linjen:

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

Hvis loggen ikke viser nogen afvisning for den peer på det tidspunkt, så hold op med at behandle denne linje som årsagen til afbrydelsen. Gå videre til appens sti, for det er der, de fleste rapporter om forbundet men ingen trafik faktisk ender.

Stop tre: afgør, om omordning er virkelig

Omordning er en egenskab ved stien, og én diagnosticering er en enkelt prøve på den. Se efter gentagne beskeder for samme peer i et kort vindue, og sammenlign med en optagelse i begge ender, før du konkluderer, at netværket omordner aggressivt.

En håndfuld beskeder under en genopkobling er intet særligt. En vedvarende strøm sammen med reelle app-timeouts er værd at undersøge, og den kombination er bevis, ikke en etiket.

Stop fire: vinduesparametrene, og hvad de ikke er

replay-window tager en sekvensstørrelse og en valgfri tidsværdi, så en udvidelse ændrer to forskellige tolerancer på én gang. At hæve tallet tillader pakker, der er længere ude af rækkefølge; tidsværdien begrænser, hvor længe en pakke stadig kan overvejes. Udvidelse er en politikændring med en sikkerhedsomkostning, og den styrker ikke en cipher eller deaktiverer dubletregistrering. De to tolerancer bevæger sig sammen, uanset om du havde til hensigt det eller ej.

En gammel autentificeret pakke kan stadig være en uønsket gentagelse, og derfor beholder modtageren disse kontroller. At acceptere mere omordning betyder at acceptere mere af den risiko.

At dæmpe advarslen med mute ændrer, hvad du ser, ikke hvad dæmonen gør. Hvis målet er en roligere log under en kendt hændelse, er det et legitimt driftsvalg; hvis målet er at reparere en tunnel, skjuler dæmpning beviset.

mute 20
replay-window 64 15

At skifte den ydre transport til TCP ændrer leverings- og genopretningsadfærd og tilføjer sine egne omkostninger ved blokering af køens hoved. Det er en designbeslutning, ikke et første svar på én logetiket. At geninstallere serveren er værre, fordi det sletter forskellen mellem en statistik og den grænse, der faktisk fejlede.

Stop fem: test den sti, brugeren bekymrer sig om

Med tunnelen forbundet kører du appens egen test og læser dens valgte rute, videresendelsestilstand og retursti. En tunnel, der kun bærer pakker i én retning, producerer slet ingen beskeder om bagudsporing, og det er langt mere almindeligt end alvorlig omordning.

Skriv ned, hvad du målte ved hvert stop. Registreringen er det, der forhindrer den næste rapport i at begynde igen ved den skræmmende linje og arbejde udad derfra.

Pakke-ID-implementeringen viser rækkefølgen af statistikken og beslutningen, og manualen beskriver vinduets sekvens- og tidsomfang. At læse de to sammen er det, der gør en skræmmende loglinje til en kendt størrelse. Ingen af dem siger noget om din specifikke sti, og derfor er målingerne ovenfor stadig vigtige.