journalctl för VPN-loggar: vilken enhet äger anslutningen?

Börja med den systemd-enhet som faktiskt äger VPN-anslutningen, inte med loggkommandot du minns. En direkt OpenVPN-tjänst, en wg-quick-enhet och en NetworkManager-profil placerar sina användbara meddelanden i olika enheter, och en fråga mot fel enhet ger ett tomt resultat som ser ut som tystnad. Jämför de tre vanliga ägarna, snäva in fönstret och läs sedan stegen i ordning.

Jämför de tre vanliga ägarna

En OpenVPN-klienttjänst är vanligtvis en instansenhet uppkallad efter profilen, till exempel [email protected]. Dess meddelanden omfattar konfigurationssökvägen, tolkning av alternativ, TLS-handskakningen och ruttinstallationen som klienten utför.

En wg-quick-enhet är tystare av design. Gränssnittskonfigurationen sker vid start, handskakningen hanteras av kärnan och rutinmässiga nyckelbyten loggas inte som standard, så wg show är ofta mer informativt än journalen. Den skillnaden spelar roll när du jämför ett protokoll som loggar förhandlingen med ett som inte gör det.

NetworkManager äger de profiler som det skapade, och dess meddelanden ligger under NetworkManager.service även när det underliggande tillägget är en VPN-hjälpare. Fråga både hanteraren och hjälpenheten när profilen hanteras på det sättet.

Snäva in frågan till en enhet och ett fönster

Fråga enheten du identifierade och begränsa tiden till det försök du undersöker. En dag räcker oftast, och ett kortare fönster är bättre när maskinen ofta återansluter.

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

Verifiera det installerade namnet innan du litar på frågan. Distributionspaketering byter namn på enheter, och en profil som finns som fil kanske aldrig aktiverades som tjänst. Om enheten inte finns berättar den tomma journalen om driftsättningen och inte om tunneln.

Läs det första misslyckade steget

Läs händelserna i den ordning de inträffar: uppslagning av slutpunkt, transport, identitet, autentisering, ruttinstallation och den senare applikationsfel. Det första konkreta felet är det som är värt att undersöka, eftersom allt efter det är en konsekvens.

En tjänst som startar framgångsrikt bevisar inte att varje nödvändig resurs är nåbar. En återanslutningsloop kan ge flera separata förhandlingar, så håll profilnamnet och försökstiden tillsammans med händelserna och läs ett försök i stället för en sammanslagen ström. Ett enskilt försök är en sekvens med en orsak, medan en sammanslagen ström är en vägg av upprepade rader. Skriv det första felet i biljetten innan du läser vidare.

Blanda inte en misslyckad tjänst med en manuell klient

Om du startade en klient för hand efter att tjänsten misslyckades går dess utdata någon annanstans och beteendet kan skilja sig. Fånga det nya resultatet från samma ägare och samma begäran efter en stödd rättelse, så att jämförelsen visar vad som ändrades i stället för att blanda två olika program.

Ändra inte ursprungliga tidsstämplar för att anpassa dem till en annan värd. Notera tidszonen och en eventuell känd klockavvikelse separat, för en tidslinje du har redigerat är inte längre bevis.

Dela ett utdrag, inte en export

Journalposter kan innehålla användarnamn, slutpunktsadresser, privat topologi och information om skriptmiljön. Granska det faktiska utdraget och maska det som är känsligt i stället för att publicera en fullständig obegränsad export. Citera raderna som styrker felet och sammanfatta resten. Ett kort granskat utdrag är lättare att agera på än en fil som ingen läser.

Skicka det smala fönstret, enhetsnamnet och det första misslyckade steget, och säg vad du redan har uteslutit. systemd journalctl-handboken dokumenterar väljarna och utdataalternativen om du behöver en form som distributionens version stöder.