VPN паѓа при големи прикачувања: прво прочитајте го редот

Тунелот е стабилен цел ден, а потоа паѓа секогаш кога ќе почне големо прикачување. Интерактивните барања први застануваат, клиентот пријавува истекување на времето, а врската се враќа кога преносот завршува. Оваа слика укажува на ред и обработка, а не на тоа дека далечинскиот сервер е паднат, бидејќи на серверот никогаш не му беше дадена шанса навреме да одговори. Задачата е да се репродуцира ова под контролиран товар и да се прочитаат вистинските бројачи.

Менувајте по една променлива на секое пуштање и држете ја крајната точка фиксна.

Изградете повторливо споредување на товарот

Запишете основна линија додека врската мирува: време на одење и враќање, неколку барања од апликации и сопствениот дневник на настани на тунелот. Потоа започнете прикачување со позната големина и повторете ги точно тие мерења додека трае. Држете ги крајната точка, клиентот и целта на тестот непроменети, бидејќи менувањето две од нив одеднаш не ви кажува ништо.

Забележете кој настан се појавува прв. Растечкото време на одење и враќање пред каква било грешка укажува на ред; тврдото истекување на времето со стабилна латентност укажува на нешто друго, како обновување на клучеви или дејство на сметката. Двете слики водат до различни следни чекори. Запишете го набљудувањето пред да смените нешто.

Зачувајте го излезот со временски ознаки за да можат натовареното и мирното пуштање да се споредат ред по ред.

Читајте го редот, не брзината

Потрошувачките врски ги баферираат пакетите во опремата на давателот, а полн ред за прикачување забавува сите, вклучително и малите контролни пакети што го одржуваат тунелот жив. Тестот за брзина што покажува висока бројка малку кажува за тоа доцнење, затоа тестот во мирување поминува додека заситената врска не успева.

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'

Споредете ги бројките за латентност под товар со оние во мирување. Скокот од десетици милисекунди на стотици, без загуба на пакети, е ред; загубата со стабилна латентност укажува на друг дефект.

Проверете го уредот и контролната патека

Шифрирањето и препраќањето чинат процесорско време, а мал рутер или преносен компјутер ограничен од топлина може да испушта пакети додека е зафатен. Гледајте го вкупниот товар, а не процентот на еден процес, бидејќи препраќањето во јадрото и обработката на прекини не се појавуваат таму каде што луѓето обично гледаат.

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

Истекувањето на времето кај клиентот може да се совпадне и со закажано обновување на клучеви или со настан од политиката на сесијата. Читајте го сопствениот дневник на клиентот за редоследот на настаните, а не само пораката за грешка на апликацијата.

Сменете една работа и повторете

Каде што платформата го поддржува, ограничете ја брзината на прикачување или класифицирајте го масовниот сообраќај под интерактивниот за редот никогаш да не се наполни. Потоа повторете го истиот работен товар и споредете ги истите три бројки како претходно. Промена што го подобрува тестот за брзина, но го остава истекувањето на времето, не поправила ништо.

Подигнувањето на сите времиња на чекање и ослабувањето на шифрирањето се двете промени што го отстрануваат симптомот без да утврдат која граница откажала. Ниту една не е поправка. Двете го поместуваат дефектот подоцна, каде што е потешко да се припише.

Завршете со тестирање на ново барање и однесувањето при повторно поврзување на кое корисникот навистина се потпира. Стабилноста под товарот што предизвикал поплаката е единствениот резултат што вреди да се запише.