Linjen sier PID_ERR replay-window backtrack occurred, og alle søkeresultater forklarer det som droppede pakker og en ødelagt tunnel. I UDP-stien til Community OpenVPN 2.6 skrives denne meldingen mens mottaksfunksjonen fortsatt bestemmer hva den skal gjøre med pakken. Den registrerer et nytt maksimum for bakover sporing, og deretter sammenligner samme funksjon avstanden med vinduet og den registrerte tilstanden før den aksepterer eller avviser. Å lese loggetiketten som dommen er feilen denne sjekklisten finnes for å hindre.

Stopp én: identifiser hva linjen er

Det er en diagnose om sekvensavstand, ikke en beslutning om en tilkobling. Den vises i pakke-ID-implementasjonen på punktet der et nylig observert maksimum for bakover sporing noteres. Det punktet ligger før grenen for aksept eller avvisning, og derfor kan en pakke som utløser det fortsatt leveres.

Bekreft hvilken vert som skrev den, og med hvilken detaljgrad. En server og en klient kan begge sende pakke-ID-meldinger, og en melding fra den ene siden sier ingenting om mottakstilstanden på den andre.

Stopp to: finn resultatet for den pakken

Les linjene etter diagnosen i stedet for bare diagnosen. Samme funksjon fortsetter til vindu- og duplikatkontrollene, så resultatet for akkurat den pakken avgjøres noen instruksjoner senere og kan godt være aksept. Et logguddrag som slutter på den skumle linjen, sier ingenting om resultatet. Søk i et vindu rundt den, ikke selve linjen:

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

Hvis loggen ikke viser noen avvisning for den peeren på det tidspunktet, slutt å behandle denne linjen som årsaken til avbruddet. Gå videre til appens sti, for det er der de fleste rapportene om tilkoblet men ingen trafikk faktisk ender.

Stopp tre: avgjør om omordning er reell

Omordning er en egenskap ved stien, og én diagnose er en enkelt prøve på den. Se etter gjentatte meldinger for samme peer i et kort vindu, og sammenlign med en opptak i begge ender før du konkluderer med at nettverket omordner aggressivt.

En håndfull meldinger under en gjenoppkobling er ikke noe spesielt. En vedvarende strøm sammen med reelle app-timeout er verdt å undersøke, og den kombinasjonen er bevis, ikke en etikett.

Stopp fire: vindusparametrene, og hva de ikke er

replay-window tar en sekvensstørrelse og en valgfri tidsverdi, så utvidelse endrer to forskjellige toleranser på én gang. Å øke tallet tillater pakker som er lenger ute av rekkefølge; tidsverdien begrenser hvor lenge en pakke fortsatt kan vurderes. Utvidelse er en policyendring med en sikkerhetskostnad, og den styrker ikke en cipher eller deaktiverer duplikatdeteksjon. De to toleransene beveger seg sammen, enten du mente det eller ikke.

En gammel autentisert pakke kan fortsatt være en uønsket gjentakelse, derfor beholder mottakeren disse kontrollene. Å akseptere mer omordning betyr å akseptere mer av den risikoen.

Å dempe advarselen med mute endrer hva du ser, ikke hva daemonen gjør. Hvis målet er en roligere logg under en kjent hendelse, er det et legitimt operasjonelt valg; hvis målet er å reparere en tunnel, skjuler demping beviset.

mute 20
replay-window 64 15

Å bytte den ytre transporten til TCP endrer leverings- og gjenopprettingsatferd og legger til egne kostnader ved blokkering av køhodet. Det er en designbeslutning, ikke et første svar på én loggetikett. Å installere serveren på nytt er verre, fordi det sletter skillet mellom en statistikk og grensen som faktisk sviktet.

Stopp fem: test stien brukeren bryr seg om

Med tunnelen tilkoblet, kjør appens egen test og les den valgte ruten, videresendingstilstanden og returveien. En tunnel som bare bærer pakker i én retning produserer ingen meldinger om bakover sporing i det hele tatt, og det er langt vanligere enn alvorlig omordning.

Skriv ned hva du målte ved hvert stopp. Registreringen er det som hindrer neste rapport i å begynne på nytt ved den skumle linjen og arbeide utover derfra.

Pakke-ID-implementasjonen viser rekkefølgen til statistikken og beslutningen, og håndboken beskriver vinduets sekvens- og tidsomfang. Å lese de to sammen er det som gjør en skummel logglinje til en kjent størrelse. Ingen av dem sier noe om din spesifikke sti, derfor er målingene ovenfor fortsatt viktige.

Relaterte artikler