Jak shromáždit protokoly Android VPN pro tiket podpory

Klepnete na Connect, profil se na okamžik točí a klient hlásí odpojení. Podpora žádá protokoly, vy přiložíte snímek obrazovky a vlákno na dva dny zamrzne, protože nikdo neumí říct, která část handshake vzdala. Zpráva postavená kolem jednoho pokusu, s úzkým časovým oknem a poslední dokončenou fází, posune tiket o kolo dál. Alternativa, celý den telefonních protokolů, obvykle dá člověku na druhé straně víc míst, kam se dívat.

Dva telefony na stejné bráně se mohou chovat různě, protože protokol, úložiště certifikátů, způsob ověřování nebo politika provozu nemusí souhlasit. Funguje to na mém telefonu je výchozí srovnání, ne důkaz o selhání Androidu.

Zachyťte jeden pokus místo celého dne historie

Zapište prostředí, než cokoli zopakujete: verze Androidu, výrobce a model, název a verze klienta, zvolený profil, síť, ke které jste připojeni, a čas hodin s časovým pásmem. Zapisuji také, zda je zapnutá úspora baterie nebo Data Saver, protože obojí mění, co klient smí dělat po vypnutí obrazovky.

Pak určete, který z pěti výsledků skutečně vidíte. Výzva k souhlasu nebo oprávnění se nikdy nedokončí, koncový bod je zcela nedostupný, ověření je odmítnuto, nastavení rozhraní selže po úspěšném přihlášení, nebo tunel naskočí a jeden konkrétní prostředek zůstane nedostupný. Každý má jiného vlastníka a jinou opravu a balík, který je smíchá, dostane odpověď s žádostí o nový pokus. Právě hádání mezi nimi mění hodinový tiket v týden dopisování.

Přechody jsou také důležité. Pokud se selhání objeví jen po zamknutí obrazovky nebo po přechodu z Wi-Fi na mobilní data, napište to do prvního řádku tiketu a poznamenejte minutu, kdy se to stalo.

Nejprve exportujte vlastní protokol klienta

První příloha by měla přijít z aplikace, ne z operačního systému. Většina klientů má v nastavení export diagnostického nebo spojovacího protokolu, někdy schovaný za dlouhým stisknutím textu verze, a tento export už rozumí svému stavovému automatu. Použijte ho tak, jak vyjde, místo přepisování zajímavých řádků do těla tiketu.

Přiložte první chybu a události těsně před ní, ne jen závěrečný řádek o odpojení. Čistý konec obvykle znamená, že skutečná závada nastala dřív: řetěz certifikátů, který se neověřil, jméno, které se přeložilo na nečekaném místě, nebo rozhraní, které nikdy nebylo nakonfigurováno.

Přidejte logcat jen pro otázku, kterou umíte pojmenovat

Emulátor terminálu v telefonu není systémový záznamník. Android zaznamenává své buffery jako oddělené kruhové toky, které může plně číst jen privilegovaný proces. Běžná aplikace tedy vidí svůj výstup plus omezený výřez, a tvrzení, že logcat byl prázdný, dokazuje jen málo o tom, co platforma zaznamenala.

Podporovaná cesta je autorizovaná relace ADB z počítače, který ovládáte. Zapněte možnosti pro vývojáře a ladění USB, připojte kabel a přijměte dialog s otiskem RSA na zařízení; pokud je tento dotaz zavřen, každý další příkaz selže s unauthorized a žádné zachytávání nezačne.

Než do zachytávání investujete čas, ověřte, že zařízení je opravdu tam. adb devices má vypsat sériové číslo a za ním slovo device, a cokoli, co ukazuje offline nebo unauthorized, potřebuje nejprve vyřešit kabel, dotaz nebo ovladač.

Jakmile se objeví v seznamu, začněte zachytávat několik sekund před klepnutím na Connect a zastavte hned poté, co klient rezignuje. Živé zachytávání s vědomým začátkem je lepší než výpis pořízený o dvacet minut později, protože kruhové buffery se už protočily a rané řádky, které potřebujete, mohou být pryč:

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

Filtrujte podle času a značky, ne podle slova VPN

Hledat v záznamu vpn je nejrychlejší způsob, jak ztratit řádek, který závadu vysvětluje. Ověřování certifikátů, pády procesů a změny připojení se zaznamenávají pod značkami, které VPN nikdy nezmíní, takže filtr podle klíčového slova podrží šum a zahodí důkazy.

Nejprve zužte okno, pak prioritu, pak značku. Když potřebujete jen to, co se stalo po známém okamžiku, adb logcat -v threadtime -t '11-03 20:14:00.000' přehraje nedávný konec od tohoto bodu a formát threadtime udrží časová razítka srovnatelná s vlastním exportem klienta.

Znáte-li balíček klienta, sledujte jeho proces, místo abyste hádali značky. adb shell pidof com.vendor.client vrátí PID a adb logcat --pid=1234 -v threadtime vypíše jen tento proces, zatímco adb logcat -g ukazuje, kolik místa má každý buffer, než začne přepisovat.

Začerněte tajemství a předejte jeden souvislý balík

Než cokoli opustí váš počítač, odstraňte hesla, tokeny, soukromé klíče, relační cookies a úplné identifikátory zařízení. Ponechte kódy chyb, pořadí událostí a vztahy adres, které činí závadu čitelnou, protože záznam vyčištěný za touto hranicí je stejně zbytečný jako ten, který se nikdy nefiltroval.

Pak pošlete jeden balík místo několika volných souborů: export klienta, okno ADB pojmenované podle začátku a konce, dvouřádkové shrnutí fáze, která selhala, a poznámku o prostředí z začátku tohoto seznamu. Pokud část nelze zveřejnit veřejně, použijte soukromý kanál podpory poskytovatele a řekněte, který soubor tento kanál potřebuje.

Před odesláním zkontrolujte čtyři věci. Pokrývá balík jeden pokus, a ne celé odpoledne? Překrývají se časová razítka klienta a systému? A obsahuje ještě token, heslo nebo úplný identifikátor předplatitele? Nejprve opravte tento poslední bod, pak přiložte soubory k existujícímu tiketu, místo abyste otevírali nový, aby ten, kdo ho převezme, zachoval dřívější kontext.