Android의 IKEv2 VPN 프로필은 기기 단위가 아니라 사용자 단위

Android에서 내장 VPN이라는 표현은 서로 무관한 두 가지를 가리킵니다. 플랫폼이 사용자를 대신해 실행하는 프로토콜 구현과, 제조사가 노출하기로 결정한 설정 화면의 형태입니다. 둘은 같은 대상이 아니며, 어느 쪽도 터널이 그 터널이 필요한 앱을 쓰는 사용자에게 속한다고 보장하지 않습니다. 프로비저닝은 특정 사용자와 특정 호출 패키지 조합에서 일어나고, 그 뒤의 모든 것은 그 문맥을 물려받습니다. 설정 화면을 읽기 전에 소유 사슬을 확인하세요.

플랫폼이 대신 만들어 주는 것

Android 11부터 플랫폼은 VpnManager을 통해 VPN 프로비저닝을 제공합니다. 승인된 앱이 IKEv2 프로필을 기술하면 플랫폼이 IPsec과 IKE 교환을 직접 수행하므로 앱은 패킷을 건드리지 않습니다. 자체 VPN 앱이 VpnService을 구현해 자기 프로세스에서 터널을 만드는 것과의 본질적 차이입니다.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

위 호출은 형태를 보여 주는 개요이며 그대로 붙여 넣는 블록이 아닙니다. 빌더에는 여러 인증 방식이 있고 API 수준에 따라 다르며, 프로필은 서버 인증서의 신뢰 자료도 함께 지닙니다. 소유 문제에서 중요한 것은 문법보다 좁은 범위입니다.

이 설계에서 두 가지 성질이 나옵니다. 프로필은 데이터이므로 관리자가 손으로 입력하는 대신 프로비저닝할 수 있습니다. 그리고 터널은 플랫폼의 네트워크이므로 앱에는 VPN 전송을 가진 네트워크로 보이고 다른 앱의 소켓으로 보이지 않습니다.

소유자는 먼저 사용자, 그다음 패키지

Android의 다중 사용자는 라벨이 아니라 실제 분리입니다. 직장 프로필은 자체 설치 패키지, 앱 데이터, 키 저장소, 신뢰 앵커를 가진 별도 사용자입니다. 두 곳에 설치된 같은 제품은 실행 아이콘과 제품명이 같아도 사용자 ID가 다른 두 개의 인스턴스입니다.

프로비저닝은 그 사용자 안의 호출 패키지에 대해 기록됩니다. 따라서 개인 프로필에서 실행되는 프로비저닝 앱은 개인 터널을 만들고, 직장 프로필의 업무 앱은 그것을 전혀 보지 못합니다. 반대도 마찬가지이므로, 명시적으로 다르다고 밝히는 정책이 없으면 직장 프로필 터널은 개인 앱에 보이지 않습니다.

기기 정책 컨트롤러는 관리 프로필을 대신해 프로비저닝할 수 있고, 이것이 사무실에서 아무도 만든 기억이 없는 항목의 설명이 됩니다. 휴대폰을 감사하고 있다면 회색으로 표시된 프로필의 유력한 소유자가 그이며, 실험 삼아 지우는 것은 당신의 일이 아닙니다.

패킷이 움직이기 전의 세 관문

첫 관문은 권한입니다. 관리가 VPN 자체를 허용해야 하고, 일부 배포는 존재 여부뿐 아니라 유형도 제한합니다. 둘째는 신원입니다. 클라이언트 인증서나 자격 증명이 프로필을 소유한 사용자에게 있어야 합니다. 개인 키 저장소로 가져온 인증서는 직장 프로필에 보이지 않기 때문입니다.

셋째는 동의와 정책입니다. 사용자는 보통 처음 사용할 때 연결을 승인하고, 관리자는 추가로 항상 켜짐으로 고정할 수 있으며 필요하면 잠금을 붙여 터널 밖으로 트래픽이 나가지 못하게 합니다. 이 설정이 터널이 끊겼을 때의 동작을 정하며, 사용자가 알아차리는 부분이 바로 여기입니다.

범위는 셋이 만나는 지점입니다. 프로필이 게이트웨이와 신원을 정하고, 정책 계층이 어떤 앱에 터널 사용을 허용할지와 트래픽을 강제로 통과시킬지를 정합니다. 그래서 같은 게이트웨이 주소를 가진 두 휴대폰도 매우 다르게 동작할 수 있습니다.

개인 연결이 업무 앱을 덮지 못하는 이유

업무 앱의 트래픽은 직장 사용자에서 생성되고, 적용되는 네트워크 정책은 그 사용자의 것입니다. 개인 프로필에서 세운 터널은 표시가 아무리 정상으로 보여도 그 트래픽을 나르지 않습니다. 이 한 가지 사실이 VPN은 연결됐다고 사용자가 단언하는데 특정 앱만 사내 서비스에 닿지 못한다는 보고의 대부분을 설명합니다.

이름 해석도 같은 경계를 따릅니다. 사설 DNS 접미사와 신뢰 앵커는 사용자별이므로, 개인 프로필에서 해석되는 사내 호스트 이름이 동등해 보이는 터널이 있어도 직장 프로필에서는 실패할 수 있습니다. 리졸버 정책과 CA 저장소가 다른 대상이기 때문입니다.

실험실 휴대폰이 아니라 실제 등록에서 검증하세요

기기에서 먼저 항목의 소유자를 식별합니다. 어느 사용자, 어느 패키지인지, 그리고 프로필이 플랫폼 프로비저너에서 왔는지 자체 VPN 서비스를 구현한 앱에서 왔는지 확인합니다. 그다음 프로필이 기대하는 신원이 실제로 그 사용자의 키 저장소에 있는지 확인합니다.

연결만이 아니라 수명 주기를 시험합니다. 로그인하고 자격 증명 저장소를 잠금 해제하고, 직장 프로필을 저녁 동안 멈추게 두었다가 다시 가져와 수동 조작 없이 터널이 돌아오는지 확인합니다. 근무 시간이 지나 꺼지는 직장 프로필은 터널을 함께 가져가며, 예상된 사용 불가 상태가 문서화되어 있다면 이는 결함이 아니라 예상된 동작입니다.

마지막으로 업무 앱 자체를 알려진 사내 엔드포인트에 대해 시험하고 개인 프로필의 결과와 비교합니다. 둘이 다른 것은 허용되지만, 달라서는 안 되는 것은 소유 모델입니다. 터널이 잘못된 사용자에게 속한다면 인증서를 다시 발급해도 고쳐지지 않습니다.

메뉴를 드러내려고 숨은 설정 액티비티를 실행해 문제를 억지로 밀어붙이지 말고, 연결이 보이게 하려고 프로필 사이에 개인 키를 복사하지 마세요. VpnManager 참조는 호출자가 무엇을 프로비저닝할 수 있는지 문서화합니다. 승인된 경로가 당신의 사례를 포함하지 않는다면 그것은 설정 문제가 아니라 관리자의 결정입니다.