VPN على iPad دون مطالبات بكلمة المرور: الشهادات أو تسجيل الدخول المحفوظ
كلمة المرور المحفوظة وشهادة الجهاز تزيلان المطالبة بطريقتين مختلفتين. قارن بينهما، ثم قرر بشكل منفصل ما الذي يفتح النفق.
«توقف عن سؤالي عن كلمة المرور» يجمع في الحقيقة ثلاثة متطلبات في شكوى واحدة، ونشر على iPad يجيب عنها في أماكن مختلفة. تأتي المطالبة من المصادقة، ويأتي التوقيت من التنشيط، وتأتي التغطية من الإنفاذ. اختر أولاً بيانات الاعتماد التي تزيل المطالبة، ثم قرر بشكل منفصل ما يحدد متى يُفتح النفق. خلط هذين القرارين هو بالضبط ما يجعل كلمة مرور محفوظة تنتهي على ملف تعريف لا يزال ينتظر لمسة.
| Saved or shared secret | Device certificate | |
|---|---|---|
| What the user sees | no prompt while the credential stays valid | no prompt, no password to rotate |
| What the admin manages | the secret in the profile and its distribution | enrollment, expiry and revocation per device |
| Typical failure | gateway demands a second factor | expired or revoked certificate |
مشكلتان في شكوى واحدة
يمكن أن يشير إعداد IKEv2 الأصلي على iPad إلى كلمة مرور أو إلى شهادة، ويحدد المفتاح AuthenticationMethod أيهما ينطبق، بينما يسمي PayloadCertificateUUID بيانات الاعتماد التي توفر الهوية. وأي الاثنين ستقبله البوابة مسألة سياسة خادم وليست تفضيل عميل. لذلك أول ما يجب تحديده هو ما تسمح به خدمة VPN، لأن iPad لا يستطيع التفاوض للوصول إلى طريقة يرفضها الطرف الآخر.
بعد ذلك فقط يكون من المنطقي الحديث عن متى يتم تنشيط النفق، وهي مجموعة مختلفة تماماً من مفاتيح ملف التعريف.
الخيار الأول: بيانات اعتماد يستطيع iPad إعادة استخدامها
كلمة مرور حساب محفوظة أو سر مشترك تُرضي بوابة تصادق المستخدم أو المجموعة، وتزيل المطالبة ما دام السر صالحاً. وضعفها هو دورة الحياة: السر موجود في ملف التعريف، وقد تتشاركه عدة أجهزة، وتدويره يعني لمس كل ملف تعريف يحمله. وإذا كانت الخدمة تطلب أيضاً عاملاً لمرة واحدة أو موافقة تفاعلية، فلا يوجد إعداد محلي يحول تلك السياسة إلى تسجيل دخول دون إشراف.
كلمة المرور التي يحفظها تطبيق واحد ليست متاحة تلقائياً لتطبيق VPN آخر، ولهذا قد يتوقف الحساب نفسه عن السؤال في عميل ويطلب في كل مرة في عميل آخر.
الخيار الثاني: شهادة جهاز بمفتاح خاص بها
الشهادة تزيل المطالبة بطريقة أقوى، لأن iPad يثبت امتلاك مفتاح خاص بدلاً من إعادة تشغيل سر. ويتطلب ذلك أن تصل شهادة الورقة ومفتاحها عبر مسار التسجيل المعتمد، وأن تقبل البوابة المصادقة بالشهادة لذلك الاتصال. واستيراد شهادة CA وحدها يمنح الجهاز مادة ثقة ولا شيء غير ذلك، وهو فشل شائع وصامت.
الثمن هو عمل دورة الحياة. كل iPad يحصل على هويته الخاصة كي يمكن إبطال جهاز مفقود دون إعادة إصدار الأسطول كله، وتصبح تواريخ الانتهاء أحداثاً تشغيلية حقيقية. والشهادة التي تنتهي بهدوء تبدو تماماً كعطل VPN في صباح حدوث ذلك.
اختر بحسب ما تقبله البوابة، لا بحسب التفضيل
اسأل مسؤول VPN سؤالين: أي طرق مصادقة تقبلها الخدمة لهذا النوع من العملاء، وهل يتطلب أي منها إدخالاً تفاعلياً. إذا كان الجواب الشهادة فقط، فخطط للتسجيل والتجديد. وإذا كان الجواب كلمة مرور مع عامل ثانٍ، فاقبل أن المطالبة سياسة وتوقف عن اعتبارها عطلاً في الجهاز. وإذا قُبل الاثنان، تفوز الشهادة في دورة الحياة لأسطول خاضع للإشراف وتفوز كلمة المرور في جهد الإعداد لعدد قليل من الأجهزة.
اكتب الطريقة المختارة في سجل النشر إلى جانب معرّف ملف التعريف، وإلا فسيختار الشخص التالي الذي يلمس الملف الأخرى.
ثم افصل التنشيط عن المصادقة
يفتح VPN On Demand النفق عندما تتطابق حالة مكوّنة، سواء كانت نطاق DNS أو نوع واجهة أو شبكة منضمة، وتوثق Apple ذلك بأنه لا يتطلب تفاعلاً من المستخدم. وهذا يناسب الموارد الخاصة التي ينبغي أن تصبح قابلة للوصول فقط عندما يطلبها شيء ما. وهو ليس مثل Always On المُدار، الذي يبقي التغطية مفروضة ويأتي بمتطلبات إشراف وملف تعريف خاصة به.
بيانات الاعتماد العاملة لا تفعل شيئاً لأي منهما. وكثير من أجهزة iPad تحمل شهادة سليمة تماماً ومع ذلك تنتظر لمسة يدوية لأن أي قاعدة عند الطلب لم تُفعّل قط.
سلّم المتطلب بصيغة يستطيع المسؤول التصرف بناءً عليها: يجب أن يصل هذا iPad إلى هذه الموارد دون إدخال متكرر من المستخدم، وبهذا النوع من بيانات الاعتماد، ووفق قواعد التنشيط والانقطاع هذه. وإذا كانت الخدمة الحالية لا تستطيع تلبية تلك الشروط، فالمطالبات المتكررة هي السياسة تعمل كما صُممت.