نفقك المنقسم يصل إلى التطبيق لكن ليس إلى خادم DNS الخاص به
يمكن للنفق المنقسم أن يوجّه شبكة التطبيق الفرعية ويُسقط مع ذلك المُحلّل المجاور لها. أضف مسار المضيف، ثم تحقّق من الخادم الذي يختاره Windows فعليًا.
توجيه الشبكة الفرعية للتطبيق هو الجزء الواضح في النفق المنقسم، وليس المهمة كلها. فالمُحلّل غالبًا ما يجلس على عنوان مختلف عن التطبيق الذي يخدمه، لذا قد يظل النفق العامل تاركًا الاستعلام خارجه. والملف التعريفي الذي يحمل 10.80.0.0/16 ولا شيء غيره يرسل الاستعلام عن 10.90.0.53 عبر الواجهة المحلية، حيث لا توجد منطقة خاصة. أضف مسار المُحلّل، ثم تحقّق من الشق الثاني من المشكلة: الخادم الذي يختاره العميل فعليًا.
الخرافة: مسار واحد يغطي الخدمة كلها
النفق المنقسم قائمة بوجهات تمر عبر الاتصال، وليس وصفًا لخدمة. فشبكة التطبيق الفرعية وعنوان المُحلّل وجهتان، وقد يحمل الملف التعريفي إحداهما دون الأخرى. وعندما يحدث ذلك يكون التطبيق قابلًا للوصول بالعنوان بينما يفشل اسمه، ما يبدو عطلًا في DNS لا فجوة في التوجيه.
الشبكة الفرعية المحيطة بالمُحلّل ليست مغطاة تلقائيًا هي الأخرى. فمسار مضيف إلى عنوان واحد يكفي لذلك المُحلّل ولا يفتح جيرانه. وهذا هو معنى مسار المضيف: ضيّق بحكم التصميم، ويسهل نسيانه عندما تظهر الخدمة التالية على الشبكة الفرعية نفسها.
يجب أن تتحقق ثلاثة أمور لكي ينجح الاستعلام: أن يوجّه العميل عنوان المُحلّل عبر النفق، وأن تقبل البوابة ذلك الطلب وتُمرّره، وأن يقبل المُحلّل المصدر الذي يصله. ويجب أن يعود الرد أيضًا عبر المسار المتفق عليه. وإن غاب أي واحد منها كان العرض نفسه، ولهذا يستحق جدول العناوين أن يُكتب قبل لمس أي إعداد.
حدّد العناوين التي يجب أن يحملها الملف التعريفي
اسرد الوجهات بالترتيب: شبكة التطبيق، وعنوان المُحلّل، ونقطة النهاية العامة التي تُنهي النفق نفسه. ولا يجوز أبدًا توجيه الثالثة إلى داخل النفق، لأن الاتصال الخارجي يحتاج مسارًا موجودًا قبل أن يوجد النفق.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
أدرج UDP وTCP معًا لـ DNS، إذ يُتوقع من التطبيقات أن تدعم TCP إلى جانب UDP، ومسار TCP المحجوب ينتج أعطالًا بطيئة وجزئية بدلًا من أعطال نظيفة. وإذا كانت المنطقة الخاصة تُقدَّم عبر IPv6 أيضًا، فإن استثناء المضيف المكافئ يستخدم عنوان IPv6 وبادئة ويُعدّ إدخالًا منفصلًا.
سجّل ما يغطيه الملف التعريفي أصلًا قبل إضافة أي شيء. فالمسار المكرّر غير ضار، لكن المسار الموجود غير المتوقع يخبرك بأن الملف صُمّم لخطة عناوين مختلفة عن التي أُعطيت لك.
أضف مسار المضيف عبر مالك الاتصال
في ملف Windows أصلي يُدار محليًا، ينتمي المسار إلى الاتصال لا إلى جدول التوجيه العام للجهاز. اعرض الإضافة أولًا، ثم طبّقها بالنطاق نفسه الذي يستخدمه الملف التعريفي.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
يعرض الأمر الأول التغيير دون تثبيت أي شيء، ويسرد الثاني المسارات التي يحملها الملف التعريفي حاليًا. وتوثّق الوثيقة المرجعية لـ Add-VpnConnectionRoute من Microsoft نطاقي المستخدم الواحد وكل المستخدمين؛ فملف كل المستخدمين يحتاج معامل نطاقه الخاص، وأمر المستخدم الواحد على ملف كل المستخدمين يفشل أو يقع في المكان الخطأ.
وعندما يكون الملف مُدارًا أو يأتي من عميل بائع، يعود التغيير إلى ذلك المالك. فتكديس مسار نظام دائم فوق سياسة اتصال ينجح إلى أن تُعاد السياسة فيزول المسار، وهو ما يحدث عادةً في مكالمة دعم لا أثناء الاختبار. وهذا العطل صامت: يختفي المسار، ويتوقف الاسم عن الحل، ولا أحد يربط الحدثين. ضع التغيير في سجل المالك نفسه كي تحمله إعادة التطبيق التالية بدل أن تمحوه.
بعد التطبيق، أعد توصيل الملف التعريفي بدل افتراض أن المسار سارٍ. فتغييرات المسار على اتصال قائم لا تُلتقط دائمًا، وإعادة التوصيل تعيد أيضًا إنتاج الحالة التي سيكون عليها مستخدموك فعلًا.
تحقّق من المُحلّل الذي استخدمه العميل فعلًا
المسار يتحكم في الحزم الموجّهة إلى المُحلّل. وهو لا يقرر أي الأسماء يجب أن تُرسل إليه، فذلك الاختيار آلية منفصلة. في Windows، يمكن لقواعد مساحة الأسماء الفعّالة اختيار مُحلّل لكل نطاق، بينما توفّر إعدادات DNS في الملف التعريفي قيمة افتراضية. وقد يختلف هذان المستويان دون إنتاج أي خطأ، ولهذا فإن الاستعلام المباشر نصف الدليل فقط.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
يطبع الأمر الأول سياسة مساحة الأسماء النافذة، ويسأل الثاني المُحلّل الخاص مباشرة عن اسم التطبيق. والإجابة المباشرة تثبت أن المسار والمُحلّل يعملان؛ لكنها لا تثبت أن استعلام التطبيق نفسه اختار ذلك الخادم. قارنها باستعلام عادي للاسم نفسه وبالإجابة التي يتلقاها التطبيق.
ضع في الحسبان ذاكرات التخزين المؤقت وDNS الآمن على مستوى المتصفح، الذي قد يتجاوز مُحلّل النظام كليًا للأسماء التي كتبها المستخدم. ولاحقة البحث سبب آخر للتضليل: فهي توسّع اسمًا قصيرًا إلى اسم مؤهّل بالكامل ولا علاقة لها بالخادم الذي يجيب.
أخيرًا أعد التوصيل وكرر الاستعلام العادي، ثم تأكد من أن التصفح العادي ما زال يتبع سياسته المعتمدة. واستبدال المُحلّل الخاص بآخر عام لكي يُحلّ اسم غير ذي صلة ليس إصلاحًا، بل ينقل الاستعلامات الخاصة بهدوء إلى مكان لم يُقصد به أبدًا.