journalctl for VPN-loggar: kva eining eig tilkoplinga?

Byrj med systemd-eininga som faktisk eig VPN-tilkoplinga, ikkje med loggkommandoen du hugsar. Ei direkte OpenVPN-teneste, ei wg-quick-eining og ein NetworkManager-profil plasserer dei nyttige meldingane sine i ulike einingar, og eit søk mot feil eining gir eit tomt resultat som ser ut som stille. Samanlikn dei tre vanlege eigarane, snevra inn vindauget og les deretter trinna i rekkjefølgje.

Samanlikn dei tre vanlege eigarane

Ei OpenVPN-klientteneste er vanlegvis ei instanseining kalla opp etter profilen, til dømes [email protected]. Meldingane hennar omfattar konfigurasjonsstien, tolking av val, TLS-handtrykket og ruteinstallasjonen klienten utfører.

Ei wg-quick-eining er stillare av design. Grensesnittkonfigurasjonen skjer ved oppstart, handtrykket blir handtert av kjernen, og rutinemessige nøkkelutskiftingar blir ikkje logga som standard, så wg show er ofte meir informativt enn journalen. Den skilnaden har noko å seie når du samanliknar ein protokoll som loggar forhandlinga med ein som ikkje gjer det.

NetworkManager eig profilane som det har oppretta, og meldingane ligg under NetworkManager.service sjølv når plugin-modulen er ein VPN-hjelpar. Spør både behandlaren og hjelpeeininga når profilen blir styrt på den måten.

Snevra inn søket til éi eining og eitt vindauge

Spør eininga du identifiserte, og avgrens tida til forsøket du granskar. Éin dag er vanlegvis nok, og eit kortare vindauge er betre når maskinen koplar til på nytt ofte.

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

Stadfest det installerte namnet før du stolar på søket. Distribusjonspakkar gir einingane nye namn, og ein profil som finst som fil er kanskje aldri aktivert som teneste. Viss eininga ikkje finst, fortel den tomme journalen deg om utrullinga og ikkje om tunnelen.

Les det første feila trinnet

Les hendingane i den rekkjefølgja dei oppstår: oppslag av endepunkt, transport, identitet, autentisering, ruteinstallasjon og den seinare feilen i applikasjonen. Den første konkrete feilen er den som er verdt å granske, fordi alt etter han er ein konsekvens.

Ei teneste som startar utan feil, beviser ikkje at kvar naudsynt ressurs er tilgjengeleg. Ei gjentilkoplingsløkke kan gi fleire atskilde forhandlingar, så hald profilenamnet og forsøkstida saman med hendingane, og les eitt forsøk i staden for ein samanslått straum. Eitt einskilt forsøk er ein sekvens med ei årsak, medan ein samanslått straum er ein vegg av gjentatte linjer. Skriv den første feilen i billetten før du les vidare.

Ikkje bland ei feila teneste med ein manuell klient

Viss du starta ein klient for hand etter at tenesta feila, går utdataa hans ein annan stad, og åtferda kan vere annleis. Fang det nye resultatet frå same eigar og same førespurnad etter ei støtta retting, slik at samanlikninga viser kva som endra seg i staden for å blande to ulike program.

Ikkje endre opphavlege tidsstempel for å tilpasse dei til ein annan vert. Noter tidssona og ein eventuell kjend klokkeskilnad separat, for ei tidslinje du har redigert er ikkje lenger bevis.

Del eit utdrag, ikkje ein eksport

Journaloppføringar kan innehalde brukarnamn, endepunktadresser, privat topologi og informasjon om skriptmiljøet. Gå gjennom det faktiske utdraget og sladd det som er sensitivt i staden for å publisere ein full, ubegrensa eksport. Siter linjene som fastslår feilen, og oppsummer resten. Eit kort gjennomgått utdrag er lettare å handle på enn ei fil ingen les.

Send det smale vindauget, einingnamnet og det første feila trinnet, og sei kva du allereie har utelukka. systemd journalctl-handboka dokumenterer veljarane og utdatavala viss du treng ei form som versjonen av distribusjonen støttar.