두 iPhone 앱이 모두 설정에 VPN 항목을 넣고, 모두 자신을 VPN 클라이언트라고 부르면서도 구현을 거의 공유하지 않을 수 있습니다. Apple은 그런 통합 중 하나를 개인용 VPN이라고 부르며, 바로 그 이름이 대부분의 혼란을 만듭니다. 개인용 VPN은 내장된 IPsec 또는 IKEv2 구현을 사용하는 구성을 만들고 관리하기 위한 API입니다. 패킷 터널 공급자는 다른 모델로, 앱이 자체 프로토콜의 클라이언트 측을 구현한 확장을 포함합니다. 그 뒤에 사람들이 이 레이블에서 추론하는 모든 것, 암호부터 소유권, 그리고 휴대폰을 관리해야 하는지까지는 추론일 뿐 진술이 아닙니다.

누가 터널을 구현하는가

이 분리가 무언가 고장 났을 때 누가 책임지는지를 결정합니다. 내장된 IPsec 또는 IKEv2에서는 iOS가 터널의 상태 머신을 소유하고 앱이 구성과 버튼을 소유합니다. 공급자의 경우 앱이 둘 다 소유하므로 프로토콜 버그가 운영체제 업데이트가 아니라 앱 업데이트가 됩니다.

누가 프로토콜을 구현하는지 물으면 비교는 짧습니다.

IntegrationApple interfaceProtocol implementation
Personal VPNNEVPNManager with a Personal VPN configurationThe system IPsec or IKEv2 client
Packet tunnelNETunnelProviderManager plus the provider extensionWhatever the extension implements

개인용 VPN 문서 앱이 처음으로 구성을 저장할 때의 명시적 사용자 승인 프롬프트도 언급하며, 이는 일반적인 VPN 앱이 아니라 그 모델에 속합니다.

레이블에 대해 접어야 할 두 가지 주장

첫째는 개인용 VPN이 암호를 선택한다는 주장입니다. 그렇지 않으며, 협상된 제품군은 프로토콜과 그 구성에서 나오고, 개인용 레이블은 어떤 것을 받게 되는지에 대해 아무것도 말하지 않습니다. 둘째는 개인용 VPN이 프록시나 제한된 터널을 의미한다는 주장입니다. 그것은 내장된 IPsec 또는 IKEv2를 의미하며, 경로가 그렇게 말할 때마다 완전한 터널입니다.

따라서 앱의 존재는 와이어 프로토콜에 대한 증거가 아닙니다. WireGuard나 OpenVPN를 말하는 타사 클라이언트는, iOS가 그 프로토콜들을 기본으로 구현하지 않기 때문에 구조상 공급자 앱입니다.

기업용이라는 표현이 오해를 부르는 이유

Apple 문서는 NETunnelProviderManager 구성을 일반 기업용 VPN 구성으로 분류합니다. 그 표현은 API 범주이며, 사람들을 두 가지 반대되는 오류로 밀어붙입니다: 소비자 앱이 공급자 모델을 쓸 수 없다고 가정하는 것과, 그 때문에 휴대폰이 감독 아래 있어야 한다고 가정하는 것입니다. 둘 다 따라오지 않습니다. 소비자 앱은 공급자를 일상적으로 포함하며, 감독은 누가 정책을 강제할 수 있는지에 대한 별개의 질문입니다.

관리 소유권이 그 네 번째 질문이며, 두 모델과 무관합니다. 조직이 설치한 구성은 자체적인 신원, 트래픽 범위, 수명 주기 규칙을 지니며, 그것들은 우연히 설치된 앱이 아니라 프로필과 함께 이동합니다. 관리되는 내장 프로필과 관리되지 않는 공급자 프로필이 같은 휴대폰에 동시에 있을 수 있기 때문에 통합 모델과 나란히 읽어 보십시오.

스크린샷 대신 증거를 확인하십시오

스크린샷은, 설정의 그룹화가 릴리스마다 바뀌기 때문에, 이용 가능한 최악의 증거입니다. 관리되는 프로필은 자체 페이로드 유형을 밝히는데, 내장 프로필은 IKEv2나 IPsec 같은 VPN 유형을 선언하고 공급자 프로필은 공급자의 번들 식별자를 밝히는 하위 유형을 지닙니다. 이는 눈앞의 기기에서 확인할 수 있고, 다음 재설계에도 살아남습니다.

앱 자체에 관해서는 사용 중인 클래스가, 개인용 VPN API의 구성 객체인지 아니면 공급자 관리자와 그 확장인지라는 같은 질문에 반대편에서 답합니다.

그다음 운영자가 실제로 제공하는 것에 따라 선택하십시오. 호환되는 기본 프로필이 있으면 내장 경로는 움직이는 부품이 적고 업데이트할 것도 하나 줄어듭니다. 서비스가 iOS에 없는 프로토콜을 필요로 하면 공급자 앱이 유일한 선택이며, 그 릴리스 주기가 위험의 일부가 됩니다.

기록을 연결과 함께 보관하십시오

인증과 리소스 정책을 앱이 아니라 연결 기록에 붙여, 재설치가 승인 모델을 함께 가져가지 않도록 하십시오. 그 기록은 터널이 올라오고 다른 것이 작동하지 않을 때 지원 엔지니어가 필요로 하는 것이기도 합니다.

마지막으로 물을 가치가 있는 질문은 어느 모델이 더 나은가가 아닙니다. 운영자가 어느 모델을 지원하는지, 그리고 실제로 가진 도구로 새벽 두 시에 어느 쪽을 디버그할 수 있는지입니다.

관련 글