هل فقد WSL2 نظام DNS بعد اتصال VPN؟ سببان

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

لماذا تحتفظ التوزيعة بمحللها الخاص

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

هذا الترتيب مستقر عبر تغييرات الشبكة العادية لأنه يُكتب مرة واحدة ويُعاد استخدامه. لكنه يتوقف عن كونه صحيحاً عندما يعيد عميل نفق كتابة قائمة محولات المضيف بعد أن يكون الجهاز المساعد قد بدأ بالفعل.

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

اجمع الأدلة من الجانبين أولاً

سجّل ما تراه التوزيعة، ثم ما يراه Windows، قبل تغيير أي منهما. الصورتان معاً هما ما يميز نمطي العطل.

داخل التوزيعة، اطبع ملف المحلل وجدول التوجيه وبحثاً داخلياً وآخر عاماً:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

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

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

مقياس المسار أم الملف القديم

العطل الأول هو الملف القديم. كُتب المحلل لحالة المحول عند الإقلاع، وقد غيّر النفق تلك الحالة. قد يكون عنوانه الوهمي غير قابل للوصول الآن، أو قد يشير إلى خادم لا يعرف شيئاً عن النطاق الداخلي.

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

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

في حالة التوجيه، أزل المقياس التلقائي من محول النفق وأعطه رقماً أعلى من مسار وصلة WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

الإيقاف مهم. تغيير المقياس لا يعيد كتابة الجهاز المساعد العامل، لذا يجب إعادة بناء التوزيعة قبل أن يظهر التغيير.

تولَّ الملف بيدك، عن قصد

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

أنشئ /etc/wsl.conf داخل التوزيعة مع قسم الشبكة الذي يعطّل التوليد، ثم اكتب ملف المحلل بنفسك، خادم الشركة أولاً وخادم عام احتياطياً:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

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

تحقق من الأسماء، ثم من الحزم

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

إذا كنت تؤتمت إعادة الكتابة، فاجعلها قابلة للتكرار بأمان: في غياب أي نفق، أبقِ الملف الموجود بدلاً من كتابة قائمة خوادم فارغة.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

بحث داخلي عامل وبحث عام عامل، من داخل التوزيعة، هو الناتج الجدير بالتسجيل. أيقونة VPN خضراء على المضيف لا تثبت أياً منهما.