Cara mengumpulkan log VPN Android untuk tiket dukungan

Anda menekan Connect, profil berputar sebentar, dan klien melaporkan terputus. Dukungan meminta log, Anda melampirkan tangkapan layar, dan utas berhenti dua hari karena tidak ada yang bisa mengatakan bagian handshake mana yang menyerah. Laporan yang dibangun di sekitar satu percobaan, dengan jendela waktu sempit dan tahap terakhir yang selesai, memajukan tiket dalam satu putaran. Alternatifnya, log ponsel sehari penuh, biasanya memberi orang di seberang lebih banyak tempat untuk melihat.

Dua ponsel pada gateway yang sama tetap bisa berperilaku berbeda, karena protokol, penyimpanan sertifikat, metode autentikasi, atau kebijakan lalu lintas mungkin tidak cocok. Ini berfungsi di ponsel saya adalah titik awal perbandingan, bukan bukti kegagalan Android.

Tangkap satu percobaan, bukan riwayat sehari

Catat lingkungan sebelum mereproduksi apa pun: versi Android, pabrikan dan model, nama dan versi klien, profil yang Anda pilih, jaringan tempat Anda terhubung, dan waktu jam beserta zona waktunya. Saya juga mencatat apakah penghemat baterai atau Data Saver aktif, karena keduanya mengubah apa yang boleh dilakukan klien setelah layar mati.

Lalu tentukan mana dari lima hasil yang sebenarnya Anda lihat. Prompt persetujuan atau izin tidak pernah selesai, endpoint sama sekali tidak dapat dijangkau, autentikasi ditolak, penyiapan antarmuka gagal setelah login berhasil, atau tunnel naik dan satu sumber daya tertentu tetap tidak terjangkau. Masing-masing punya pemilik dan perbaikan berbeda, dan bundel yang mencampurnya mendapat balasan agar mencoba lagi. Menebak di antara mereka adalah yang mengubah tiket satu jam menjadi seminggu bolak-balik.

Transisi juga penting. Jika kegagalan hanya muncul setelah layar dikunci atau setelah peralihan dari Wi-Fi ke data seluler, tuliskan itu di baris pertama tiket dan catat menit kejadiannya.

Ekspor dulu log milik klien sendiri

Lampiran pertama sebaiknya berasal dari aplikasi, bukan dari sistem operasi. Sebagian besar klien menyediakan ekspor log diagnostik atau log koneksi di pengaturan, kadang tersembunyi di balik tekan lama pada string versi, dan ekspor itu sudah memahami mesin keadaannya sendiri. Gunakan apa adanya alih-alih mengetik ulang baris menarik ke isi tiket.

Lampirkan kesalahan pertama dan peristiwa tepat sebelumnya, bukan hanya baris terputus terakhir. Ekor yang bersih biasanya berarti kegagalan sebenarnya terjadi lebih awal: rantai sertifikat yang tidak tervalidasi, nama yang ter-resolve di tempat tak terduga, atau antarmuka yang tidak pernah dikonfigurasi.

Tambahkan logcat hanya untuk pertanyaan yang bisa Anda sebutkan

Emulator terminal di ponsel bukan pencatat sistem. Android mencatat buffer-nya sebagai aliran melingkar terpisah yang hanya dapat dibaca penuh oleh proses berhak istimewa. Jadi aplikasi biasa melihat keluarannya sendiri plus potongan terbatas, dan pernyataan bahwa logcat kosong membuktikan sangat sedikit tentang apa yang direkam platform.

Jalur yang didukung adalah sesi ADB resmi dari komputer yang Anda kendalikan. Aktifkan opsi pengembang dan debugging USB, sambungkan kabel, dan terima dialog sidik jari RSA di perangkat; jika prompt itu ditutup, setiap perintah berikutnya gagal dengan unauthorized dan tidak ada tangkapan yang pernah dimulai.

Pastikan perangkat benar-benar ada sebelum menginvestasikan waktu untuk menangkap. adb devices seharusnya mencetak nomor seri diikuti kata device, dan apa pun yang menampilkan offline atau unauthorized perlu membereskan kabel, prompt, atau driver lebih dulu.

Setelah terdaftar, mulai menangkap beberapa detik sebelum menekan Connect dan berhenti tepat setelah klien menyerah. Tangkapan langsung dengan awal yang disengaja mengalahkan dump yang diambil dua puluh menit kemudian, karena buffer melingkar sudah berputar dan baris awal yang Anda butuhkan mungkin sudah hilang:

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

Filter berdasarkan waktu dan tag, bukan kata VPN

Mencari vpn dalam tangkapan adalah cara tercepat kehilangan baris yang menjelaskan kegagalan. Validasi sertifikat, crash proses, dan perubahan konektivitas dicatat di bawah tag yang tidak pernah menyebut VPN, jadi filter kata kunci menyimpan kebisingan dan membuang buktinya.

Persempit jendela dulu, lalu prioritas, lalu tag. Saat hanya perlu apa yang terjadi setelah momen yang diketahui, adb logcat -v threadtime -t '11-03 20:14:00.000' memutar ulang ekor terbaru dari titik itu, dan format threadtime menjaga stempel waktu tetap sebanding dengan ekspor klien sendiri.

Jika Anda tahu paket klien, ikuti prosesnya alih-alih menebak tag. adb shell pidof com.vendor.client mengembalikan PID dan adb logcat --pid=1234 -v threadtime hanya mencetak proses itu, sementara adb logcat -g menunjukkan berapa banyak ruang yang dimiliki setiap buffer sebelum mulai menimpa.

Hapus rahasia, lalu serahkan satu bundel yang koheren

Sebelum apa pun meninggalkan mesin Anda, hapus kata sandi, token, kunci privat, cookie sesi, dan pengenal perangkat lengkap. Pertahankan kode kesalahan, urutan peristiwa, dan hubungan alamat yang membuat kegagalan dapat dibaca, karena tangkapan yang dibersihkan melewati titik itu sama tidak bergunanya dengan yang tidak pernah difilter.

Lalu kirim satu bundel alih-alih beberapa file terpisah: ekspor klien, jendela ADB yang dinamai dengan waktu mulai dan berhenti, ringkasan dua baris tentang tahap yang gagal, dan catatan lingkungan dari atas daftar ini. Jika sebagian tidak dapat diposting publik, gunakan saluran dukungan privat penyedia dan sebutkan file mana yang memerlukan saluran itu.

Sebelum mengirim, periksa empat hal. Apakah bundel mencakup satu percobaan, bukan seluruh sore? Apakah stempel waktu klien dan sistem tumpang tindih? Dan apakah masih berisi token, kata sandi, atau pengenal pelanggan lengkap? Perbaiki poin terakhir itu dulu, lalu lampirkan file ke tiket yang ada alih-alih membuka yang baru, agar siapa pun yang mengambilnya mempertahankan konteks sebelumnya.