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

المُشغّل قاعدة دورة حياة، لا قاعدة توجيه

Add-VpnConnectionTriggerApplication يربط مسار ملف تنفيذي باسم ملف تعريف. عندما تبدأ تلك العملية، يتصل مدير اتصالات الوصول عن بُعد بملف التعريف، و عندما ينتهي شرط المُشغّل يمكن أن ينقطع الاتصال. لا شيء في ذلك التبادل يفحص المقابس. تحتاج الأداة إلى صدفة مرفوعة، والمسار الكامل إلى الملف الثنائي، و -Force عند استبدال إدخال موجود. تأكد من بقاء الربط باستخدام Get-VpnConnectionTrigger بدلًا من الوثوق بالمطالبة؛ مرجع Microsoft الخاص بـ Add-VpnConnectionTriggerApplication يسرد المعاملات والأمثلة.

حدّان يفسران معظم التقارير التي تقول «المُشغّل لا يفعل شيئًا». تُبنى المُشغّلات حول ملفات تعريف لكل المستخدمين، لذا فإن نطاق ملف التعريف هو أول ما يجب حسمه، ويجب أن يطابق مسار التطبيق الملف الثنائي الذي يعمل فعلًا، لا اختصارًا ولا مشغّلًا ينشئ عملية ثانية. الحد الآخر مقصود: على شبكة يصنفها Windows موثوقة، يبقى المُشغّل خاملًا، لأن ملف التعريف مخصص للعمل خارج المكتب.

Add-VpnConnectionTriggerApplication -Name "APP_VPN" -ApplicationID "C:\Program Files\Vendor\app.exe" -Force
Get-VpnConnectionTrigger -Name "APP_VPN" | Format-List *
Get-VpnConnection -Name "APP_VPN" | Format-List Name,ConnectionStatus,SplitTunneling,AllUserConnection

النفق المنقسم يقرر ما يعبر النفق

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

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

Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix

حيث يتوقف الانقسام الموجّه عن عزل تطبيقك

الفشل الشائع هو وجهة لا تظهر أبدًا في قائمة مسارات النفق. التطبيق الذي يسجّل الدخول إلى عنوان واحد ثم يبثّ من CDN، أو يحل دستة من نقاط النهاية المتغيرة، سيضع بعض الاتصالات على واجهة VPN والبقية على Wi-Fi. IPv6 جدول منفصل، لذا قد يبدو ملف تعريف يدفع بادئات IPv4 فقط صحيحًا بينما تبقى حركة IPv6 للتطبيق محلية.

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

ثلاثة أشكال، وما يشتريه كل منها

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

ShapeWhat starts the tunnelWhat enters itPick it when
Trigger plus routed splitProcess startOnly pushed or added prefixesThe app's endpoints are stable prefixes and the host should stay direct
Trigger plus default routeProcess startEverything, machine-wideYou need one exit for all traffic and accept the wider scope
Separate VM or deviceGuest boot or loginEverything inside that guestThe app's destinations rotate, or the host must keep its own public address

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

تحقق من الزوج في تمريرة واحدة

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

$app = Get-Process app | Select-Object -First 1
Get-VpnConnection -Name "APP_VPN" | Select-Object ConnectionStatus
Get-NetTCPConnection -OwningProcess $app.Id -State Established | Select-Object RemoteAddress,RemotePort
Find-NetRoute -RemoteIPAddress 203.0.113.10

Find-NetRoute يسمّي الواجهة والخطوة التالية التي ستحمل تلك الوجهة. وجود اسم مستعار فيزيائي هناك يعني أن النفق مرتفع وغير ذي صلة بذلك التدفق: افحص البادئات المدفوعة، ثم المسارات الأكثر تحديدًا، ثم IPv6. إذا لم تتغير الحالة إطلاقًا، فإن المُشغّل لم يعمل، ومسار الملف التنفيذي ونطاق ملف التعريف وسجل تشغيل عميل VPN هي الأماكن الثلاثة التي يجب النظر فيها.

نظّف بعناية ليكون الاختبار التالي صادقًا

أزل بالترتيب العكسي للبناء: مُشغّل التطبيق أولًا، ثم ملف التعريف. حذف ملف التعريف مع بقاء المُشغّل يترك ارتباطًا معلقًا يجعل المحاولة التالية مربكة، و Remove-VpnConnection -Force لا ينظف دائمًا إدخال دفتر هاتف أُنشئ خارج الأوامر.

الإدخالات حسب المستخدم موجودة في rasphone.pbk المستخدم تحت ملف تعريف Roaming؛ والإدخالات لكل المستخدمين موجودة تحت ProgramData. تحقق من المخزن المطابق لنطاق ملف التعريف، وأعد اتصال ملف التعريف الذي أبقيت عليه، وأكّد أن مساراته وDNS ما زالت تتصرف، حتى يقيس اختبار لاحق التغيير الذي أجريته لا الحالة المتبقية.

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

مقالات ذات صلة