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 документирует селекторы и параметры вывода, если вам нужна форма, которую поддерживает версия дистрибутива.