VPN отключается через одинаковый интервал? Сопоставьте таймер
Обрыв через фиксированный интервал — это отпечаток. Сравните переобновление ключей туннеля, таймер простоя NAT, аренду DHCP и лимит учётной записи, прежде чем что-то менять.
Туннель, который умирает каждые пятнадцать минут или каждый час в одну и ту же минуту, сообщает, что истёк какой-то таймер, а не что сеть нестабильна. Полезный шаг — записать интервал и сравнить его с четырьмя таймерами, которые дают такую картину. Смена тайм-аутов до этого сравнения обычно переносит сбой, не объясняя его, из-за чего следующий случай читать труднее, чем первый. Измерение занимает десять минут и заменяет неделю догадок.
Превратите интервал в число
Соберите пять или шесть случаев и вычислите разрыв между ними, а не от начала дня. Обрыв в 09:12, 10:12 и 11:12 — это часовая граница; обрыв в 09:12, 09:27 и 09:42 — это пятнадцать минут от последнего успешного подключения. Округлите результат до самого вероятного таймера, а не до ближайшей минуты.
Запишите два момента на событие: когда трафик последний раз двигался и когда клиент сообщил об отключении. Они различаются, когда туннель умирает молча и клиент замечает это только при следующей отправке, и именно эта разница отделяет тайм-аут простоя от жёсткого сбоя. Клиент, который замечает поздно, раздувает измеряемое окно простоя.
Отметьте, автоматическое ли переподключение. Клиент, который переподключается за секунды, держит интервал видимым в журнале и вне отчёта пользователя, поэтому такие сбои часто описывают как случайные, а не периодические. Он также скрывает событие от человека, который пользуется ноутбуком.
Четыре таймера, которые выглядят одинаково
Почти каждый повторяющийся обрыв туннеля происходит из одного из этих: переобновление ключей протокола, истечение простаивающего сопоставления, событие DHCP или интерфейса, либо политика учётной записи. Они различаются тем, шёл ли трафик, и тем, что журнал говорит на границе.
Подписи ниже стоит выучить, потому что они позволяют отклонить три объяснения по одной строке журнала:
| Timer | Typical trigger | What the log shows at the boundary |
|---|---|---|
| Protocol rekey | Traffic present, fixed interval | Negotiation lines, sometimes a failure |
| NAT or firewall idle | No traffic for minutes | Silence, then a timeout on send |
| DHCP lease or link change | Half the lease, or a radio event | Address or interface churn |
| Account session limit | Wall-clock hours since login | Clean disconnect, server-side reason |
Первая строка — это механизм безопасности, выполняющий свою работу, а вторая — промежуточное устройство, забывающее состояние. Их путаница ведёт либо к ослаблению переобновления, либо к погоне за правилом брандмауэра, которое никогда не участвовало.
Занятость против простоя говорит, какая половина
Проведите контролируемое сравнение с непрерывным трафиком, например длинным потоком к хосту внутри туннеля, и наблюдайте, меняется ли интервал. Если обрыв исчезает, пока идут данные, таймер основан на простое.
Если он выдерживает непрерывный трафик, причина относится к переобновлению, аренде или политике. Этот единственный тест убирает половину кандидатов примерно за час наблюдения, и он не стоит ничего, кроме внимания.
Держите сеть доступа неизменной во время теста. Переключение между Wi-Fi и Ethernet посреди сравнения вносит именно то событие интерфейса, которое вы пытаетесь отличить от таймера.
Сопоставьте строку журнала с границей
Читайте журналы клиента и сервера вокруг зафиксированного момента, а не весь файл. Переобновление показывает переговоры; истечение простоя ничего не показывает до следующего пакета; смена аренды показывает работу с адресом; лимит политики обычно показывает чистое административное отключение.
Эти команды извлекают нужное окно из каждого источника:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showЕсли три источника совпадают по метке времени, вы знаете владельца таймера. Если что-то есть только в журнале клиента, сервер, вероятно, не тот, кто завершает сеанс.
Исправьте этап, а не значок
У каждого владельца есть одно поддерживаемое исправление. Сбой переобновления требует совместимых предложений на обоих концах. Истечение простоя требует сигнала поддержания или более короткого ожидания простоя, в пределах того, что допускает путь. Событие аренды требует исправления настроек интерфейса или питания. Лимит учётной записи — это решение политики, а не ошибка.
Отключение переобновления или аутентификации, чтобы значок оставался зелёным, меняет видимый обрыв на невидимую слабость и оставляет вас без возможности сказать, когда туннель последний раз согласовывал новые ключи. После этого повторите тест исходной длительности и сохраните метки времени, чтобы следующее событие можно было сравнить с этим, а не начинать заново.