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

Изтичане на времето при клиента може също да съвпадне с планирана смяна на ключове или със събитие по политиката на сесията. Четете собствения журнал на клиента за реда на събитията, а не само съобщението за грешка на приложението.

Променете едно нещо и повторете

Където платформата го позволява, ограничете скоростта на качване или класифицирайте масовия трафик под интерактивния, така че опашката никога да не се пълни. След това повторете същата работа и сравнете същите три числа като преди. Промяна, която подобрява теста за скорост, но оставя изтичането на времето, не е поправила нищо.

Вдигането на всички времена за изчакване и отслабването на шифроването са двете промени, които карат симптома да изчезне, без да установят коя граница е отказала. Нито една от тях не е ремонт. И двете отместват отказа по-късно, където е по-трудно да се припише.

Завършете с тест на нова заявка и на поведението при повторно свързване, на което потребителят наистина разчита. Стабилността под товара, който предизвика оплакването, е единственият резултат, който си струва да се запише.