BIND عبر VPN: توجيه شرطي أم منطقة stub؟
ثلاث طرق لحل منطقة خاصة واحدة عبر VPN، والحالة التي تناسب كلًّا منها: forward أو stub أو secondary، إضافة إلى فحص عنوان المصدر الذي يحسم الاختيار.
خادم الحل في مكتبك يجيب عن كل شيء عدا نطاق مؤسسي واحد، وخادم DNS المؤسسي الذي يعرفه يقع خلف VPN. يستطيع BIND تسليم تلك المنطقة الواحدة إلى المنبع بثلاث طرق مختلفة، وكل منها يفشل بطريقة مختلفة. التوجيه الشرطي هو أصغر التزام، ومنطقة stub تحتفظ ببيانات التفويض، ومنطقة secondary تحتفظ بنسخة كاملة. اختر بحسب ما يسمح به المنبع وبحسب ما تريد أن يحتفظ به خادم الحل، لا بحسب المقتطف الذي صادفته أولًا.
ثلاثة ترتيبات لنطاق واحد
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
التوجيه الشرطي: أصغر التزام
افترض خادم حل في المكتب على 192.168.10.53 وخادمًا مؤسسيًا على 10.40.0.53 يمكن الوصول إليه عبر نفق معتمد. التعريف ثلاثة أسطر، والسطر المهم هو forward only، لأنه يغيّر سلوك الفشل لا المسار.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};مع forward only، ينتج عن المنبع غير القابل للوصول SERVFAIL لهذه المنطقة بدلًا من الرجوع إلى الحل التكراري. هذا هو ما تريده عادة لنطاق خاص، لأن الرجوع سيرسل الأسماء الخاصة إلى خادم حل عام ويعيد إجابة غير مفيدة من الإنترنت. مرجع BIND يوثّق كلتا السياستين، والفرق أهم مما يوحي به المقتطف. ادمج المنطقة في التكوين القائم بدلًا من استبدال منطقة موجودة بالاسم نفسه.
منطقة stub أم secondary: عندما يهم التفويض
تسأل منطقة stub الخادم المؤسسي عن سجلات NS للمنطقة ثم تستعلم من الخوادم المرجعية مباشرة. اخترها عندما تكون منطقة المنبع كبيرة أو مقسّمة وتريد أن يتبع خادم الحل التفويض بدلًا من تثبيت كل شيء على عنوان واحد. الثمن هو الاعتماد على حداثة بيانات NS، وعلى إمكانية الوصول إلى كل خادم أسماء مدرج من عنوان المصدر الخاص بخادم الحل.
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};يجيب secondary من بيانات محلية وينجو من انقطاع المنبع، وهذا سبب قبول اعتماد النقل. ويعني أيضًا أن خادم الحل يحتفظ الآن بنسخة من منطقة لا يملكها، فيصبح مسار الملف وقائمة ACL للنقل على الخادم الأساسي ومؤقتات التحديث جزءًا من سطحك التشغيلي.
الفحص الذي يحسم الاختيار
يولّد BIND استعلامه الصادر بنفسه، فالسؤال ليس هل يستطيع حاسوب محمول الوصول إلى 10.40.0.53، بل هل يستطيع مضيف خادم الحل ذلك، من عنوان المصدر الذي سيراه الخادم المؤسسي. اسأل النواة، ثم اسأل الخادم، بهذا الترتيب.
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.exampleاسمح بـ UDP و TCP على المسار: الاستجابة المقتطعة تفرض TCP، والسياسة التي تسمح بـ UDP فقط تنتج أعطالًا متقطعة تشبه فقدان الحزم. يحتاج الجانب المؤسسي إلى قاعدة قبول لعنوان المصدر الخاص بخادم الحل وإلى مسار عودة إليه؛ وقد يكون ذلك المصدر هو العنوان الموجّه لخادم الحل أو عنوانًا مترجمًا صراحة، ونادرًا ما يكون عنوان مجموعة عملاء. إذا فشل استعلام NS فلن تعمل منطقة stub مهما كان سلوك منطقة forward.
تحقّق من الإجابة، لا من النفق
استعلم عبر خادم حل المكتب عن اسم لم تسأل عنه من قبل، وافحص قسم authority في الإجابة لترى هل جاءت من المنطقة المؤسسية. الإجابة المخزنة في الذاكرة لا تثبت شيئًا عن المسار الحالي، والاستعلام الناجح من المنبع مباشرة لا يثبت أن خادم الحل اختار تلك المنطقة. أعد الاستعلام نفسه عبر TCP لتتأكد من أن المسار ينجو من الاقتطاع.
أبقِ العملاء متوجهين إلى خادم حل المكتب، وأبقِ التحقق من DNSSEC مفعّلًا. المتصفح المهيأ بخادم حل مشفّر مستقل يتجاوز هذا الترتيب كليًا، وتعطيل التحقق لتظهر إجابة غير متوقعة صحيحة يقايض فشلًا مرئيًا بفشل غير مرئي.
اكتب أي الأنواع الثلاثة اخترت ولماذا. من سيرى المنطقة تفشل بعدك سيحتاج تلك الجملة أكثر من ملف التكوين.