OpenVPN-herhaal-backtrack in het log: wat de regel niet bewijst
Het backtrackbericht wordt geschreven vóór de beslissing om te accepteren of te weigeren. Volg zes haltes: identificeer de regel, vind de uitkomst en test dan het pad van de app.
De regel zegt PID_ERR replay-window backtrack occurred, en alle zoekresultaten verklaren het als weggevallen pakketten en een kapotte tunnel. In het UDP-pad van Community OpenVPN 2.6 wordt dat bericht geschreven terwijl de ontvangstfunctie nog beslist wat er met het pakket moet gebeuren. Het registreert een nieuw maximum aan backtrack, daarna vergelijkt dezelfde functie de afstand met het venster en de vastgelegde toestand voordat ze accepteert of weigert. Het loglabel als het vonnis lezen is de fout die deze checklist wil voorkomen.
Halte één: identificeer wat de regel is
Het is een diagnose over sequentieafstand, geen beslissing over een verbinding. Het verschijnt in de pakket-ID-implementatie op het punt waar een nieuw waargenomen maximum aan backtrack wordt genoteerd. Dat punt ligt vóór de vertakking voor accepteren of weigeren, waardoor een pakket dat dit veroorzaakt alsnog kan worden afgeleverd.
Bevestig welke host het schreef en met welk detailniveau. Een server en een client kunnen beide pakket-ID-berichten uitzenden, en een bericht van de ene kant zegt niets over de ontvangsttoestand van de andere.
Halte twee: vind de uitkomst voor dat pakket
Lees de regels ná de diagnose in plaats van alleen de diagnose. Dezelfde functie gaat verder naar haar venster- en duplicaatcontroles, dus de uitkomst voor dat specifieke pakket wordt een paar instructies later beslist en kan heel goed acceptatie zijn. Een logfragment dat bij de enge regel eindigt, zegt niets over de uitkomst. Zoek een venster eromheen, niet de regel zelf:
journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"Als het log op dat moment geen weigering voor die peer toont, stop dan met deze regel als oorzaak van de storing te behandelen. Ga verder naar het pad van de app, want daar eindigen de meeste meldingen van verbonden maar geen verkeer in werkelijkheid.
Halte drie: beslis of herordening echt is
Herordening is een eigenschap van het pad, en één diagnose is er één enkele steekproef van. Zoek herhaalde berichten voor dezelfde peer binnen een kort venster, en vergelijk met een opname aan beide uiteinden voordat je concludeert dat het netwerk agressief herordent.
Een handvol berichten tijdens een herverbinding is niets bijzonders. Een aanhoudende stroom naast echte app-time-outs is het onderzoeken waard, en die combinatie is bewijs, geen etiket.
Halte vier: de vensterparameters, en wat ze niet zijn
replay-window neemt een sequentiegrootte en een optionele tijdwaarde, dus het verbreden ervan verandert twee verschillende toleranties tegelijk. Het getal verhogen staat pakketten toe die verder buiten de volgorde liggen; de tijdwaarde begrenst hoe lang een pakket nog mag worden beschouwd. Verbreden is een beleidswijziging met een beveiligingskosten, en het versterkt geen cijfer en schakelt geen duplicaatdetectie uit. De twee toleranties bewegen samen, of je dat nu bedoelde of niet.
Een oud geauthenticeerd pakket kan nog steeds een ongewenste herhaling zijn, daarom houdt de ontvanger deze controles. Meer herordening accepteren betekent meer van dat risico accepteren.
De waarschuwing dempen met mute verandert wat je ziet, niet wat de daemon doet. Als het doel een rustiger log tijdens een bekend evenement is, is dat een legitieme operationele keuze; als het doel is een tunnel te repareren, verbergt dempen het bewijs.
mute 20
replay-window 64 15Het buitenste transport naar TCP omzetten verandert het aflever- en herstelgedrag en voegt eigen kosten voor het blokkeren van de wachtrijkop toe. Het is een ontwerpbeslissing, geen eerste reactie op één loglabel. De server opnieuw installeren is erger, omdat het het onderscheid wist tussen een statistiek en de grens die werkelijk faalde.
Halte vijf: test het pad dat de gebruiker belangrijk vindt
Met de tunnel verbonden, voer de eigen test van de app uit en lees de gekozen route, de doorstuurstaat en het retourpad. Een tunnel die pakketten maar in één richting draagt, levert helemaal geen backtrackberichten op, en dat is veel gewoner dan ernstige herordening.
Schrijf op wat je bij elke halte hebt gemeten. Het verslag is wat voorkomt dat het volgende rapport weer bij de enge regel begint en van daaruit naar buiten werkt.
De pakket-ID-implementatie toont de volgorde van de statistiek en de beslissing, en de handleiding beschrijft de sequentie- en tijdscope van het venster. Beide samen lezen is wat een eng logregel in een bekende grootheid verandert. Geen van beide zegt iets over jouw specifieke pad, daarom blijven de metingen hierboven belangrijk.