iPhone에서 VPN 두 개를 동시에: 어느 쪽이 트래픽을 전달할까?

두 VPN 앱이 모두 Connected를 표시하면 트래픽이 이제 둘 다를 통과하며 하나가 다른 하나 안에 있다고 가정하기 쉽습니다. 보통은 그렇지 않습니다. iOS에는 특정한 공존 모델이 있고, 그것은 체인이 아닙니다. 한 구성 클래스는 활성화된 인스턴스 하나로 제한되고, 다른 하나는 그 옆에서 실행될 수 있으며, 경로 우선순위가 충돌을 결정합니다. 켜진 스위치 두 개는 두 홉이 아닙니다. 모델이 문서화되어 있으므로 아이콘에서 짐작하는 대신 경로를 예측할 수 있습니다.

속설: 연결된 VPN 두 개는 체인이다

두 홉 체인에는 정의된 외부 전송, 정의된 내부 터널, 호환되는 엔드포인트 라우팅, 그리고 둘 중 하나가 실패할 때 벌어질 일에 대한 계획이 필요합니다. 독립적인 두 구성은 단지 동시에 존재한다고 해서 그것을 만들지 않습니다. 경로 우선순위는 캡슐화와 같지 않으며, 한 구성이 경로 조회에서 이겼다는 사실은 다른 구성이 결과 패킷을 전달하는지에 대해 아무것도 말해 주지 않습니다.

중첩이 필요하다면 중첩으로 설계하세요. 연결 표시 두 개에서 그것을 추론하지 마세요. 그 구분이 디버깅을 많이 아껴 줍니다.

그 속설 뒤의 문서화된 모델

Apple의 NETunnelProviderManager는 일반적인 엔터프라이즈 VPN 구성을 설명하며, 그런 종류는 한 번에 하나만 활성화할 수 있다고 명시합니다. 같은 참조 문서는 Personal VPN이 그 옆에서 활성화되고 연결된 상태로 남을 수 있게 하며, 둘이 겹치는 곳에서는 엔터프라이즈 경로에 우선권을 줍니다.

여기서 Personal VPN은 NEVPNManager를 통해 관리되는 내장 IPsec 또는 IKEv2 구현을 가리키는 API 용어입니다. NETunnelProviderManager는 터널 공급자 모델입니다. 소비자 앱이 공급자 모델을 사용할 수 있으므로 personal이 들어간 제품명이 그것을 분류하지는 않습니다.

Apple은 허용되는 조합 하나를 문서화하며, 허가가 두 공급업체 프로필의 호환성을 알려 주지는 않으므로 어떤 쌍이 지원되는지 각 공급업체에 물어보세요. 그들의 구성 유형, 경로, 정책이 여전히 결과를 결정합니다.

속설: 개인 VPN이 브라우징 트래픽을 받는다

모든 목적지를 주장하는 업무 프로필은 공용 브라우징의 경로 조회도 이기므로, 개인 출구는 그중 아무것도 전달하지 않습니다. 문서화된 우선순위에 따르면 엔터프라이즈 경로가 충돌하는 곳에서 이기므로, 공용 브라우징이 그 앱도 연결되었다고 보고한다는 이유만으로 자동으로 개인 출구를 쓰지는 않습니다. 더 좁은 업무 구성이 라우팅 상황을 바꿀 수 있지만, 조직의 클라이언트는 여전히 DNS, 차단, 기기 요구 사항을 강제할 수 있습니다. 그 요구 사항을 로컬에서 편집하는 대신 지원되는 방식을 소유자에게 받으세요.

관리되는 앱별 구성에는 자체 범위가 있습니다. 기기 수준 규칙을 모든 관리 배포에 일반화하지 마세요.

테스트 전에 두 흐름을 적어 두세요: 업무 서비스의 사설 이름과 범위, 그리고 새 공용 브라우징 요청입니다. 둘 다 정당하며, 서로 다른 확인이 필요합니다.

분할 터널 업무 프로필과 경로 우선순위

분할 터널 업무 프로필은 나열된 사설 접두사와 내부 DNS 접미사를 주장하며, 그 경로는 그것과 일치하는 모든 조회에서 이깁니다. 어떤 엔터프라이즈 경로와도 일치하지 않는 공용 목적지는 개인 VPN이 먼저 주장하지 않는 한 물리 링크로 떨어집니다. 우선순위 규칙은 겹치는 일치만 결정하므로, 두 프로필은 아이콘이 아니라 경로 표로 읽어야 합니다.

쌍을 두 줄로 적고 각각의 예상 승자를 지목하세요: 10.x 또는 172.16.x로 해석되는 업무 호스트 이름은 엔터프라이즈 터널로 나가야 하고, 일치하는 접두사가 없는 공용 주소는 남은 기본 경로를 가져야 합니다. 두 줄이 같은 출구를 지목하면, 분할은 문서가 설명하는 대로 작동하지 않습니다.

두 흐름을 적고 각각 검증하세요

각 흐름에 대해 어느 승인된 구성이 그것을 전달해야 하는지, 어느 리졸버가 각 종류의 이름을 받아야 하는지 기록하세요. 그다음 캐시된 업무 페이지나 오래된 IP 결과가 아니라 새 요청으로 검증하세요.

구성 하나를 중지하고 두 흐름을 반복하세요. 실패 동작은 설계의 일부이며, 사용자가 알아차리는 부분입니다. 두 공급업체가 그 조합을 지원할 수 없으면, 승인된 구성 하나로 정하고 그것이 어느 흐름을 전달하는지 문서화하거나, 관리되는 단일 터널 설계로 옮기세요. NETunnelProviderManager 문서가 공존 규칙의 출처입니다.