DNS المدفوع من OpenVPN مُتجاهَل: أي مكوّن يطبّقه

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

الخيار المدفوع عرض، لا تنصيب

على الخادم، يعبّر توجيهان عن النيّة لا عن الأثر:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

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

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

تأكّد من وصول الدفع وحدّد المالك

ابدأ بتسمية المشغّل: أمر openvpn مجرد، أو نسخة systemd، أو NetworkManager، أو عميل مورّد. هذا يحدّد أين يمكن أن يعيش الخطّاف. على مضيف يعمل بـ systemd-resolved، resolvectl status يسرد كل رابط مع خوادم DNS ونطاقات البحث التي يستخدمها فعلًا، ورابط النفق ليس دائمًا باسم tun0.

إذا ظهر العنوان المدفوع في السجل لكن ليس على أي رابط، فالتكامل مفقود. وإذا ظهر على الرابط وما زالت الاستعلامات تخرج من مكان آخر، فالمشكلة هي أي الاستعلامات تختار ذلك الرابط. أما NetworkManager مع dns=dnsmasq داخل /etc/NetworkManager/NetworkManager.conf فيدير مُمرِّرًا محليًا يطبّق DNS المنقسم عن قصد: الأسماء داخل نطاق VPN تذهب إلى مُحلِّل VPN، وكل ما عدا ذلك يحتفظ بمساره السابق. هذا السلوك يبدو عطلًا حين كنت تتوقع أن ينتقل كل المرور؛ راجع إعدادات الاتصال مع nmcli connection show "My VPN"، حيث ipv4.dns و ipv4.dns-search تحملان القيم الكامنة وراء ما يبلّغ عنه الجهاز، قبل أن تصفه بالعطل. وإذا كان يجب أن تصل كل استعلامات فعلًا إلى مُحلِّل VPN، فأزل dns=dnsmasq من NetworkManager.conf وأعد تشغيل NetworkManager، الذي يعيد حلّ الأسماء إلى إعدادات الاتصال؛ وإلا فاحتفظ بـ DNS المنقسم وصحّح قائمة النطاقات المدفوعة بدلًا من ذلك.

Linux: سلّم الخيارات إلى المُحلِّل

تُشحن حزم التوزيعات خطّافًا لهذا، ويجب السماح للعميل بتشغيله. ترتيب نموذجي على مضيف بلا systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

مع systemd-resolved قد لا يغيّر سكربت resolv.conf الأقدم شيئًا مهمًا، لأن المُحلِّل الوكيل يحمل حالة لكل رابط. أداة update-systemd-resolved تُوثّق صيغة خطّاف تستخدم up-restart و down-pre، وهذا يهم عندما تعيش الواجهة أطول من محاولة اتصال واحدة. أيًّا كان ما تختاره، يجب أن يملك مكوّن واحد الحالة. إضافة خطّاف غير ذي صلة بجانب NetworkManager تعطي كاتبَين للرابط نفسه، وحينها تعتمد النتيجة على الترتيب لا على إعدادك.

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

Windows وmacOS يطبّقان أجزاء مختلفة

عميل Windows يضبط خوادم DNS لمهايئ VPN، لكن Windows ما زال يختار الواجهة بالمقياس وما زال يحتاج لاحقة لتوسيع اسم قصير. تحقّق من حالة المهايئ لا من ملف التعريف:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

إذا كان العنوان مفقودًا، اضبطه بـ Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1، ثم أضف اللاحقة إلى خصائص IPv4 للمهايئ كي يصبح fileserver هو fileserver.corp.example. وقيمة SearchList على مستوى الجهاز تحت Tcpip\Parameters تفعل الشيء نفسه. حيث يُحلّ الاسم الطويل ولا يُحلّ المجرّد، يكون المُحلِّل صحيحًا أصلًا وتكون قائمة البحث هي العطل. الإصلاحات بالترتيب: ادفع DOMAIN ليتعلّم العميل اللاحقة، وأضف تلك اللاحقة إلى قائمة البحث للمهايئ أو الاتصال، وكإجراء مؤقت ثبّت الاسم في hosts، أو LMHOSTS على Windows؛ تصفّح NetBIOS لا يعبر موجّهًا، لذا لا يصل البث الذي يجد اسمًا قصيرًا على شبكة المكتب إلى عميل نفق.

block-outside-dns block-outside-dns سلوك عميل Windows، لا سطر ملف تعريف محمول، ونسخه إلى ملف تعريف Linux أو macOS لا يعيده هناك. إذا عملت الأسماء العامة وفشلت الداخلية على Windows، قارن ترتيب المهايئات ضمن الإعدادات المتقدمة مع ipconfig /all. على macOS ينتمي ترتيب المُحلِّل لكل خدمة إلى النظام، لذا استخدم scutil --dns لترى أي مُحلِّل يُستشار لأي نطاق، وتعامل مع أي إصلاح واحد مُبلَّغ عنه على أنه تابع للعميل لا عام.

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

التاريخ هو السبب الثالث. إعدادات خوادم DNS أو اللواحق من ملف تعريف أقدم قد تبقى بعد إعادة الاتصال، فحين يبدو المهايئ صحيحًا وتظل عمليات البحث تفشل، قارن المهايئ الحيّ مع Get-VpnConnection وامسح الإدخال القديم أو استبدله قبل أن تلمس الخادم.

أثبت إلى أين ذهب الاستعلام

التقاط أثناء بحث واحد يحسم الجدل: tcpdump -ni eth0 port 53 يُظهر استعلامات على الواجهة الفعلية، أي أنها تخرج خارج النفق ولم يُبدَّل المُحلِّل قط. dig @10.8.0.1 name.corp.example ثم يفصل الحالتين المتبقيتين. إذا أجاب الاستعلام المباشر، فالمُحلِّل يعمل والعميل لا يستخدمه؛ وإذا انتهى بالمهلة، فالمُحلِّل غير قابل للوصول عبر النفق ولن يساعد أي تغيير محلي.

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

تشمل قابلية الوصول الجدار الناري على مضيف VPN، الذي يجب أن يسمح بـ UDP وTCP 53 من التجمع. المنفذ المُسقَط يبدو تمامًا كدفع معطوب، وكذلك مُحلِّل لا يجيب إلا من داخل شبكة النفق. أعد الالتقاط بعد قطع الاتصال وإعادة توصيله مرة، لأن الإعدادات التي تظهر عند الاتصال الأول وتختفي عند الثاني عطل دورة حياة في الخطّاف، لا خيار مفقود.

احتفظ بمالك واحد وتحقق بالترتيب

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

أغلق الحلقة بأربعة فحوص: العنوان المدفوع حاضر على رابط النفق، والاسم الداخلي يُحلّ كاسم مؤهّل كاملًا، والاسم نفسه يُحلّ دون اللاحقة، وكلاهما صحيح بعد إعادة اتصال واحدة. التقاط واحد يخبرك أي الفحوص الأربعة فشل. دليل OpenVPN 2.6 يسرد توجيهات dhcp-option وتوجيهات السكربت مع ملاحظات المنصة.