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

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

Измените одну вещь и повторите

Где платформа это поддерживает, ограничьте скорость выгрузки или отнесите массовый трафик ниже интерактивного, чтобы очередь никогда не заполнялась. Затем повторите ту же работу и сравните те же три числа, что и раньше. Изменение, которое улучшает тест скорости, но оставляет тайм-аут, ничего не исправило.

Повышение тайм-аутов повсеместно и ослабление шифрования — это две перемены, которые убирают симптом, не выяснив, какая граница отказала. Ни одна из них не является ремонтом. Обе переносят отказ позже, туда, где его труднее связать с причиной.

Завершите проверкой нового запроса и того поведения при переподключении, на которое пользователь действительно полагается. Устойчивость под нагрузкой, вызвавшей жалобу, — единственный результат, который стоит записать.