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 ги документира селекторите и опциите за излез ако ви треба форма што ја поддржува верзијата на дистрибуцијата.