관리되는 iPhone 앱의 앱별 VPN: 무엇이 라우팅되고 무엇이 아닌가
앱별 터널은 관리되는 앱을 따르며 전화기 전체를 따르지 않습니다. 페이로드 연결, 관리되는 사본, 요청 시 그규, 앱을 떠나는 흐름을 확인하세요.
iPhone의 앱별 VPN은 전화기 전체의 스위치가 아닙니다. 하나의 관리되는 앱과 하나의 VPN 페이로드 사이의 연결로, 앱을 배포할 때 만들어지며 나머지 모든 트래픽은 이전 경로를 유지합니다. 그래서 같은 전화기가 일관성 없이 동작합니다: 업무 앱은 내부 페이지를 여는데 Safari는 같은 호스트에 도달하지 못하거나, 터널이 전혀 올라오지 않고 앱이 잘못된 자격 증명처럼 보이는 시간 초과를 보고합니다. 점검은 가장 넓은 원인에서 아래로 진행되므로 처음 실패하는 지점에서 멈추세요.
먼저 페이로드와 앱 레코드를 확인하세요
연결은 두 객체에 존재하며 하나가 아닙니다. VPN 페이로드는 터널의 유형, 서버, 인증, DNS, 사용자 지정 클라이언트를 쓸 때 공급자 번들 ID를 정의합니다. 앱 레코드가 그 페이로드를 가리키며, 대부분의 관리 콘솔은 이를 앱 구성에서 Per-App VPN에 가까운 이름의 앱별 옵션으로 제공합니다. 어느 앱도 가리키지 않는 페이로드는 앱별로 아무것도 라우팅하지 않으며, 누군가 수동으로 시작해야 하는 일반 터널처럼 동작합니다.
전화기를 만지기 전에 두 객체를 읽으세요. 앱 구성이 테스트 중인 페이로드를 가리키고 이전 사본이 아님을 확인하세요. 마이그레이션 후에는 이름이 거의 같은 중복 페이로드가 흔하고 앱은 폐기된 쪽을 기꺼이 가리킵니다. 그다음 구성이 기기에 도달했는지 확인하세요. 설정, 일반, VPN 및 기기 관리에 설치된 프로필로 표시되어야 합니다. 그곳의 VPN 목록은 시험이 아닙니다. 앱별 서비스에는 보통 수동 스위치가 없으므로 올바르게 배포된 구성이 시작 가능한 VPN에 나타나지 않을 수 있습니다. 부재는 앱 레코드와 앱의 첫 요청에서 터널이 올라오는지에 나타납니다.
한 조건이 많은 티켓을 설명합니다. 이 모델은 앱이 관리 경로로 도착할 것을 요구합니다. 사이드로드되었거나 개인적으로 구매한 사본은 번들 ID가 일치해도 연결을 얻지 못합니다. Apple의 VPN 배포 안내서는 그 뒤의 페이로드 모델을 설명합니다 (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
설치된 앱이 관리되는 사본인지 확인하세요
연결은 설치된 관리되는 앱을 따릅니다. 누군가 개인 Apple ID로 App Store에서 다시 설치했거나, 다시 서명한 엔터프라이즈 빌드로 교체했거나, 기기가 다시 등록되어 앱이 다른 채널로 돌아왔다면 앱 자체는 완전히 정상으로 보여도 터널은 내려가 있을 수 있습니다.
단일 관찰이 아니라 비교로 시험하세요. 관리 인벤토리에서 앱은 해당 기기에 대해 관리됨으로, 레코드에 VPN 매핑과 함께 표시되어야 합니다. 전화기에서는 앱이 실행되고 첫 요청이 나갈 때 터널이 올라와야 하며, 누군가 설정에서 별도의 수동 구성을 시작할 때만이 아닙니다. 앱 실행이 아무것도 바꾸지 않고 그 수동 구성이 바꾼다면, 앱은 앱별 터널에 전혀 묶여 있지 않습니다.
업데이트가 중요합니다. 관리 경로로 푸시된 업데이트는 매핑을 유지하지만 사용자가 시작한 재설치는 이를 잃을 수 있습니다. 불만이 업데이트에서 시작된다면 네트워크보다 먼저 앱 레코드를 확인하세요.
터널이 무엇을 가져갈 수 있는지 확인하세요
앱별 터널은 소스 앱으로 선택되므로 전화기의 기본 경로는 여전히 Wi-Fi나 셀룰러에 속합니다. 이를 바꾸는 키가 OverridePrimary입니다. 프로필이 이를 설정하면 터널은 전체 터널처럼 동작하고 모든 앱이 이를 상속하므로, VPN을 통과하는 모든 것이 앱 결함이 아니라 프로필 문제가 됩니다.
요청 시 규칙이 지속성을 결정합니다. OnDemandEnabled와 그 규칙 집합이 앱이 트래픽을 보낼 때 터널을 되살리고, Wi-Fi에서 셀룰러로의 전환을 견디며, 앱이 백그라운드로 가면 내려가게 합니다. 연결된 뒤 조용히 죽는 배포는 보통 앱이 유휴일 때 절대 발동하지 않는 프로브에만 일치하는 규칙을 가집니다.
그런 다음 경로 쪽을 정직하게 읽으세요. 공급자나 공급업체 프로필이 포함 목록을 제공하면 10.20.0.0/16만 나르는 터널은 10.30.0.0/16의 서비스를 나르지 않습니다. 그것은 목록이 제 일을 하는 것이며 앱별 결함이 아닙니다. 내장 iOS 페이로드에는 포함 목록이 없습니다. 그것이 없으면 분할은 공급자 기본값과 IncludeAllNetworks를 따르며 숨은 목록을 따르지 않습니다.
앱을 시험하고, 그다음 앱에서 나가는 것을 시험하세요
주소만이 아니라 이름으로 시험하세요. 관리되는 앱 안에서 내부 호스트가 확인된다는 것은 DNS도 터널을 통과했다는 증거입니다. 페이로드가 어느 리졸버가 응답하고 어떤 검색 도메인이 적용되는지를 결정하기 때문입니다. 이름 조회가 실패해도 라우팅은 완벽할 수 있으며, 두 증상은 서로 다른 설정을 가리킵니다.
그다음 경계를 양쪽에서 시험하세요. 개인 앱이나 Safari는 일반 공개 페이지에 도달해 통신사나 집 주소를 보고해야 하고, 관리되는 앱은 내부 서비스에 도달합니다. 둘 다 같은 공개 주소를 보고한다면 앱 레코드가 무엇을 주장하든 터널은 더 이상 앱별이 아닙니다.
앱을 떠나는 흐름이 혼란스러운 티켓을 만듭니다. Safari에서 열리는 링크, 공유 시트로 넘겨진 문서, 브라우저로 전환되는 SSO 로그인은 앱의 프로세스와 함께 터널을 떠납니다. 앱 안에 표시되는 로그인은 보통 앱에 귀속되므로 같은 URL이 Safari에서 실패하는 곳에서 내장 로그인이 성공할 수 있습니다. 그것을 가정하지 말고 검증하세요. ID 공급자가 터널로만 도달 가능하다면 로그인을 앱 안에 두거나 공급자 도메인을 페이로드의 Safari 도메인에 추가해 일치하는 Safari 트래픽이 잡히게 하세요.
증상을 계층에 맞추세요
실패의 형태가 어떤 점검을 반복해야 하는지 알려줍니다.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
가운데 행 뒤에는 두 가지 세부가 있는데, 앱별 터널은 건강해도 어떤 공급자 목록에도 없는 서브넷을 놓칠 수 있고, 관리되는 전화기는 하나 이상의 VPN 구성을 가질 수 있으므로 읽고 있는 것이 그것이라고 가정하지 말고 앱이 어느 것에 묶여 있는지 확인하세요.
이 순서로 고치세요 — 앱 레코드를 활성 페이로드를 가리키게 고치고, 관리 경로로 앱을 다시 설치하고, 앱의 첫 요청에서 터널이 올라오는지 확인한 다음 이름과 경계 시험을 반복하세요. 첫 요청이 터널을 전혀 시작할 수 없다면 멈추고 공급자 쪽을 확인하세요 — 사용자 지정 클라이언트에는 설치된 앱과 일치하는 식별자를 가진 Network Extension이 있어야 합니다.
스크린샷 대신 세 가지 사실을 돌려주세요. 앱 레코드가 어느 페이로드를 가리키는지, 설정이 설치된 프로필로 표시하는지, 실패한 요청이 이름인지 주소인지 브라우저 전환인지. 이 세 답이 배포 실수와 라우팅 실수를 구분하며 다음 사람은 진단을 반복하지 않고 조치할 수 있습니다.