한 대의 휴대폰에 VPN 두 개: 앱 개수가 아니라 구성을 고르세요

VPN 두 개를 쓰는 것은 하나의 요청이 아니다. 두 조직에 차례로 접근하는 것, 업무용과 개인용 앱을 분리해 두는 것, 또는 한 터널을 다른 터널 안에서 돌리는 것을 뜻할 수 있다. Android는 이 세 경우를 전혀 다른 방식으로 처리하며, 휴대폰에 설치된 VPN 앱 수는 아키텍처가 아니다. 이들을 구분하는 질문은 간단하다: 같은 앱을 위해 두 경로가 같은 순간에 모두 있어야 하는가?

세 가지 구성, 하나의 질문

두 네트워크를 다른 시간에 쓰기 때문에 답이 아니오라면, 의도적인 전환이 필요하다. 앱 자체가 분리되어 있어서 답이 아니오라면, 프로필 분리가 필요하며, 각 앱은 자기 터널을 소유한 컨텍스트에 놓인다. 답이 예이고 한 경로가 다른 경로를 물리적으로 실어야 한다면 체인이 필요하며, 순서가 설계의 일부가 되는 경우는 셋 중 이것뿐이다.

나머지는 모두 그 선택에서 나온다. 전환에는 전이 구간이 있고, 분리에는 정책 경계가 있으며, 체인에는 오버헤드와 의존 비용이 있다. 잘못된 것을 고르면 깔끔하게 실패하지 않고, 연결된 것처럼 보이는 휴대폰과 아무 데도 닿지 못하는 앱이 생길 뿐이다.

한 사용자 컨텍스트 안에서의 전환

Android는 사용자당 하나의 활성 VPN 서비스만 허용한다. 같은 컨텍스트에서 두 번째 VPN 앱을 실행하면 첫 번째가 대체되거나 곧바로 거부되며, 두 경로 집합이 합성되는 일은 없고, 암호화가 겹쳐 쌓이는 일도 결코 없다. 한 사용자 안에서 두 터널은 합이 아니라 순서다.

접근이 정말로 순차적일 때 이것은 실용적이다. 어느 프로필이 활성인지 분명하도록 이름을 붙이고, 전환하기 전에 민감한 일을 끝내고, 두 경로 모두 완전히 성립하지 않은 짧은 구간을 예상하라. 브라우저 탭을 닫는 것은 세션을 끝내는 것과 같지 않으며, 탭은 계정 상태를 유지한 채 다음 요청을 새로 선택한 네트워크로 보낼 수 있고, 그것이 바로 사람들이 나중에 알아차리는 유출이다.

전환이 줄 수 없는 것은 동시에 두 네트워크에 있는 기계다. 앱이 양쪽에서 사설 주소를 필요로 한다면 어떤 클라이언트 규율로도 그것을 만들어낼 수 없다.

프로필로 분리하기

관리되는 업무 프로필은 자체 앱과 키스토어, 네트워크 정책을 가진 별도의 사용자다. 업무용 메일 클라이언트가 조직의 터널을 쓰는 동안 개인용 브라우저는 개인용 터널을 쓸 수 있고, 둘은 같은 컨텍스트에서 자리를 두고 경쟁하지 않으므로 동시에 연결될 수 있다.

분리는 곧 한계이기도 하다. 개인용 브라우저는 업무 터널을 빌리지 않고, 업무용 DNS 접미사를 보지 못하며, 두 서비스가 연결된 것으로 보인다는 이유만으로 업무 네트워크에 닿지도 않는다. 누군가 링크가 열리지 않는다고 보고하면, 두 VPN 중 어느 것도 건드리기 전에 앱의 어느 사본이 그것을 처리했는지, 어느 프로필이 그 계정을 소유하는지 확인하라.

경계를 고정된 것으로 다루라. 고용주의 라우팅 결정을 피하려고 두 번째 프로필을 만들거나 업무 프로필을 제거하면 그 구성을 작동하게 만든 분리 자체를 파괴하며, 관리되는 기기에서는 보통 구성 변경이 아니라 정책 위반이다.

순서가 설계인 체인

체인은 사람들이 둘 다 동시에라고 말할 때 흔히 뜻하는 구성으로, 휴대폰의 터널이 공유기의 터널 안을 지난다. 작동할 수 있고 제약은 구체적이다. 바깥 제공자는 휴대폰의 VPN 엔드포인트로 가는 작동 경로를 허용해야 하며, UDP 기반 프로토콜에서는 바깥 서비스가 그 트래픽을 차단하거나 제한해서는 안 된다는 뜻이다.

누가 무엇을 보는지 이해하라. 바깥 제공자는 안쪽 엔드포인트를 향한 연결을 본다. 안쪽 제공자는 바깥 출구에서 휴대폰의 트래픽을 받아 앞으로 전달한다. 최종 목적지는 보통 안쪽 서비스의 출구를 보며, 체인을 따라 어떤 제공자도 눈이 먼 상태가 아니며, 앱 계정은 경로와 무관하게 사용자를 식별한다.

실제 비용을 예상하라. 계층이 늘 때마다 캡슐화가 더해지므로 실효 MTU가 낮아지고, 터널 하나에는 문제없던 값이 안쪽 터널의 MTU를 보수적으로 설정할 때까지 단편화되거나 멈춘다. 두 계층은 두 개의 장애 의존과 두 벌의 keepalive 메시지도 뜻하며, 손실이 있는 바깥 링크 위의 TCP 기반 안쪽 터널은 죽은 서버처럼 보이는 방식으로 멈출 수 있다.

가장 중요한 점은 체인이 두 사설 네트워크를 합치지 않는다는 것이다. 경로, 겹치는 프리픽스, DNS 해석, 접근 규칙은 별개의 결정으로 남고, 한 VPN을 실은 공유기와 다른 VPN을 실은 휴대폰이 있다고 해서 휴대폰이 두 주소 공간을 모두 얻지는 않는다.

디버깅하기 전에 설계를 확인하라

구성을 한 문장으로 적고 실패한 앱에 대해 시험하라. 순차 접근이라면 한 번에 터널 하나가 보여야 하고, 프로필 분리라면 각 앱이 자기 사용자에 보여야 하며, 체인이라면 안쪽 터널이 물리 인터페이스가 아니라 바깥 인터페이스 위로 성립하는 것이 보여야 한다.

adb shell ip -br addr
adb shell ip route get 10.20.0.8
adb shell dumpsys connectivity | grep -i vpn

앱이 터널을 기대하는데 경로 조회가 물리 인터페이스를 지목한다면 설계와 앱 컨텍스트가 어긋난 것이며, 어떤 추가 VPN 앱도 둘을 화해시키지 못한다. 라우팅이 아니라 정책 세부가 필요하다면 관리 프로필 문서가 분리 규칙을 다룬다.