journalctl dla dzienników VPN: która jednostka posiada połączenie?

Zacznij od jednostki systemd, która naprawdę posiada połączenie VPN, a nie od polecenia dziennika, które pamiętasz. Bezpośrednia usługa OpenVPN, jednostka wg-quick i profil NetworkManager umieszczają swoje użyteczne komunikaty w różnych jednostkach, a zapytanie do niewłaściwej daje pusty wynik, który wygląda jak cisza. Porównaj trzech typowych właścicieli, zawęź okno i przeczytaj etapy po kolei.

Porównaj trzech typowych właścicieli

Usługa klienta OpenVPN to zwykle jednostka instancji nazwana od profilu, na przykład [email protected]. Jej komunikaty obejmują ścieżkę konfiguracji, analizę opcji, uścisk dłoni TLS i instalację tras, którą wykonuje klient.

Jednostka wg-quick jest z założenia cichsza. Konfiguracja interfejsu odbywa się przy starcie, uściskiem dłoni zajmuje się jądro, a rutynowe odświeżanie kluczy nie jest domyślnie rejestrowane, więc wg show jest często bardziej informacyjne niż dziennik. Ta różnica ma znaczenie, gdy porównujesz protokół, który rejestruje negocjacje, z takim, który tego nie robi.

NetworkManager posiada profile, które utworzył, a jego komunikaty znajdują się pod NetworkManager.service, nawet gdy podstawowa wtyczka jest pomocnikiem VPN. Pytaj zarówno menedżera, jak i jednostkę pomocniczą, gdy profil jest zarządzany w ten sposób.

Zawęź zapytanie do jednej jednostki i jednego okna

Pytaj jednostkę, którą zidentyfikowałeś, i ogranicz czas do próby, którą badasz. Jeden dzień zwykle wystarcza, a krótsze okno jest lepsze, gdy maszyna często łączy się ponownie.

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

Sprawdź zainstalowaną nazwę, zanim zaufasz zapytaniu. Pakowanie dystrybucji zmienia nazwy jednostek, a profil istniejący jako plik mógł nigdy nie zostać włączony jako usługa. Jeśli jednostka nie istnieje, pusty dziennik mówi o wdrożeniu, a nie o tunelu.

Przeczytaj pierwszy nieudany etap

Czytaj zdarzenia w kolejności ich występowania: wyszukiwanie punktu końcowego, transport, tożsamość, uwierzytelnianie, instalacja tras i późniejsza awaria aplikacji. Pierwsza konkretna awaria jest tą, którą warto zbadać, ponieważ wszystko po niej jest konsekwencją.

Usługa, która uruchamia się poprawnie, nie dowodzi, że każdy wymagany zasób jest osiągalny. Pętla ponownego łączenia może wytworzyć kilka osobnych negocjacji, więc trzymaj nazwę profilu i czas próby razem ze zdarzeniami i czytaj jedną próbę zamiast scalonego strumienia. Pojedyncza próba to sekwencja z przyczyną, a scalony strumień to ściana powtarzanych linii. Zapisz pierwszy błąd w zgłoszeniu, zanim przeczytasz dalej.

Nie mieszaj nieudanej usługi z klientem uruchamianym ręcznie

Jeśli uruchomiłeś klienta ręcznie po awarii usługi, jego dane wyjściowe trafiają gdzie indziej, a zachowanie może być inne. Przechwyć nowy wynik od tego samego właściciela i z tym samym żądaniem po obsługiwanej poprawce, aby porównanie pokazało, co się zmieniło, zamiast mieszać dwa różne programy.

Nie zmieniaj oryginalnych znaczników czasu, aby wyrównać je z innym hostem. Zapisz osobno strefę czasową i znaną różnicę zegara, ponieważ edytowana os czasu nie jest już dowodem.

Udostępnij fragment, a nie eksport

Wpisy dziennika mogą zawierać nazwy użytkowników, adresy punktów końcowych, prywatną topologię i informacje o środowisku skryptów. Przejrzyj rzeczywisty fragment i zamaluj to, co wrażliwe, zamiast publikować pełny nieograniczony eksport. Zacytuj wiersze, które dowodzą awarii, i podsumuj resztę. Krótki sprawdzony fragment jest łatwiejszy do wykorzystania niż plik, którego nikt nie czyta.

Wyślij wąskie okno, nazwę jednostki i pierwszy nieudany etap oraz powiedz, co już wykluczyłeś. Podręcznik systemd journalctl dokumentuje selektory i opcje wyjścia, jeśli potrzebujesz formatu obsługiwanego przez wersję dystrybucji.