VPN fell under store opplastingar: les køen først

Tunnelen er stabil heile dagen og fell så kvar gong ei stor opplasting startar. Interaktive førespurnader stoppar først, klienten rapporterer tidsavbrot, og sambandet kjem tilbake når overføringa er ferdig. Mønsteret peikar på køing og handsaming, ikkje på at fjertenaren er nede, fordi tenaren aldri fekk sjansen til å svare i tide. Arbeidet er å gjenskape dette under kontrollert last og lese dei rette teljarane.

Endre éin variabel per køyring, og hald endepunktet fast.

Bygg ein repeterbar lastsamanlikning

Ta opp ei grunnlinje medan lenka er i tomgang: rundturtid, nokre få applikasjonsførespurnader og den eigne hendingsloggen til tunnelen. Start deretter ei opplasting av kjend storleik og gjenta nøyaktig dei målingane medan ho køyrer. Hald endepunktet, klienten og testmålet uendra, fordi å endre to av dei samstundes ikkje fortel deg noko.

Legg merke til kva hending som viser seg først. Ei stigande rundturtid før nokon feil tyder på køing; eit hardt tidsavbrot med stabil latenstid tyder på noko anna, som ein nøkkelrotasjon eller ei handling på kontoen. Dei to mønstera fører til ulike neste steg. Skriv ned observasjonen før du endrar noko.

Lagre utdataa med tidsstempel slik at den belasta og den tomme køyringa kan samanliknast linje for linje.

Les køen, ikkje hastigheita

Forbrukarlinjer bufrer pakkar i utstyret til leverandøren, og ein full oppstraumskø forseinkar alt, også dei små kontrollpakkane som held ein tunnel i live. Ein hastigheitstest med høgt tal seier lite om den forseinkinga, og difor går ein tomgangstest gjennom medan ei metta lenke feilar.

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'

Samanlikn latenstala under last med dei i tomgang. Eit sprang frå titals millisekund til hundrevis utan pakketap er køing; tap med stabil latenstid peikar på ein annan feil.

Kontroller eininga og kontrollvegen

Kryptering og vidaresending kostar prosessortid, og ein liten ruter eller ein termisk avgrensa berbar PC kan miste pakkar medan han er opptatt. Følg med på den samla lasta i staden for prosentdelen til éin prosess, fordi vidaresending i kjernen og avbrotshandtering ikkje viser seg der folk vanlegvis ser.

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

Eit klienttidsavbrot kan også falle saman med ein planlagd nøkkelrotasjon eller med ei hending i sesjonspolicyen. Les den eigne loggen til klienten for rekkjefølgja av hendingar, ikkje berre feilmeldinga til applikasjonen.

Endre éin ting og gjenta

Der plattforma støttar det, avgrens opplastingshastigheita eller klassifiser massetrafikk under interaktiv trafikk slik at køen aldri blir full. Gjenta deretter same arbeidslasta og samanlikn dei same tre tala som før. Ei endring som betrar ein hastigheitstest men lèt tidsavbrotet stå, har ikkje reparert noko.

Å heve tidsavbrot over heile linja og svekkje krypteringa er dei to endringane som får symptomet til å forsvinne utan å identifisere kva grense som feila. Ingen av dei er ein reparasjon. Begge flyttar feilen seinare, der han er vanskelegare å tilskrive.

Avslutt med å teste ein ny førespurnad og den gjenoppkoplingsåtferda brukaren faktisk er avhengig av. Stabilitet under lasta som utløyste klaga, er det einaste resultatet som er verdt å notere.