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

النفق وخادم التحليل عقدان منفصلان

WireGuard صغير عن قصد. ينقل الحزم للعناوين التي تسردها ويوثّق النظراء؛ وكل ما فوق تلك الطبقة هو تصميمك. OpenVPN يمكنه دفع dhcp-option DNS لأن قناة التحكم لديه تحمل التهيئة، وذلك الفرق يُربك من ينتقلون بين الاثنين.

لذا فالنفق العامل لا يخبرك شيئًا عن تحليل الأسماء. يمكن أن يكون لدى العميل مسار مثالي إلى 10.90.0.1 وما زال يرسل استعلاماته إلى خادم أسماء عام، ولهذا تبدو العَرَض كأن “VPN كسر DNS” بينما DNS لم يُوجَّه إلى VPN قط.

قدّم المنطقة دون أن تصبح خادم أسماء تكراريًا

الجانب الخادم منطقة موثوقة صغيرة، لا خادم أسماء عامًا. في هذا المثال البوابة هي 10.90.0.1، والعملاء 10.90.0.0/24، والتطبيق الذي يهمك يجيب على 10.60.0.20.

ادمج هذه الإعدادات في كتلة options الموجودة بدلًا من إنشاء كتلة ثانية:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

ثم أعلن المنطقة وملفها:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

تحقّق قبل إعادة التحميل، لأن خطأً في الصياغة عند إعادة التحميل يُسقط الخادم كله لكل منطقة يخدمها:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

افتح UDP و TCP 53 على واجهة VPN فقط. نشر سلطة خاصة على الواجهة العامة يستدعي الاستعلامات والتعداد معًا، وينبغي أن يبقى allow-transfer مغلقًا ما لم يكن هناك ثانوي يحتاجه فعلًا.

وجّه العميل إليه، لكل وصلة

افترض أن NetworkManager يملك الاتصال وأن systemd-resolved هو خادم التحليل. اقرأ السياسة الموجودة أولًا، خصوصًا أي نطاق توجيه جذري، لأن مدخل ~. سيتقدّم على ما أنت على وشك إضافته.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

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

طبّق التغيير عبر المدير الذي يملك الواجهة، ثم أعد توصيل الاتصال. لا تبدأ نسخة wg-quick ثانية للواجهة نفسها؛ سيتخاصم مالكان على المسارات وسيفوز أحدهما في أسوأ لحظة.

تحقّق من المسار قبل الاسم

استعلم عن الاسم من العميل وأكّد الإجابة والخادم الذي أنتجها:

resolvectl query portal.corp.example

إذا أعاد ذلك 10.60.0.20، فعقد DNS منتهٍ. وإذا انتهت المدة، فافحص المسار إلى 10.90.0.1 أولًا، ثم قاعدة الجدار الناري، ثم allow-query على الخادم. إخفاقات تحليل الأسماء في هذا الإعداد تكون دائمًا تقريبًا مسألة وصول أو قائمة تحكم، لا ملف المنطقة. اعمل من العميل إلى الخارج، لأن الخادم لا يستطيع أن يخبرك لماذا لم يصل استعلام.

تذكّر أن التطبيق ما زال يحتاج مساره الخاص وإذن الخدمة الخاص به. الاسم المُحلَّل الذي يشير إلى عنوان غير قابل للوصول هو فشل آخر يرتدي الثوب نفسه.

ما ليس تلقائيًا بعد

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

يمكن للأساطيل أتمتة سياسة العميل هذه عبر نظام التزويد لديها، لكن السياسة تبقى كائنًا منفصلًا له مالك. مرجع BIND 9 يغطي عناصر التحكم في الاستماع والاستعلام المستخدمة أعلاه، وهو المكان الصحيح لتأكيد السلوك لإصدارك المثبت.

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

مقالات ذات صلة