چگونه گزارش‌های VPN اندروید را برای تیکت پشتیبانی جمع کنید

روی Connect می‌زنید، پروفایل یک لحظه می‌چرخد و کلاینت اعلام قطع ارتباط می‌کند. پشتیبانی گزارش می‌خواهد، شما یک تصویر صفحه پیوست می‌کنید و رشته دو روز معطل می‌ماند، چون هیچ‌کس نمی‌تواند بگوید کدام بخش از دست‌دادن اطلاعات تسلیم شده است. گزارشی که حول یک تلاش ساخته شده باشد، با پنجره زمانی باریک و آخرین مرحله تکمیل‌شده، تیکت را در یک دور جلو می‌برد. گزینه دیگر، یعنی گزارش یک روز کامل گوشی، معمولاً به فرد آن‌طرف جای بیشتری برای نگاه کردن می‌دهد.

دو گوشی روی یک دروازه ممکن است متفاوت رفتار کنند، چون پروتکل، مخزن گواهی، روش احراز هویت یا سیاست ترافیک ممکن است یکی نباشد. جمله اینکه روی گوشی من کار می‌کند نقطه شروع مقایسه است، نه مدرکی درباره خرابی اندروید.

یک تلاش را ثبت کنید، نه یک روز تاریخچه

محیط را پیش از بازتولید هر چیزی بنویسید: نسخه اندروید، سازنده و مدل، نام و نسخه کلاینت، پروفایلی که انتخاب کرده‌اید، شبکه‌ای که به آن وصل هستید و ساعت با منطقه زمانی آن. همچنین یادداشت می‌کنم که صرفه‌جویی باتری یا Data Saver روشن است یا نه، چون هر دو تغییر می‌دهند کلاینت پس از خاموش شدن صفحه چه کاری می‌تواند بکند.

سپس مشخص کنید واقعاً کدام یک از پنج نتیجه را می‌بینید. پنجره رضایت یا مجوز هرگز کامل نمی‌شود، به نقطه پایانی اصلاً دسترسی نیست، احراز هویت رد می‌شود، راه‌اندازی رابط پس از ورود موفق شکست می‌خورد، یا تونل بالا می‌آید و یک منبع مشخص غیرقابل دسترس می‌ماند. هر کدام مالک و راه‌حل متفاوتی دارند و بسته‌ای که آن‌ها را قاطی کند پاسخی می‌گیرد که دوباره تلاش کنید. حدس زدن میان آن‌هاست که تیکت یک‌ساعته را به یک هفته مکاتبه تبدیل می‌کند.

انتقال‌ها هم مهم‌اند. اگر خرابی فقط پس از قفل صفحه یا پس از جابه‌جایی از وای‌فای به داده همراه ظاهر می‌شود، آن را در خط اول تیکت بنویسید و دقیقه وقوعش را ذکر کنید.

نخست گزارش خود کلاینت را صادر کنید

پیوست اول باید از اپلیکیشن بیاید، نه از سیستم‌عامل. بیشتر کلاینت‌ها در تنظیمات صدور گزارش تشخیصی یا گزارش اتصال دارند، گاه پشت یک فشار طولانی روی رشته نسخه پنهان شده، و آن خروجی خود ماشین حالت خودش را می‌فهمد. آن را همان‌طور که بیرون می‌آید به کار ببرید، نه اینکه خطوط مهم را دوباره در متن تیکت تایپ کنید.

اولین خطا و رویدادهای بلافاصله پیش از آن را پیوست کنید، نه فقط آخرین خط قطع ارتباط را. دنباله پاک معمولاً یعنی خرابی واقعی زودتر رخ داده: زنجیره گواهی‌ای که اعتبارسنجی نمی‌شد، نامی که در جایی غیرمنتظره حل شده بود، یا رابطی که هرگز پیکربندی نشد.

logcat را فقط برای پرسشی اضافه کنید که می‌توانید نامش را ببرید

شبیه‌ساز ترمینال روی گوشی یک ثبت‌کننده سیستم نیست. اندروید بافرهایش را ثبت می‌کند به صورت جریان‌های حلقه‌ای جداگانه که تنها فرایندهای ممتاز می‌توانند کامل بخوانند. بنابراین یک اپلیکیشن معمولی خروجی خودش به علاوه یک برش محدود را می‌بیند و این جمله که logcat خالی بود چیز بسیار کمی درباره آنچه پلتفرم ثبت کرده اثبات می‌کند.

