محاكي أندرويد و VPN المضيف: لقطة DNS وشرح NAT

عندما يفشل المحاكي في الوصول إلى خادم بناء يفتحه متصفح المضيف بلا مشكلة، فالسؤال المفيد ليس هل يعمل VPN. بل أي من آليتين يفتقده الضيف. يشغّل الجهاز الافتراضي مكدس شبكته الخاص خلف NAT المحاكي، وقائمة المُحلِّل لديه نسخة مأخوذة عند الإقلاع، لذا فإن نفقًا صعد بعد ذلك يغيّر مسار المضيف دون أن يغيّر ما يطلبه الضيف. وفهم هاتين الطبقتين يفسّر تقريبًا كل صورة من صور هذه المشكلة.

الضيف مكدس منفصل خلف NAT ثابت

يضع QEMU في وضع شبكة المستخدم الضيف على 10.0.2.15 مع بوابة على 10.0.2.2، وخدمة DNS على 10.0.2.3 حتى 10.0.2.6. ولا تُمرَّر حركة الضيف الصادرة عبر نواة المضيف، بل تُترجم إلى مآخذ على جانب المضيف، مأخذ واحد لكل اتصال ضيف، وتخرج تلك المآخذ من فضاء عناوين المضيف. ولهذا يرث اتصال الضيف قرار التوجيه عند لحظة إنشائه، ولهذا لا يملك الضيف أي مدخل في جدول التوجيه يذكر نفقك.

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

ما لا يستطيع الضيف فعله هو رؤية شبكة المضيف كما لو كانت فضاء أسماء عليه. فلا جسر، ولا جدول توجيه مشترك، ولا مُحلِّل موروث، بل خدمة NAT التي تقبل حزمه واللقطة التي أخذها المشغّل عند بدء الجهاز الافتراضي فحسب.

DNS لقطة وليس عرضًا حيًا

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

لذا فإن الإصلاح عبر الترتيب ليس خرافة. صِل النفق أولًا، ثم أعد تشغيل المحاكي، وفضّل إقلاعًا باردًا على استعادة لقطة، لأن صورة الإقلاع السريع قد تعود بحالة المُحلِّل والتوجيه التي حفظتها سابقًا. وإذا أردت معرفة ما يستخدمه الضيف الآن، فاسأل الجهاز لا المضيف:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

يقبل المحاكي أيضًا مُحلِّلًا صريحًا عند التشغيل، وهذا مفيد عندما تعرف بالضبط أي خادم ينبغي أن يستخدمه الضيف وخطر عندما يكون ذلك الخادم عامًا:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

المُحلِّل العام لا يملك نسخة من منطقة داخلية، لذا فإن تثبيت واحد يحوّل مشكلة ترتيب إلى فشل دائم. وإذا كان الملف الشخصي يدفع DNS خاصًا، فدع النفق يوفّره وأقلع الضيف إقلاعًا باردًا بدل كتابة عنوان ثابت.

التوجيه يتبع المضيف عند وقت الاتصال

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

التحقق مكانه واجهة المضيف لا إحصاءات الضيف:

sudo tcpdump -ni tun0 'host 203.0.113.10'

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

حين يقدّم العميل وسيط عودة فقط

بعض العملاء التجاريين لا ينشئون نفقًا نظاميًا على الإطلاق. بل يعرضون مستمع HTTP أو SOCKS على 127.0.0.1 ويتوقعون أن تستخدمه التطبيقات. ولا يستطيع الضيف رؤية ذلك المأخذ مباشرة، لكن يمكن إخبار المحاكي باستخدامه، إما عبر عناصر التحكم الموسّعة (الإعدادات، ثم الوسيط، الوضع اليدوي، المضيف 127.0.0.1 والمنفذ الذي يطبعه العميل) أو عند التشغيل:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

انسخ المنفذ من نافذة العميل، فالمنفذ المخمّن يفشل بصمت ويبدو كنفق معطّل. وتذكّر ما يغطيه هذا: إعداد وسيط HTTP تحترمه التطبيقات التي تعرف الوسيط، أما المآخذ الخام فتتجاهله كليًا. وإذا كان الحمل برنامجًا أصليًا يفتح اتصالاته بنفسه، فمسار الوسيط لا يعادل النفق ويجب إجراء المقارنة صراحة.

أثبت النتيجة من داخل الضيف

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

وأخيرًا، اعرف على أي ضيف تختبر. فصور المحاكي القديمة جدًا شُحنت دون دعم tun الذي يحتاجه عميل VPN على جانب الضيف، لذا لم يكن أي ملف شخصي لينجح هناك؛ أما الصور الحالية فتشمل هذا الدعم. والعميل الذي يفشل على صورة حالية مشكلة عميل أو ملف شخصي، ولن تغيّر إعادة بناء نفق المضيف النتيجة.