Android-VPN-Protokolle für ein Support-Ticket sammeln

Sie tippen auf Verbinden, das Profil dreht sich eine Sekunde, und der Client meldet getrennt. Der Support bittet um Protokolle, Sie hängen einen Screenshot an, und der Thread steht zwei Tage still, weil niemand sagen kann, welcher Teil des Handshakes aufgegeben hat. Ein Bericht, der um einen einzigen Versuch herum gebaut ist, mit einem engen Zeitfenster und der letzten abgeschlossenen Stufe, bringt das Ticket in einer Runde voran. Die Alternative, ein ganzer Tag Telefonprotokolle, gibt der Person auf der anderen Seite meist mehr Stellen zum Nachsehen.

Zwei Telefone am selben Gateway können sich trotzdem unterschiedlich verhalten, weil Protokoll, Zertifikatsspeicher, Authentifizierungsmethode oder Verkehrsrichtlinie nicht übereinstimmen müssen. Es funktioniert auf meinem iPhone ist ein Ausgangspunkt für den Vergleich, kein Beweis für einen Android-Fehler.

Einen Versuch festhalten statt eines Tages Geschichte

Notieren Sie die Umgebung, bevor Sie etwas reproduzieren: Android-Version, Hersteller und Modell, Clientname und -version, das gewählte Profil, das Netzwerk, mit dem Sie verbunden sind, und die Uhrzeit mit ihrer Zeitzone. Ich notiere auch, ob Energiesparmodus oder Datensparmodus aktiv ist, weil beides ändert, was der Client tun darf, sobald der Bildschirm ausgeht.

Dann entscheiden Sie, welches der fünf Ergebnisse Sie tatsächlich sehen. Die Zustimmungs- oder Berechtigungsabfrage wird nie abgeschlossen, der Endpunkt ist überhaupt nicht erreichbar, die Authentifizierung wird abgelehnt, die Einrichtung der Schnittstelle scheitert nach erfolgreicher Anmeldung, oder der Tunnel kommt hoch und eine bestimmte Ressource bleibt unerreichbar. Jedes davon hat einen anderen Zuständigen und eine andere Lösung, und ein Paket, das sie vermischt, bekommt die Antwort, es erneut zu versuchen. Das Raten zwischen ihnen macht aus einem einstündigen Ticket eine Woche Hin und Her.

Auch Übergänge zählen. Wenn der Fehler nur nach der Bildschirmsperre oder nach dem Wechsel von WLAN zu Mobilfunkdaten auftritt, schreiben Sie das in die erste Zeile des Tickets und notieren Sie die Minute, in der es passierte.

Zuerst das eigene Protokoll des Clients exportieren

Der erste Anhang sollte aus der App kommen und nicht aus dem Betriebssystem. Die meisten Clients bieten in den Einstellungen einen Export des Diagnose- oder Verbindungsprotokolls, manchmal hinter einem langen Druck auf die Versionszeichenfolge versteckt, und dieser Export versteht seine eigene Zustandsmaschine. Verwenden Sie ihn so, wie er kommt, statt die interessanten Zeilen in den Tickettext abzutippen.

Hängen Sie den ersten Fehler und die Ereignisse unmittelbar davor an, nicht nur die letzte Zeile der Trennung. Ein sauberes Ende bedeutet meist, dass der eigentliche Fehler früher passierte: eine Zertifikatskette, die nicht validierte, ein Name, der an einer unerwarteten Stelle aufgelöst wurde, oder eine Schnittstelle, die nie konfiguriert wurde.

logcat nur für eine Frage hinzufügen, die Sie benennen können

Ein Terminal-Emulator auf dem Telefon ist kein Systemlogger. Android protokolliert seine Puffer als getrennte ringförmige Ströme, die nur privilegierte Prozesse vollständig lesen können. Eine gewöhnliche App sieht daher ihre eigene Ausgabe plus einen eingeschränkten Ausschnitt, und die Aussage, logcat sei leer gewesen, beweist sehr wenig darüber, was die Plattform aufgezeichnet hat.

