Как измерить время работы клиента OpenVPN с помощью хуков up и down

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

Убедитесь, что хуки действительно выполняются

Докажите, что хук срабатывает, прежде чем что-либо вокруг него проектировать. Минимальной конфигурации клиента нужны script-security 2 и явные пути up и down; без строки безопасности OpenVPN отказывается выполнять скрипт и прямо об этом говорит. Добавьте up-restart и down-pre одновременно, чтобы пути перезапуска и разборки вели себя предсказуемо.

Сделайте первую версию хука такой, чтобы она дописывала своё окружение в файл и больше ничего не делала. Так вы увидите имена переменных, которые ваша сборка действительно экспортирует, например dev и script_type, вместо тех, что помните из другой версии. Выполните одно подключение и одно отключение, затем прочитайте файл. Если ничего не появилось, остановитесь здесь: схема с меткой времени поверх хука, который никогда не запускается, неделями будет выглядеть как сбой мониторинга.

Проверьте, от имени какого пользователя работает хук. При заданных user и group OpenVPN сбрасывает привилегии перед запуском скриптов, поэтому каталог, в который root может писать, может быть закрыт для хука. Выбирайте путь с точки зрения службы, а не вашей оболочки.

Запишите одно значение epoch и сотрите его намеренно

Хуку up нужна одна строка, date +%s > /run/openvpn-client.started, с путём, подправленным под каждый экземпляр. Значение epoch избавляет позже от вопросов языка, часового пояса и формата, и это то же число, которое агент мониторинга может сравнить со своими часами.

Стирание так же важно, как запись. Хук down должен опустошить или удалить файл, а down-pre делает это до закрытия интерфейса, что убирает окно, в котором файл описывает уже исчезнувший туннель. up-restart затем обновляет метку при внутреннем перезапуске вместо того, чтобы оставить исходное значение на месте. Без этой пары перезапуск после истечения пинга даёт число, которое продолжает расти, пока туннель восстанавливается.

Выберите место с правильным сроком жизни. Файл под /run исчезает при перезагрузке, что соответствует реальности, тогда как файл под /tmp может быть непредсказуемо очищен, а файл в каталоге конфигурации выживает обманчивым образом. Задайте права так, чтобы читать его могли только пользователь службы и читатель мониторинга.

Считайте время работы, не доверяя строкам журнала

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

Разбор временных меток из журнала — соблазнительный короткий путь, и он проваливается тремя способами: формат зависит от заданных опций, ротация удаляет историю, а переподключения выглядят как отдельные сессии, а не один непрерывный туннель. Хук записывает событие один раз, в момент, когда оно происходит.

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

Покройте переподключения, перезапуски и несколько экземпляров

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

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

На стороне сервера файл состояния несёт значение connected-since для каждого клиента, которое отвечает на другой вопрос: когда сервер в последний раз видел этого партнёра. Используйте его для перекрёстной проверки, а не как замену, поскольку он исчезает вместе с сессией, которую описывает. Ни одно из измерений ничего не говорит о здоровье приложения за туннелем.

Выполните три проверки, которые ловят ошибки порядка

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

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