لماذا تفشل عمليات البحث عن الأسماء عبر نفق OpenVPN الموجَّه

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

خرافة: النفق معطوب لأن الأسماء تفشل

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

معالجة ذلك كخلل في النفق تؤدي إلى تعديلات في الملف التعريفي لا يمكن أن تنفع. فإضافة خيارات أو تغيير الشيفرات أو إعادة تثبيت العميل تُبقي البث في مكانه تمامًا.

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

ما الذي يحمله TUN وما لا يحمله

جهاز TUN هو واجهة IP، وهذا ما يجعله قابلًا للتوجيه. ويمنح OpenVPN العميلَ عنوانًا ومجموعة مسارات، ومنذ ذلك الحين يرسل العميل حزم بيانات إلى نظير. ولا شيء في ذلك النموذج ينشئ وصلة مشتركة يسمع فيها كل مضيف كل إطار.

حركة الاكتشاف لا تناسب ذلك النموذج إطلاقًا. استعلامات الأسماء القديمة في Windows وإعلانات SSDP وطلبات mDNS تُرسل إلى الجميع على قطاع بدلًا من وجهة واحدة. والوصلة الموجَّهة ليس فيها «جميع» تُرسل إليه. وكل واحدة من تلك الآليات تفترض وسيطًا مشتركًا.

لذلك يمكن أن يكون النفق سليمًا بينما يفشل الاكتشاف فشلًا كاملًا. تلك هي الجملة التي ينبغي التمسك بها حين يُبلِّغ أحدهم بأن الشبكة الافتراضية معطلة.

الجسر يعمل بإزالة الحدود

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

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

بالنسبة لمختبر صغير هذه مقايضة معقولة. أما عبر قوة عمل موزَّعة فنادرًا ما تكون كذلك.

دفع DNS وWINS هو الإصلاح الأضيق

أعطِ العميل مكانًا محددًا يسأل فيه. فالعنصران dhcp-option DNS و dhcp-option DOMAIN يوجِّهان الأسماء الداخلية إلى خادم يعرف النطاق، وعميل Windows الذي لا يزال يعتمد على NetBIOS يمكنه تلقي خادم WINS بالطريقة نفسها. ويبقى النفق موجَّهًا ويبقى القطاع في مكانه.

شرطان يحددان نجاح ذلك. يجب أن يجيب الخادم المذكور عن النطاق، ويجب أن يُسمح بالاستعلام عبر النفق.

اختبر المُحلِّل من العميل لا من صدفة الخادم نفسها. فالمُحلِّل الذي يعمل محليًا لا يقول شيئًا عمّا يحمله النفق.

اكتشف أي طبقة فشلت

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

البث المتعدد يقف خلف الجدار نفسه. فمجموعة مثل 224.0.0.251 لا تُمرَّر عبر نفق موجَّه افتراضيًا، ومسار للمجموعة لا يكفي دون مسار يدرك البث المتعدد أو عاكس على LAN.