앱이 Android 또는 iOS에서 저장된 VPN 프로파일을 켤 수 없는 이유

아주 다른 두 가지 작업이 프로그래밍 방식 VPN이라는 이름 아래 묶이지만, 그중 하나만 두 모바일 플랫폼 어디서든 일반 앱에 열려 있습니다. 첫 번째는 사용자가 이미 저장한 프로파일을 켜는 일이고, 두 번째는 자체 프로세스 안에서 터널을 구축하는 일입니다. Android는 두 번째를 VpnService을 통해 제공하고 iOS는 두 번째를 Network Extension 권한을 통해 제공하며, 첫 번째는 시스템, 기기 소유자 또는 MDM 서버에 남습니다. 실제로 어느 쪽이 필요한지 파악하면 보통 프로젝트가 작아집니다.

이름을 공유하는 두 가지 작업

저장된 프로파일을 활성화한다는 것은 기존 터널에게 올라오라고 말하는 것입니다: 호스트, 자격 증명, 프로토콜이 모두 사용자가 볼 수 있는 어딘가에 이미 구성되어 있습니다. 터널을 구축한다는 것은 코드가 인터페이스, 패킷 루프, 프로토콜을 소유한다는 뜻입니다. 제품 백로그에서는 비슷해 보이지만 구현을 거의 공유하지 않습니다.

어느 모바일 플랫폼도 첫 번째를 SDK 앱에 노출하지 않습니다. 사용자가 아무것도 하지 않았는데 나타나는 연결은 악성코드와 구분할 수 없으므로, 두 시스템 모두 트래픽을 나르는 앱 앞에 동의 게이트를 둡니다.

Android: 동의 게이트, 그리고 프로파일 API 없음

VpnService은 Android 4.0부터 존재하며 앱이 tun 인터페이스를 만들고 패킷을 읽고 쓸 수 있게 합니다. 서비스는 BIND_VPN_SERVICE로 선언해야 하고, VpnService.prepare()은 사용자에게 허용을 요청하는 시스템 대화상자를 생성합니다. 플랫폼 샘플인 ToyVpn은 의도된 형태를 가장 명확히 보여줍니다: 코드가 인터페이스와 그 안을 흐르는 모든 것을 소유한다는 점입니다.

그것이 하지 않는 일은 시스템 VPN 설정 화면에 항목을 추가하는 것입니다. 이를 위한 공개 API는 없고, 설정 앱은 프로파일을 일반 앱이 닿을 수 없는 저장소에 보관합니다. 일반 애플리케이션에서 숨겨진 클래스를 호출하면 시스템이 절대 목록에 올리지 않는 프로파일이 만들어지며, 한 빌드에서 작동하는 것처럼 보이던 코드가 다음 빌드에서 조용히 작동을 멈추는 이유입니다.

관리되는 경로는 별개입니다. 기기 소유자나 프로파일 소유자는 기기 정책 API를 통해 항상 켜진 VPN 패키지를 지정할 수 있고, 기업 도구는 사용자가 나중에 승인하는 프로파일을 배포할 수 있습니다. 이것은 기기 관리 권한이며, 앱이 설치 시 요청하는 허가가 아닙니다. 고객이 조직이라면 계획해야 할 경로가 이것이고, 고객이 스토어에서 설치하는 개인이라면 전혀 사용할 수 없습니다.

iOS: 권한이 경계다

iOS는 같은 작업을 다르게 나눕니다. VPN 클라이언트는 Network Extension 프레임워크 아래에서 패킷 터널 공급자나 앱 프록시를 구현하며, 해당 권한을 개발자 계정에 부여받아야 합니다. 더 단순한 경우를 위한 개인 VPN 구성이 NEVPNManager을 통해 존재하고, 그것도 같은 허가 모델 안에서 실행됩니다. Apple은 전체 표면을 Network Extension 참조에 문서화하며, 작업 범위를 정하기 전에 읽어 볼 가치가 있습니다.

VPN 설정 화면을 열거나, 사용자가 저장한 구성을 읽거나, 그중 하나를 시작하는 지원되는 방법은 없습니다. 클라이언트가 할 수 있는 일은 사용자가 설치할 구성 프로파일을 배포하고, 그 결과 생긴 터널을 일반 네트워크 호출로 사용하는 것입니다. 앱별 터널링은 MDM 서버가 주문형 규칙으로 할당하며, 앱이 런타임에 선택하지 않습니다.

대형 공급업체의 VPN 클라이언트는 귀하의 계정이 같은 것을 배포할 수 있다는 증거가 아닙니다. 그 권한은 개발자 계정별로 신청하고 심사하므로 일정 위험은 Apple에 있고, 귀하의 스프린트 계획에 있지 않습니다.

데스크톱은 더 멀리 가지만 소유권은 그대로다

Windows는 관대한 경우입니다. Add-VpnConnection는 승격된 PowerShell 세션에서 전화번호부 항목을 만들고, rasdial는 스크립트에서 그것을 연결하거나 끊습니다. 앱은 문서화된 명령줄로 공급업체 클라이언트를 구동할 수도 있습니다. 프로파일 생성은 여전히 관리 작업인데, 항목이 머신 전체 저장소에 있기 때문입니다.

macOS는 다른 도구로 같은 방식으로 동작합니다. scutil --nc start과 stop은 이미 존재하는 서비스에서 작동하고, 서비스를 새로 만드는 것은 시스템 관리 작업입니다. 노트북에서 프로세스를 소유한다고 해서 구성의 소유자가 되지는 않습니다.

대신 무엇을 만들 것인가

진짜 요구가 앱이 내부 API에 도달하는 것이라면 사용자가 이미 실행 중인 터널로 충분합니다. 일반 HTTPS 요청을 보내고 경로는 시스템이 고르게 하며, 터널을 제어하려는 시도를 멈추십시오. 요구가 앱의 트래픽만 터널을 쓰는 것이라면 관리 채널을 통해 앱별 VPN을 요청하거나, 없이도 도달 가능한 서비스에 대해 앱 안에서 TLS를 종료하십시오.

숨겨진 API는 택할 가치가 있는 지름길이 아닙니다. 릴리스마다 바뀌고, 앱 심사에서 실패하며, 그것이 만드는 장애는 코드를 이어받은 사람에게 평범한 네트워크 장애처럼 보입니다. 비교는 Android 대 iOS가 아니라 터널을 소유하는 것과 플랫폼에 트래픽 라우팅을 요청하는 것의 차이이며, 귀하가 만들어야 하는 것은 전자뿐입니다.