كيف تتحقق مما يمرره VPN على Windows فعليًا عبر PowerShell
لا يثبت مربع VPN المتصل أن التغطية كاملة. اقرأ علامة الملف الشخصي المحفوظة، وجدول المسارات الحالي، وقواعد NRPT بهذا الترتيب.
وصلت عميل VPN على حاسوب محمول يعمل بـ Windows 11، فتحول المربع إلى «متصل»، وانفتح ملف مشترك داخلي، وظل موقع عام يُحمَّل مباشرة من شبكة Wi-Fi المكتب. هذه الخلطة تبدو كنفق معطوب. لكنها الناتج الطبيعي لملف شخصي يرسل بعض حركة المرور عبر VPN ويترك الباقي على المحول الفيزيائي. النفق القسري يغيّر المسار الافتراضي الذي يفضله Windows؛ ولا يحذف المسارات الأكثر تحديدًا، ولا يَعِد بأن الحركة تتوقف عند انقطاع الاتصال. وفي ما يلي الترتيب الذي أتبعه عندما يدّعي عميل أن التغطية كاملة: حالة العميل، والملف المحفوظ، والمسارات المطبقة، وحلّال الأسماء، ثم التدفقات الفعلية.
ابدأ من العميل، ثم توقف عن الوثوق به
العميل هو نقطة البداية الصحيحة فقط لأنه يخبرك أي ملف شخصي نشط. افتح خصائص الاتصال وسجّل اسم الملف الشخصي بدقة، وهل أُنشئ للمستخدم الحالي أم لكل مستخدمي الجهاز، وأي محول يظهر في ncpa.cpl بعد الاتصال. على حاسوبي التجريبي حمل المحول اسم الملف، ما جعل قراءة إخراج المسارات سهلة. وعلى أجهزة أخرى يظهر كمدخل WAN Miniport ولا يخبرك الاسم بشيء.
ما لا يستطيع العميل إخبارك به هو التغطية. المربع المتصل يصف حالة النفق، لا جرد الوجهات. عملاء الطرف الثالث يحتفظون أيضًا بتكوينهم الخاص، لذا قد لا يكون ملف Windows الأصلي، وكل خاصية ستقرأها منه، على صلة بما ثبّته ذلك العميل. وإذا وصل VPN عبر AnyConnect أو OpenVPN GUI أو WireGuard أو وكيل مورّد، فإن فحوص PowerShell أدناه لا تنطبق في الغالب، وعليك قراءة إعدادات النفق المنقسم والتوجيه الخاصة بذلك العميل بدلًا منها.
اقرأ الملف المحفوظ، لا المربع
بالنسبة إلى ملف Windows أصلي (IKEv2 أو L2TP أو SSTP أو ملف يدفعه MDM) فإن قرار النفق المنقسم المحفوظ خاصية واحدة:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixأضف -AllUserConnection عندما أُنشئ الملف لكل مستخدمي الجهاز. وبدونه تقرأ قائمة المستخدم الحالي، وقد تكون فارغة أو تحمل إدخالًا آخر باسم مشابه. قيمة False في SplitTunneling تعني أن الملف حُفظ كنفق كامل: يثبّت Windows مسارًا افتراضيًا عبر محول VPN. وTrue تعني نفقًا منقسمًا، وحينها تعتمد التغطية كليًا على المسارات وقواعد حلّ الأسماء التي يدفعها الملف.
تعامل مع تلك القيمة كتكوين لا كملاحظة. فهي تسجّل ما طلبه الملف عند الاتصال. قد ينتهي Windows بمسارات مطبقة مختلفة، بسبب مسار أكثر تحديدًا لمحول آخر أو إعداد سياسة أو إدخال متبقٍ من اتصال سابق، لذا لا تحسم القيمة المنطقية السؤال وحدها.
قارن القيمة المحفوظة بجدول المسارات المطبق
بعد الاتصال، اسرد المسارات على محول النفق بدلًا من التمرير في الجدول كله:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute هو النصف المفيد. فهو يجيب عن السؤال الذي لا يجيب عنه العميل: لهذه الوجهة، أي محول وأي عنوان مصدر سيستخدمه Windows فعلًا؟ شغّله لمضيف داخلي ومضيف عام وأي شيء تعتقد أنه استثناء مقصود. من المفترض أن يُظهر ملف النفق الكامل واجهة النفق للعنوان العام. أما ملف النفق المنقسم فيُظهر عادةً المحول الفيزيائي هناك بينما تظل البادئات الداخلية تُحلّ إلى VPN.
مصيدتان تفسّران معظم تقارير «يوجّه في الاتجاه الخطأ». البادئة الأكثر تحديدًا تفوز دائمًا، لذا يتغلب /24 على المحول الفيزيائي على مسار افتراضي على VPN مهما كان مقياس النفق منخفضًا. والمقياس لا يفصل إلا بين المسارات ذات البادئة نفسها. ويُقرَّر IPv4 وIPv6 كلٌّ على حدة: ملف يغطي 0.0.0.0/0 قد يترك IPv6 على الرابط المحلي، ما يجعل موقعًا مزدوج الحزمة يبدو نصف منفَّق. افحص Get-NetRoute -AddressFamily IPv6 قبل أن تستنتج أن النفق سليم.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
افحص حلّ الأسماء منفصلًا باستخدام NRPT
الأسماء الداخلية التي تفشل بينما تعمل عناوين IP الداخلية تشير إلى سياسة حلّال الأسماء لا إلى التوجيه. يقرّر Windows DNS لكل نطاق أسماء عبر جدول سياسة حلّ الأسماء، وهو مستقل عن جدول المسارات:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexعندما تطابق قاعدة ما *.corp.example تذهب استعلامات ذلك النطاق إلى خوادم DNS الخاصة بالنفق حتى لو بقي مسار البيانات إلى تلك الخوادم على المحول الفيزيائي في وضع النفق المنقسم. هذا هو التصميم، ولهذا لا يخبرك اختبار متصفح يفتح موقعًا عامًا بشيء عن الأسماء الداخلية. وإذا سرد المحول الخوادم المتوقعة لكن البحث ما زال يذهب إلى مكان آخر، فقارن ترتيب قواعد NRPT وافحص ما إذا كان نطاق أكثر تحديدًا يطابق أولًا.
تحقق من التدفقات، ثم قرّر ما طلبته فعلًا
اعمل على الوجهات بترتيب ثابت كي تكون النتائج قابلة للمقارنة بين الأجهزة: عنوان عام، وعنوان داخلي، واسم داخلي، واستثناء مقصود واحد مثل طابعة محلية أو مكالمة فيديو. سجّل المحول وعنوان المصدر الذي يعيده Find-NetRoute لكل منها. بعد أي تغيير في السياسة، أعد الاتصال وكرّر الفحوص الأربعة نفسها؛ جدول المسارات بعد إعادة الاتصال هو الدليل الوحيد على أن الملف الجديد أصبح ساريًا.
ثم افصل التوجيه عن الإنفاذ. النفق القسري يفضّل النفق لحركة المرور المشمولة ما دام قائمًا. وهو ليس مفتاح إيقاف. وإذا كان المطلوب ألا يغادر شيء الجهاز عند سقوط النفق، فيجب أن يأتي ذلك من تصميم حاجب: ملف جدار حماية مرتبط بحالة النفق، أو ملف دائم التشغيل بمرشحات حركة، أو خيار الإغلاق عند الفشل الخاص بعميل المورّد. وعلى النفق القسري أيضًا أن يبقي عنوان خادم VPN نفسه قابلًا للوصول خارج النفق، وحجبه باسم «فرض كل شيء» طريقة موثوقة لإغلاق الاتصال الذي تحاول فرضه.
قبل أن تغيّر أي شيء، مرّ على هذه القائمة. كل بند يفشل يضيّق مكان المشكلة الحقيقي.
- تأكيد اسم الملف ونطاقه، مع استخدام
-AllUserConnectionللملفات على مستوى الجهاز. - قراءة
SplitTunnelingومعاملته كتكوين لا كدليل على التغطية. - سرد مسارات محول النفق لـ IPv4 وIPv6 منفصلين.
- تشغيل
Find-NetRouteلوجهة عامة وأخرى داخلية ووجهة استثناء واحدة. - فحص قواعد NRPT قبل لوم المسارات على فشل اسم.
- إعادة قراءة شرط الحجب: التوجيه المفضّل ليس هو الحجب المفروض.
قرار النفق الكامل أو المنقسم نفسه يعود إلى مالك الملف، وملاحظات Microsoft عن التوجيه تصف السلوك الذي يطبقه Windows عندما يضبطه ملف. Microsoft: النفق القسري والمنقسم هو المرجع الذي أبقيه مفتوحًا أثناء قراءة الإخراج.