VPN faller under store opplastinger: les køen først

Tunnelen er stabil hele dagen og faller så hver gang en stor opplasting starter. Interaktive forespørsler stopper først, klienten rapporterer tidsavbrudd, og forbindelsen kommer tilbake når overføringen er ferdig. Mønsteret peker på køing og behandling, ikke på at fjernserveren er nede, fordi serveren aldri fikk sjansen til å svare i tide. Arbeidet er å gjenskape dette under kontrollert last og lese de riktige tellerne.

Endre én variabel per kjøring, og hold endepunktet fast.

Bygg en repeterbar lastsammenligning

Ta opp en basislinje mens linken er i tomgang: rundturtid, noen få applikasjonsforespørsler og tunnelens egen hendelseslogg. Start deretter en opplasting av kjent størrelse og gjenta nøyaktig de målingene mens den kjører. Hold endepunktet, klienten og testmålet uendret, fordi å endre to av dem samtidig ikke forteller deg noe.

Legg merke til hvilken hendelse som vises først. En stigende rundturtid før noen feil tyder på køing; en hard tidsavbrudd med stabil latenstid tyder på noe annet, som en nøkkelrotasjon eller en handling på kontoen. De to mønstrene fører til ulike neste steg. Skriv ned observasjonen før du endrer noe.

Lagre utdataene med tidsstempler slik at den belastede og den tomme kjøringen kan sammenlignes linje for linje.

Les køen, ikke hastigheten

Forbrukerlinjer bufrer pakker i leverandørens utstyr, og en full oppstrømskø forsinker alt, også de små kontrollpakkene som holder en tunnel i live. En hastighetstest med høyt tall sier lite om den forsinkelsen, og derfor består en tomgangstest mens en mettet link feiler.

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 sprang fra titalls millisekunder til hundrevis uten pakketap er køing; tap med stabil latenstid peker på en annen feil.

Kontroller enheten og kontrollveien

Kryptering og videresending koster prosessortid, og en liten ruter eller en termisk begrenset bærbar PC kan miste pakker mens den er opptatt. Følg med på den samlede lasten i stedet for prosentandelen til én prosess, fordi videresending i kjernen og avbruddsbehandling ikke vises der folk vanligvis ser.

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

En klienttidsavbrudd kan også falle sammen med en planlagt nøkkelrotasjon eller med en hendelse i sesjonspolicyen. Les klientens egen logg for rekkefølgen av hendelser, ikke bare applikasjonens feilmelding.

Endre én ting og gjenta

Der plattformen støtter det, begrens opplastingshastigheten eller klassifiser massetrafikk under interaktiv trafikk slik at køen aldri fylles. Gjenta deretter samme arbeidslast og sammenlign de samme tre tallene som før. En endring som forbedrer en hastighetstest men lar tidsavbruddet stå, har ikke reparert noe.

Å heve tidsavbrudd over hele linjen og svekke krypteringen er de to endringene som får symptomet til å forsvinne uten å identifisere hvilken grense som feilet. Ingen av dem er en reparasjon. Begge flytter feilen senere, der den er vanskeligere å tilskrive.

Avslutt med å teste en ny forespørsel og den gjenoppkoblingsatferden brukeren faktisk er avhengig av. Stabilitet under lasten som utløste klagen, er det eneste resultatet som er verdt å notere.