관리되는 업무 앱의 VPN 및 프록시 상태를 읽는 방법

관리되는 휴대폰에서 업무 앱이 실패하면 누군가 VPN 토글을 확인하고 켜져 있는 것을 보고 경로가 건강하다고 선언한다. 대부분의 이런 진단은 거기서 멈추는데, 그것은 너무 이르다: 활성 VPN 전송이 있다고 해서 이 앱의 요청이 그것을 썼다는 뜻은 아니며, 실제로 적용되는 프록시는 앱별일 수도 있고 설정에 표시되지 않고 PAC 파일로 선택될 수도 있다. 디버깅 중인 특정 앱과 프로필에서 시작한 다음 플랫폼 자체의 경로 관점을 읽어라.

앱과 그 프로필에서 시작하라

업무 배지가 있는 앱은 보통 자체 네트워크 정책을 가진 별도 프로필에서 실행된다. 같은 휴대폰의 개인 브라우저는 그 증거가 되지 못하며, 다른 관리 방식의 동료 기기에서 나온 결과도 마찬가지다. 무엇이든 읽기 전에 앱이 어느 프로필에 속하는지 적어 두라.

설정에서 구성된 VPN 항목을 나열하고 각 항목의 소유자를 확인하라. Samsung 빌드에서는 메뉴 레이블이 릴리스마다 바뀌므로 항목으로 가는 경로가 아니라 항목 자체를 설명하라. 회색으로 표시되거나 관리되는 항목은 기기를 관리하는 사람의 것이다. 실험 삼아 그것을 끄면 측정하려는 대상이 달라지고 정책에 어긋날 수 있다.

플랫폼이 보고하는 상태를 읽어라

지원 도구의 기존 액티비티 안에서, API 23 이상에서는 바이트 하나 보내지 않고 네트워크 상태를 읽을 수 있다. 이 호출에는 기능을 읽기 위한 일반 ACCESS_NETWORK_STATE 매니페스트 권한이 필요하다.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

각 값은 좁은 질문에 답한다. 활성 네트워크는 그 순간 호출 프로세스의 기본 네트워크다. 기능 검사는 그 기본 네트워크가 VPN 기반인지 알려 준다. 프록시 호출은 유효한 기본 HTTP 프록시를 보고하며, 반환된 객체는 정적 프록시나 PAC 스크립트를 설명할 수 있다.

기본 대신 네트워크별 보기가 필요하면 같은 네트워크의 링크 속성을 읽고 cm.getLinkProperties(network)?.httpProxy와 비교하라. 기기 관리로 설치된 프록시는 기본 프록시 호출에 나타나고 링크 속성에는 나타나지 않는데, 이것은 정책이 준 프록시와 네트워크가 준 프록시를 빠르게 구분하는 방법이다.

출력은 공개 보고서가 아니라 지원 채널에 보관하라. 프록시 호스트 이름, PAC URL, 내부 접미사는 조직이 트래픽을 어떻게 라우팅하는지 드러내며, 장애를 설명하는 데 어느 것도 필요하지 않다.

각 필드를 좁게 해석하라

네트워크가 null이거나 기능 객체가 null이라는 것은 호출자의 네트워크 상태를 얻지 못했거나 읽는 동안 바뀌었다는 뜻이다. VPN이 없다는 뜻은 아니다. 알 수 없음으로 다루고 앱이 전면으로 나온 뒤 다시 읽어야 하며, 부정적 결과로 다루어서는 안 된다.

VPN 전송은 긍정 신호 가운데 가장 약하다. VpnService을 가진 앱이라면 트래픽을 어디로도 보내지 않는 로컬 필터링 앱이라도 하나를 만들어 낸다. 따라서 true 값은 VPN 기반 기본 네트워크가 존재한다는 것만 말하며, 조직의 출구가 사용되었다거나 검사가 일어났다는 뜻은 아니다.

기본 프록시가 null이라는 것은 이 API가 유효한 구성에 대해 기본 HTTP 프록시를 보고하지 않는다는 뜻이다. 배제되는 것은 매우 적다. 앱은 자체 SOCKS 설정을 가질 수 있고, 자체 HTTP 클라이언트를 구현할 수 있으며, 기기가 전혀 알지 못하는 게이트웨이의 프록시로 유도될 수도 있다.

단일 값으로는 답할 수 없는 경우가 PAC다. 스크립트는 한 목적지는 프록시로 보내고 다른 목적지는 직접 보낼 수 있으므로, 같은 앱의 일 초 이내 두 요청이 다른 경로를 탈 수 있다. 또한 소켓을 선택한 네트워크에 묶는 앱이나 bindProcessToNetwork을 호출하는 앱은 기본을 따를 의무가 전혀 없다.

이 스냅샷이 말해 주지 못하는 것

이것은 이력이 아니다. 실패한 요청이 어느 경로를 탔는지는 아무것도 기록하지 않으며, 실패 후의 성공적인 읽기는 실패에 대한 증거가 아니다. 목록도 아니다. 얻는 것은 호출 프로세스의 기본 네트워크이지 모든 앱의 사설 연결 목록이 아니다.

소켓 위에서 일어나는 일에 대해서도 아무 말도 하지 않는다. 관리되는 기기에서 실패하는 TLS 핸드셰이크는 신뢰 저장소 문제, 피닝 불일치, 프록시가 거부하는 이름 중 하나일 수 있으며, 어느 것도 연결성 읽기에 나타나지 않는다.

그래서 두 절반이 함께 중요하다: 스냅샷은 어디를 볼지 좁히고, 앱 자체의 진단은 실제로 무엇이 실패했는지 말한다.

관리자가 쓸 수 있는 형태로 보고하라

영향받은 앱, 프로필, 타임스탬프, 실패한 정확한 단계를 제시하라: 이름 확인, TCP 연결, TLS 핸드셰이크, HTTP 상태 중 하나다. 스냅샷 값을 읽은 그대로 덧붙이고, null은 없음이 아니라 null로 적되, 같은 프로필의 다른 앱도 같은 방식으로 실패하는지 적어라. 이것이 앱 문제와 프로필 전체의 경로 문제를 가른다.

그런 다음 멈추고 경로 소유자가 응답하게 하라. 기업 인증서, 프록시 주소, VPN 항목을 관리 삭제나 승인된 경로 우회의 허가로 받아들이지 마라. 그것은 지원 사례를 정책 사고로 바꾼다.

기본 프록시 계약은 짧고 한 번 읽을 가치가 있는데, 호출이 어느 프록시를 보고하는지 정확히 정의하며, 이 스냅샷을 과하게 읽는 모든 해석은 더 많은 것을 보고한다고 가정하는 데서 시작한다.