شبكتا VPN على iPhone في وقت واحد: أيّهما ينقل حركة المرور؟

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

خرافة: شبكتا VPN متصلتان سلسلة

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

إذا كنت تحتاج إلى التعشيش، فصمّمه تعشيشًا. لا تستنتجه من مؤشري اتصال. هذا التمييز يوفّر كثيرًا من التنقيح.

النموذج الموثّق وراء تلك الخرافة

تصف فئة NETunnelProviderManager من Apple إعدادات VPN المؤسسية العادية، وتنص على أنه لا يمكن تفعيل سوى واحد من هذا النوع في وقت واحد. ويسمح المرجع نفسه لشبكة Personal VPN بالبقاء مفعّلة ومتصلة إلى جانبها، ويمنح مسارات المؤسسة الأسبقية حيث تتقاطع الشبكتان.

Personal VPN هنا هو مصطلح واجهة البرمجة للتطبيق المدمج لـ IPsec أو IKEv2 المُدار عبر NEVPNManager. أما NETunnelProviderManager فهو نموذج مزوّد النفق. يمكن لتطبيق موجّه للمستهلك أن يستخدم نموذج المزوّد، لذا فإن اسم منتج يحتوي على personal لا يصنّفه.

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

خرافة: الشبكة الشخصية تحصل على حركة التصفح

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

لإعدادات التطبيقات المُدارة نطاقها الخاص. لا تعمّم قاعدة على مستوى الجهاز على كل نشر مُدار.

اكتب التدفقين قبل الاختبار: الاسم والنطاق الخاصان بخدمة العمل، وطلب تصفح عام جديد. كلاهما مشروع، وكلاهما يحتاج فحوصًا مختلفة.

أسبقية المسارات مع ملف عمل ذي نفق منقسم

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

اكتب الزوج في سطرين وسمِّ الفائز المتوقع لكل منهما: اسم مضيف عمل يُحلّ إلى 10.x أو 172.16.x يجب أن يخرج عبر نفق المؤسسة، وعنوان عام بلا بادئة مطابقة يجب أن يأخذ المسار الافتراضي المتبقي. إذا سمّى السطران المخرج نفسه، فالتقسيم لا يفعل ما تصفه الوثائق.

اكتب تدفقين واختبر كلًا منهما

لكل تدفق، سجّل أي إعداد معتمد يجب أن يحمله وأي مُحلِّل يجب أن يتلقى كل نوع من الأسماء. ثم تحقّق بطلبات جديدة، لا بصفحة عمل مخزّنة أو نتيجة IP قديمة.

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