VPN لكل تطبيق أم split tunnel؟ ما الذي يمكن أن يقرره مسار في Mac

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

المُحدِّد وجهة، وليس عملية أبدًا

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

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

ما يقدمه split tunnel العادي فعليًا

يثبّت split tunnel مسارات للبادئات الخاصة ويترك كل شيء آخر على المسار الفيزيائي. هذا عادة ما يعنيه الطلب: الوصول إلى الخادم المكتبي عبر النفق، وإبقاء التصفح العام مباشرًا. الأمر بسيط، وكل عميل شائع يدعمه، وتفرضه الآلية نفسها التي تفرض أي مسار آخر. تحقق من الوجهة المحددة باستخدام route -n get بدلًا من قراءة المسار الافتراضي، لأن split tunnel غالبًا ما يترك المسار الافتراضي دون مساس.

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

ما يتطلبه VPN لكل تطبيق على macOS

VPN الحقيقي لكل تطبيق على macOS هو ميزة Network Extension يقودها ملف تعريف إعداد. تحمّل إدارة يربط التطبيقات المختارة بإعداد VPN، ثم يوجّه النظام حركة تلك التطبيقات وفقًا لذلك. إنه نشر مُدار، ما يعني MDM وملفًا موقّعًا ومسؤولًا يملك الاثنين.

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

ثلاثة طرق للفصل على مستوى التطبيق دون MDM

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

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

اكتب الطلب بحيث تكون الإجابة قاطعة

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

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