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

Тайм-аут у клієнта може також збігтися з запланованою зміною ключів або з подією політики сеансу. Читайте власний журнал клієнта заради порядку подій, а не лише повідомлення про помилку застосунку.

Змініть одну річ і повторіть

Де платформа це підтримує, обмежте швидкість вивантаження або віднесіть масовий трафік нижче інтерактивного, щоб черга ніколи не заповнювалася. Потім повторіть ту саму роботу й порівняйте ті самі три числа, що й раніше. Зміна, яка покращує тест швидкості, але лишає тайм-аут, нічого не виправила.

Підвищення тайм-аутів усюди й ослаблення шифрування — це дві зміни, які прибирають симптом, не з'ясувавши, яка межа відмовила. Жодна з них не є ремонтом. Обидві переносять відмову пізніше, туди, де її важче пов'язати з причиною.

Завершіть перевіркою нового запиту й тієї поведінки під час перепідключення, на яку користувач справді покладається. Стійкість під навантаженням, що спричинило скаргу, — єдиний результат, який варто записати.

Схожі статті