Android VPN 내보내기: 새 휴대폰으로 실제로 넘어가는 것
Android VPN 내보내기는 설정과 때로는 키를 보내지만 기기 인증은 절대 보내지 않습니다. 오래된 휴대폰을 지우기 전에 실제로 무엇이 이동하는지 확인하세요.
Android에서 VPN 프로필을 내보내는 일은 백업 단계처럼 느껴지고, 그것을 제공하는 메뉴는 그런 인상을 바로잡아 주지 않습니다. 남는 것은 파서 입력, 운영체제가 끝내 돌려주지 않을 수도 있는 키, 그리고 바로 그 휴대폰에 발급된 인증입니다. 이 셋을 분리하면 유용한 질문이 나타납니다. 새 기기에서 아직 빠진 부분은 무엇일까요?
파일은 쉬운 부분입니다. 나머지 둘이 이전이 되는지를 결정합니다.
내보낸 프로필에 실제로 들어 있는 것
믿기 전에 텍스트 편집기로 파일을 열어 보세요. OpenVPN 프로필은 작은 설정 언어입니다. remote, proto, data-ciphers, 그리고 흔히 클라이언트가 TLS 스택에 넘기는 인라인 <ca>, <cert>, <key>, <tls-crypt> 블록이 있습니다. WireGuard 설정은 더 평평해서 [Interface]에 PrivateKey과 Address가 들어 있고, 이어서 엔드포인트마다 하나의 [Peer]이 PublicKey, AllowedIPs, Endpoint을 담습니다. IKEv2는 키 블록 대신 페이로드 사전을 가진 .mobileconfig로 옵니다.
그 텍스트 어느 것도 그 자체로 자격 증명은 아닙니다. 자격 증명은 개인 키이고, 각 형식은 그것을 인라인으로 붙이거나 자신을 만든 클라이언트 안에서만 풀리는 별칭을 가리킵니다.
Android에서 키가 실제로 사는 곳
Android는 앱 데이터를 /data/data/<package> 아래에 두며, 그 앱의 UID만 읽을 수 있습니다. 루팅하지 않은 휴대폰에서 다른 앱의 비공개 디렉터리를 복사하는 지원되는 방법은 없고, Android 12가 이를 폐기하고 클라이언트들이 allowBackup="false"를 선언하기 시작한 뒤로 adb backup은 일반적인 답이 아니게 되었습니다. 따라서 Android 클라이언트에서의 내보내기는 그 클라이언트가 구현한 것을 뜻하며 파일 시스템 복사가 아닙니다.
신원 계층은 앱 아래에 있습니다. 클라이언트가 키를 Android Keystore로 가져왔다면 자료는 그곳에서 생성되거나 감싸지고, 이후 내보내기는 바이트 대신 Keystore 별칭에 대한 참조를 담을 수 있습니다. 하드웨어 지원 키는 소유 앱조차 읽을 수 없도록 만들어져 있으며, Keystore documentation이 설명하는 대로입니다. 그래서 그 별칭을 가리키는 프로필은 같은 휴대폰에서는 깨끗하게 가져와지고 다른 어디서든 실패합니다.
그것은 망가진 내보내기가 아닙니다. 플랫폼에 요구된 성질입니다.
프로필이 옮길 수 없는 것
대상이 받아들일 것과 객체를 나란히 놓으세요.
| 객체 | 이동하는가 | 이유 |
|---|---|---|
| 프로토콜과 엔드포인트 | 예, 대상 클라이언트가 지원하면 | 프로필 안의 평문 |
| CA 인증서와 호스트 이름 검사 | 대개 | 공개 자료지만 호스트 이름은 여전히 인증서와 맞아야 함 |
| 클라이언트 인증서 | 예, 기기별로 묶여 있지 않다면 | 인증서는 휴대 가능하며, 하나를 몇 대가 쓸지는 발급자가 정함 |
| 개인 키 | Keystore 밖에서 생성된 경우에만 | 하드웨어 지원 키는 내보낼 수 없고 교체만 가능 |
| 계정, MFA, SSO 세션 | 아니오 | 토큰은 만료되고 이를 얻은 기기에 묶여 있음 |
| 경로, DNS, 앱 범위 | 설정 텍스트로만 | Android는 연결 시 VpnService.Builder를 통해 적용 |
| 분할 터널 앱 목록 | 드물게 | 패키지 이름이 기기마다 다르고 목록은 클라이언트 상태 |
혼란의 대부분은 두 행에서 생깁니다. 기기에서 생성되어 내보낼 수 없다고 표시된 키는 앱 데이터와 함께 실제로 사라지므로 대체는 새 키와 그에 발급된 인증서입니다. 새 휴대폰으로 복사한 세션 토큰은 보통 첫 갱신에서 죽고, 그것은 가져오기 실패처럼 보입니다.
가져오기는 파싱이고, 그다음 동의 요청
받는 쪽에서 가져오기는 파싱에 이어 커밋입니다. 클라이언트는 설정을 읽고 참조된 모든 블록이 있는지 확인한 뒤 터널 정의를 자기 샌드박스에 씁니다. 그래서 다운로드에서 고른 파일이 이후 연결되는 대상이 아닙니다.
그다음 어떤 파일도 건너뛸 수 없는 인증 단계가 옵니다. Android는 터널을 세우기 전에 앱이 VpnService.prepare()를 호출하고 당신의 동의를 받도록 요구하므로, 방금 가져온 프로필도 시스템 대화상자를 한 번은 띄웁니다. 그다음 터널은 addAddress, addRoute, addDnsServer, 그리고 앱별 라우팅을 위한 addAllowedApplication 또는 addDisallowedApplication를 통해 명시적으로 만들어집니다. 이 중 어느 것도 엔드포인트에서 함축되지 않으므로 같은 프로필이 두 클라이언트에서 다른 실효 경로 집합을 만들 수 있습니다.
인증서 기반 설정은 분기를 하나 더 추가합니다. 서버가 특정 기기에 인증서를 발급할 때, MDM과 SCEP 등록이 그러하듯, 두 번째 휴대폰에서의 재사용은 서버가 신원당 하나의 세션을 강제할 때까지 작동하거나 TLS 핸드셰이크에서 실패합니다. 재사용을 계획하기 전에 발급자 정책을 확인하세요.
오래된 기기를 은퇴시키기 전에 새 기기를 검증하세요
새 휴대폰이 초록 아이콘보다 나은 무언가를 통과할 때까지 오래된 휴대폰을 연결해 두세요. 새 기기에서 나가는 주소와 실제로 사용한 DNS 리졸버를 확인하세요. split tunneling가 중요하다면 터널을 우회해야 하는 앱과 그렇지 않은 앱을 실행해 어느 쪽이 ISP에 닿는지 보세요.
한 번의 확인으로 나가는 주소가 정리됩니다. 휴대폰 브라우저에서 https://ifconfig.me을 열고, 같은 Wi-Fi의 노트북에서 curl -s https://ifconfig.me을 실행해 두 답을 공급자가 할당한 주소와 비교하세요.
그때서야 오래된 신원을 은퇴시키고, 발급자를 통해 하세요. 인증서를 폐기하거나 계정에서 기기를 제거하세요. 다운로드에서 파일을 지우는 것은 아무것도 끝내지 못합니다. 같은 인증서를 가진 두 기기는 서버 로그에서 똑같이 보이기 때문입니다.
내보내기가 휴대 불가로 판명되면 해결책은 공개 설정 번들이 아니라 새 등록입니다. 두 번째 기기용 프로필을 요청하거나 새 휴대폰에서 키 쌍을 만들어 CSR을 제출하세요. 더 느리지만 발급자가 지원하는 길입니다.
무언가를 지우기 전에 체크리스트를 실행하세요. 새 기기가 연결되고, 나가는 주소와 DNS가 일치하고, 앱별 범위가 의도한 대로이고, 오래된 신원이 폐기되었으며, 보관한 설정 파일이 암호화된 저장소에 있습니다.