برنامه اندروید از کار با VPN خودداری می‌کند: کدام لایه تصمیم می‌گیرد

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

گام 1: بفهمید برنامه کِی امتناع می‌کند

زمان، نخستین عامل تمایز است. بافر گزارش را پاک کنید، خرابی را بازتولید کنید و ببینید برنامه پیش از شکایت چه کرده است:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

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

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

گام 2: نگاه خود گوشی به شبکه را بخوانید

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

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

آن بررسی محلی و ارزان است و کلاسی کامل از گزارش‌های «این برنامه روی VPN کار نمی‌کند» را بدون هیچ دسته‌بندی از راه دور توضیح می‌دهد. آنچه برنامه می‌تواند ببیند همچنان به بافت شبکه خودش بستگی دارد، پس فرض نکنید هر برنامه هر پروفایلی را روی دستگاه بررسی می‌کند.

از یک ایستگاه کاری می‌توانید همان وضعیت را روی یک دستگاه آزمایشی با adb shell dumpsys connectivity و با جست‌وجوی ورودی شبکه VPN ببینید. اجرایی با تونل بالا را با اجرایی با تونل پایین مقایسه کنید و هر دو خروجی را نگه دارید.

گام 3: بخوانید سرور واقعاً چه می‌بیند

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

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

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

گام 4: شواهد را با یکی از سه حکم تطبیق دهید

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

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

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

گام 5: مسیر پشتیبانی‌شده را بروید و آن را بسنجید

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

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

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