حسابان لتسجيل الدخول على Mac لا يقسمان حركة VPN

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

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

ابدأ من الحركة، لا من قائمة الحسابات

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

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

قناة الملف الشخصي ونطاق الحركة أمران مختلفان

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

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

نظام الضيف حدّ حقيقي بحدود حقيقية

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

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

الوكيل أضيق من حساب مستخدم

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

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

أثبت الحد باختبارين

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

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