VPN tappar förbindelsen vid stora uppladdningar: läs kön först

Tunneln är stabil hela dagen och tappar sedan förbindelsen varje gång en stor uppladdning startar. Interaktiva förfrågningar stannar först, klienten rapporterar timeout, och anslutningen kommer tillbaka när överföringen är klar. Mönstret pekar på köbildning och bearbetning, inte på att fjärrservern är nere, eftersom servern aldrig fick chansen att svara i tid. Arbetet är att återskapa detta under kontrollerad last och läsa rätt räknare.

Ändra en variabel per körning och håll ändpunkten fast.

Bygg en repeterbar lastjämförelse

Registrera en baslinje medan länken är i vila: svarstid tur och retur, några applikationsförfrågningar och tunnelns egen händelselogg. Starta sedan en uppladdning av känd storlek och upprepa exakt de mätningarna medan den körs. Håll ändpunkten, klienten och testmålet oförändrade, eftersom att ändra två av dem samtidigt inte säger dig något.

Notera vilken händelse som dyker upp först. En stigande svarstid före något fel tyder på köbildning; en hård timeout med stabil latens tyder på något annat, som en nyckelrotation eller en åtgärd på kontot. De två mönstren leder till olika nästa steg. Skriv ner observationen innan du ändrar något.

Spara utdata med tidsstämplar så att den belastade och den tomma körningen kan jämföras rad för rad.

Läs kön, inte hastigheten

Konsumentlänkar buffrar paket i leverantörens utrustning, och en full uppströmskö fördröjer allt, även de små kontrollpaketen som håller en tunnel vid liv. Ett hastighetstest med högt tal säger lite om den fördröjningen, och därför lyckas ett test i vila medan en mättad länk misslyckas.

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'

Jämför latenssiffrorna under last med dem i vila. Ett hopp från tiotal millisekunder till hundratals utan paketförlust är köbildning; förlust med stabil latens pekar på ett annat fel.

Kontrollera enheten och kontrollvägen

Kryptering och vidarebefordran kostar processortid, och en liten router eller en termiskt begränsad bärbar dator kan tappa paket medan den är upptagen. Följ den totala lasten i stället för procenten för en process, eftersom vidarebefordran i kärnan och avbrottshantering inte syns där folk brukar titta.

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 också sammanfalla med en schemalagd nyckelrotation eller med en händelse i sessionsprincipen. Läs klientens egen logg för ordningen på händelserna, inte bara applikationens felmeddelande.

Ändra en sak och upprepa

Där plattformen stöder det, begränsa uppladdningshastigheten eller klassa bulktrafik under interaktiv trafik så att kön aldrig fylls. Upprepa sedan samma arbetsbelastning och jämför samma tre siffror som tidigare. En ändring som förbättrar ett hastighetstest men lämnar timeouten har inte reparerat något.

Att höja timeouts överallt och försvaga krypteringen är de två ändringarna som får symtomet att försvinna utan att identifiera vilken gräns som brast. Ingen av dem är en reparation. Båda flyttar felet senare, där det är svårare att tillskriva.

Avsluta med att testa en ny förfrågan och det återanslutningsbeteende som användaren faktiskt förlitar sig på. Stabilitet under den last som utlöste klagomålet är det enda resultat som är värt att anteckna.