VPN سيطر على DNS وأفسد الأسماء المحلية: أصلح القائمة

يرتفع النفق، وتُحمَّل الشبكة الداخلية، ثم يتوقف اسم الطابعة عن الحل. أو العكس: تظل الأسماء المحلية تعمل بينما يتوقف كل شيء داخل شبكة الشركة عن الاستجابة. العَرَضان كلاهما من المصدر نفسه، قائمة محلِّلات أعاد عميل VPN كتابتها عند الاتصال.

أصلح القائمة عن قصد، ثم تعامل مع آلية الدفع بشكل منفصل. المسارات موضوع ثالث وليست ما يُصلَح هنا.

أي قائمة تستخدمها التطبيقات فعلاً

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

السؤال هو أي الخوادم انتهى بها المطاف في المقدمة، وهل وصلت كإدخالات ثابتة أم كإيجار DHCP. الحقيقتان تحدّدان أي إصلاح متاح لك.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

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

احذف الخوادم المدفوعة، أو رتّبها في مرتبة أدنى

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

يُستشار الفهرس 1 أولاً، فتبقى العناوين المدفوعة متاحة لكنها تتوقف عن كونها الجواب الافتراضي لكل استعلام. تتجاوز راية validate=no فحص إمكانية الوصول الذي يفشل كثيراً بينما لا يزال النفق يستقر، لذا أكّد النتيجة بأمر العرض بدل الوثوق برمز الخروج.

ثمة حدّان يستحقان المعرفة قبل الاعتماد على هذا. لن يحذف Windows الخوادم التي وصلت عبر DHCP من خلال netsh، وتبقى تلك القيم باسم DhcpNameServer تحت مفتاح السجل الخاص بالواجهة، لذا تعديل السجل حل أخير يجب إعادة فحصه بعد الإيجار التالي. ترتيب ارتباط المحوّلات ليس آلية ترتيب موثوقة أيضاً، لأن عميل VPN يستطيع إدراج إدخاله في أعلى القائمة.

أين يمكن فلترة الدفع

الإصلاح الأفضل يزيل الخيار قبل تطبيقه. يستطيع عميل Community OpenVPN فلترة توجيه مدفوع بالاسم، وهذا يبقي إعداد الخادم دون مساس.

pull-filter ignore "dhcp-option DNS "

المسافة اللاحقة تخص المطابقة والفلتر يسمّي الخيار لا عنوان خادم. إذا كان الملف الشخصي يحتوي أيضاً على توجيه block-outside-dns، فإن إزالته تغيّر حماية التسريب لا حل الأسماء، فقرّر ذلك منفصلاً بدل ضم التعديلين.

من أجل اسم مضيف عنيد واحد، سطر واحد في ملف hosts في Windows أثبت من إعادة ترتيب المحلِّلات للجهاز بأكمله. وهو أيضاً غير مرئي للشخص التالي، فسجّله حيثما تُوثَّق إعدادات الجهاز.

اجعل الإصلاح يصمد أمام إعادة الاتصال

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

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

أعد توصيل النفق وكرّر الأمرين. كل ما غيّرته يدوياً يصمد فقط حتى الاتصال التالي، لأن العميل يعيد بناء حالة محلِّلاته أثناء رفع المحوّل. ضع أسطر netsh في نص الاتصال المدعوم لعميلك، ودع ذلك النص ينتهي بنجاح، وأضف انتظاراً قصيراً قبل تنفيذه. العميل الذي يطبّق DNS بعد النص سيطمس النتيجة في كل الأحوال.

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