journalctl për regjistrat e VPN: cila njësi zotëron lidhjen?

Filloni me njësinë systemd që zotëron vërtet lidhjen VPN, jo me komandën e regjistrit që mbani mend. Një shërbim i drejtpërdrejtë OpenVPN, një njësi wg-quick dhe një profil NetworkManager i vendosin mesazhet e tyre të dobishme në njësi të ndryshme, dhe një pyetës kundër njësisë së gabuar jep një rezultat bosh që duket si heshtje. Krahasoni tre pronarët e zakonshëm, ngushtoni dritaren dhe më pas lexoni fazat me radhë.

Krahasoni tre pronarët e zakonshëm

Një shërbim klienti OpenVPN është zakonisht një njësi instance e quajtur sipas profilit, si [email protected]. Mesazhet e tij përfshijnë rrugën e konfigurimit, analizën e opsioneve, shtrëngimin e duarve TLS dhe instalimin e rrugëve që bën klienti.

Një njësi wg-quick është më e qetë nga ndërtimi. Konfigurimi i ndërfaqes ndodh në nisje, shtrëngimin e duarve e trajton kerneli dhe ripërtëritjet rutinë të çelësave nuk regjistrohen si parazgjedhje, prandaj wg show shpesh është më informativ se regjistri. Ky ndryshim ka rëndësi kur krahason një protokoll që regjistron negociatat me një që nuk e bën.

NetworkManager zotëron profilet që ka krijuar, dhe mesazhet e tij jetojnë nën NetworkManager.service edhe kur shtojca bazë është një ndihmës VPN. Pyetni edhe menaxherin edhe njësinë ndihmëse kur profili administrohet në atë mënyrë.

Ngushtoni pyetësin në një njësi dhe një dritare

Pyetni njësinë që identifikuat dhe kufizoni kohën në përpjekjen që po hetoni. Një ditë zakonisht mjafton, dhe një dritare më e shkurtër është më e mirë kur makina rilidhet shpesh.

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

Verifikoni emrin e instaluar përpara se t'i besoni pyetësit. Paketimi i distribucionit i riemërton njësitë, dhe një profil që ekziston si skedar mund të mos jetë aktivizuar kurrë si shërbim. Nëse njësia nuk ekziston, regjistri bosh ju flet për vendosjen dhe jo për tunelin.

Lexoni fazën e parë të dështuar

Lexoni ngjarjet sipas radhës që ndodhin: kërkimi i pikës fundore, transporti, identiteti, vërtetimi, instalimi i rrugëve dhe dështimi i mëpasshëm i aplikacionit. Dështimi i parë konkret është ai që ia vlen të hetohet, sepse gjithçka pas tij është pasojë.

Një shërbim që niset me sukses nuk provon se çdo burim i nevojshëm është i arritshëm. Një cikël rilidhjeje mund të prodhojë disa negociata të veçanta, prandaj mbajini emrin e profilit dhe kohën e përpjekjes bashkë me ngjarjet, dhe lexoni një përpjekje në vend të një rryme të bashkuar. Një përpjekje e vetme është një sekuencë me shkak, ndërsa një rrymë e bashkuar është një mur rreshtash të përsëritur. Shkruani gabimin e parë në biletë përpara se të lexoni më tej.

Mos përzieni një shërbim të dështuar me një klient manual

Nëse e keni nisur klientin me dorë pasi shërbimi dështoi, dalja e tij shkon diku tjetër dhe sjellja mund të ndryshojë. Kapni rezultatin e ri nga i njëjti pronar dhe i njëjti kërkesë pas një korrigjimi të mbështetur, që krahasimi të tregojë çfarë ndryshoi në vend që të përziejë dy programe të ndryshme.

Mos i ndryshoni vulat kohore origjinale për t'i rreshtuar me një host tjetër. Shënoni veçmas zonën kohore dhe çdo diferencë të njohur të orës, sepse një kronologji që keni redaktuar nuk është më provë.

Ndani një fragment, jo një eksportim

Regjistrimet mund të përmbajnë emra përdoruesish, adresa pikash fundore, topologji private dhe informacion mbi mjedisin e skripteve. Shqyrtoni fragmentin aktual dhe fshihni atë që është e ndjeshme në vend që të publikoni një eksportim të plotë pa kufizime. Citoni rreshtat që vërtetojnë dështimin dhe përmblidhni pjesën tjetër. Një fragment i shkurtër i shqyrtuar është më i lehtë për t'u përdorur sesa një skedar që askush nuk e lexon.

Dërgoni dritaren e ngushtë, emrin e njësisë dhe fazën e parë të dështuar, dhe thoni çfarë keni përjashtuar tashmë. Manuali systemd journalctl dokumenton përzgjedhësit dhe opsionet e daljes nëse ju nevojitet një formë që versioni i distribucionit e mbështet.