journalctl za dnevnike VPN: katera enota ima povezavo?
OpenVPN, wg-quick in NetworkManager pišejo v različne enote. Izberite lastnika, zožite časovno okno in nato po vrsti preberite prvo neuspešno stopnjo.
Začnite z enoto systemd, ki dejansko ima povezavo VPN, ne s ukazom za dnevnik, ki se ga spomnite. Neposredna storitev OpenVPN, enota wg-quick in profil NetworkManager svoja koristna sporočila postavljajo v različne enote, poizvedba po napačni enoti pa vrne prazen rezultat, ki je videti kot tišina. Primerjajte tri običajne lastnike, zožite okno in nato po vrsti preberite stopnje.
Primerjajte tri običajne lastnike
Storitev odjemalca OpenVPN je običajno instančna enota, poimenovana po profilu, na primer [email protected]. Njena sporočila vključujejo pot konfiguracije, razčlenjevanje možnosti, rokovanje TLS in namestitev poti, ki jo izvede odjemalec.
Enota wg-quick je po zasnovi tišja. Konfiguracija vmesnika se zgodi ob zagonu, rokovanje obdela jedro, redne menjave ključev pa se privzeto ne beležijo, zato je wg show pogosto bolj poučen kot dnevnik. Ta razlika je pomembna, ko primerjate protokol, ki beleži pogajanja, s takšnim, ki jih ne.
NetworkManager ima v lasti profile, ki jih je ustvaril, in njegova sporočila živijo pod NetworkManager.service tudi takrat, ko je osnovni vtičnik pomočnik VPN. Vprašajte tako upravitelja kot pomožno enoto, ko se profil upravlja na ta način.
Zožite poizvedbo na eno enoto in eno okno
Vprašajte enoto, ki ste jo prepoznali, in omejite čas na poskus, ki ga preiskujete. En dan običajno zadostuje, krajše okno pa je boljše, ko se stroj pogosto znova poveže.
journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]Preverite nameščeno ime, preden zaupate poizvedbi. Pakiranje distribucije preimenuje enote in profil, ki obstaja kot datoteka, morda ni bil nikoli omogočen kot storitev. Če enota ne obstaja, vam prazen dnevnik govori o uvajanju in ne o tunelu.
Preberite prvo neuspešno stopnjo
Preberite dogodke v vrstnem redu, v katerem se zgodijo: iskanje končne točke, prenos, identiteta, preverjanje pristnosti, namestitev poti in poznejša odpoved aplikacije. Prva konkretna odpoved je tista, ki jo je vredno preiskati, ker je vse za njo posledica.
Storitev, ki se uspešno zažene, ne dokazuje, da je vsak potreben vir dosegljiv. Zanka ponovnega povezovanja lahko ustvari več ločenih pogajanj, zato imejte ime profila in čas poskusa skupaj z dogodki in berite en poskus namesto združenega toka. En poskus je zaporedje z vzrokom, medtem ko je združen tok zid ponovljenih vrstic. Preden berete naprej, zapišite prvo napako v zahtevek.
Ne mešajte neuspešne storitve z ročnim odjemalcem
Če ste odjemalca zagnali ročno po tem, ko je storitev odpovedala, gre njegov izhod drugam in vedenje je lahko drugačno. Po podprtem popravku zajemite nov rezultat pri istem lastniku in isti zahtevi, da primerjava pokaže, kaj se je spremenilo, namesto da bi zmešala dva različna programa.
Ne spreminjajte izvirnih časovnih žigov, da bi jih poravnali z drugim gostiteljem. Ločeno zabeležite časovni pas in morebitno znano razliko ure, ker časovnica, ki ste jo uredili, ni več dokaz.
Delite izvleček, ne izvoza
Vnosi v dnevniku lahko vsebujejo uporabniška imena, naslove končnih točk, zasebno topologijo in podatke o okolju skriptov. Preglejte dejanski izvleček in prekrijte občutljivo, namesto da objavite popoln neomejen izvoz. Citirajte vrstice, ki dokazujejo odpoved, in povzemite ostalo. Kratek pregledan izvleček je lažje uporabiti kot datoteka, ki je nihče ne bere.
Pošljite ozko okno, ime enote in prvo neuspešno stopnjo ter povejte, kaj ste že izključili. Priročnik systemd journalctl dokumentira izbirnike in možnosti izhoda, če potrebujete obliko, ki jo podpira različica distribucije.