لماذا يتوقف DNS عن العمل بعد اتصال OpenVPN على Windows

لا يزال ping إلى محلل المكتب يجيب بعد اتصال "OpenVPN"، ومع ذلك يفشل كل بحث عن اسم. العنوان قابل للوصول بينما المنفذ ليس كذلك، وهو مزيج يصبح مفهومًا بمجرد أن تعرف أن Windows يستطيع تصفية DNS حسب المحول. مع وجود block-outside-dns في الملف الشخصي، يكون هذا المرشح أول المشتبه بهم، وجدول التوجيه هو المكان الخطأ للبحث فيه. والاختباران أدناه يفصلان الطبقات في ثوانٍ.

عنوان قابل للوصول ومنفذ ميت

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

ping <resolver-ip>
nslookup <name> <resolver-ip>

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

الخيار قاعدة في منصة التصفية

يصف مرجع OpenVPN الخيار block-outside-dns بأنه قيد في Windows Filtering Platform يمنع التطبيقات من الوصول إلى DNS على المحولات خارج النفق. ويغطي TCP و UDP على المنفذ 53. ولأن المرشح يعيش في WFP وليس في قائمة قواعد جدار الحماية العادية، فإن إضافة قاعدة سماح في مكان آخر لا تغيّر النتيجة بالضرورة. ولهذا يستمر فشل النصيحة الشائعة بالسماح بـ DNS.

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

ابحث عن مكوّن العميل الذي يملك القيد بدلًا من إضافة المزيد من القواعد. فالمالك هو الشيء الذي يستطيع فعليًا إزالته.

المرشح ليس محللًا

حظر حركة المرور خارج النفق لا يثبّت محللًا عاملًا داخله. فالخيار يزيل مسارًا ويترك تكوين DNS للنفق لمن أعدّ الملف الشخصي. والملف الشخصي الذي لم يدفع محللًا أبدًا ليس لديه أي محلل الآن.

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

1. المحلل المستخدم: قارن Resolve-DnsName -Server <resolver-ip> <name> بخوادم DNS المدرجة في ipconfig /all.
2. تطبيق DNS عبر VPN: افحص إدخالات DNS لمحول النفق في المخرجات نفسها من ipconfig /all.
3. الواجهة المستخدمة: يسمّي Find-NetRoute -RemoteIPAddress <resolver-ip> الواجهة الصادرة لتلك الوجهة.

يصبح محلل LAN غير قابل للوصول بحكم التصميم في ظل هذه السياسة حتى بينما تعمل حركة LAN الأخرى. وهذا هو الخيار وهو يؤدي وظيفته. إذا كان التصميم يحتاج DNS عبر VPN، فأصلح تسجيل المحلل ومسار النفق؛ وإذا كان مطلوبًا DNS منقسم مع استثناءات محلية، فعلى مالك التكوين التعبير عن تلك الاستثناءات بطريقة مدعومة.

ما لا يغطيه الخيار

المنفذ 53 ليس كل تحليل الأسماء. فـ DNS عبر HTTPS و DNS عبر TLS يستخدمان ناقلين مختلفين، وبعض التطبيقات تشغّل منطق المحلل الخاص بها بغض النظر عن إعدادات النظام. ولذلك يمكن للمتصفح أن يحلل الأسماء بينما لا يستطيع سطر الأوامر ذلك.

اعتبر هذا الاختلاف تشخيصًا وليس تناقضًا. قارن الاثنين قبل أن تقرر أن محلل النظام معطل.

اجعل الاستنتاج ضيقًا عندما تكتبه. فهذا الخيار يقيّد ناقلًا واحدًا على منصة واحدة، وبقية مسار التحليل سؤال تصميم منفصل له مالكه الخاص.

تحقق من الحالة قبل الفصل وبعده

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

ipconfig /displaydns
nslookup <name> <resolver-ip>

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

فقط بعد تلك الفحوص يصبح استبدال المحلل أو إعادة بناء سياسة جدار الحماية منطقيًا. وكلاهما تغييران أكبر مما تدعمه الأدلة.