journalctl für VPN-Protokolle: Welche Unit besitzt die Verbindung?

Beginnen Sie mit der systemd-Unit, die die VPN-Verbindung tatsächlich besitzt, nicht mit dem Logbefehl, an den Sie sich erinnern. Ein direkter OpenVPN-Dienst, eine wg-quick-Unit und ein NetworkManager-Profil legen ihre nützlichen Meldungen in unterschiedlichen Units ab, und eine Abfrage gegen die falsche Unit liefert ein leeres Ergebnis, das wie Stille aussieht. Vergleichen Sie die drei üblichen Eigentümer, grenzen Sie das Fenster ein und lesen Sie dann die Stufen der Reihe nach.

Vergleichen Sie die drei üblichen Eigentümer

Ein OpenVPN-Clientdienst ist normalerweise eine Instanz-Unit, die nach dem Profil benannt ist, etwa [email protected]. Ihre Meldungen umfassen den Konfigurationspfad, das Auswerten der Optionen, den TLS-Handshake und die Routeninstallation, die der Client vornimmt.

Eine wg-quick-Unit ist konstruktionsbedingt stiller. Die Schnittstellenkonfiguration geschieht beim Start, den Handshake übernimmt der Kernel, und routinemäßige Schlüsselerneuerungen werden standardmäßig nicht protokolliert, daher ist wg show oft aufschlussreicher als das Journal. Dieser Unterschied zählt, wenn Sie ein Protokoll, das die Aushandlung protokolliert, mit einem vergleichen, das dies nicht tut.

NetworkManager besitzt die von ihm erstellten Profile, und seine Meldungen liegen unter NetworkManager.service, selbst wenn das zugrunde liegende Plugin ein VPN-Helfer ist. Fragen Sie sowohl den Manager als auch die Helfer-Unit ab, wenn das Profil so verwaltet wird.

Grenzen Sie die Abfrage auf eine Unit und ein Fenster ein

Fragen Sie die Unit ab, die Sie bestimmt haben, und begrenzen Sie die Zeit auf den Versuch, den Sie untersuchen. Ein Tag ist normalerweise genug, und ein kürzeres Fenster ist besser, wenn die Maschine sich häufig neu verbindet.

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

Prüfen Sie den installierten Namen, bevor Sie der Abfrage trauen. Distributionspakete benennen Units um, und ein Profil, das als Datei existiert, wurde vielleicht nie als Dienst aktiviert. Wenn die Unit nicht existiert, sagt Ihnen das leere Journal etwas über die Bereitstellung und nicht über den Tunnel.

Lesen Sie die erste fehlgeschlagene Stufe

Lesen Sie die Ereignisse in der Reihenfolge ihres Auftretens: Endpunktsuche, Transport, Identität, Authentifizierung, Routeninstallation und das spätere Scheitern der Anwendung. Der erste konkrete Fehler ist der, der untersucht werden sollte, denn alles danach ist eine Folge.

Ein Dienst, der erfolgreich startet, belegt nicht, dass jede benötigte Ressource erreichbar ist. Eine Wiederverbindungsschleife kann mehrere getrennte Aushandlungen erzeugen, daher halten Sie Profilnamen und Versuchszeit bei den Ereignissen und lesen einen Versuch statt eines zusammengeführten Stroms. Ein einzelner Versuch ist eine Abfolge mit einer Ursache, während ein zusammengeführter Strom eine Wand aus wiederholten Zeilen ist. Schreiben Sie den ersten Fehler ins Ticket, bevor Sie weiterlesen.

Mischen Sie keinen fehlgeschlagenen Dienst mit einem manuellen Client

Wenn Sie nach dem Fehlschlagen des Dienstes einen Client von Hand gestartet haben, geht seine Ausgabe woanders hin, und sein Verhalten kann abweichen. Erfassen Sie das neue Ergebnis vom selben Eigentümer und derselben Anfrage nach einer unterstützten Korrektur, damit der Vergleich zeigt, was sich geändert hat, statt zwei verschiedene Programme zu mischen.

Verändern Sie keine ursprünglichen Zeitstempel, um sie an einen anderen Host anzugleichen. Notieren Sie die Zeitzone und eine bekannte Uhrabweichung getrennt, denn eine bearbeitete Zeitachse ist kein Beweis mehr.

Teilen Sie einen Auszug, keinen Export

Journal-Einträge können Benutzernamen, Endpunktadressen, private Topologie und Informationen zur Skriptumgebung enthalten. Prüfen Sie den tatsächlichen Auszug und schwärzen Sie Sensibles, statt einen vollständigen uneingeschränkten Export zu veröffentlichen. Zitieren Sie die Zeilen, die den Fehler belegen, und fassen Sie den Rest zusammen. Ein kurzer geprüfter Auszug ist leichter umzusetzen als eine Datei, die niemand liest.

Senden Sie das enge Fenster, den Unit-Namen und die erste fehlgeschlagene Stufe und sagen Sie, was Sie bereits ausgeschlossen haben. Das systemd-journalctl-Handbuch dokumentiert die Selektoren und Ausgabeoptionen, falls Sie eine Form benötigen, die die Version der Distribution unterstützt.