VPN على Android يحل اسم المضيف الكامل لكن ليس الاسم القصير
نطاق البحث وعنوان خادم DNS حقلان منفصلان في Android. حدِّد أيهما الناقص قبل أن تغيّر النفق أو بيانات الاعتماد.
تكتبfilesفي محاكي طرفية فلا يعود شيء؛ وتكتبfiles.corp.exampleفيجيب الخادم نفسه فوراً. لم يتغيّر شيء في بيانات اعتماد VPN، ولم يكن خادم DNS الخاص معطلاً قط. في Android يسلك الاسم القصير والاسم الكامل مسارين مختلفين عبر المحلِّل، ويعتمد أحد هذين المسارين على إعداد يجب أن يوفّره مالك النفق. القرار المطروح أمامك ليس أي خادم DNS تغيّر، بل من يتحكم في الشبكة التي يستخدمها التطبيق فعلاً.
نطاق البحث ليس عنواناً. إنه قائمة لواحق يضيفها المحلِّل إلى تسمية مجرّدة قبل أن يستسلم.
لاحقة البحث وخادم DNS حقلان منفصلان
عنوان المحلِّل يخبر Android أين يسأل. ولاحقة البحث تخبره عمّ يسأل عندما تعطي التسمية اليسرى وحدها. كلاهما يعيش على كائن الشبكة نفسه، ويمكن أن يغيب أي منهما بمفرده.
هذا الاستقلال هو بالضبط سبب عمل اسم المضيف الكامل. الاسم المؤهَّل بالكامل لا يحتاج إلى لاحقة، لأنه أصلاً هو السلسلة التي تذهب إلى الخادم.
يكشف Android هذا الانفصال عبرLinkProperties. تقع قائمة خوادم DNS وقائمة بحث النطاقات على الكائن نفسه، وغالباً ما تكون الثانية فارغة حتى عندما تكون الأولى ممتلئة تماماً. الشبكة التي لها محلِّل بلا نطاق هي شبكة لم تُطبَّق فيها اللاحقة قط — وليست خادماً رفض الاسم القصير.
اقرأ الشبكة الفعّالة قبل أن تغيّر أي شيء
Wi-Fi والشبكة الخلوية وواجهة VPN ثلاث شبكات منفصلة، ويصبح النفق هو الافتراضي بمجرد أن يبدأ. لذلك فإن اللاحقة التي عملت على Wi-Fi المكتب ليست تلقائياً اللاحقة السارية أثناء عمل النفق. افحص الشبكة التي اختير عليها التطبيق فعلاً، لا الشبكة التي أعددتها الأسبوع الماضي.
صدفة طرفية على الجهاز شاهد ضعيف هنا، لأنresolv.confيعكس رؤية واحدة للمحلِّل بدل رؤية كل تطبيق.
تضيف أشرطة عناوين المتصفح طبقة أخرى فوق ذلك: قد تُعامل الكلمة المجرّدة كاستعلام بحث، أو تُحلّ عبرسياسة DNS المشفّر الخاصة بالمتصفح، لذا فإن صفحة تُحمَّل في Chrome لا تثبت شيئاً عن عمليات البحث على مستوى النظام. اختبر بشيء يستخدم محلِّل المنصة ويطبع ما عاد. ثم شغّل الصيغة القصيرة والصيغة الكاملة في الجلسة نفسها، على الشبكة نفسها، ولاحظ أيّهما أنتج جواباً.
إذا كنت تبني تطبيق VPN، فأرفق اللاحقة في الباني
عندما ينشئ تطبيقك الواجهة عبرVpnService،addSearchDomainفهو المدخل المدعوم لهذا الغرض. يأخذ سلسلة نطاق مثلcorp.example، وليس طريقة بديلة لتمرير عنوان خادم.
تربط الاستدعاء اللاحقة بالشبكة التي تبنيها، لذا لا يوجد إعداد عام تقلبه بعد ذلك. وإذا هدم التطبيق الواجهة وأعاد بناءها عند إعادة الاتصال، فسيحتاج الباني الجديد إلى إضافة اللاحقة مرة أخرى، وإلا فإن الشبكة البديلة تبدأ بدونها.
هنا تفقد كثير من عمليات استيراد ملفات تعريف سطح المكتب هذا الحقل. يكتب المُصدِّر النطاق في نموذجه الخاص، وتقابل واجهة Android الأمامية الخيارات التي تعرفها فقط، فتبدو الواجهة الناتجة صحيحة في كل ناحية أخرى. وملف تعريف يعمل على حاسوب محمول ويفشل على هاتف هو عادةً فجوة في المقابلة، لا مشكلة في البروتوكول.
إذا كنت مستخدماً لـ VPN فقط، فهذا ليس من شأنك ضبطه
لا يوجد تعديل من جهة العميل يضيف لاحقة، ولا خاصية عامة يمكنك تغييرها لتزييف واحدة. القيمة يسلّمها من يملك النفق: في ملف تعريف العميل المُدار، أو في مقابلته لكل منصة، أو عبر أي شيء يدفعه الخادم. قل على أي منصة أنت وأي اسم يفشل، لأن الواجهتين المكتبية والمحمولة تختلفان في هذا الحقل تحديداً.
استيراد ملف تعريف سطح مكتب مرة أخرى لا يثبت شيئاً عن مقابلة الهاتف.
ثلاثة شروط تحدد ما إذا كانت لديك عيب أو قيد متوقع. أولاً، هل تعتبر المؤسسة الاسم القصير اسماً مدعوماً أصلاً، أم أنه تسهيل لم يعمل يوماً إلا على Wi-Fi المكتب؟ ثانياً، هل يأتي فشل البحث من متصفح قد يتجاوز محلِّل النظام كلياً؟ ثالثاً، هل يُقصد أن يكون الاسم القصير متاحاً عبر النفق، أم من الشبكة المحلية فقط؟ إذا كان الجواب الأخير محلياً فقط، فإن إضافة لاحقة تُنشئ اسماً يُحلّ خارج المكتب ثم يفشل في التوجيه.
عندما تكون اللاحقة موجودة ومع ذلك تفشل الأسماء القصيرة
إذا كانت قائمة بحث النطاقات تعرضcorp.exampleبالفعل، فتوقف عن إلقاء اللوم على اللاحقة. تحقق مما إذا كان المحلِّل يعيد جواباً للاسم الموسَّع أصلاً، لأن اللاحقة تغيّر السؤال الذي تطرحه فقط. وهي لا تجعل الخادم مرجعياً لمنطقة لا يستضيفها.
ثم افحص المسار. العنوان الذي يُحلّ لكن لا يحمله النفق يفشل عند الاتصال، وهذا يبدو مطابقاً لفشل البحث في متصفح يستسلم بصمت.
تستحق الشهادات ذكراً خاصاً. يستخدم التحقق من HTTPS اسم المضيف الذي كتبته فعلاً، لذا فإن الاسم القصير الذي يتوسّع بشكل صحيح لا يزال يقدّمfilesفي المصافحة. الشهادة الصادرة لـfiles.corp.exampleلن تتحقق له، وذلك الخطأ سلوك صحيح لا عرض من أعراض مشكلة DNS التي بدأت بها.
ما العمل بعد ذلك
أكّد الانفصال قبل أن تلمس أي شيء: الاسم الكامل يُحلّ، والاسم القصير لا، التطبيق نفسه، الجلسة نفسها. ثم اعثر على الشبكة المختارة واقرأ قائمة بحث نطاقاتها بجانب قائمة محلِّلها. وأي القائمتين كانت فارغة يخبرك من عليه أن يتصرف — أنت، إن كنت تملك التطبيق؛ ومشغّل النفق، إن لم تكن.
أخيراً، فضّل اسم الخدمة الكامل في الإشارات المرجعية وإعدادات العميل حيثما كانت قابلية النقل مهمة. فهو ينجو من تبديل الشبكة، ولا يعتمد على مقابلة قد لا تنفذها الواجهة المحمولة، ويطابق الاسم الذي صدرت شهادة من أجله.