Jak zebrać logi VPN z Androida do zgłoszenia wsparcia

Naciskasz Connect, profil kręci się sekundę, a klient zgłasza rozłączenie. Wsparcie prosi o logi, dołączasz zrzut ekranu, a wątek stoi dwa dni, bo nikt nie potrafi powiedzieć, która część uzgadniania połączenia się poddała. Raport zbudowany wokół jednej próby, z wąskim oknem czasu i ostatnim ukończonym etapem, przesuwa zgłoszenie do przodu w jednej rundzie. Alternatywa, cały dzień logów telefonu, zwykle daje osobie po drugiej stronie więcej miejsc do sprawdzenia.

Dwa telefony w tej samej bramie mogą zachowywać się różnie, bo protokół, magazyn certyfikatów, metoda uwierzytelniania lub polityka ruchu mogą się nie zgadzać. Działa na moim telefonie to punkt wyjścia do porównania, nie dowód awarii Androida.

Zarejestruj jedną próbę zamiast całego dnia historii

Zapisz środowisko, zanim cokolwiek odtworzysz: wersję Androida, producenta i model, nazwę i wersję klienta, wybrany profil, sieć, do której jesteś podłączony, oraz czas zegara ze strefą czasową. Notuję też, czy włączone jest oszczędzanie baterii lub Data Saver, bo oba zmieniają to, co klient może robić po wyłączeniu ekranu.

Potem ustal, który z pięciu wyników naprawdę widzisz. Monit o zgodę lub uprawnienie nigdy się nie kończy, punkt końcowy jest w ogóle nieosiągalny, uwierzytelnianie zostaje odrzucone, konfiguracja interfejsu nie udaje się po udanym logowaniu albo tunel wstaje i jeden konkretny zasób pozostaje nieosiągalny. Każdy z nich ma innego właściciela i inne rozwiązanie, a pakiet, który je miesza, dostaje odpowiedź z prośbą o ponowną próbę. Zgadywanie między nimi zamienia zgłoszenie na godzinę w tydzień korespondencji.

Przejścia też mają znaczenie. Jeśli błąd pojawia się tylko po zablokowaniu ekranu albo po przejściu z Wi-Fi na dane mobilne, wpisz to w pierwszej linii zgłoszenia i zanotuj minutę, w której to nastąpiło.

Najpierw wyeksportuj własny log klienta

Pierwszy załącznik powinien pochodzić z aplikacji, a nie z systemu operacyjnego. Większość klientów udostępnia w ustawieniach eksport logu diagnostycznego lub połączenia, czasem ukryty pod długim naciśnięciem ciągu wersji, a ten eksport już rozumie własną maszynę stanów. Użyj go tak, jak wychodzi, zamiast przepisywać ciekawe linie do treści zgłoszenia.

Załącz pierwszy błąd i zdarzenia bezpośrednio przed nim, a nie tylko ostatnią linię o rozłączeniu. Czysty ogon zwykle oznacza, że prawdziwa awaria nastąpiła wcześniej: łańcuch certyfikatów, który się nie walidował, nazwa rozwiązana w nieoczekiwanym miejscu albo interfejs, który nigdy nie został skonfigurowany.

Dodawaj logcat tylko do pytania, które potrafisz nazwać

Emulator terminala na telefonie nie jest rejestratorem systemowym. Android zapisuje swoje bufory jako osobne strumienie pierścieniowe, które w całości mogą czytać tylko uprzywilejowane procesy. Zwykła aplikacja widzi więc własne wyjście plus ograniczony fragment, a stwierdzenie, że logcat był pusty, dowodzi bardzo niewiele o tym, co zapisała platforma.

Wspierana droga to autoryzowana sesja ADB z komputera, który kontrolujesz. Włącz opcje programisty i debugowanie USB, podłącz kabel i zaakceptuj okno odcisku RSA na urządzeniu; jeśli ten monit zostanie zamknięty, każde kolejne polecenie kończy się błędem unauthorized i żadne przechwytywanie się nie zaczyna.

Zanim zainwestujesz czas w przechwytywanie, potwierdź, że urządzenie naprawdę tam jest. adb devices powinien wypisać numer seryjny, a po nim słowo device, a wszystko, co pokazuje offline lub unauthorized, wymaga najpierw uporządkowania kabla, monitu lub sterownika.

Gdy pojawi się na liście, zacznij przechwytywać kilka sekund przed naciśnięciem Connect i zatrzymaj zaraz po tym, jak klient się podda. Przechwytywanie na żywo ze świadomym startem bije zrzut wzięty dwadzieścia minut później, bo bufory pierścieniowe już się obróciły i wczesne linie, których potrzebujesz, mogą zniknąć:

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

Filtruj według czasu i tagu, a nie słowa VPN

Szukanie vpn w przechwyceniu to najszybszy sposób utraty linii, która wyjaśnia awarię. Walidacja certyfikatów, awarie procesów i zmiany łączności są zapisywane pod tagami, które nigdy nie wspominają VPN, więc filtr po słowie kluczowym zachowuje szum i wyrzuca dowody.

Najpierw zawęź okno, potem priorytet, potem tag. Gdy potrzebujesz tylko tego, co stało się po znanym momencie, adb logcat -v threadtime -t '11-03 20:14:00.000' odtwarza ostatni ogon od tego punktu, a format threadtime utrzymuje znaczniki czasu porównywalne z własnym eksportem klienta.

Jeśli znasz pakiet klienta, śledź jego proces zamiast zgadywać tagi. adb shell pidof com.vendor.client zwraca PID, a adb logcat --pid=1234 -v threadtime wypisuje tylko ten proces, podczas gdy adb logcat -g pokazuje, ile miejsca ma każdy bufor, zanim zacznie nadpisywać.

Ukryj sekrety, a potem przekaż jeden spójny pakiet

Zanim cokolwiek opuści twoją maszynę, usuń hasła, tokeny, klucze prywatne, ciasteczka sesji i pełne identyfikatory urządzenia. Zachowaj kody błędów, kolejność zdarzeń i relacje adresów, które czynią awarię czytelną, bo przechwycenie oczyszczone poza tym punktem jest tak samo bezużyteczne jak to, które nigdy nie zostało przefiltrowane.

Potem wyślij jeden pakiet zamiast kilku luźnych plików: eksport klienta, okno ADB nazwane godziną startu i stopu, dwuliniowe podsumowanie etapu, który zawiódł, oraz notatkę o środowisku ze szczytu tej listy. Jeśli część nie może być opublikowana publicznie, użyj prywatnego kanału wsparcia dostawcy i powiedz, który plik potrzebuje tego kanału.

Przed wysłaniem sprawdź cztery rzeczy. Czy pakiet obejmuje jedną próbę, a nie całe popołudnie? Czy znaczniki czasu klienta i systemu się pokrywają? I czy nadal zawiera token, hasło lub pełny identyfikator abonenta? Najpierw napraw ten ostatni punkt, a potem dołącz pliki do istniejącego zgłoszenia zamiast otwierać nowe, aby przejmująca osoba zachowała wcześniejszy kontekst.