업무 앱이 VPN을 요구한다면? 먼저 이 세 계층을 확인하세요

메시지는 앱에 VPN이 필요하다고 하지만, 보통 앱은 그것을 막은 대상의 이름을 대신 말하기보다 증상을 보고합니다. 세 가지 서로 다른 주체가 그 문장을 만들 수 있습니다. 앱이 통신하는 사설 서비스, 앱 자체의 정책 코드, 그리고 업무 프로필을 제어하는 기기 관리 계층입니다. 어느 쪽이 묻고 있는지에 따라 해야 할 일이 달라지며, 셋 중 터널 연결로 해결되는 것은 하나뿐입니다. 주체를 먼저 찾으면 애초에 문제가 아니었던 클라이언트를 다시 설치하는 일을 피할 수 있습니다.

앱 자체가 확인할 수 있는 것

숨겨진 플랫폼 규칙을 가정하기 전에, 일반 앱도 VPN 전송이 활성인지 볼 수 있다는 점을 기억하세요. ConnectivityManager는 TRANSPORT_VPN을 가진 네트워크를 보고하고, NET_CAPABILITY_NOT_VPN이 없으면 현재 경로가 터널을 통과한다고 호출자에게 알립니다. 터널 밖에서의 동작을 거부하려는 개발자는 공개 API만으로, 기업 도구 없이도 그렇게 할 수 있습니다.

앱이 그런 방식으로 볼 수 없는 것은 그 VPN이 누구의 것인지입니다. 전송 플래그는 터널이 존재한다는 것만 말하며, 조직이 기대하는 곳에서 끝난다는 것은 말하지 않습니다.

서비스 경로: 사설 이름과 주소

메시지의 가장 흔한 정직한 형태는 정책 검사가 전혀 아닙니다. 앱은 기업 DNS 뷰 안에만 존재하는 위키나 API 엔드포인트 같은 내부 호스트 이름을 해석하고, 어떤 정책 코드도 실행되기 전에 조회가 실패합니다. 터널은 켜져 있고 일반 인터넷 트래픽을 통과시키는데, 분할 DNS가 그 이름을 한 번도 들어본 적 없는 해석기로 보내는 경우입니다.

여기서의 증상은 좁습니다. 호스트 하나만 실패하고 앱의 나머지 네트워크 호출은 동작하며, 실패는 시작 시점이 아니라 이름 조회 중에 나타납니다. 내부 인증서는 두 번째 실패 모드를 더합니다. 조직 CA에 고정된 앱은 패킷이 흐르더라도 공개 인증서를 거부하기 때문입니다.

무작위 상용 VPN을 연결해도 그것들 중 어느 것도 해결되지 않습니다. 출구 주소만 바뀌고 내부 이름은 그대로 해석 불가능합니다.

앱 정책 계층

앱은 자체 게이트를 가질 수도 있습니다. 관리형 구성을 통해 조직은 앱이 선언한 키와 값 쌍을 밀어 넣을 수 있고, 앱은 RestrictionManager를 통해 이를 읽습니다. 필수 프로필 이름이나 허용 네트워크 목록 같은 키는 전적으로 개발자의 설계이며, 애플리케이션 코드에서 그 코드가 선택한 오류 텍스트와 함께 적용됩니다.

이 계층은 문구가 보통 정체를 드러내는 곳입니다. 메시지가 시작 직후, 어떤 네트워크 호출보다 먼저 나타나고 정책, 프로필, 관리자를 언급한다면, 아마 떨어진 패킷이 아니라 애플리케이션 로직을 보고 있는 것입니다.

같은 제한을 개인 기기에서 읽는 것은 막다른 길입니다. 관리되지 않는 기기에는 읽을 제한이 없으므로, 앱은 구축 당시의 기본값으로 돌아갑니다.

플랫폼 계층: 상시 연결과 잠금

기기 관리는 앱이 무시할 수 없는 강제를 더합니다. 기기 정책 컨트롤러는 업무 프로필에 대해 setAlwaysOnVpnPackage를 호출할 수 있고, 원하면 잠금을 켤 수 있으며, 잠금이 켜지면 플랫폼은 그 패키지를 거치지 않는 트래픽을 거부합니다. 차단은 앱 오류가 아니라 시스템 상태로 보이며, 프로필의 다른 앱도 네트워크에 도달하지 못합니다.

범위가 중요합니다. 상시 연결 VPN은 사용자별로 구성되므로 업무 프로필 패키지가 개인 프로필을 덮지 않고, 개인 VPN은 업무 프로필 패키지를 충족하지 못합니다. 두 프로필, 두 개의 독립적인 네트워크 정책, 한 기기입니다.

정책이 특정 패키지 하나를 지목하기 때문에, 이것은 무관한 VPN이 도움이 될 수 없는 유일한 계층입니다.

셋을 구분하기

징후를 순서대로 훑고 처음 맞는 것에서 멈추세요. 호스트 이름 하나만 실패하고 나머지는 해석되면 서비스 경로입니다. 시작 시 정책 문구와 함께 즉시 거부되면 애플리케이션 로직입니다. 승인된 클라이언트가 끊길 때마다 프로필 전체가 연결을 잃으면 잠금입니다. 그리고 어떤 터널이든 받아들이는 앱은 조직의 정체성이 아니라 전송 플래그를 검사하는 것입니다.

유용한 증거는 정확한 문구와 그 시점, 같은 프로필의 다른 앱에 아직 연결이 있는지, 승인된 터널 안에서 사설 이름이 해석되는지, 그리고 연 앱에 기기가 업무 배지를 표시하는지입니다.

지원 요청에 쓸 내용

계층을 지목한 요청은 첫 시도에 올바르게 라우팅됩니다. 예를 들어 업무 프로필 앱은 열리지만 승인된 VPN 연결 후 리소스 목록이 실패하고, 허용된 진단에서 사설 이름 해석이 실패하며, 프로필의 다른 앱은 계속 동작한다고 적으면 됩니다. 이것은 경로나 해석기 문제로 읽히며 계정 초기화 루프를 건너뜁니다.

승인된 VPN이 아예 없다면 지원되는 경로는 관리자를 통한 등록 또는 재프로비저닝입니다. 관리 프로필을 제거하거나 무관한 클라이언트를 설치하거나 네트워크 상태를 위조하는 것은 보안 배치를 복원하는 것이 아니라 변경하는 일입니다.

클라이언트가 아니라 계층에서 시작하세요. 위의 세 징후로 보통 한 세션에서 정리됩니다.