ADB ومحاكي Android يفشلان خلف VPN: ثلاثة مسارات

تتصل بشبكة VPN المكتبية، فيفقد Android Studio المحاكي العامل، ويتعلق adb start-server، ويهبط هاتف فعلي على Wi-Fi من قائمة الأجهزة. يبدو الأمر كأن منتجا واحدا يحجبه نفق واحد. في الواقع تفشل ثلاثة مسارات منفصلة بثلاث طرق مختلفة: اكتشاف أجهزة adb، والشبكة الافتراضية للمحاكي، ومحلل أسماء المضيف. النفق عادة يملك الأخير فقط، وغالبا جزءا منه فقط.

ثلاثة مقابس، ثلاثة مالكين

خادم adb يستمع على المنفذ 5037 في المضيف ويتحدث إلى الأجهزة عبر USB أو TCP، مع mDNS للاكتشاف الشبكي. يعمل المحاكي خلف موجه افتراضي خاص به: الضيف 10.0.2.15، وبوابته 10.0.2.2، وخادم DNS الخاص به 10.0.2.3، وكلها تترجمها عملية المحاكي إلى مقابس المضيف. محلل أسماء المضيف هو المكان الذي يثبت فيه عميل VPN إعدادات DNS ونطاقات البحث.

هذا الفصل يفسر لماذا يبدو إصلاح ناجحا مع أداة وفاشلا مع أخرى. العميل الذي يغير محلل المضيف يترك عملية محاكي قيد التشغيل بحالة المحلل التي قرأتها عند البدء. والعميل الذي يرشح multicast يكسر الاكتشاف دون أن يمس DNS. والعميل الذي يرشح المحولات الافتراضية يمنع المحاكي بينما يظل متصفح المضيف يعمل. لكل عرض سبب مختلف، فحدد المسار الفاشل قبل تغيير أي إعداد.

ابدأ بما يستطيع adb رؤيته

شغل adb devices قبل لمس VPN. القائمة الفارغة مشكلة نقل لا مشكلة توجيه، ولا إعداد نفق سيصلح جهازا لم يسرده الخادم أبدا. أعد تشغيل الخادم بنظافة باستخدام adb kill-server ثم adb start-server، واقرأ المخرجات لتعرف المنفذ الذي ارتبط به. إذا تعلق التشغيل نفسه فاكتشاف mDNS هو المشتبه المعتاد على شبكة ترشح multicast؛ والحل الموثق هو بدء الخادم مع تعطيل الاكتشاف:

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

بالنسبة لجهاز فعلي، USB هو أقصر طريق. إذا احتجت TCP فضع الجهاز في وضع الاستماع باستخدام adb tcpip 5555 واتصل بعنوان الجهاز ومنفذ الجهاز، adb connect 192.0.2.10:5555. المنفذ 5037 هو منفذ خادم المضيف وليس المنفذ الذي يستمع عليه الجهاز.

اختبر المحاكي من الداخل

يجيب المحاكي عن DNS من 10.0.2.3، وهذا المحلل يغذيه عملية المضيف. عندما يغير عميل VPN محلل المضيف يمكن للمحاكي أن يرثه؛ وعندما يرشح العميل عملية المحاكي أو تتغير قائمة محولات المضيف بعد بدء المحاكي فإنه لا يستطيع. افصل بينهما بهدف رقمي واسم من الصدفة نفسها. adb shell ping -c 2 10.0.2.2 يثبت أن الشبكة الافتراضية تصل إلى جهة المضيف. وبحث الاسم بعد ذلك يخبرك هل تجاوز التحليل الحدود.

ثم شغل بحث الاسم نفسه على المضيف. المضيف يحل والمحاكي لا يعني أن الانقطاع بين محلل المضيف والشبكة الافتراضية للمحاكي، لا في النفق نفسه. وفشل الاثنين يعني أن محلل المضيف هو موضع البحث. إعادة تشغيل المحاكي بعد اتصال VPN تستحق محاولة واحدة، لأن بعض العملاء يثبتون حالة محلل لا تلتقطها عملية محاكي قيد التشغيل.

افحص محلل المضيف ومرشحات العميل

عميل النفق الكامل يستبدل محلل المضيف بمحلله، وعميل DNS المنقسم يضيف نطاقات بحث وموجهات شرطية. الأسماء الداخلية غالبا تعتمد على إعداد DNS المنقسم ذاك، فافحص ما يستخدمه المضيف أثناء الاتصال: عنوان المحلل، ونطاق البحث، وهل توجه المنطقة الداخلية إلى DNS الشركة. المحلل الذي يجيب عن الأسماء العامة لا الداخلية مسألة سياسة، لا نفق معطل.

بعض عملاء الشركات يحجبون أيضا حركة المحولات الافتراضية. المحاكي يبدو كمحول افتراضي لسائق ترشيح، فيمكن للمضيف أن يعمل تماما بينما يمنع المحاكي بالسياسة. هذه السياسة غير مرئية من محطة العمل، والتخمين في إعدادات الوكيل لن يكشفها. إذا كان المضيف يحل والمحاكي محجوب بغض النظر عن إعدادات المحلل، فالتصعيد الصحيح إلى الفريق المالك لسياسة العميل.

ترتيب الفحوص وما يعنيه كل نتيجة

اعمل من أعلى إلى أسفل وتوقف عند أول صف فاشل. كل نتيجة تشير إلى مالك مختلف، ولا واحدة منها تصلح بإعادة تثبيت Android Studio.

الصفان الأخيران فقط أسئلة VPN بالمعنى المعتاد، والأخير فقط يتعلق بمحتوى DNS. توثيق adb يغطي منفذ الخادم ومتغيرات البيئة المذكورة هنا، وهو ما يكفي للحفاظ على دقة جانب النقل أثناء اختبار الباقي.