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