التقاط Split-DNS: بيّن أين أُخذت كل ملاحظة

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

بحث واحد، ونقاط ملاحظة عدة

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

كل واحد منها يجيب عن سؤال مختلف، ولا يثبت أي منها بمفرده إلى أين ذهب الاستعلام.

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

مرشّح العميل يقف بين التطبيق والسلك

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

تغطي إرشادات Split-DNS في Secure Client من Cisco مطابقة النطاق ومرشّح Windows، وتفصل بين ما يراه التطبيق عندما يستخدم واجهة المُحلِّل الأصلية وما تراه أداة مثل nslookup. هذه الفروق هي المقصد.

ابدأ من الملف الفعّال وعملية بحث عادية واحدة للتطبيق. أي اختبار يسمّي خادماً صريحاً هو انحراف متعمّد؛ استخدم تشخيصات العميل نفسه لتفسيره، ولا تدعه يصبح معيار القبول.

nslookup يسلك مساراً مختلفاً عن التطبيق

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

في Windows، يحدد جدول سياسة تحليل الأسماء أي لاحقة تستخدم أي خادم. وقراءته تُظهر السياسة التي سيتبعها التطبيق، وهي غالباً القطعة الناقصة.

اقرأ السياسة ثم اطرح السؤال نفسه عبر المُحلِّل العادي:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

المُحلِّلات المشفّرة تخفي الاستعلام، لا الاتصال

المتصفح الذي يملك مُحلِّل DNS-over-HTTPS خاصاً به حالة مختلفة تماماً. يغادر الاستعلام داخل TLS، لذا يُظهر التقاط الحزم اتصالاً بعنوان مُحلِّل لكنه لا يُظهر الاسم المطلوب.

استنتج سياسة المتصفح المُدارة أولاً، ثم قارنها ببحث من نظام التشغيل. المتصفح المسموح له باختيار مُحلِّله الخاص قد لا يرى سياسة Split-DNS إطلاقاً.

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

قارن باختبار مُعلَّم

اختر اسماً داخلياً معتمداً للاختبار، مع اسم عام لا يحمل معنى حساساً. ولكل منهما، سجّل الوقت ونوع السجل والإجابة والسياسة التي توقعتها.

حيث يُسمح بذلك، قارن إيصال المُحلِّل بملاحظة واحدة دقيقة من العميل أو البوابة:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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