Android 12와 IKEv1 VPN: 출하 당시 SDK 레벨, IKEv2, 서드파티 앱

두 휴대폰 모두 설정에 Android 12를 표시하지만, 게이트웨이가 제공하는 오래된 IPsec XAuth 프로필을 여전히 시작하는 기기는 하나뿐입니다. 차이는 사용자가 만질 수 있는 설정이 아닙니다. 네이티브 IKEv1 경로를 제어하는 가드는 기기가 출하된 SDK 레벨을 보며, 지금 실행 중인 버전만 보지는 않습니다. 이 한 가지 세부가 플리트 비교에 의미가 있는지, 그리고 세 가지 마이그레이션 경로 중 무엇이 정말 필요한지를 결정합니다.

두 Android 12 휴대폰은 같은 테스트 케이스가 아닙니다

새 기기가 오래된 IKEv1 프로필을 시작하지 못하게 한 AOSP 변경은 DEVICE_INITIAL_SDK_INT 을 Android S, 즉 API 31과 비교합니다. 네이티브 시작 경로에서 조건을 충족하는 프로필은 쓸 만한 연결이 생기기 전에 지원되지 않는 작업 오류를 발생시킵니다. Android 11로 출하되어 나중에 업데이트된 기기는 이 가드를 여전히 통과하지만, Android 12로 출시된 모델은 통과하지 못합니다.

디버깅을 켠 기기에서 두 숫자를 읽을 수 있습니다.

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

첫 번째 값이 가드가 보는 출하 레벨이고, 두 번째는 오늘 기기가 실행하는 레벨입니다. 속성이 없으면 마케팅 이름으로 추측하지 말고 모델 지원 문서를 참고하세요. 또한 제조사 빌드가 기본 릴리스의 모든 호환 경로를 보존한다고 가정하지 마세요.

또 하나의 구분이 한 시간의 낭비된 지원 시간을 아낍니다. VPN 설정에 여전히 나열된 저장된 프로필은 플랫폼이 그것을 시작할지에 대해 아무것도 증명하지 않습니다. PSK를 다시 입력하거나 경로를 편집해도 더 앞서 실행되는 프로토콜 지원 검사를 없앨 수 없고, 실패는 자격 증명 문제처럼 보이지만 그렇지 않습니다.

경로 하나: 아직 동작하는 곳에서 네이티브 스택 유지

오래된 스택은 시스템 VPN 화면에서 IPsec XAuth PSK, IPsec Hybrid RSA, L2TP/IPsec PSK 프로필을 읽는 스택입니다. API 31 미만으로 출하된 기기에서는 업데이트 후에도 여전히 유효한 경로이며, 그래서 오래된 기기에서의 시험은 성공하고 새 기기에서는 같은 프로필을 시작하지 못할 수 있습니다.

중요한 비교는 Android 버전별이 아니라 기기 등급별입니다. 플리트의 모델을 나열하고, 출하 API 레벨을 읽고, 프로필을 아직 시작하는 기기와 그렇지 않은 기기로 나누세요. 다른 방식은 사용자가 새 휴대폰을 사는 순간 스스로 모순되는 지원 정책을 만듭니다.

경로 둘: 플랫폼 IKEv2 프로필

IKEv2에 대한 Android의 공개 프로비저닝 모델은 다른 객체이며 이름만 바꾼 IKEv1 프로필이 아닙니다. IKEv2 프로필용 플랫폼 API는 API 30과 함께 나왔고, 게이트웨이가 제공하는 인증 방식(보통 인증서 기반이나 EAP)을 갖춘 IKEv2를 기대합니다. IKEv1 XAuth나 Hybrid에서 IKEv2로 가는 유선 호환 업그레이드는 없습니다. 게이트웨이를 새 프로토콜에 맞게 구성해야 하고 프로필이 대응하는 신원을 담아야 합니다.

가장 수명이 긴 경로이며 실제 작업을 드러내는 경로이기도 합니다. 신원 검증, 사용자 인증, DNS, 분할 터널 경로, 리소스 권한 부여가 모두 마이그레이션을 견뎌야 합니다. 핸드셰이크만 성공시키면 사용자는 아무 데도 닿지 않는 터널에 묶여 있게 됩니다.

배포는 보통 사용자가 필드를 입력하는 대신 MDM이나 관리형 구성으로 이루어집니다. 그 기반이 아직 없다면 마이그레이션 계획에 포함해야 합니다. 모든 기기에서 IKEv2 프로필을 손으로 다시 입력하는 일은 헬프데스크가 감당할 작업이 아니기 때문입니다.

경로 셋: 서드파티 클라이언트 앱

일부 VPN 앱은 자체 프로토콜 구현을 탑재하며 네이티브 스택에 전혀 의존하지 않습니다. 그래서 빠르게 마이그레이션할 수 없는 플리트에 합법적인 임시 방편이 되지만, 호환성 질문은 앱으로 옮겨갑니다. 게이트웨이가 말하는 exact IKEv1 모드를 게이트웨이가 요구하는 인증과 암호 제품군과 함께 구현하는지입니다.

스토어 설명이 아니라 앱 자체의 지원 매트릭스를 근거로 삼고, 추천하기 전에 실제 기기로 실제 게이트웨이를 시험하세요. 제거된 플랫폼 경로를 되살리기 위해 기기를 루팅하는 것도 유지되는 해법이 아닙니다. 다음 시스템 업데이트가 조용히 깨뜨릴 수 있는 비지원 구성으로 문제를 옮길 뿐입니다.

게이트웨이가 제공할 수 있는 것으로 선택하세요

두 가지를 알면 결정이 좁아집니다. 어떤 기기가 API 31 이후에 출시되었는지, 그리고 게이트웨이가 같은 등록 모델로 IKEv2 서비스를 제공할 수 있는지입니다. 가능하면 마이그레이션하고 오래된 프로필에 대한 투자를 멈추세요. 아직 불가능하면 여전히 시작하는 기기에는 IKEv1을 유지하고, 새 기기에는 서드파티 클라이언트를 문서화된 기한부 예외로 주세요. 암묵적인 우회로가 되어서는 안 됩니다.

두 가지가 계획을 방어 가능하게 만듭니다. 첫째, 각 예외의 이유를 모델과 출하 레벨과 함께 기록해 감사자가 그 경계가 설명 없는 선호가 아니라 플랫폼 가드임을 보게 하세요. 둘째, 마이그레이션을 계획된 작업으로 다루세요. IKEv1은 표준 흐름에서 폐기되었으며(RFC 9395), 남은 기기는 계속 줄어들고 예외도 그에 맞춰 만료되어야 합니다.