journalctl pro protokoly VPN: která jednotka vlastní připojení?

Začněte jednotkou systemd, která VPN připojení skutečně vlastní, ne příkazem pro protokol, který si pamatujete. Přímá služba OpenVPN, jednotka wg-quick a profil NetworkManager umisťují své užitečné zprávy do různých jednotek a dotaz na špatnou jednotku vrátí prázdný výsledek, který vypadá jako ticho. Porovnejte tři běžné vlastníky, zúžte okno a potom čtěte fáze popořadě.

Porovnejte tři běžné vlastníky

Klientská služba OpenVPN je obvykle instance jednotky pojmenovaná podle profilu, například [email protected]. Její zprávy zahrnují cestu ke konfiguraci, zpracování voleb, TLS handshake a instalaci tras, kterou klient provádí.

Jednotka wg-quick je záměrně tišší. Konfigurace rozhraní proběhne při startu, handshake zpracovává jádro a rutinní obnova klíčů se ve výchozím nastavení nezapisuje, takže wg show je často informativnější než protokol. Tento rozdíl je důležitý, když porovnáváte protokol, který zaznamenává vyjednávání, s takovým, který to nedělá.

NetworkManager vlastní profily, které vytvořil, a jeho zprávy žijí pod NetworkManager.service, i když je základní plugin pomocník VPN. Dotazujte se jak na správce, tak na pomocnou jednotku, když je profil spravován tímto způsobem.

Zúžte dotaz na jednu jednotku a okno

Dotazujte se na jednotku, kterou jste určili, a ohraničte čas pokusem, který zkoumáte. Jeden den obvykle stačí a kratší okno je lepší, když se stroj často připojuje znovu.

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

Ověřte nainstalovaný název, než dotazu uvěříte. Distribuční balíčky jednotky přejmenovávají a profil, který existuje jako soubor, nemusel být nikdy povolen jako služba. Pokud jednotka neexistuje, prázdný protokol vám vypráví o nasazení, ne o tunelu.

Přečtěte první neúspěšnou fázi

Čtěte události v pořadí, v jakém nastávají: hledání koncového bodu, přenos, identita, ověřování, instalace tras a pozdější selhání aplikace. První konkrétní selhání je to, které stojí za vyšetření, protože vše po něm je následek.

Služba, která úspěšně startuje, nedokazuje, že je každý potřebný zdroj dostupný. Smyčka opětovného připojení může vytvořit několik samostatných vyjednávání, proto držte název profilu a čas pokusu u událostí a čtěte jeden pokus místo sloučeného proudu. Jediný pokus je posloupnost s příčinou, zatímco sloučený proud je zeď opakovaných řádků. Napište první chybu do tiketu, než budete číst dál.

Nemíchejte neúspěšnou službu s ručním klientem

Pokud jste klienta spustili ručně poté, co služba selhala, jeho výstup jde jinam a jeho chování se může lišit. Zachyťte nový výsledek od stejného vlastníka a stejného požadavku po podporované opravě, aby srovnání ukázalo, co se změnilo, místo míchání dvou různých programů.

Neměňte původní časová razítka, aby se srovnala s jiným hostitelem. Poznamenejte časové pásmo a známý rozdíl hodin odděleně, protože časová osa, kterou jste upravili, už není důkaz.

Sdílejte výňatek, ne export

Záznamy protokolu mohou obsahovat uživatelská jména, adresy koncových bodů, soukromou topologii a informace o prostředí skriptu. Prohlédněte si skutečný výňatek a citlivé údaje začerněte, místo abyste zveřejnili úplný neomezený export. Citujte řádky, které dokazují selhání, a zbytek shrňte. Krátký zkontrolovaný výňatek se dá snáze použít než soubor, který nikdo nečte.

Pošlete úzké okno, název jednotky a první neúspěšnou fázi a řekněte, co jste už vyloučili. manuál systemd journalctl dokumentuje selektory a volby výstupu, pokud potřebujete formu, kterou verze distribuce podporuje.