VPN لكل تطبيق على تطبيقات iPhone المُدارة: ما الذي يُوجّه وما الذي لا يُوجّه

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

افحص الحمولة وسجل التطبيق أولًا

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

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

شرط واحد يفسّر كثيرًا من التذاكر: يحتاج هذا النموذج إلى وصول التطبيق عبر الإدارة. فالنسخة المحمّلة جانبيًا أو المشتراة شخصيًا لا تحصل على الارتباط، حتى عندما يطابق معرّف حزمتها. ويصف دليل النشر من Apple الخاص بـ VPN نموذج الحمولة الكامن وراء ذلك (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).

تأكّد من أن التطبيق المثبّت هو النسخة المُدارة

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

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

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

تحقّق مما يُسمح للنفق بأخذه

يُختار نفق لكل تطبيق حسب التطبيق المصدر، لذا يظل المسار الافتراضي للهاتف ملكًا لشبكة Wi-Fi أو الشبكة الخلوية. وOverridePrimary هو المفتاح الذي يغيّر ذلك. وعندما يضبطه ملف تعريف، يتصرف النفق كنفق كامل ويرثه كل تطبيق، فيصبح كل ما يمر عبر VPN مسألة ملف تعريف بدلًا من أن يكون عطل تطبيق.

قواعد التشغيل عند الطلب تحدّد الاستمرارية. فـ OnDemandEnabled مع مجموعة قواعده هو ما يجعل النفق يعود عندما يرسل التطبيق حركة، ويصمد أمام الانتقال من Wi-Fi إلى الشبكة الخلوية، أو يسقط بمجرد انتقال التطبيق إلى الخلفية. والنشر الذي يتصل ثم يموت بهدوء عادةً ما تكون لديه قاعدة تطابق فقط مسبارًا لا يعمل أبدًا بينما يكون التطبيق خاملًا.

ثم اقرأ جانب المسار بصدق. إذا وفّر ملف تعريف المزوّد أو البائع قائمة تضمين، فلن ينقل نفق يحمل 10.20.0.0/16 فقط خدمة في 10.30.0.0/16؛ فالقائمة تؤدي عملها، وليس ذلك عطلًا خاصًا بالتطبيقات. ولا تحتوي حمولة iOS المدمجة على قائمة تضمين. وبدونها يتبع التقسيم إعدادات المزوّد الافتراضية وIncludeAllNetworks، لا قائمة مخفية.

اختبر التطبيق، ثم اختبر ما يخرج منه

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

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

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

طابق العرَض مع الطبقة

شكل العطل يخبرك بالفحص الذي يجب تكراره.

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

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

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