VPN shkëputet gjatë ngarkimeve të mëdha: lexo radhën fillimisht

Tuneli është i qëndrueshëm gjatë gjithë ditës dhe pastaj shkëputet sa herë që fillon një ngarkim i madh. Kërkesat interaktive ngecin të parat, klienti raporton një skadim kohe dhe lidhja kthehet kur transferimi përfundon. Ky model tregon radhë dhe përpunim, jo një server të largët të rrëzuar, sepse serverit nuk iu dha kurrë mundësia të përgjigjej në kohë. Puna është ta riprodhoni këtë nën një ngarkesë të kontrolluar dhe të lexoni numëruesit e duhur.

Ndryshoni një variabël për çdo ekzekutim dhe mbani pikën fundore fikse.

Ndërtoni një krahasim ngarkese të përsëritshëm

Regjistroni një vijë bazë me lidhjen në pushim: kohën e shkuarjes dhe kthimit, disa kërkesa aplikacioni dhe regjistrin e ngjarjeve të vetë tunelit. Pastaj nisni një ngarkim me madhësi të njohur dhe përsëritni saktësisht ato matje ndërsa ai punon. Mbani të pandryshuara pikën fundore, klientin dhe destinacionin e provës, sepse ndryshimi i dy prej tyre njëherësh nuk ju thotë asgjë.

Vini re cila ngjarje shfaqet e para. Një kohë shkuarje dhe kthimi në rritje para çdo gabimi sugjeron radhë; një skadim i fortë kohe me vonesë të qëndrueshme sugjeron diçka tjetër, si një rrotullim çelësash ose një veprim në llogari. Të dy modelet çojnë në hapa të ndryshëm. Shkruani vëzhgimin përpara se të ndryshoni çdo gjë.

Ruani daljen me vulë kohe që ekzekutimet nën ngarkesë dhe në pushim të krahasohen rresht për rresht.

Lexoni radhën, jo shpejtësinë

Lidhjet e konsumatorit i ruajnë paketat në pajisjet e ofruesit, dhe një radhë dalëse e plotë vonon gjithçka, përfshirë paketat e vogla të kontrollit që e mbajnë tunelin gjallë. Një provë shpejtësie që raporton një shifër të lartë thotë pak për atë vonesë, prandaj një provë në pushim kalon ndërsa një lidhje e ngopur dështon.

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'

Krahasoni shifrat e vonesës nën ngarkesë me ato në pushim. Një kërcim nga dhjetëra milisekonda në qindra, pa humbje paketash, është radhë; humbja me vonesë të qëndrueshme tregon një defekt tjetër.

Kontrolloni pajisjen dhe rrugën e kontrollit

Kriptimi dhe përcjellja kushtojnë kohë procesori, dhe një router i vogël ose një laptop i kufizuar termikisht mund të hedhë paketa ndërsa është i zënë. Vëzhgoni ngarkesën e përgjithshme, jo përqindjen e një procesi, sepse përcjellja në kernel dhe trajtimi i ndërprerjeve nuk shfaqen atje ku njerëzit zakonisht shikojnë.

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

Skadimi i kohës në klient mund të përkojë edhe me një rrotullim të planifikuar çelësash ose me një ngjarje të politikës së sesionit. Lexoni regjistrin e vetë klientit për rendin e ngjarjeve, jo vetëm mesazhin e gabimit të aplikacionit.

Ndryshoni një gjë dhe përsëritni

Kur platforma e mbështet, kufizoni ritmin e ngarkimit ose klasifikoni trafikun masiv nën atë interaktiv, që radha të mos mbushet kurrë. Pastaj përsëritni të njëjtën ngarkesë pune dhe krahasoni të njëjtat tri shifra si më parë. Një ndryshim që përmirëson një provë shpejtësie por lë skadimin e kohës nuk rregulloi asgjë.

Ngritja e afateve kudo dhe dobësimi i kriptimit janë dy ndryshimet që e bëjnë simptomën të zhduket pa identifikuar se cila kufi dështoi. Asnjëri nuk është riparim. Të dy e zhvendosin dështimin më vonë, atje ku është më e vështirë t'i atribuohet.

Përfundoni duke provuar një kërkesë të re dhe sjelljen e rilidhjes ku përdoruesi mbështetet vërtet. Qëndrueshmëria nën ngarkesën që shkaktoi ankesën është i vetmi rezultat që ia vlen të regjistrohet.