VPN valt weg bij grote uploads: lees eerst de wachtrij

De tunnel is de hele dag stabiel en valt dan weg zodra een grote upload begint. Interactieve verzoeken stokken eerst, de client meldt een time-out, en de verbinding komt terug wanneer de overdracht klaar is. Dat patroon wijst op wachtrijen en verwerking, niet op een uitgevallen externe server, want de server kreeg nooit de kans om op tijd te antwoorden. Het werk is dit onder een gecontroleerde belasting reproduceren en de juiste tellers lezen.

Verander per run één variabele en houd het eindpunt vast.

Bouw een herhaalbare belastingvergelijking

Leg een basislijn vast terwijl de verbinding in rust is: round-triptijd, een paar toepassingsverzoeken en het eigen gebeurtenislog van de tunnel. Start dan een upload van bekende grootte en herhaal precies die metingen terwijl hij loopt. Houd het eindpunt, de client en de testbestemming ongewijzigd, want twee daarvan tegelijk veranderen zegt je niets.

Let op welke gebeurtenis het eerst verschijnt. Een stijgende round-triptijd vóór elke fout wijst op wachtrijen; een harde time-out bij stabiele latentie wijst op iets anders, zoals een sleutelrotatie of een actie op het account. De twee patronen leiden tot verschillende vervolgstappen. Schrijf de waarneming op voordat je iets verandert.

Bewaar de uitvoer met tijdstempels zodat de belaste en de rustige run regel voor regel vergeleken kunnen worden.

Lees de wachtrij, niet de snelheid

Consumentenlijnen bufferen pakketten in de apparatuur van de provider, en een volle upstreamwachtrij vertraagt alles, inclusief de kleine controlepakketten die een tunnel in leven houden. Een snelheidstest met een hoog getal zegt weinig over die vertraging, en daarom slaagt een test in rust terwijl een verzadigde lijn faalt.

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'

Vergelijk de latentiecijfers onder belasting met die in rust. Een sprong van tientallen milliseconden naar honderden, zonder pakketverlies, is wachtrijen; verlies bij stabiele latentie wijst op een ander defect.

Controleer het apparaat en het controlepad

Versleuteling en doorsturen kosten processortijd, en een kleine router of een thermisch begrensde laptop kan pakketten laten vallen terwijl hij bezig is. Kijk naar de totale belasting in plaats van het percentage van één proces, want doorsturen in de kernel en interruptafhandeling verschijnen niet waar mensen meestal kijken.

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

Een time-out aan de clientzijde kan ook samenvallen met een geplande sleutelrotatie of met een gebeurtenis in het sessiebeleid. Lees het eigen log van de client voor de volgorde van gebeurtenissen, niet alleen de foutmelding van de toepassing.

Verander één ding en herhaal

Waar het platform dit ondersteunt, beperk je de uploadsnelheid of classificeer je bulkverkeer onder interactief verkeer zodat de wachtrij nooit vol raakt. Herhaal dan dezelfde werklast en vergelijk dezelfde drie getallen als voorheen. Een wijziging die een snelheidstest verbetert maar de time-out laat staan, heeft niets gerepareerd.

Time-outs overal verhogen en versleuteling verzwakken zijn de twee wijzigingen die het symptoom laten verdwijnen zonder de grens te benoemen die faalde. Geen van beide is een reparatie. Beide schuiven het falen naar later, waar het moeilijker toe te schrijven is.

Sluit af met het testen van een nieuw verzoek en het herverbindingsgedrag waar de gebruiker echt op vertrouwt. Stabiliteit onder de belasting die de klacht veroorzaakte, is het enige resultaat dat het opschrijven waard is.