2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
VPN 사용자 환경 개선
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 페이지에서는 소비자 및 엔터프라이즈 가상 사설망(VPN) 앱이 네트워크에 우수한 최종 사용자 환경을 제공하도록 보장하기 위한 네트워크 운영자용 가이드라인을 제공합니다. Android는 개발자가 VPN 솔루션을 만들 수 있도록 VpnManager 클래스를 제공합니다. VPN 클래스는 소비자와 기업이 통신을 암호화하거나 다른 네트워크로 통신을 라우팅하는 데 사용됩니다.
네트워크 운영자는 다음 가이드라인을 따르는 것이 좋습니다.
- 네트워크에서 IPv6 캡슐화 보안 페이로드(ESP) 프로토콜(다음 헤더 50) 패킷 지원 트래픽이 사용자 데이터그램 프로토콜(UDP) 또는 전송 제어 프로토콜(TCP) 연결과 비슷한 성능을 제공하도록 보장해 줍니다. ESP 세션은 기기에 인바운드 가능하거나 매우 높은 시간 제한으로 설정하거나 선 속도로 전달해야 합니다.
- 네트워크 주소 변환(NAT) 및 스테이트풀(Stateful) 방화벽 시간 제한 설정 VPN 솔루션이 과도한 전력 비용 발생 없이 안정적인 연결을 유지할 수 있도록 UDP 연결의 경우 포트 4500에서 최솟값이 600초입니다.
보안 페이로드 캡슐화(VPN)는 VPN 솔루션의 패킷을 암호화하고 인증하기 위한 IPSec(Internet Protocol Security) 프로토콜 집합의 일부로 정의된 패킷 형식입니다. Android OS는 기본 제공되는 VPN 솔루션에 이 표준 보안 프로토콜을 구현합니다.
IPv6 지원 네트워크에서 ESP 패킷은 다음 헤더 필드 50을 사용하여 IPv6 패킷으로 직접 전달됩니다. 네트워크가 이러한 유형의 패킷을 제대로 지원하지 않으면 패킷을 더 캡슐화하지 않고 이 프로토콜을 사용하는 것을 목표로 하는 VPN 솔루션의 연결이 부족해질 수 있습니다. 방화벽 구성으로 인해 네트워크에서 이러한 패킷을 삭제할 수 있습니다. 또는 ESP 패킷이 네트워크에서 느린 경로를 사용해 TCP 또는 UDP 연결에 비해 처리량 성능이 크게 저하될 수 있습니다.
인터넷 엔지니어링 태스크포스(IETF)에서는 소비자용 인터넷 액세스 서비스에 사용되는 방화벽을 통해 IPsec을 허용하는 것이 좋습니다. 예를 들어 RFC 6092 섹션 3.2.4를 참고하세요.
기기가 기존 보안 연결에 속하지 않는 ESP 패킷을 수신하면 패킷을 삭제하므로 ESP 패킷은 양방향으로 방화벽을 통해 안전하게 허용됩니다. 따라서 기기는 VPN 연결을 유지하기 위해 연결 유지 패킷을 전송하지 않아도 되므로 배터리 수명이 절약됩니다. 네트워크에서 항상 ESP 패킷을 기기에 허용하거나 장시간 비활성 상태(예: 30분) 후에만 ESP 세션 시간을 제한하는 것이 좋습니다.
네트워크 운영자는 네트워크에서 ESP 프로토콜 패킷(다음 헤더가 50인 IPv6 패킷)을 지원하고 이러한 패킷을 하드웨어에서 선 속도로 전달하는 것이 좋습니다. 그러면 VPN 솔루션이 연결 문제를 겪지 않고 UDP 또는 TCP 연결과 비슷한 성능을 제공할 수 있습니다.
충분한 NAT 및 스테이트풀(Stateful) 방화벽 시간 제한 설정
연결 안정성을 유지하기 위해 VPN 솔루션은 아웃바운드 및 인바운드 연결을 제공하는 VPN 서버와의 장기 연결을 유지해야 합니다 (예: 들어오는 푸시 알림, 채팅 메시지, 오디오 통화 또는 영상 통화 수신). 대부분의 IPsec VPN 앱은 RFC 3948에 설명된 대로 대상 포트 4500과 함께 IPv4 UDP 패킷에 캡슐화된 ESP를 사용합니다.
이 연결을 유지하려면 기기는 주기적으로 패킷을 서버로 전송해야 합니다. 이러한 패킷은 네트워크 운영자가 적용하는 NAT 및 방화벽 시간 제한보다 더 높은 빈도로 전송해야 합니다. 빈번한 연결 유지는 클라이언트 측에 과도한 전력 소모를 야기하고 배터리 수명에 큰 영향을 미칩니다. 또한 기기가 유휴 상태일 때도 네트워크에서 상당한 신호 트래픽이 발생합니다.
운영자는 배터리에 미치는 영향을 방지하기 위해 NAT 및 스테이트풀(Stateful) 방화벽 시간 제한을 충분히 늘리는 것이 좋습니다. IPsec UDP 캡슐화(포트 4500)에 권장되는 제한 시간은 600초 이상입니다.
모바일 네트워크에서 IPv4 주소 부족으로 인해 포트 재사용 요인이 많이 발생하므로 UDP NAT 시간 제한이 낮게 유지되는 경우가 많습니다. 그러나 VPN이 설정되면 기기 네트워크는 인바운드 알림을 전달하는 데 사용되는 TCP 연결 등 장기 TCP 연결을 지원할 필요가 없습니다. 따라서 VPN이 실행 중일 경우 네트워크에서 지원해야 하는 장기 연결의 수가 VPN이 실행되고 있지 않을 때와 비교하면 작거나 같습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(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-07-27(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."]]
