journalctl til VPN-logfiler: hvilken enhed ejer forbindelsen?

Begynd med den systemd-enhed, der faktisk ejer VPN-forbindelsen, ikke med den logkommando, du husker. En direkte OpenVPN-tjeneste, en wg-quick-enhed og en NetworkManager-profil placerer deres nyttige meddelelser i forskellige enheder, og en forespørgsel mod den forkerte giver et tomt resultat, der ligner tavshed. Sammenlign de tre almindelige ejere, indsnævr vinduet, og læs derefter faserne i rækkefølge.

Sammenlign de tre almindelige ejere

En OpenVPN-klienttjeneste er normalt en instansenhed opkaldt efter profilen, for eksempel [email protected]. Dens meddelelser omfatter konfigurationsstien, fortolkning af tilvalg, TLS-håndtrykket og den ruteinstallation, klienten udfører.

En wg-quick-enhed er mere tavs af design. Grænsefladekonfigurationen sker ved start, håndtrykket håndteres af kernen, og rutinemæssige nøgleudskiftninger logges ikke som standard, så wg show er ofte mere informativ end journalen. Den forskel betyder noget, når du sammenligner en protokol, der logger forhandling, med en, der ikke gør.

NetworkManager ejer de profiler, den har oprettet, og dens meddelelser ligger under NetworkManager.service, selv når det underliggende plugin er en VPN-hjælper. Forespørg både manageren og hjælpeenheden, når profilen styres på den måde.

Indsnævr forespørgslen til én enhed og ét vindue

Forespørg den enhed, du identificerede, og afgræns tiden til det forsøg, du undersøger. En dag er normalt nok, og et kortere vindue er bedre, når maskinen ofte genopretter forbindelsen.

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

Bekræft det installerede navn, før du stoler på forespørgslen. Distributionspakker omdøber enheder, og en profil, der findes som fil, er måske aldrig blevet aktiveret som tjeneste. Hvis enheden ikke findes, fortæller den tomme journal dig om udrulningen og ikke om tunnelen.

Læs den første fejlede fase

Læs hændelserne i den rækkefølge, de opstår: opslag af endepunkt, transport, identitet, godkendelse, ruteinstallation og applikationens senere fejl. Den første konkrete fejl er den, der er værd at undersøge, fordi alt efter den er en konsekvens.

En tjeneste, der starter med succes, beviser ikke, at enhver nødvendig ressource er tilgængelig. En genopkoblingsløkke kan give flere separate forhandlinger, så hold profilnavnet og forsøgstiden sammen med hændelserne, og læs ét forsøg i stedet for en sammenflettet strøm. Et enkelt forsøg er et forløb med en årsag, mens en sammenflettet strøm er en mur af gentagne linjer. Skriv den første fejl i billetten, før du læser videre.

Bland ikke en fejlet tjeneste sammen med en manuel klient

Hvis du startede en klient manuelt, efter at tjenesten fejlede, går dens output et andet sted hen, og dens adfærd kan være anderledes. Fang det nye resultat fra samme ejer og samme anmodning efter en understøttet rettelse, så sammenligningen viser, hvad der ændrede sig, i stedet for at blande to forskellige programmer.

Ret ikke i de oprindelige tidsstempler for at tilpasse dem til en anden vært. Notér tidszonen og en eventuel kendt urforskel separat, for en tidslinje, du har redigeret, er ikke længere bevis.

Del et uddrag, ikke en eksport

Journalposter kan indeholde brugernavne, endepunktsadresser, privat topologi og oplysninger om scriptmiljøet. Gennemgå det faktiske uddrag og slør det følsomme i stedet for at offentliggøre en fuld, ubegrænset eksport. Citér de linjer, der fastslår fejlen, og opsummer resten. Et kort gennemgået uddrag er lettere at handle på end en fil, ingen læser.

Send det snævre vindue, enhedsnavnet og den første fejlede fase, og sig, hvad du allerede har udelukket. systemd journalctl-manualen dokumenterer vælgerne og outputtilvalgene, hvis du har brug for en form, som distributionens version understøtter.