مسیر پشتیبانی‌شده یک نشست ADB مجاز از رایانه‌ای است که خودتان کنترل می‌کنید. گزینه‌های توسعه‌دهنده و اشکال‌زدایی USB را روشن کنید، کابل را وصل کنید و دیالوگ اثر انگشت RSA را روی دستگاه بپذیرید؛ اگر آن درخواست بسته شود، هر فرمان بعدی با unauthorized شکست می‌خورد و هیچ ضبطی هرگز شروع نمی‌شود.

پیش از صرف وقت برای ضبط، تأیید کنید دستگاه واقعاً آنجاست. adb devices باید شماره سریال و سپس واژه device را چاپ کند، و هر چیزی که offline یا unauthorized نشان دهد نخست به درست کردن کابل، درخواست یا درایور نیاز دارد.

وقتی در فهرست آمد، چند ثانیه پیش از زدن Connect ضبط را شروع کنید و درست پس از تسلیم شدن کلاینت متوقف کنید. ضبط زنده با شروع آگاهانه بهتر از خروجی‌ای است که بیست دقیقه بعد گرفته می‌شود، چون بافرهای حلقه‌ای قبلاً چرخیده‌اند و خطوط اولیه‌ای که لازم دارید ممکن است رفته باشند:

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

بر اساس زمان و برچسب فیلتر کنید، نه واژه VPN

جست‌وجوی vpn در یک ضبط سریع‌ترین راه از دست دادن خطی است که خرابی را توضیح می‌دهد. اعتبارسنجی گواهی، کرش فرایندها و تغییرات اتصال زیر برچسب‌هایی ثبت می‌شوند که هرگز VPN را ذکر نمی‌کنند، پس فیلتر کلیدواژه سروصدا را نگه می‌دارد و مدرک را دور می‌ریزد.

نخست پنجره را باریک کنید، سپس اولویت، سپس برچسب. وقتی فقط به آنچه پس از لحظه‌ای معلوم رخ داده نیاز دارید، adb logcat -v threadtime -t '11-03 20:14:00.000' دنباله اخیر را از آن نقطه پخش می‌کند و قالب threadtime مُهرهای زمانی را با خروجی خود کلاینت قابل مقایسه نگه می‌دارد.

اگر بسته کلاینت را می‌دانید، به جای حدس زدن برچسب‌ها فرایندش را دنبال کنید. adb shell pidof com.vendor.client یک PID برمی‌گرداند و adb logcat --pid=1234 -v threadtime فقط همان فرایند را چاپ می‌کند، در حالی که adb logcat -g نشان می‌دهد هر بافر پیش از شروع بازنویسی چقدر جا دارد.

اسرار را حذف کنید، سپس یک بسته منسجم تحویل دهید

پیش از آنکه چیزی از دستگاه شما بیرون برود، گذرواژه‌ها، توکن‌ها، کلیدهای خصوصی، کوکی‌های نشست و شناسه‌های کامل دستگاه را پاک کنید. کدهای خطا، ترتیب رویدادها و روابط نشانی را نگه دارید که خرابی را خوانا می‌کنند، چون ضبطی که بیش از آن پاک‌سازی شود به همان اندازه بی‌فایده است که هرگز فیلتر نشده باشد.

سپس یک بسته بفرستید نه چند فایل پراکنده: خروجی کلاینت، پنجره ADB با نام زمان شروع و توقف، خلاصه‌ای دوخطی از مرحله‌ای که شکست خورد و یادداشت محیط از بالای این فهرست. اگر بخشی را نمی‌توان به صورت عمومی منتشر کرد، از کانال پشتیبانی خصوصی ارائه‌دهنده استفاده کنید و بگویید کدام فایل به آن کانال نیاز دارد.

پیش از ارسال، چهار چیز را بررسی کنید. آیا بسته یک تلاش را پوشش می‌دهد نه یک بعدازظهر کامل؟ آیا مُهرهای زمانی کلاینت و سیستم هم‌پوشانی دارند؟ و آیا هنوز توکن، گذرواژه یا شناسه کامل مشترک در آن هست؟ نخست همان نکته آخر را درست کنید، سپس فایل‌ها را به تیکت موجود پیوست کنید نه اینکه تیکت جدید باز کنید، تا هر کس آن را بردارد زمینه قبلی را حفظ کند.