Android VPN 서버: root만으로는 휴대폰에 도달할 수 없습니다
휴대폰이 VPN 클라이언트를 서비스할 수 있는지는 세 가지 별개 문제로 결정됩니다. 인바운드 경로, 권한 모델, 포워딩입니다. root는 가운데 하나만 건드립니다.
root는 프로세스가 시도할 수 있는 네트워크 작업의 범위를 바꿉니다. 휴대폰에 공개적으로 도달 가능한 주소를 주지도, 통신사 쪽 인바운드 매핑을 확보하지도, 재부팅 후에도 데몬을 살려 두지도 않습니다. Android 휴대폰이 VPN 서버가 될 수 있는지 판단할 때는 세 질문을 분리하세요. 의도한 클라이언트가 리스너에 애초에 도달할 수 있는가, 서버 구현에 어떤 권한 모델이 필요한가, 그리고 터널이 올라온 뒤 무엇을 포워딩해야 하는가입니다.
누가, 어디서 휴대폰에 도달해야 하는가
같은 허용된 LAN의 클라이언트와 모바일 데이터의 클라이언트는 서로 다른 두 네트워크를 시험하는 것입니다. 먼저 의도한 쪽을 정하세요. 답은 서로 전용되지 않습니다. Wi-Fi에서는 요청하지 않은 인바운드 트래픽에 보통 상위 라우터의 매핑과 그 너머의 쓸 만한 공용 경로가 필요합니다. 셀룰러에서는 통신사 등급 NAT 때문에 인바운드 IPv4를 자주 쓸 수 없습니다. 휴대폰이 무엇을 허용하든 마찬가지입니다.
root가 손댈 수 없는 것이 바로 이 마지막 지점입니다. 휴대폰의 로컬 방화벽과 통신사의 NAT는 서로 다른 시스템이고, 앞의 것을 바꿔도 뒤의 것에는 영향이 없습니다. 사설 인터페이스 주소, 모바일 데이터 아이콘, 대기 중인 소켓은 도달 가능성의 증거가 아닙니다. 통신사 경로가 전 세계 라우팅 가능한 IPv6를 제공하더라도, 그것을 위한 의도적인 리스너와 방화벽 정책은 따로 필요합니다. 주소가 있는 것과 연결을 받아들이는 것은 같지 않습니다.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
서비스와 포워딩은 서로 다른 두 가지 성공입니다
완료된 VPN 핸드셰이크는 터널이 존재함을 증명합니다. 클라이언트가 휴대폰 뒤의 LAN에 도달할 수 있음을, 휴대폰이 인터넷 출구가 될 수 있음을 증명하지는 않습니다. 그것들은 내부 주소 계획, 경로, 반환 동작, 그리고 실제로 원하는 작업에 맞춘 좁은 포워딩 정책 위에 세워지는 별개의 구성입니다.
실패 방식은 예측 가능합니다. 핸드셰이크는 성공하고, 클라이언트는 연결됨으로 표시되며, 아무것도 로드되지 않습니다. 클라이언트를 디버그하기 전에 두 역할 중 무엇을 만드는지 정하세요. 휴대폰 네트워크에 있는 장치로의 원격 접근과 전체 터널 인터넷 출구는 서로 다른 포워딩 규칙을 요구하며, 하나를 원할 때 둘 다 허용하면 원한 능력을 더하지 않으면서 노출만 넓힙니다.
권한 모델은 선택입니다, root 아니면 전무가 아닙니다
커널 TUN 장치를 쓰는 전통적인 OpenVPN 데몬에는 해당 기능, 장치 노드 접근, 그리고 Android 보안 정책의 협력이 필요합니다. root는 SELinux로부터의 포괄적 면제가 아닙니다. 권한 있는 프로세스도 플랫폼 정책에 묶입니다. Linux 서버에서 잘 도는 바이너리가 휴대폰에서 권한에 관한 뚜렷한 오류 없이 실패할 수 있는 이유입니다.
사용자 공간 게이트웨이 구현은 권한 모델이 완전히 다를 수 있으므로, Android의 모든 VPN 서버에 root가 필요하다는 흔한 주장은 너무 넓습니다. root가 사 주는 것은 더 많은 작업을 시도할 능력이지, 그것이 허용되거나 결과에 도달할 수 있다는 보장이 아닙니다.
Android 자체의 VPN 서비스 등록은 또 다른 별개의 장치입니다. 앱에 정의된 수명 주기를 가진 관리형 클라이언트 인터페이스를 줍니다. 범용 서버 설치자가 아니며, 터미널에서 데몬을 시작해도 상시 관리, 앱별 정책, 자체 복구 경로가 생기지 않습니다.
출구 지점을 원한다면 구조를 바꾸세요
목표가 기존 OpenVPN 프로파일과의 호환이 아니라 휴대폰을 통한 원격 인터넷 출구라면, 오버레이 네트워크의 지원되는 출구 노드가 더 잘 맞는 설계입니다. Tailscale은 자체 등록, 권한 부여, 클라이언트 선택 단계가 있는 Android 출구 노드 역할을 문서화합니다.
교환은 실제이며 분명히 말할 가치가 있습니다. 다른 프로토콜, 다른 신뢰 모델, 그리고 그 계정과 조정 서비스에 대한 의존을 받아들이는 것입니다. 수정하지 않은 OpenVPN 클라이언트가 오버레이에 가입하게 만들지도 않고, 공용 주소에서 OpenVPN 리스너를 주지도 않습니다.
배포에 아직 필요한 것
어떤 경로를 택하든 운영의 기본이 일주일을 버틸지를 결정합니다. 서버 자격 증명은 비공개로 두고, 클라이언트 신원은 서로 다르게 발급하고, 폐기는 필요해지기 전에 계획하세요. 업데이트가 어떻게 도착하는지, 무엇이 서비스를 백그라운드에서 계속 돌리는지, 재부팅이나 네트워크 변경 뒤에 어떻게 회복하는지 정하세요.
편해 보이는 지름길은 피하세요. 구식 정적 바이너리, 하드코딩된 인터페이스 이름, 기존 방화벽 정책을 지워 버리는 시작 스크립트입니다. 그다음에는 구체적인 시험으로만 결과를 받아들이세요. 권한 있는 원격 클라이언트가 의도한 자원에 도달하고, 금지된 목적지는 계속 사용할 수 없으며, 지원되는 수명 주기 이벤트 뒤에 장치가 스스로 돌아오는지입니다. root 접근은 그 결과의 가능한 재료 하나이며, 결정적인 경우는 드뭅니다.