VPN padá při velkých nahráváních: nejdřív si přečtěte frontu

Přeplněná odchozí fronta zpožďuje řídicí provoz stejně jako aplikace. Porovnejte chování v klidu a při zátěži, pak změňte jednu věc a test zopakujte.

Tunel je celý den stabilní a pak spadne, kdykoli začne velké nahrávání. Interaktivní požadavky nejdřív zamrznou, klient hlásí vypršení časového limitu a spojení se vrátí, když přenos skončí. Ten vzorec ukazuje na frontu a zpracování, ne na to, že vzdálený server neběží, protože server nikdy nedostal šanci včas odpovědět. Úkolem je reprodukovat to pod řízenou zátěží a přečíst správné čítače.

Měňte jednu proměnnou na běh a koncový bod držte pevně.

Vytvořte opakovatelné srovnání zátěže

Zaznamenejte základní stav s nečinným spojem: dobu odezvy, několik požadavků aplikace a vlastní protokol událostí tunelu. Pak spusťte nahrávání známé velikosti a přesně ta měření opakujte, dokud běží. Koncový bod, klienta i cíl testu nechte beze změny, protože změna dvou najednou vám nic neřekne.

Všimněte si, která událost se objeví první. Rostoucí doba odezvy před jakoukoli chybou naznačuje frontu; tvrdé vypršení při stabilní latenci naznačuje něco jiného, třeba obnovu klíčů nebo zásah do účtu. Oba vzorce vedou k jiným dalším krokům. Pozorování zapište, než cokoli změníte.

Uložte výstup s časovými razítky, aby šlo zatížený a klidový běh porovnat řádek po řádku.

Čtěte frontu, ne rychlost

Spotřebitelská připojení bufferují pakety v zařízení poskytovatele a plná odchozí fronta zpožďuje všechno včetně malých řídicích paketů, které drží tunel naživu. Rychlostní test s vysokým číslem o tom zpoždění říká málo, a proto test v klidu projde, zatímco nasycené spojení selže.

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'

Porovnejte čísla latence při zátěži s čísly v klidu. Skok z desítek milisekund na stovky bez ztráty paketů je fronta; ztráta při stabilní latenci ukazuje na jinou závadu.

Zkontrolujte zařízení a řídicí cestu

Šifrování a předávání stojí procesorový čas a malý router nebo tepelně omezený notebook může při zátěži zahazovat pakety. Sledujte celkovou zátěž, ne procento jednoho procesu, protože předávání v jádru a obsluha přerušení se neobjevují tam, kam se lidé obvykle dívají.

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

Vypršení na klientu se může překrýt i s plánovanou obnovou klíčů nebo s událostí zásady relace. Přečtěte si vlastní protokol klienta kvůli pořadí událostí, ne jen chybovou zprávu aplikace.

Změňte jednu věc a opakujte

Kde to platforma podporuje, omezte rychlost nahrávání nebo zařaďte hromadný provoz pod interaktivní, aby se fronta nikdy nezaplnila. Pak zopakujte stejnou práci a porovnejte stejná tři čísla jako předtím. Změna, která zlepší rychlostní test, ale vypršení ponechá, nic neopravila.

Plošné zvýšení časových limitů a oslabení šifrování jsou dvě změny, které symptom odstraní, aniž by určily, která hranice selhala. Ani jedna není oprava. Obě posouvají selhání později, kde se přisuzuje obtížněji.

Skončete testem nového požadavku a chováním při opětovném připojení, na které uživatel skutečně spoléhá. Stabilita pod zátěží, která stížnost vyvolala, je jediný výsledek, který stojí za zapsání.

Související články