2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
VPN のユーザー エクスペリエンスを改善する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このページでは、一般ユーザー向けおよび企業向けのバーチャル プライベート ネットワーク(VPN)アプリがネットワークで優れたエンドユーザー エクスペリエンスを提供するようにするための、ネットワーク事業者向けのガイドラインを紹介します。Android には、一般ユーザーや企業が通信の暗号化や別のネットワークへの通信の転送に使用する VPN ソリューションをデベロッパーが作成するための VpnManager
クラスが用意されています。
ネットワーク事業者は、次のガイドラインに準拠することをおすすめします。
- ネットワークで IPv6 カプセル化セキュリティ ペイロード(ESP)プロトコル(Next Header 50)パケットをサポートし、このトラフィックのパフォーマンスが User Datagram Protocol(UDP)や伝送制御プロトコル(TCP)の接続に匹敵するようにします。ESP セッションは、デバイスへのインバウンドを許可するか、タイムアウトを非常に高く設定して、ラインレートで転送されるようにする必要があります。
- ネットワーク アドレス変換(NAT)とステートフル ファイアウォールのタイムアウトを設定し(ポート 4500 での UDP 接続で 600 秒以上)、VPN ソリューションが電力コストをかけすぎることなく信頼できる接続を維持できるようにします。
カプセル化セキュリティ ペイロード(ESP)は、VPN ソリューションでパケットの暗号化と認証を行うためのインターネット プロトコル セキュリティ(IPSec)のプロトコル セットの一部として定義されたパケット形式です。Android OS は、組み込みの VPN ソリューションでこの標準のセキュリティ プロトコルを実装しています。
IPv6 対応ネットワークでは、ESP パケットは IPv6 パケットの Next Header フィールド 50 で直接伝送されます。ネットワークがこれらの種類のパケットを適切にサポートしていないと、パケットをこれ以上カプセル化せずにこのプロトコルを使用するつもりの VPN ソリューションで未接続が生じる可能性があります。ファイアウォール設定のため、ネットワークがこれらのパケットをドロップする可能性もあります。また、ネットワーク パスで ESP パケットの速度が遅くなり、TCP 接続や UDP 接続と比べてスループット パフォーマンスが著しく低下する可能性もあります。
インターネット技術特別調査委員会(IETF)は、一般ユーザー向けインターネット アクセス サービスで使用されるファイアウォールで IPsec の通過を許可することを推奨しています。たとえば、RFC 6092 第 3.2.4 項をご覧ください。デバイスは、既存のセキュリティ アソシエーションに含まれない ESP パケットを受け取ると、そのパケットをドロップするため、ESP パケットがファイアウォールを双方向で通過することを安全に許可することができます。このため、デバイスは VPN 接続を維持するためにキープアライブ パケットを送信する必要がなく、バッテリーを無駄に使わずに済みます。Google は、ネットワークでデバイスへの ESP パケットを常に許可するか、長期間(たとえば、30 分間)無効であった場合のみ ESP セッションをタイムアウトすることをおすすめしています。
ネットワーク事象者に対しては、ネットワークで ESP プロトコル パケット(Next Header 50 による IPv6 パケット)をサポートし、ハードウェアではラインレートでこれらのパケットを転送することをおすすめしています。これにより、VPN ソリューションで接続に関する問題を発生させることなく、UDP 接続や TCP 接続に匹敵するパフォーマンスを提供できます。
十分な NAT とステートフル ファイアウォールのタイムアウトを設定する
接続の信頼性を維持するため、VPN ソリューションは、アウトバウンドとインバウンドの接続(プッシュ通知、チャット メッセージ、音声またはビデオ通話の受信など)を提供する VPN サーバーへの長時間の接続を維持する必要があります。ほとんどの IPsec VPN アプリは、RFC 3948 に記載されているように、宛先ポート 4500 で ESP パケットの IPv4 UDP カプセル化を使用しています。
この接続を維持するため、デバイスはサーバーに定期的にパケットを送信する必要があります。これらのパケットは、ネットワーク事業者で課される NAT やファイアウォールのタイムアウトよりも高い頻度で送信する必要があります。キープアライブが頻繁に発生すると、クライアント側で電力を大量に消費し、バッテリー駆動時間に大きな影響を及ぼします。また、デバイスがアイドル状態の場合でも、ネットワーク上でかなりのシグナリング トラフィックが生成されます。
バッテリーに影響しないよう、事業者は NAT とステートフル ファイアウォールのタイムアウトを十分に高くすることをおすすめします。IPsec UDP カプセル化(ポート 4500)の推奨タイムアウトは 600 秒以上です。
モバイル ネットワークでは、IPv4 アドレス不足によりポートの再利用率が高くなるため、UDP NAT タイムアウトが低く抑えられていることがよくありますが、VPN が確立されれば、デバイス ネットワークは、長時間の TCP 接続(受信通知の配信に使用される接続など)をサポートする必要がありません。そのため、ネットワークがサポートする必要がある長時間の接続の数は、VPN が実行されているときは、実行されていないときと比べて同じまたはそれ以下となります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","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-03-26 UTC。"],[],[],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."]]