WSL2 لا يصل إلى شبكة VPN الفرعية: اقرأ مسار المضيف

من داخل التوزيعة ينتهي أمر ping إلى خادم داخلي بمهلة، بينما يستجيب العنوان نفسه من Windows. الـVPN متصل ومسار Windows صحيح، لذا الفجوة هي حدود WSL. تتبّع المسار من الأمر الفاشل رجوعًا إلى واجهة المضيف. الإصلاح ليس CIDR ثابتًا في ملف إعداد، بل قراءة العنوان الحالي وإضافته حيث تستطيع التوزيعة استخدامه.

تأكد من أين يتوقف المسار

نفّذ الاختبار نفسه على الجانبين: حلّ اسم مضيف داخلي واتصل به من Windows، ثم كرّر ذلك داخل التوزيعة. نجاح في Windows مع مهلة في التوزيعة يحدد موضع الفشل بينهما، لا في عميل الـVPN أو الخادم الداخلي. افعل ذلك قبل تغيير أي مسار، حتى يصف النتيجتان الوجهة نفسها.

داخل التوزيعة يعرض ip -4 addr محولًا افتراضيًا بعنوان من نطاق NAT الخاص بـWSL، ويعرض ip route مسارًا افتراضيًا يشير إلى بوابة WSL. لا يوجد مسار للبادئة المؤسسية، لأن محول النفق في المضيف ليس له نظير داخل التوزيعة. البوابة الافتراضية تؤدي إلى NAT الخاص بـWSL، لا إلى الشبكة المؤسسية.

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

اختر الشبكة المتطابقة أو مسارًا بسكربت

تسلّم الشبكة المتطابقة للتوزيعة واجهات المضيف نفسها، فيظهر النفق ومساره دون نسخ. تعتمد الميزة على إصدار Windows حديث وعلى networkingMode=mirrored في .wslconfig، وتفعيلها يغيّر سلوكًا غير ذي صلة مثل تمرير localhost. اعتبرها تغييرًا على مستوى المنصة، لا تعديلًا للمسار. إذا كان الإصدار يدعمها والآثار الجانبية مقبولة، فهي أقصر طريق.

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

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

اسحب تفاصيل النفق الحالية من المضيف

طابق المحول بعنوان MAC لا بالاسم، لأن الأسماء تتغير مع عميل الـVPN وترتيب الاتصال. اسرد المحولات مرة واحدة، ودوّن MAC محول النفق، ثم استعلم عن عنوانه وبادئته. يبقى MAC مع المحول الافتراضي عبر إعادات الاتصال، بينما لا يبقى الاسم ولا فهرس الواجهة:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

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

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

مرّر الخرج عبر tr -d '\r' قبل إسناده إلى متغير. يُنهي PowerShell الأسطر بحرف إرجاع، وبدون التجريد يحمل الحقل الأخير حرفًا خفيًا يجعل أمر المسار يفشل بخطأ تحليل محيّر.

طبّق العنوان والمسار داخل التوزيعة

ثبّت عنوان النفق كعنوان مقيّد ببادئة على واجهة التوزيعة، ثم وجّه الكتلة المؤسسية عبر بوابة المضيف:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

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

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

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

ثبّت الاسم وأثبت المسار

يمكن أن تعيد النواة تسمية واجهة التوزيعة بين eth1 وeth2 بعد تبديل الشبكة، وعندها يحرّر سكربت مكتوب باسم الجهاز الخطأ. قاعدة udev مرتبطة بـMAC تعطي الواجهة تسمية ثابتة:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

ثم تحقق بالعنوان والمسار واتصال TCP حقيقي: ip -4 addr show dev vpn، ثم ip route get 172.20.4.10، واتصال بمنفذ داخلي معروف. يجب أن يسمّي بحث المسار جهاز vpn وعنوان المصدر الذي أضفته.

إذا نجحت الثلاثة داخل التوزيعة وظل الاتصال فاشلًا، فإن الحزمة تغادر WSL وتُسقَط على جانب Windows. افحص جدار حماية المضيف وفلترة عميل الـVPN قبل تغيير السكربت، لأن تعديل مسار آخر لن يصلح حزمة تصل إلى المضيف بالفعل.