تقسيم DNS عبر OpenVPN: ما يجب أن يفعله نطاق التوجيه في كل نظام تشغيل

يبدأ كل طلب لتقسيم DNS بالجملة نفسها: أسماء الشركة تذهب إلى DNS الشركة، وكل ما عداها يبقى يعمل. وتحويل تلك الجملة إلى إعداد يعني الإجابة عن ثلاثة أسئلة لكل نظام تشغيل، والإجابات تستخدم آليات مختلفة في كل منها. الملفات الشخصية التي تعمل على حاسوب Linux محمول كثيرا ما تفشل على Windows لأسباب لا علاقة لها بالنفق. والفجوة عادة هي إعداد محلل يظن أنه مسار.

سم السياسة أولا، ثم اختر الأساس الذي يعبر عنها في المنصة.

ثلاثة إعدادات يسهل الخلط بينها

توسع لاحقة البحث الاسم القصير: كتابة files تصبح files.corp.example عندما يجر ب المحلل اللواحق بالترتيب. ونطاق التوجيه يحدد أي محلل يجيب عن الاستعلامات داخل نطاق أسماء. أما مسار IP فيجعل المحلل المختار قابلا للوصول فقط. وهذه الثلاثة تعيش في طبقات مختلفة، واستبدال أحدها بالآخر ينتج إعدادا يبدو صحيحا ولا يحل شيئا.

للخلط ثمن: إضافة لاحقة بحث ترسل كل اسم قصير إلى محلل العمل، بما في ذلك أسماء تنتمي إلى مكان آخر. أما اختيار نطاق توجيه فيبقي الاستعلامات غير المتعلقة على المحلل المحلي مع إرسال *.corp.example عبر النفق.

Linux: نطاق توجيه فقط، لا لاحقة بحث

في systemd-resolved، النطاق المسبوق بعلامة التلدة هو نطاق توجيه فقط، أي أن الاستعلامات الخاصة بذلك النطاق تذهب إلى المحلل المرتبط دون أن تصبح لاحقة بحث أيضا. الأمر resolvectl domain tun0 '~corp.example' يضبط ذلك، والأمر resolvectl dns tun0 10.8.0.1 يسمي الخادم. الإعدادان ينتميان إلى الواجهة، فيزولان معها. والتلدة هي الجزء الذي يغفله الناس، وبدونها تبدأ الأسماء القصيرة في الحل عبر محلل العمل.

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

Windows يحتاج سياسة نطاق أسماء، لا لاحقة

يحتفظ Windows بسياسة تقسيم DNS في جدول سياسة حل الأسماء، لا في لاحقة DNS الخاصة بالمحول. والقاعدة تربط نطاق أسماء بخوادم محددة: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. وضبط اللاحقة وحدها يغير شكل الأسماء القصيرة؛ لكنه لا يوجه الاستعلام إلى خادم آخر.

تحقق من السياسة الفعالة بالأمر Get-DnsClientNrptPolicy بعد الاتصال، لأن قاعدة من اتصال سابق قد تبقى بعد زوال النفق. أزل القواعد بالاسم عند توقف النفق، وأبق اسم العرض ثابتا كي يستهدف التنظيف الإدخال الصحيح.

احتفظ بمالك واحد للمحلل لكل منصة

يمكن لمدير سطح المكتب وسكربت up الخاص بـ OpenVPN وخادم محلل محلي أن تحاول جميعا كتابة الإعداد نفسه. وعندما تختلف، يفوز آخر كاتب وتعتمد النتيجة على ترتيب الإنهاء. اختر مكونا واحدا ليملك حالة المحلل، ودع الآخرين يبلغون بدل أن يكتبوا، واختبر إعادة الاتصال: ينبغي أن تصمد السياسة دون تكرار القواعد. واختبر قطع الاتصال أيضا، لأن الحالة المتبقية هي ما يجعل الاتصال التالي يتصرف بشكل مختلف.

التطبيقات التي تأتي بمحلل مشفر خاص بها تتجاهل سياسة نظام التشغيل تماما. وهذا خاصية في التطبيق، لا عيب في النفق.

تحقق من النتيجة، لا من نص الملف الشخصي

حل اسما واحدا يجب أن يمر عبر النفق واسما آخر لا يجب، على كل منصة، وأكد أي خادم أجاب. الأمر resolvectl query host.corp.example والأمر Resolve-DnsName host.corp.example يبلغان كلاهما عن الخادم الذي استجاب. أعد ذلك بعد إعادة الاتصال. ثم أكد أن محلل النفق قابل للوصول على العنوان الذي يدفعه الملف الشخصي، لأن سياسة صحيحة تشير إلى خادم غير قابل للوصول تفشل كما يفشل غياب السياسة تماما.

سجل السلوك المقصود في ملاحظات الملف الشخصي: أي لاحقة توجه، وأي خادم يجيب عنها، وما يحدث لكل ما عداها. المنصة التالية التي تدعمها ستكون بحاجة إلى تلك الجملة أكثر من حاجتها إلى ملف الإعداد.