تقدّم هذه الصفحة إرشادات لمشغّلي الشبكات لضمان توفير تطبيقات الشبكة الافتراضية الخاصة (VPN) للمستهلكين والمؤسسات تجربة جيّدة للمستخدمين النهائيين على شبكاتهم. يوفّر نظام التشغيل Android فئة
VpnManager
للمطوّرين لإنشاء حلول شبكات VPN التي يستخدمها المستهلكون
والمؤسسات لتشفير اتصالاتهم أو توجيهها إلى شبكات مختلفة.
ننصح مشغّلي الشبكات باتّباع الإرشادات التالية:
- توفير بروتوكول ESP (حمولة الأمان المغلفة) المتوافق مع IPv6 (الرأس التالي 50) على شبكتك، مع التأكّد من أنّ حركة البيانات هذه تتضمّن أداءً مشابهًا لاتصالات بروتوكول مخطط بيانات المستخدم (UDP) أو بروتوكول التحكم في الإرسال (TCP). يجب السماح لجلسات ESP بالوصول إلى الأجهزة، أو ضبطها على مهلات طويلة جدًا، وإعادة توجيهها بمعدل خطي.
- اضبط مهلات ترجمة عناوين الشبكة (NAT) وجدار الحماية المزود بحالة بما لا يقل عن 600 ثانية لاتصالات UDP على المنفذ 4500 لضمان قدرة حلول VPN على الحفاظ على اتصال موثوق بدون تكبّد تكاليف طاقة مفرطة.
إتاحة حِزم بروتوكول ESP للإصدار 6 من بروتوكول الإنترنت (الرأس التالي 50)
Encapsulating Security Payload (ESP) هو تنسيق الحزمة المحدّد كجزء من مجموعة بروتوكولات أمان بروتوكول الإنترنت (IPSec) لتشفير الحزم والمصادقة عليها في حلول شبكات VPN. ينفّذ نظام التشغيل Android بروتوكول الأمان العادي هذا في حلّ VPN المُضمَّن.
في الشبكات المتوافقة مع الإصدار 6 من بروتوكول الإنترنت، يتم نقل حِزم ESP مباشرةً في حِزم الإصدار 6 من بروتوكول الإنترنت مع حقل "العنوان التالي" بقيمة 50. إذا كانت الشبكة لا تتوافق بشكل صحيح مع هذه الأنواع من الحِزم، قد يؤدي ذلك إلى عدم توفّر اتصال لحلول VPN التي تهدف إلى استخدام هذا البروتوكول بدون تغليف إضافي للحِزم. قد تسقط الشبكة هذه الحِزم بسبب إعدادات جدار الحماية. أو قد تصل حِزم ESP إلى مسارات بطيئة على الشبكة، ما يؤدي إلى انخفاض كبير في أداء معدل النقل مقارنةً باتصالات TCP أو UDP.
تنصح "مجموعة مهندسي شبكة الإنترنت" (IETF) بالسماح لبروتوكول IPsec بالمرور عبر جدران الحماية التي تستخدمها خدمات الوصول إلى الإنترنت المخصّصة للمستهلكين. على سبيل المثال، راجِع القسم 3.2.4 من RFC 6092. يمكن السماح بمرور حِزم ESP بأمان عبر جدران الحماية في كلا الاتجاهين، لأنّه إذا تلقّى جهاز حزمة ESP ليست جزءًا من ربط أمان حالي، سيتجاهل الجهاز الحزمة. نتيجةً لذلك، لا يحتاج الجهاز إلى إرسال حِزم إبقاء الاتصال نشطًا للحفاظ على الاتصال عبر شبكة VPN، ما يؤدي إلى توفير شحن البطارية. ننصح الشبكات إما بالسماح بحِزم ESP للأجهزة في جميع الأوقات، أو بإنهاء جلسات ESP بعد فترات طويلة من عدم النشاط (على سبيل المثال، 30 دقيقة).
ننصح مشغّلي الشبكات بتوفير حِزم بروتوكول ESP (حِزم IPv6 مع رأس تالٍ بقيمة 50) على شبكاتهم وإعادة توجيه هذه الحِزم في الأجهزة بمعدّل سرعة الخط. ويضمن ذلك ألا تواجه حلول شبكات VPN مشاكل في الاتصال وأن تقدّم أداءً مماثلاً لاتصالات UDP أو TCP.
ضبط مهلات كافية لجدار الحماية المزود بميزة "ترجمة عنوان الشبكة" (NAT)
للحفاظ على موثوقية الاتصال، يجب أن يحافظ حلّ شبكة VPN على اتصال طويل الأمد بخادم VPN الذي يوفّر إمكانية الاتصال الصادر والوارد (على سبيل المثال، لتلقّي الإشعارات الفورية الواردة ورسائل المحادثة والمكالمات الصوتية أو مكالمات الفيديو). تستخدم معظم تطبيقات IPsec VPN بروتوكول ESP مضمّنًا في حِزم IPv4 UDP مع منفذ الوجهة 4500، كما هو موضّح في RFC 3948.
للحفاظ على هذا الاتصال، يجب أن يرسل الجهاز حِزمًا بشكل دوري إلى الخادم. ويجب إرسال هذه الحِزم بمعدل تكرار أعلى من معدل انتهاء المهلة الذي يفرضه مشغّل الشبكة على NAT وجدار الحماية. تتطلّب عمليات إبقاء الاتصال نشطًا المتكرّرة طاقة كبيرة من جانب العميل، كما أنّها تؤثر بشكل كبير في عمر البطارية. وتؤدي أيضًا إلى إنشاء عدد كبير من الزيارات المتعلقة بالإشارات على الشبكة، حتى إذا كان الجهاز غير نشط.
ننصح المشغّلين برفع مهلات NAT والجدار الناري المزود بحفظ الحالة إلى مستوى مرتفع بما يكفي لتجنُّب التأثير في البطارية. الوقت الذي يُنصح بتحديده لانتهاء مهلة تغليف IPsec UDP (المنفذ 4500) هو 600 ثانية أو أكثر.
في شبكات الجوّال، يتم غالبًا إبقاء مهلات UDP NAT منخفضة لأنّ ندرة عناوين IPv4 تفرض عوامل عالية لإعادة استخدام المنافذ. ومع ذلك، عند إنشاء شبكة VPN، لا تحتاج شبكة الجهاز إلى توفير اتصالات TCP طويلة الأمد، مثل تلك المستخدَمة لتلقّي الإشعارات الواردة. وبالتالي، فإنّ عدد الاتصالات الطويلة الأمد التي يجب أن توفّرها الشبكة يكون مماثلاً أو أقل عند تشغيل شبكة VPN مقارنةً بعدم تشغيلها.