journalctl для журналів VPN: який юніт володіє з’єднанням?

Почніть із юніта systemd, який справді володіє з’єднанням VPN, а не з команди журналу, яку ви пам’ятаєте. Пряма служба OpenVPN, юніт wg-quick і профіль NetworkManager розміщують свої корисні повідомлення в різних юнітах, а запит до неправильного дає порожній результат, який виглядає як тиша. Порівняйте трьох звичайних власників, звузьте вікно, а потім прочитайте етапи по порядку.

Порівняйте трьох звичайних власників

Клієнтська служба OpenVPN зазвичай є екземплярним юнітом, названим за профілем, наприклад [email protected]. Її повідомлення охоплюють шлях до конфігурації, розбір параметрів, рукостискання TLS і встановлення маршрутів, яке виконує клієнт.

Юніт wg-quick тихіший за задумом. Конфігурація інтерфейсу відбувається під час запуску, рукостискання обробляє ядро, а планові зміни ключів за замовчуванням не записуються, тому wg show часто інформативніше за журнал. Ця різниця важлива, коли ви порівнюєте протокол, який записує узгодження, з тим, який цього не робить.

NetworkManager володіє створеними ним профілями, і його повідомлення живуть під NetworkManager.service навіть тоді, коли базовий плагін є помічником VPN. Запитуйте і менеджер, і допоміжний юніт, коли профіль керується в такий спосіб.

Звузьте запит до одного юніта і одного вікна

Запитайте юніт, який ви визначили, і обмежте час тією спробою, яку досліджуєте. Одного дня зазвичай достатньо, а коротше вікно краще, коли машина часто перепідключається.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

Перевірте встановлену назву, перш ніж довіряти запиту. Пакування дистрибутива перейменовує юніти, і профіль, що існує як файл, міг ніколи не бути ввімкнений як служба. Якщо юніта немає, порожній журнал розповідає вам про розгортання, а не про тунель.

Прочитайте перший невдалий етап

Читайте події в порядку їх виникнення: пошук кінцевої точки, транспорт, ідентичність, автентифікація, встановлення маршрутів і подальший збій застосунку. Перший конкретний збій — той, який варто дослідити, бо все після нього є наслідком.

Служба, яка успішно запускається, не доводить, що кожен потрібний ресурс доступний. Цикл перепідключення може створити кілька окремих узгоджень, тому тримайте назву профілю й час спроби разом із подіями і читайте одну спробу, а не об’єднаний потік. Одна спроба — це послідовність із причиною, тоді як об’єднаний потік — стіна повторюваних рядків. Запишіть першу помилку в тікет, перш ніж читати далі.

Не змішуйте невдалу службу з ручним клієнтом

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

Не змінюйте оригінальні часові позначки, щоб вирівняти їх з іншим хостом. Запишіть часовий пояс і відому різницю годинників окремо, бо відредагована хронологія більше не є доказом.

Діліться фрагментом, а не експортом

Записи журналу можуть містити імена користувачів, адреси кінцевих точок, приватну топологію та відомості про середовище скриптів. Перегляньте фактичний фрагмент і закрийте чутливе, замість того щоб публікувати повний необмежений експорт. Цитуйте рядки, які доводять збій, і підсумуйте решту. Короткий переглянутий фрагмент легше використати, ніж файл, який ніхто не читає.

Надішліть вузьке вікно, назву юніта й перший невдалий етап і скажіть, що ви вже виключили. Посібник systemd journalctl документує селектори й параметри виводу, якщо вам потрібна форма, яку підтримує версія дистрибутива.