Der unterstützte Weg ist eine autorisierte ADB-Sitzung von einem Computer, den Sie kontrollieren. Aktivieren Sie Entwickleroptionen und USB-Debugging, schließen Sie das Kabel an und akzeptieren Sie den RSA-Fingerabdruckdialog auf dem Gerät; wird diese Abfrage weggeklickt, scheitert jeder spätere Befehl mit unauthorized, und keine Aufzeichnung beginnt.

Bestätigen Sie, dass das Gerät wirklich da ist, bevor Sie Zeit in eine Aufzeichnung stecken. adb devices sollte die Seriennummer gefolgt vom Wort device ausgeben, und alles, was offline oder unauthorized anzeigt, braucht zuerst Kabel, Abfrage oder Treiber in Ordnung.

Sobald es gelistet ist, beginnen Sie einige Sekunden vor dem Tippen auf Verbinden mit der Aufzeichnung und stoppen Sie kurz nachdem der Client aufgibt. Eine Live-Aufzeichnung mit bewusstem Start schlägt einen zwanzig Minuten später genommenen Dump, weil die Ringpuffer sich bereits gedreht haben und die frühen Zeilen, die Sie brauchen, weg sein können:

adb logcat -v threadtime -b main,system,crash > attempt.txt

Nach Zeit und Tag filtern statt nach dem Wort VPN

Eine Aufzeichnung nach vpn zu durchsuchen ist der schnellste Weg, die Zeile zu verlieren, die den Fehler erklärt. Zertifikatsvalidierung, Prozessabstürze und Konnektivitätsänderungen werden unter Tags protokolliert, die VPN nie erwähnen, sodass ein Stichwortfilter den Lärm behält und die Beweise wegwirft.

Verengen Sie zuerst das Fenster, dann die Priorität, dann den Tag. Wenn Sie nur brauchen, was nach einem bekannten Moment geschah, spielt adb logcat -v threadtime -t '11-03 20:14:00.000' das jüngste Ende ab diesem Punkt erneut ab, und das Format threadtime hält Zeitstempel mit dem eigenen Export des Clients vergleichbar.

Wenn Sie das Client-Paket kennen, folgen Sie seinem Prozess, statt Tags zu raten. adb shell pidof com.vendor.client gibt eine PID zurück, und adb logcat --pid=1234 -v threadtime gibt nur diesen Prozess aus, während adb logcat -g zeigt, wie viel Platz jeder Puffer hat, bevor er zu überschreiben beginnt.

Geheimnisse schwärzen, dann ein zusammenhängendes Paket übergeben

Bevor etwas Ihren Rechner verlässt, entfernen Sie Passwörter, Token, private Schlüssel, Sitzungscookies und vollständige Gerätekennungen. Behalten Sie die Fehlercodes, die Reihenfolge der Ereignisse und die Adressbeziehungen, die den Fehler lesbar machen, denn eine Aufzeichnung, die über diesen Punkt hinaus bereinigt wurde, ist so nutzlos wie eine, die nie gefiltert wurde.

Senden Sie dann ein Paket statt mehrerer loser Dateien: den Client-Export, das ADB-Fenster mit Start- und Stoppzeit im Namen, eine zweizeilige Zusammenfassung der gescheiterten Stufe und die Umgebungsnotiz von oben in dieser Liste. Wenn ein Teil nicht öffentlich gepostet werden kann, nutzen Sie den privaten Supportkanal des Anbieters und sagen Sie, welche Datei diesen Kanal braucht.

Prüfen Sie vor dem Senden vier Dinge. Deckt das Paket einen Versuch ab statt einen ganzen Nachmittag? Überlappen sich die Zeitstempel von Client und System? Und enthält es noch ein Token, ein Passwort oder eine vollständige Teilnehmerkennung? Beheben Sie zuerst diesen letzten Punkt und hängen Sie die Dateien dann an das bestehende Ticket an, statt ein neues zu öffnen, damit wer es übernimmt, den früheren Kontext behält.