journalctl for VPN-logger: hvilken enhet eier tilkoblingen?

Begynn med systemd-enheten som faktisk eier VPN-tilkoblingen, ikke med loggkommandoen du husker. En direkte OpenVPN-tjeneste, en wg-quick-enhet og en NetworkManager-profil plasserer de nyttige meldingene sine i forskjellige enheter, og et søk mot feil enhet gir et tomt resultat som ser ut som stillhet. Sammenlign de tre vanlige eierne, snevre inn vinduet, og les deretter trinnene i rekkefølge.

Sammenlign de tre vanlige eierne

En OpenVPN-klienttjeneste er vanligvis en instansenhet oppkalt etter profilen, for eksempel [email protected]. Meldingene dens omfatter konfigurasjonsstien, tolkning av valg, TLS-håndtrykket og ruteinstallasjonen klienten utfører.

En wg-quick-enhet er stillere av design. Grensesnittkonfigurasjonen skjer ved oppstart, håndtrykket håndteres av kjernen, og rutinemessige nøkkelutskiftninger logges ikke som standard, så wg show er ofte mer informativt enn journalen. Den forskjellen betyr noe når du sammenligner en protokoll som logger forhandlingen med en som ikke gjør det.

NetworkManager eier profilene den har opprettet, og meldingene dens ligger under NetworkManager.service selv når plugin-modulen er en VPN-hjelper. Spør både behandleren og hjelpeenheten når profilen styres på den måten.

Snevre inn søket til én enhet og ett vindu

Spør enheten du identifiserte, og avgrens tiden til forsøket du undersøker. Én dag er vanligvis nok, og et kortere vindu er bedre når maskinen kobler til på nytt ofte.

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

Bekreft det installerte navnet før du stoler på søket. Distribusjonspakker gir enhetene nye navn, og en profil som finnes som fil er kanskje aldri aktivert som tjeneste. Hvis enheten ikke finnes, forteller den tomme journalen deg om utrullingen og ikke om tunnelen.

Les det første feilede trinnet

Les hendelsene i den rekkefølgen de oppstår: oppslag av endepunkt, transport, identitet, autentisering, ruteinstallasjon og den senere feilen i applikasjonen. Den første konkrete feilen er den som er verdt å undersøke, fordi alt etter den er en konsekvens.

En tjeneste som starter uten feil, beviser ikke at hver nødvendige ressurs er tilgjengelig. En gjentilkoblingsløkke kan gi flere atskilte forhandlinger, så hold profilenavnet og forsøkstiden sammen med hendelsene, og les ett forsøk i stedet for en sammenslått strøm. Ett enkelt forsøk er en sekvens med en årsak, mens en sammenslått strøm er en vegg av gjentatte linjer. Skriv den første feilen i billetten før du leser videre.

Ikke bland en feilet tjeneste med en manuell klient

Hvis du startet en klient for hånd etter at tjenesten feilet, går utdataene dens et annet sted, og oppførselen kan være annerledes. Fang det nye resultatet fra samme eier og samme forespørsel etter en støttet rettelse, slik at sammenligningen viser hva som endret seg i stedet for å blande to forskjellige programmer.

Ikke endre opprinnelige tidsstempler for å tilpasse dem til en annen vert. Noter tidssonen og en eventuell kjent klokkeforskjell separat, for en tidslinje du har redigert er ikke lenger bevis.

Del et utdrag, ikke en eksport

Journaloppføringer kan inneholde brukernavn, endepunktadresser, privat topologi og informasjon om skriptmiljøet. Gå gjennom det faktiske utdraget og sladd det som er sensitivt i stedet for å publisere en full, ubegrenset eksport. Siter linjene som fastslår feilen, og oppsummer resten. Et kort gjennomgått utdrag er lettere å handle på enn en fil ingen leser.

Send det smale vinduet, enhetsnavnet og det første feilede trinnet, og si hva du allerede har utelukket. systemd journalctl-håndboken dokumenterer velgerne og utdataalternativene hvis du trenger en form som distribusjonens versjon støtter.