VPN nutrūksta didelių įkėlimų metu: pirmiausia skaitykite eilę

Tunelis visą dieną stabilus, o paskui nutrūksta, kai tik prasideda didelis įkėlimas. Interaktyvios užklausos pirmiausia užstringa, klientas praneša apie skirtąjį laiką, o ryšys grįžta, kai perkėlimas baigiasi. Šis modelis rodo eilę ir apdorojimą, o ne tai, kad nuotolinis serveris neveikia, nes serveriui niekada nebuvo suteikta galimybė laiku atsakyti. Darbas – atkurti tai kontroliuojamos apkrovos sąlygomis ir perskaityti teisingus skaitiklius.

Keiskite vieną kintamąjį per bandymą, o galinį tašką laikykite fiksuotą.

Sukurkite pakartojamą apkrovos palyginimą

Užfiksuokite bazinę liniją, kai ryšys tuščias: kelionės pirmyn ir atgal laiką, kelias programų užklausas ir paties tunelio įvykių žurnalą. Tada pradėkite žinomo dydžio įkėlimą ir tiksliai pakartokite tuos matavimus, kol jis vyksta. Galinį tašką, klientą ir testo paskirties vietą palikite nepakeistus, nes pakeitus du iš jų iš karto nieko nesužinosite.

Atkreipkite dėmesį, kuris įvykis pasirodo pirmas. Didėjantis kelionės pirmyn ir atgal laikas prieš bet kokią klaidą rodo eilę; griežtas skirtasis laikas esant stabiliai delsai rodo ką kita, pavyzdžiui, raktų atnaujinimą ar veiksmą paskyroje. Du modeliai veda prie skirtingų tolesnių žingsnių. Užrašykite stebėjimą prieš ką nors keisdami.

Išsaugokite išvestį su laiko žymomis, kad apkrautas ir tuščias bandymai būtų lyginami eilutė po eilutės.

Skaitykite eilę, o ne greitį

Vartotojų linijos kaupia paketus tiekėjo įrangoje, o pilna siuntimo eilė vėlina viską, įskaitant mažus valdymo paketus, kurie palaiko tunelį gyvą. Greičio testas, rodantis didelį skaičių, mažai pasako apie tą vėlavimą, todėl testas tuščioje linijoje praeina, o perpildyta linija nepraeina.

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'

Palyginkite apkrautos delsos skaičius su tuščios. Šuolis nuo dešimčių milisekundžių iki šimtų, neprarandant paketų, yra eilė; nuostoliai esant stabiliai delsai rodo kitą gedimą.

Patikrinkite įrenginį ir valdymo kelią

Šifravimas ir persiuntimas kainuoja procesoriaus laiką, o mažas maršrutizatorius ar šilumos ribojamas nešiojamasis kompiuteris gali mesti paketus, kol yra užimtas. Stebėkite bendrą apkrovą, o ne vieno proceso procentą, nes persiuntimas branduolyje ir pertraukimų apdorojimas neatsiranda ten, kur žmonės paprastai žiūri.

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

Kliento skirtasis laikas taip pat gali sutapti su suplanuotu raktų atnaujinimu arba sesijos politikos įvykiu. Skaitykite paties kliento žurnalą, kad sužinotumėte įvykių tvarką, o ne tik programos klaidos pranešimą.

Pakeiskite vieną dalyką ir pakartokite

Kur platforma tai palaiko, apribokite įkėlimo spartą arba suskirstykite masinį srautą žemiau interaktyvaus, kad eilė niekada neprisipildytų. Tada pakartokite tą pačią darbo apkrovą ir palyginkite tuos pačius tris skaičius kaip anksčiau. Pakeitimas, kuris pagerina greičio testą, bet palieka skirtąjį laiką, nieko nesutvarkė.

Visur padidinti skirtuosius laikus ir susilpninti šifravimą yra du pakeitimai, kurie pašalina simptomą neidentifikavę, kuri riba sugedo. Nė vienas jų nėra taisymas. Abu nukelia gedimą vėliau, kur jį priskirti sunkiau.

Pabaikite išbandę naują užklausą ir pakartotinio prisijungimo elgseną, kuria naudotojas tikrai remiasi. Stabilumas esant tai apkrovai, kuri sukėlė skundą, yra vienintelis rezultatas, kurį verta užrašyti.