واجهات برمجة VPN في iOS: NEVPNManager أم مزوّد النفق أم الملف الشخصي؟

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

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

الخطوة 1: اختر حسب النقل

إذا كان الخادم يعمل بـ IKEv2 أو بـ IPsec على طريقة Cisco، فإن NEVPNManager يكفي ونقل النظام يأتي مجانًا. وإذا كان الخادم يتحدث OpenVPN، أو WireGuard أو أي شيء آخر، فإن NEVPNManager لا يستطيع المساعدة: فليس فيه خطاف لبروتوكول طرف ثالث. وتلك الحالة تحتاج NETunnelProviderManager مع مزوّد نفق حزم ينفّذ البروتوكول. أما الملف الشخصي فلا يوزّع إلا التكوين، ولا يمكنه إضافة نقل يفتقده نظام التشغيل.

PPTP ليس هدفًا على الأنظمة الحالية. ولا يزال IPsec بالمفتاح المشترك يتوقع اسم المجموعة في remoteIdentifier، وعنصرًا في سلسلة المفاتيح يحمل السر، ومصادقة موسّعة عندما يطلب الخادم اسم مستخدم. وكل جزء ناقص يظهر كخطأ التكوين العام نفسه، فأضفها كلها قبل تشخيص أي شيء آخر.

الخطوة 2: احترم ترتيب الحفظ والتحميل والبدء

يكتب NEVPNManager في التفضيلات، ثم يقرأها مرة أخرى، ولا يبدأ إلا بعد ذلك. املأ كائنَي البروتوكول والمدير، واستدعِ saveToPreferences، ثم call loadFromPreferences، ثم استدعِ startVPNTunnel من معالج إكمال التحميل. أما البدء قبل عودة التحميل فينتج خطأ تكوين غير صالح، وهو الرمز 1 في NEVPNErrorDomain، على تكوين صحيح في ما عدا ذلك.

الشكل قصير بما يكفي لحفظه في مكان واحد:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

يعود startVPNTunnel عند قبول الطلب، لا عند صعود النفق. راقب NEVPNStatusDidChange واقرأ connection.status لمعرفة الحالة الحقيقية. والتطبيق الذي يفترض النجاح عند موضع النداء يبلّغ عن VPN متصلة بينما الامتداد ما زال يتفاوض. وحالة الاتصال العابرة أمر طبيعي للحظة؛ أما حالة لا تخرج منها أبدًا فهي العطل الذي يستحق التسجيل.

الخطوة 3: امنح عملية المزوّد ما تحتاجه

النقل المخصص يعمل في عملية منفصلة بمعرّف حزمة خاص به واستحقاق خاص به. ويحتاج كل من تطبيق الحاوية والمزوّد إلى استحقاق امتداد الشبكة وقت التوقيع، كما أن بناء Developer ID خارج App Store عليه أن يحمله في ملف التزويد. والاستحقاق الناقص يبدو كخطأ بروتوكول لأن الامتداد ببساطة يفشل في البدء.

لا يوجد واصف مقبس عام لاستعارته. يمنحك NEPacketTunnelProvider الكائن NEPacketTunnelFlow مع read وwrite وcancel، والشفرة التي تمتد إلى مسارات مفاتيح خاصة تتعطل بين الإصدارات. ويستمر المزوّد في العمل بينما التطبيق في الخلفية، فلا يحتاج تطبيق الحاوية إلى وضع خلفية لذلك.

الخطوة 4: التشغيل عند الطلب مجموعة قواعد، لا مفتاح

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

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

الخطوة 5: أثبت المسار، لا التسمية

البحث عن واجهات tun أو tap أو ppp أو ipsec يثبت أن VPN مكوّنة، لا أن طلبك استخدمها. وNWPathMonitor مع usesInterfaceType(.other) يقول إن واجهة افتراضية متاحة، ويمكن لمعالج صلاحية أن يختبر مضيفًا واحدًا. ولا يثبت أي منهما مسار الخروج، فاجمعهما مع طلب إلى مورد لا يصل إليه إلا النفق. أسماء الواجهات عون تشخيصي، وليست أبدًا بوابة يجب أن يتفرّع عليها منطق التطبيق.

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