VPN padá pri veľkých nahrávaniach: najprv si prečítajte front

Preplnený odchádzajúci front zdržiava riadiacu prevádzku rovnako ako aplikácie. Porovnajte správanie v pokoji a pri záťaži, potom zmeňte jednu vec a test zopakujte.

Tunel je celý deň stabilný a potom padne vždy, keď sa začne veľké nahrávanie. Interaktívne požiadavky najprv zamrznú, klient hlási vypršanie časového limitu a spojenie sa vráti, keď sa prenos skončí. Ten vzorec ukazuje na front a spracovanie, nie na to, že vzdialený server nebeží, pretože server nikdy nedostal šancu včas odpovedať. Úlohou je reprodukovať to pod riadenou záťažou a prečítať správne počítadlá.

Meňte jednu premennú na beh a koncový bod držte pevne.

Vytvorte opakovateľné porovnanie záťaže

Zaznamenajte základnú líniu s nečinným spojením: čas obehu, niekoľko požiadaviek aplikácie a vlastný protokol udalostí tunela. Potom spustite nahrávanie známej veľkosti a presne tie merania opakujte, kým beží. Koncový bod, klienta aj cieľ testu nechajte nezmenené, pretože zmena dvoch naraz vám nič nepovie.

Všimnite si, ktorá udalosť sa objaví prvá. Rastúci čas obehu pred akoukoľvek chybou naznačuje front; tvrdé vypršanie pri stabilnej latencii naznačuje niečo iné, napríklad obnovu kľúčov alebo zásah do účtu. Oba vzorce vedú k iným ďalším krokom. Pozorovanie si zapíšte, skôr než čokoľvek zmeníte.

Uložte výstup s časovými značkami, aby sa zaťažený a pokojový beh dali porovnať riadok po riadku.

Čítajte front, nie rýchlosť

Spotrebiteľské pripojenia ukladajú pakety do zariadenia poskytovateľa a plný odchádzajúci front zdržiava všetko vrátane malých riadiacich paketov, ktoré držia tunel nažive. Rýchlostný test s vysokým číslom o tom zdržaní hovorí málo, a preto test v pokoji prejde, kým nasýtené spojenie zlyhá.

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'

Porovnajte čísla latencie pri záťaži s číslami v pokoji. Skok z desiatok milisekúnd na stovky bez straty paketov je front; strata pri stabilnej latencii ukazuje na inú poruchu.

Skontrolujte zariadenie a riadiacu cestu

Šifrovanie a preposielanie stoja procesorový čas a malý router alebo tepelne obmedzený notebook môže pri záťaži zahadzovať pakety. Sledujte celkovú záťaž, nie percento jedného procesu, pretože preposielanie v jadre a obsluha prerušení sa neobjavujú tam, kam sa ľudia zvyčajne pozerajú.

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

Vypršanie na klientovi sa môže prekryť aj s plánovanou obnovou kľúčov alebo s udalosťou zásady relácie. Prečítajte si vlastný protokol klienta kvôli poradiu udalostí, nielen chybovú správu aplikácie.

Zmeňte jednu vec a zopakujte

Kde to platforma podporuje, obmedzte rýchlosť nahrávania alebo zaradte hromadnú prevádzku pod interaktívnu, aby sa front nikdy nezaplnil. Potom zopakujte rovnakú prácu a porovnajte tie isté tri čísla ako predtým. Zmena, ktorá zlepší rýchlostný test, ale vypršanie ponechá, nič neopravila.

Plošné zvýšenie časových limitov a oslabenie šifrovania sú dve zmeny, ktoré odstránia príznak bez toho, aby určili, ktorá hranica zlyhala. Ani jedna nie je oprava. Obe posúvajú zlyhanie neskôr, kde sa prisudzuje ťažšie.

Skončite testom novej požiadavky a správaním pri opätovnom pripojení, na ktoré sa používateľ skutočne spolieha. Stabilita pod záťažou, ktorá vyvolala sťažnosť, je jediný výsledok, ktorý stojí za zapísanie.

Súvisiace články