از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
تجربه کاربر VPN را بهبود بخشید
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
این صفحه دستورالعمل‌هایی را برای اپراتورهای شبکه ارائه می‌کند تا اطمینان حاصل کنند که برنامه‌های شبکه خصوصی مجازی مجازی (VPN) مصرف‌کننده و شرکت تجربه خوبی برای کاربر نهایی در شبکه‌های خود ارائه می‌دهند. Android کلاس VpnManager را برای توسعه دهندگان فراهم می کند تا راه حل های VPN را ایجاد کنند، که توسط مصرف کنندگان و شرکت ها برای رمزگذاری ارتباطات خود یا مسیریابی آنها به شبکه های مختلف استفاده می شود.
ما به اپراتورهای شبکه توصیه می کنیم این دستورالعمل ها را دنبال کنند:
- از بسته‌های پروتکل IPv6 محفظه بار امنیتی (ESP) (Next Header 50) در شبکه خود پشتیبانی کنید و اطمینان حاصل کنید که این ترافیک عملکردی قابل مقایسه با اتصالات پروتکل دیتاگرام کاربر (UDP) یا پروتکل کنترل انتقال (TCP) دارد. جلسات ESP باید اجازه ورود به دستگاه‌ها را داشته باشند یا روی بازه‌های زمانی بسیار بالا تنظیم شوند و با نرخ خط ارسال شوند.
- ترجمه آدرس شبکه (NAT) و وقفه های فایروال حالتی را تنظیم کنید که حداقل 600 ثانیه برای اتصالات UDP در پورت 4500 باشد تا مطمئن شوید که راه حل های VPN می توانند اتصال قابل اعتماد را بدون متحمل شدن هزینه های انرژی بیش از حد حفظ کنند.
محصور کردن بار امنیتی (ESP) قالب بسته ای است که به عنوان بخشی از مجموعه پروتکل های امنیت پروتکل اینترنت (IPSec) برای رمزگذاری و احراز هویت بسته ها در یک راه حل VPN تعریف شده است. سیستم عامل اندروید این پروتکل امنیتی استاندارد را در راه حل داخلی VPN خود پیاده سازی می کند.
در شبکه‌های دارای IPv6، بسته‌های ESP مستقیماً در بسته‌های IPv6 با فیلد Next Header 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 در مقایسه با زمانی که VPN در حال اجرا نیست، یکسان یا کمتر است.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Improve VPN user experience\n\nThis page provides guidelines for network operators to ensure that consumer and\nenterprise virtual private network (VPN) apps provide a good end-user experience\nin their networks. Android provides the\n[`VpnManager`](https://developer.android.com/reference/android/net/VpnManager)\nclass for developers to create VPN solutions, which are used by consumers and\nenterprises to encrypt their communications or route them to different networks.\n\nWe recommend network operators follow these guidelines:\n\n- **Support IPv6 Encapsulating Security Payload (ESP) protocol (Next Header\n 50) packets on your network**, ensuring this traffic has comparable performance to user datagram protocol (UDP) or transmission control protocol (TCP) connections. ESP sessions should be allowed inbound to devices, or set to very high timeouts, and forwarded at line rate.\n- **Set network address translation (NAT) and stateful firewall timeouts** that are a minimum of 600 seconds for UDP connections on port 4500 to ensure VPN solutions can maintain reliable connectivity without incurring excessive power costs.\n\nSupport IPv6 ESP protocol (Next Header 50) packets\n--------------------------------------------------\n\nEncapsulating Security Payload (ESP) is the packet format defined as part of the\nInternet Protocol Security (IPSec) set of protocols to encrypt and authenticate\npackets in a VPN solution. The Android OS implements this standard security\nprotocol in its built-in VPN solution.\n\nOn IPv6-capable networks, ESP packets are carried directly in IPv6 packets with\na Next Header field of 50. If a network doesn't properly support these types of\npackets, it can cause a lack of connectivity for VPN solutions that aim to use\nthis protocol without further encapsulation of the packets. The network might\ndrop these packets due to firewall configuration. Or ESP packets might\nhit slow paths on the network, with severely degraded throughput performance\ncompared to TCP or UDP connections.\n\nThe Internet Engineering Task Force (IETF) recommends allowing IPsec through\nfirewalls used by consumer internet access services. For example, see\n[RFC 6092 section 3.2.4](https://www.rfc-editor.org/rfc/rfc6092.html#section-3.2.4).\nESP packets can be safely allowed through firewalls in both directions because\nif a device receives an ESP packet that isn't part of an existing security\nassociation, the device drops the packet. As a result, the device doesn't need\nto send keepalive packets to maintain VPN connectivity, which saves battery\nlife. We recommend that networks either allow ESP packets to devices at all\ntimes, or time out ESP sessions only after long periods of inactivity (for\nexample, 30 minutes).\n\nWe recommend network operators support ESP protocol packets (IPv6 packets with a\nNext Header of 50) on their networks and forward those packets in hardware at\nline rate. This ensures VPN solutions don't encounter connectivity issues and\nprovide performance comparable to UDP or TCP connections.\n\nSet sufficient NAT and stateful firewall timeouts\n-------------------------------------------------\n\nTo maintain connection reliability, a VPN solution needs to maintain a\nlong-lived connection to the VPN server that provides outbound and inbound\nconnectivity (for example, to receive incoming push notifications, chat\nmessages, and audio or video calls). Most IPsec VPN apps use ESP encapsulated in\nIPv4 UDP packets with destination port 4500, as described in\n[RFC 3948](https://www.rfc-editor.org/rfc/rfc3948.html).\n\nTo maintain this connection, the device needs to periodically send packets to\nthe server. These packets must be sent at a higher frequency than the NAT and\nfirewall timeouts imposed by the network operator. Frequent keepalives are power\nintensive on the client side, and have a major impact on battery life. They also\ngenerate substantial signaling traffic on the network, even if the device is\notherwise idle.\n\nWe recommend that operators raise NAT and stateful firewall timeouts high enough\nto avoid battery impact. The recommended timeout for IPsec UDP encapsulation\n(port 4500) is 600 seconds or greater.\n\nIn mobile networks, UDP NAT timeouts are often kept low because IPv4 address\nscarcity imposes high port reuse factors. However, when a VPN is established,\nthe device network doesn't need to support long-lived TCP connections, such as\nthose used to deliver inbound notifications. So the number of long-lived\nconnections that the network needs to support is the same or lower when a VPN is\nrunning compared to when a VPN isn't running."]]
