Ежечасный обрыв OpenVPN: пересогласование или настоящий перезапуск?
Обрыв на подозрительно круглом интервале — обычно обновление ключей, а не мёртвый канал. Прочитайте действующий таймер и строку журнала, прежде чем что-либо отключать.
Шестьдесят минут, тридцать или сто двадцать: обрыв, который приходится на круглый интервал, почти никогда не связан с сетью. OpenVPN обновляет по таймеру ключевой материал, защищающий канал данных, и таймер короче того, который вы предполагали, выглядит в точности как канал, который постоянно падает. Пользователи сообщают о разорванном соединении, тогда как журнал сообщает об успешном обмене ключами. Инструкция ниже отделяет это обновление от настоящего перезапуска, читает фактически действующее значение и меняет его только после того, как цена названа.
Выполняйте шаги по порядку, потому что первый из них решает, относится ли к вам вообще всё остальное на этой странице. Пропустите его вперёд — и вы потратите вечер на настройку таймера из-за сбоя, который к нему не имеет отношения.
Отличите мягкий сброс от перезапуска
Строка журнала — это весь диагноз. Пересогласование записывает мягкий сброс, а затем новый обмен ключами внутри того же туннеля: интерфейс сохраняет свой адрес, маршруты заново не добавляются, а установленные сессии TCP обычно переживают это с паузой. Настоящий перезапуск разрывает сессию, пересоздаёт интерфейс, может выдать другой адрес клиента и убивает все долгоживущие соединения. Оба события обычны; лишь одно из них объясняет оборванный звонок.
journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1
Строка версии важна, потому что формулировки в журнале меняются от выпуска к выпуску, и сообщение, которое вы помните из 2.3, в 2.6 может звучать иначе. Читайте собственный журнал, а не выдержку с форума, взятую у кого-то другого. Цитируйте точную строку, когда просите о помощи, потому что пересказ теряет деталь, по которой опознаётся событие. Если адрес интерфейса за время события не изменился и список сессий сохранился, перед вами обновление, и остальные разделы применимы.
Читайте действующий таймер, а не свой файл
reneg-sec — это число секунд между пересогласованиями канала данных, по умолчанию 3600. Каждая сторона несёт своё значение, и именно меньшее из двух запускает обновление. Это единственное правило объясняет большинство сообщений: профиль клиента, задающий большое число, всё равно сбрасывается каждый час, пока сервер сохраняет значение по умолчанию.
grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/
Читайте также действующую конфигурацию сервера, включая всё, что он передаёт, прежде чем делать вывод по файлу клиента. Затем повысьте подробность и проследите один интервал от начала до конца: уровень 3 уже показывает строки пересогласования, а отметки времени подскажут, повторяется ли событие каждые 3600 секунд или следует за активностью.
Меняйте там, где значение действительно передаётся
Ходячее лекарство — одна строка в профиле клиента, и примерно в половине случаев это неверное место. Поскольку побеждает меньшее значение стороны, клиент, задавший таймер в ноль, всё равно может быть пересогласован сервером, который не менялся.
# on both ends, or on the side that owns the pushed configuration
reneg-sec 0
Если профили генерируются централизованно, правьте шаблон, а не развёрнутую копию, иначе следующий запуск провижининга восстановит значение, которое вы только что убрали. Проверяйте, наблюдая два интервала, а не один: один спокойный час согласуется и с таймером, установленным в 7200.
Решите также, что произойдёт при смешанном развёртывании. Если выкатить изменение сначала на клиенты, останется окно, в котором сервер всё ещё запускает обновление; это безвредно, но сбивает с толку, если вы следите за журналами в поисках подтверждения. Меняйте первой ту сторону, где значение меньше, и симптом исчезнет там, где вы ожидаете.
Что вы отдаёте, отключая пересогласование
Регулярное пересогласование ограничивает, как долго один набор ключей канала данных защищает трафик. Отключение таймера не ломает туннель, и на домашнем роутере или шлюзе небольшого офиса практическая экспозиция невелика. Это всё равно обмен, и обмен стоит назвать до того, как вы его совершите. Меняется то, как долго один набор ключей защищает сессию, а не то, работает ли туннель вообще.
Разумный случай для отключения — сброс, который ломает нечто невосстанавливаемое: звонок, который обрывается, сеанс удалённого рабочего стола, который приходится устанавливать заново, резервное копирование, которое начинается с начала. Если пауза незаметна для пользователей, сохранение значения по умолчанию ничего не стоит и сохраняет вам ротацию ключей.
Предпочитайте исправлять причину, когда картина это позволяет. Обновление, которое срывается на полпути, тогда как первое рукопожатие прошло успешно, указывает на путь, а не на таймер: ищите проблему размера пакета в более крупном обмене канала управления, межсетевой экран с отслеживанием состояния, который отбрасывает поток, или предложение, которое проходит только с первой попытки. Каждый из этих признаков оставляет след в том же журнале, который вы только что читали. Отключение таймера скрывает эти улики.
Когда интервал указывает в другую сторону
Два соседа в конфигурации дают похожие симптомы и разные исправления. ping-restart перезапускает туннель, когда ничего не приходит в течение заданного периода, а ping-exit полностью выключает клиента. Обрыв при простое, без какого-либо пересогласования в журнале, относится к ним или к устройству NAT, у которого истекло отображение UDP по его собственному расписанию.
Потребительские роутеры, мобильные точки доступа и NAT операторского класса истекают простаивающие сессии UDP, никому не сообщая. Этот сбой следует за простоем, а не за часами, и это и есть примета: сессия, которая обрывается после десяти тихих минут и выживает час ровного трафика, не пересогласовывается.
Запишите три вещи, прежде чем менять четвёртую: измеренный интервал, найденное действующее значение и команду, которая его показала. Если интервал сдвигается вместе с таймером, механизм опознан, и исправление — это решение об обмене, о котором выше. Если он не сдвигается, верните настройку и продолжайте смотреть на keepalive, состояние NAT и потери пакетов.