VPN falder under store uploads: læs køen først

Tunnelen er stabil hele dagen og falder så, hver gang en stor upload starter. Interaktive forespørgsler går i stå først, klienten rapporterer en timeout, og forbindelsen kommer tilbage, når overførslen er færdig. Det mønster peger på kødannelse og behandling frem for på, at fjernserveren er nede, for serveren fik aldrig chancen for at svare i tide. Arbejdet er at genskabe det under en kontrolleret last og aflæse de rigtige tællere.

Ændr én variabel for hver kørsel, og hold endepunktet fast.

Byg en gentagelig lastsammenligning

Optag en baseline, mens linket er i tomgang: rundturrstid, et par applikationsforespørgsler og tunnelens egen hændelseslog. Start derefter en upload af kendt størrelse, og gentag præcis de målinger, mens den kører. Hold endepunktet, klienten og testdestinationen uændrede, fordi ændringer af to af dem på én gang ikke fortæller noget.

Læg mærke til, hvilken hændelse der vises først. En stigende rundturrstid før nogen fejl tyder på kødannelse; en hård timeout med stabil latenstid tyder på noget andet, fx et nøgleskift eller en handling på kontoen. De to mønstre fører til forskellige næste skridt. Skriv observationen ned, før du ændrer noget.

Gem outputtet med tidsstempler, så den belastede og den tomme kørsel kan sammenlignes linje for linje.

Læs køen, ikke hastigheden

Forbrugerforbindelser buffer pakker i udbyderens udstyr, og en fuld opstrømskø forsinker alt, inklusive de små kontrolpakker, der holder en tunnel i live. En hastighedstest med et højt tal siger lidt om den forsinkelse, og derfor består en tomgangstest, mens et mættet link fejler.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Sammenlign latenstallene under last med dem i tomgang. Et spring fra titalls millisekunder til hundreder uden pakketab er kødannelse; tab med stabil latenstid peger på en anden fejl.

Kontroller enheden og kontrolvejen

Kryptering og videresendelse koster processortid, og en lille router eller en termisk begrænset bærbar computer kan tabe pakker, mens den er travl. Hold øje med den samlede last frem for én proces' procentdel, fordi videresendelse i kernen og afbrydelseshåndtering ikke vises der, hvor folk normalt kigger.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

En klienttimeout kan også falde sammen med et planlagt nøgleskift eller med en hændelse i sessionspolitikken. Læs klientens egen log for rækkefølgen af hændelser, ikke kun applikationens fejlmeddelelse.

Ændr én ting, og gentag

Hvor platformen understøtter det, så begræns uploadhastigheden eller klassificér bulktrafik under interaktiv trafik, så køen aldrig fyldes. Gentag derefter den samme arbejdsbyrde, og sammenlign de samme tre tal som før. En ændring, der forbedrer en hastighedstest, men lader timeouten blive, har ikke løst noget.

At hæve timeouts over hele linjen og svække krypteringen er de to ændringer, der får symptomet til at forsvinde uden at identificere den grænse, der fejlede. Ingen af dem er en reparation. Begge flytter fejlen længere frem, hvor den er sværere at henføre.

Slut af med at teste en ny forespørgsel og den genopkoblingsadfærd, brugeren faktisk er afhængig af. Stabilitet under den last, der udløste klagen, er det eneste resultat, der er værd at notere.