لماذا لا يستطيع تطبيق iPhone تشغيل شبكة VPN النظام أو إيقافها

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

ابدأ من الأشياء الثلاثة التي يقصدها المستخدم

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

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

ما يمكن للتطبيق إنشاؤه فعليًا

يمنح NetworkExtension التطبيق إعدادًا خاصًا به عبر NEVPNManager. ومع استحقاق Personal VPN وموافقة المستخدم، يحفظ التطبيق إعدادًا يظهر في الإعدادات باسمه، ويمكنه تشغيل ذلك الاتصال الواحد أو إيقافه. هذه قدرة حقيقية قابلة للمراجعة، وهي أيضًا النطاق كله: فالمدير لا يقرأ ولا يكتب إلا ما أنشأه.

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

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

قراءة الحالة تصطدم بالجدار نفسه

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

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

On Demand وAlways On هما الرافعتان الحقيقيتان

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

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

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

اشحن المسار المدعوم

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

أي API خاص يعبث بشبكة VPN النظام سينجح في عرض تجريبي ويفشل في المراجعة، وإن شُحن بوسيلة أخرى فسينكسر في إصدار iOS التالي. ولا توجد نسخة من تلك المقايضة تستحق العناء من أجل مفتاح تشغيل.

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