VPN постоянно отключается? Пройдите это в таком порядке

Прежде чем переустанавливать клиент, запишите три вещи: сколько туннель держался, что клиент сказал при обрыве и спала ли машина или меняла сеть за это время. Эта заметка — единственное доказательство, которое у вас будет позже, а переустановка обычно её стирает. Обрыв с повторяющимся интервалом — это таймер или истечение состояния; обрыв в случайный момент — проблема пути. Порядок ниже не даёт вам изменить три вещи сразу и не узнать ничего.

Первый шаг: зафиксируйте интервал и текст ошибки

Начните с собственного журнала клиента, а не с панели провайдера. На клиенте Linux журнал службы плюс живое состояние туннеля покрывают большую часть:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

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

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

Второй шаг: меняйте одну переменную, а не профиль

Держите устройство и профиль неизменными и перенесите машину в другую сеть доступа, например в точку доступа телефона. Это самый дешёвый тест, отделяющий клиента от пути. Запустите его достаточно долго, чтобы покрыть исходный интервал сбоя; две стабильные минуты ничего не доказывают об обрыве на тридцатой минуте.

Ноутбук с портом Ethernet даёт второе сравнение, которое полностью убирает Wi-Fi из картины. Если туннель держится на обоих вариантах, исходная сеть доступа заслуживает внимания: роуминг между точками доступа, домашний маршрутизатор с истекающей таблицей трансляции или вышестоящее звено, сбрасывающее долгие потоки.

Запишите, какую переменную вы изменили. Сравнение считается только тогда, когда всё остальное осталось прежним, и это включает конечную точку сервера и время суток.

Третий шаг: сопоставьте интервал с уровнем

Длительность хорошей сессии — самое информативное единственное число, которое у вас есть. Сверьтесь с этим списком, прежде чем трогать таймеры:

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

Для случая простоя настройки зависят от протокола, и важны оба конца. keepalive 10 60 OpenVPN на сервере отправляет пинг каждые 10 секунд и перезапускает соединение через 60 секунд без него; клиенты WireGuard за NAT используют PersistentKeepalive = 25 в блоке партнёра. OpenVPN также пересогласовывает канал данных по таймеру, reneg-sec, который по умолчанию равен 3600 секундам в 2.x.

Не копируйте агрессивные значения из руководства другого провайдера. Короткий тайм-аут на мобильном канале с потерями порождает именно те обрывы, которые должен был предотвратить, а значения, присылаемые сервером, переопределяют заданные в профиле клиента.

Четвёртый шаг: сравните одну поддерживаемую альтернативу

Если оператор публикует и профиль UDP, и профиль TCP, запустите то же устройство и сеть против другого. Используйте реальный подходящий файл, а не правьте транспорт в скопированном профиле. Стабильный профиль TCP на пути, где UDP сбрасывается, сужает проблему до этого пути; он не доказывает, что TCP — лучший транспорт везде.

Та же логика применима к конечным точкам. Попробуйте другой сервер и держите исходный результат рядом. Если сессии сбрасывает только один выход, это доказательство о той конечной точке, а не повод перестраивать каждый адаптер на ноутбуке.

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

Проверьте исправление и сохраните возможность отката

Исправление проверяется воспроизведением исходного триггера, а не успешным подключением. Оставьте туннель в простое дольше старого интервала сбоя, один раз приостановите и возобновите, а затем проверьте возраст рукопожатия и адрес выхода:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Держите прежний профиль и прежние значения таймеров, пока новое поведение не переживёт полный рабочий день. Если обрывы вернутся, восстановите резервную копию и затем снова применяйте изменения по одному, чтобы вторая попытка начиналась из известного состояния.

Если журнал остаётся чистым, а туннель всё ещё обрывается с повторяющимся интервалом, следующий пункт — сторона сервера для этой сессии. Возьмите с собой идентификатор сессии клиента и точное время обрыва, потому что именно эта пара делает журнал сервера доступным для поиска. Параметры связи протокола описаны в руководстве OpenVPN 2.6 когда вам нужно точное значение параметра.