VPN이 켜져 있을 때 Android 방화벽 규칙이 있어야 할 자리
활성 VpnService는 하나뿐이므로 방화벽 앱과 VPN 앱은 겹쳐 쌓이지 않습니다. 작업 요청 하나를 따라가며 각 규칙을 트래픽이 실제로 지나는 지점에 두세요.
정책은 문장 하나입니다. 이 앱은 업무 서비스에 닿을 수 있고, 그 밖의 무엇에도 닿아서는 안 됩니다. 다음 질문은 제품 선택처럼 보이지만 실은 위치에 대한 질문입니다. 강제할 수 있는 후보 지점마다 휴대전화 트래픽의 다른 부분만 보기 때문입니다. 게이트웨이는 터널로 들어가는 것만 봅니다. 휴대전화 쪽 필터는 관찰이 허용된 것만 봅니다. 요청 하나를 둘 다 통과시키면 답이 분명해집니다.
제품이 아니라 문장에서 시작하세요
무엇을 고르기 전에 요구사항을 펼치세요. 먼저 패키지와 그것이 실행되는 프로필입니다. 업무 프로필의 앱은 개인 프로필의 같은 앱과 다른 사용자이기 때문입니다. 다음은 목적지입니다. 호스트, 포트, 프로토콜이며 서비스 이름이 아닙니다. 그 이름을 해석하는 DNS 경로도 포함되고, 터널을 쓸 수 없을 때 무엇이 일어나야 하는지도 포함됩니다.
글로 옮기면 예시의 정책은 네 줄입니다. 업무 앱은 업무 서비스에 닿을 수 있다. 그 밖의 어디에도 닿을 수 없다. 다른 앱은 그대로 둔다. 터널이 없으면 업무 앱은 직접 경로로 떨어지는 대신 거부된다. 각 줄에는 소유자가 있고, 모두 같은 소유자는 아닙니다.
1단계: 휴대전화 자체가 강제할 수 있는 것
루트 없이 쓰는 Android 방화벽은 VpnService이며, 뒤에 원격 터널이 없어도 트래픽을 기기 안에서 붙잡습니다. Android는 사용자 프로필마다 VPN 서비스 하나만 동시에 허용합니다. 그래서 두 번째 방화벽 앱은 첫 번째 뒤에 이어 붙는 것이 아니라 그것을 대체합니다. 대체되는 순간 첫 앱이 걸러 내던 인터페이스는 사라집니다.
VPN 클라이언트 옆에 방화벽을 설치해도 기대한 조합이 되지 않는 이유가 여기 있습니다. 방화벽이 시작되고 VPN이 끊기면 결합이 아니라 자리 교대입니다. 인터페이스 교체는 협력이 아니며, 증상은 다른 앱을 열 때마다 터널이 계속 끊기는 것입니다.
지원되는 구성은 있습니다. 이미 쓰는 VPN 클라이언트에 내장된 필터링, 기기 정책 컨트롤러나 업무 프로필을 통한 관리형 플랫폼 제어, 공급업체가 문서화한 아키텍처입니다. 그 밖의 것은 앱을 업데이트할 때마다 다시 검증해야 하는 실험입니다.
2단계: 게이트웨이가 강제할 수 있는 것
원격 끝에서 트래픽이 복호화되면, 게이트웨이는 전달되는 패킷을 승인된 주소, 서비스 또는 인증된 VPN 신원으로 제한할 수 있습니다. 그곳을 지나 나가는 모든 것에 대한 실제 강제이며, 사설 서브넷 접근을 제한하기에 알맞은 자리입니다.
받지 못하는 것은 일반 IP 패킷마다 붙는 휴대전화 앱 신원입니다. 터널 주소 하나를 공유하는 여러 앱은 설계가 별도 주소나 별도 인증 신원을 주지 않는 한 게이트웨이에게 하나의 주체입니다. 그래서 게이트웨이의 사용자 단위 규칙은 휴대전화의 앱 단위 규칙이 아닙니다. 관리 콘솔이 무엇이라 부르든 마찬가지입니다.
3단계: 결코 도착하지 않는 것을 나열하세요
VPN에서 제외된 앱이 가까운 기기와 통신하면 게이트웨이에 결코 닿지 않습니다. 받지 않는 패킷을 출구 방화벽이 거부할 수는 없습니다. 장애 중 의도치 않은 직접 경로와 로컬 접근 네트워크로 들어오는 노출도 같습니다. 정의상 로컬 경계입니다.
반대도 성립합니다. 연결을 허용하는 로컬 규칙은 게이트웨이의 사설 네트워크 ACL을 통한 접근을 주지 않습니다. 요청 하나가 두 경계에 동시에 걸릴 수 있고, 하나를 만족해도 다른 하나에 대해서는 아무 말도 하지 못합니다.
4단계: 각 규칙을 경로에 배정하세요
무엇이든 설정하기 전에 결정을 표에 두세요. 빈 칸이야말로 설계가 무너지는 자리입니다.
| 경로 | 누가 강제할 수 있는가 | 사각지대 |
|---|---|---|
| 업무 앱에서 업무 서비스로, 터널 켜짐 | 주소와 서비스에 대한 게이트웨이 ACL, 그리고 다른 경로에 대한 로컬 차단 | 게이트웨이는 어느 앱이 보냈는지 보지 못한다 |
| 업무 앱에서 다른 목적지로, 터널 켜짐 | 앱을 인식하는 로컬 필터, 또는 그 목적지가 그곳에서 주소 지정되면 게이트웨이 | 로컬 필터가 활성 VpnService여야 한다 |
| 터널 없는 업무 앱 | 로컬 거부. 앱이 직접 경로를 택할 수 없게 한다 | 터널이 사라져도 필터가 살아 있어야 한다 |
| 가까운 LAN 기기 | 로컬 정책만 | 게이트웨이는 결코 보지 못한다 |
동작하는 형태는 두 가지 일을 하는 두 경계입니다. 앱을 인식하는 로컬 경계가 직접 낙하를 포함한 휴대전화의 행동을 지배하고, 게이트웨이 경계가 원격 자원을 지배합니다. 게이트웨이 쪽은 업무 서비스를 허용하고 다른 모든 사설 서브넷을 거부할 수 있으며, 휴대전화 쪽 정책은 앱이 택할 수 있는 직접 경로를 스스로 판단합니다.
5단계: 전송을 살려 두고 검증하세요
어떤 로컬 정책을 고르든 VPN을 세우고 유지하는 전송을 허용해야 합니다. 그 전송을 막으면 휴대전화는 터널도 정책도 없이 남습니다. 일관되게 아무것도 강제하지 못하고, 앱에 네트워크가 아예 없으니 진단도 어렵습니다.
그다음 전체 인상이 아니라 원래 문장의 각 줄을 검증하세요. 업무 앱은 업무 서비스에 닿는다. 같은 앱은 다른 목적지에서 거부된다. 업무가 아닌 앱은 이전처럼 동작한다. 터널을 멈추면 업무 앱은 직접 연결로 떨어지지 않는다. DNS 경로는 따로 확인하세요. 사설 DNS나 암호화 리졸버는 주소만 검사하는 필터를 우회할 수 있습니다.
이 단계 중 하나라도 휴대전화에서 충족할 수 없다면, 요구사항은 방화벽 설정이 아니라 아키텍처 질문입니다. 정책을 관리하는 기기와 관리하는 게이트웨이 사이에 나누는 것이 보통 정직한 답이며, Android VPN 연결 문서는 플랫폼이 서비스 하나에 무엇을 허용하고 허용하지 않는지 확인하는 자리입니다.