Einen einzelnen VPN-Versuch in der macOS-Konsole aufzeichnen

Sie suchen das Mac-VPN-Protokoll, finden eine Anleitung, die auf eine PPP-Datei verweist, die es auf diesem Rechner nicht gibt, und schließen daraus, dass nichts aufgezeichnet wurde. Dieser Schluss ist meist falsch. Der Eintrag existiert im einheitlichen Protokoll, und die fehlende Datei bedeutet, dass dieses Deployment nicht zu denen gehört, die sie schreiben, nicht dass der Versuch nicht protokolliert wurde. Beides zu verwechseln schickt Leute eine Stunde lang los, ein Negativ zu beweisen.

Ein natives VPN, Tunnelblick und der eigene Client eines Anbieters können alle unterschiedliche Protokolleigentümer haben. Beginnen Sie mit der unterstützten Protokollansicht des Clients, wenn er eine anbietet, und greifen Sie zur Konsole, wenn Sie die System- oder Anbietereignisse rund um den Versuch brauchen.

Wählen Sie den Client, der tatsächlich fehlgeschlagen ist

Notieren Sie die macOS-Version, die Client-Version, den Verbindungsnamen und das Protokoll, bevor Sie etwas öffnen. Diese vier Angaben entscheiden, nach welchem Prozessnamen Sie suchen, und sie sind das Erste, wonach ein Support-Mitarbeiter Sie fragt.

Wurde die Verbindung über einen Menüleisteneintrag eines Anbieter-Clients gestartet, können die interessanten Meldungen von diesem Client statt vom VPN-Anbieter des Systems kommen. Wurde sie über die eigene VPN-Leiste des Systems gestartet, ist der Anbieterprozess der richtige Suchpunkt. Raten zwischen beiden kostet einen Versuch, prüfen Sie also zuerst, welche Anwendung die Verbindung besitzt.

Starten Sie die Live-Ansicht vor dem Versuch

Öffnen Sie die Konsole und wählen Sie diesen Mac unter Devices, nicht ein angeschlossenes Telefon und kein altes Berichtsbündel. Klicken Sie in der Werkzeugleiste auf Start, damit der Strom live ist, und notieren Sie dann die Zeit mit ihrer Zeitzone. Nutzen Sie Administratorzugriff, wenn die Ansicht ihn verlangt, und fragen Sie auf einem verwalteten Mac den Eigentümer nach diesem Zugriff, statt ihn zu umgehen.

Machen Sie nun einen normalen Verbindungsversuch und notieren Sie den sichtbaren Fehler. Ein Versuch zählt: Ein zweiter Wiederholungsversuch hängt neue Ereignisse an denselben Strom, und zwei Versuche in einem Fenster zu mischen, führt dazu, dass Leute den falschen Handshake untersuchen.

Nichts davon verspricht, dass bereits eine Spur existiert. Die Konsole ist ein Sammelverfahren, und Sie schaffen die Bedingungen für eine saubere Aufzeichnung, statt etwas abzurufen, das vorher aufgezeichnet wurde.

Grenzen Sie nach Prozess ein, nicht nach Hörensagen

Beginnen Sie weit genug, um den Eigentümer zu erkennen, und verfeinern Sie dann mit den Prozess- und Nachrichteneigenschaften, die in Ihrer Aufzeichnung tatsächlich auftauchen. Ein in einer älteren Anleitung zitierter Anbietername ist ein Hinweis für eine macOS-Version und ein Protokoll, kein dauerhafter Filter. Zu früh danach zu filtern kann ein leeres Fenster erzeugen, das wie ein Protokollfehler aussieht und in Wahrheit ein Fehlgriff der Suche ist. Fügen Sie eine Bedingung hinzu, die Sie entfernen können, nicht eine, die den Beweis entfernt.

Die Konsole lässt Sie Kriterien kombinieren, und sie grenzen gemeinsam ein. Verschwinden die Ergebnisse, entfernen oder lockern Sie die restriktivste Bedingung, statt eine weitere hinzuzufügen. Nur den letzten Fehler anzuzeigen ist ein häufiger Fehler, denn das Ereignis, das den Fehler erklärt, erscheint meist einige Zeilen früher.

Behalten Sie genug Kontext, um eine Frage zu beantworten

Klappen Sie die relevante Meldung auf und lesen Sie ihre Details, und behalten Sie dann den ersten aussagekräftigen Fehler zusammen mit den Verbindungsereignissen darum herum. Eine einzelne Zeile, die sagt, die Verbindung sei beendet worden, sagt dem Leser nichts über das Warum.

Sagen Sie genau, welche Stufe der Eintrag belegt: ein lokaler Anbieter oder Dienst, der nie startete, ein Austausch mit der Gegenseite, eine Ablehnung bei der Authentifizierung oder eine spätere Beschwerde über Routing oder Namensauflösung. Eine Meldung über einen startenden Prozess ist kein Beweis, dass ein Handshake abgeschlossen wurde, und eine Routenwarnung nach erfolgreicher Verbindung beschreibt einen anderen Fehler als eine gescheiterte.

Führt der Client sein eigenes Protokoll, vergleichen Sie denselben Versuch dort, statt ein aktuelles Konsolenereignis mit einem anderen Wiederholungsversuch aus einer rein anfügenden Datei zu kombinieren. Anleitungen zur alten PPP-Datei gehören nur zu einem Deployment, das diese Datei noch erzeugt.

Teilen Sie den kleinsten nützlichen Auszug

Wählen Sie die relevanten Meldungen und nutzen Sie die unterstützte Share-Aktion für den vorgesehenen Empfänger. Fügen Sie die Versions- und Zeitangaben hinzu und prüfen Sie dann interne Hostnamen, Kontokennungen, Adressen und unzusammenhängende Ereignisse, bevor Sie senden. Ein ganzes Diagnosearchiv ist leicht anzuhängen und später schwer zu rechtfertigen.

Rechnen Sie damit, dass unter der aktuellen Datenschutz- oder Protokollierungskonfiguration einige Ereignisse fehlen. Nutzen Sie dann das Diagnoseverfahren, das Ihr Anbieter oder Administrator vorschreibt, und widerstehen Sie dem Drang, systemweite Schutzmaßnahmen abzuschalten, um mehr Verlauf zu sammeln. Die Übergabe, die sich lohnt, ist klein: welcher Client, welches Protokoll, wann der Versuch stattfand, sein erstes relevantes Ereignis und was darauf folgte.