Android VPN의 Keystore 오류: 재등록, 잠금 해제, 재시도 중 무엇을 할까?

프로필은 여전히 목록에 있고, 인증서도 여전히 설치된 것으로 표시되며, 연결 버튼은 «Keystore 오류»라고만 적힌 메시지와 함께 실패합니다. 앱 저장공간을 지우거나 휴대폰을 넘기기 전에 어떤 키 작업이 실패했는지 확인하세요. 세 가지 결과가 같은 대화상자를 만들지만 각각 다른 세 가지 조치에 반응하며, 그중 파괴적인 것은 하나뿐입니다. 이 비교에 십 분을 쓸 가치가 있는 이유는 잘못된 갈래를 고르면 지키려던 신원을 잃기 때문입니다.

하나의 대화상자 뒤에 있는 세 가지 실패

첫 번째는 인증입니다. 키는 존재하고 유효하지만, 사용하려면 사용자가 존재를 증명해야 합니다. 기기 잠금 해제, 생체 인증, 또는 업무 프로필 챌린지입니다. 잠금 시간 제한, 등록된 생체 인증, 프로필 상태가 최근에 바뀌었다면 키 자체는 완전히 정상이어도 키 사용이 실패할 수 있습니다.

두 번째는 영구적 무효화입니다. 일부 키 자료는 잠금 방식이 재설정되거나 생체 등록이 바뀔 때 플랫폼 정책으로 무효화됩니다. 보호하던 결속이 더 이상 성립하지 않기 때문입니다. 키는 복구할 수 없고 재시도는 복구 계획이 아닙니다. 신원은 그것을 발급한 등록 절차를 통해 교체해야 합니다.

세 번째는 공급자 장애입니다. keystore 서비스가 지금 작업을 완료하지 못했습니다. 가끔 재시도할 가치가 있는 분류는 이것뿐입니다.

세 가지 중 둘은 파괴적이지 않고, 하나는 기기 수준에서 해결책이 전혀 없다는 점을 보세요. 어느 것도 휴대폰을 지워서 해결되지 않습니다. 그래도 사람들이 먼저 그 단계를 밟는 것은 대화상자가 다른 무엇도 주지 않기 때문입니다.

재등록과 데이터 삭제

이 둘은 밖에서 보면 비슷해 보이지만 같지 않습니다. 재등록은 발급 시스템에 새 신원을 요청합니다. 이 기기에 묶인 새 인증서나 키이며, 기존 것은 은퇴시킵니다. 데이터 삭제는 앱의 저장 상태를 지우므로, 키를 지우지 않고 키에 대한 참조만 지울 수도 있고, 키를 지우고 다시 만들 권한을 남기지 않을 수도 있습니다.

구분이 중요한 이유는 내보낼 수 없는 키가 설계상 이동할 수 없기 때문입니다. 그 키는 기기의 keystore에 살고, 사용 가능한 하드웨어나 공급자의 지원을 받으며, 백업이 잡아 두고 복원이 되돌려 놓는 대상이 아닙니다. 배포의 신원이 내보낼 수 없는 키라면 복구 수단을 재등록으로 계획하고, 그 등록을 얻을 수 있는 승인된 경로가 있는지 미리 확인하세요. 일부 조직은 이를 위해 사설 네트워크 접근을 요구하며, 바로 그것이 고장 난 VPN이 제공하던 것입니다.

따라서 순서는 이렇습니다. 지원되는 인증 경로를 시도하고, 다음으로 키가 영구히 무효인지 판단하고, 그럴 때만 신원을 교체합니다. 저장공간 삭제는 마지막입니다. 무엇이 다시 만들어질지 안 뒤에 하며, 쉽다는 이유로 처음 하지 않습니다.

재시도할 수 있는 것만 재시도하세요

구버전 플랫폼은 keystore 오류를 하나의 예외로 합쳐 두었고, 그래서 많은 클라이언트가 모든 것을 재시도합니다. API 33부터 예외 유형은 구조를 담습니다. 숫자 오류, 일시적 실패 플래그, 재시도 정책입니다. 클라이언트 개발자에게 재시도 정책은 일시성 플래그가 참일 때만 의미가 있습니다. 영구 무효화에는 재시도 일정이 없고, 루프로 두드리면 배터리만 소모하고 로그만 채웁니다.

클라이언트를 작성하는 대신 진단한다면 실제 결과는 같습니다. 매번 동일한 실패는 일회성 오류를 배제하지만, 영구히 무효화된 키와 한동안 접근할 수 없는 공급자를 구분하지는 못합니다. 공급자 장애는 열 번째 시도에서도 첫 번째와 똑같이 보입니다. API 33의 구조화된 필드가 없다면 반복을 두 번째 신호를 찾는 이유로 다루세요. 빌드가 노출한다면 오류 코드, 사업자 상태, 또는 같은 기기의 다른 키가 성공하는 경우입니다. 키가 죽었다는 증거로 다루지 마세요.

원인 사슬을 읽고 라벨을 읽지 마세요

애플리케이션은 원래 예외를 감싸고, 화면의 친절한 문자열은 갈래를 결정하는 유일한 필드를 자주 숨깁니다. 원인 사슬과 시도 시각을 보존하세요: 바깥 예외는 보통 작업을 지목하고, 원인은 키 상태를 지목합니다.

두 앱이 실패한다고 기기가 결함이 있다는 추론에 저항하세요. 서로 다른 키가 서로 다른 공급자와 보안 수준에 의해 지원될 수 있고, 아직 동작하는 앱이 같은 작업을 전혀 수행하지 않을 수도 있습니다. 서명, 복호화, 키 증명은 같은 서비스에 대한 서로 다른 요청입니다. KeyStoreException 참조 문서는 더 새로운 API 수준의 구조화된 필드를 설명하며, 빌드가 실제로 무엇을 보고할 수 있는지 확인하는 곳입니다.

하드웨어 결론을 뒷받침할 근거는 대부분의 생각보다 좁습니다. 같은 작업이 같은 공급자에서 독립적인 키들에 걸쳐 키 수준 오류가 아니라 공급자 수준 오류로 실패하는 경우입니다. 그것은 플랫폼 진단에 대한 질문이지, 기기 묶음에 관한 지원 포럼 스레드에 대한 질문이 아닙니다.

결정하는 동안 기록할 것

Android 빌드, 클라이언트 버전, 선택한 프로필, 실패한 작업, 최근에 무엇이 바뀌었는지(OS 업데이트, 잠금 화면 변경, 새 지문, 재등록)를 기록하세요. 순서는 원인의 증거가 아니라 맥락으로 기록하세요. 키 실패 전의 잠금 변경은 그럴듯한 상관일 뿐 증명은 아닙니다.

그다음 확인한 갈래에 따라 행동하세요. 일시적이라면 신원을 유지하고 지원되는 재시도 경로를 사용합니다. 인증이 필요하다면 지원되는 잠금 해제 흐름을 마치고, 대화상자를 넘기려고 비활성화하는 대신 배포에서 요구하는 잠금 정책을 유지합니다. 영구히 무효라면 정상 등록을 통해 신원을 교체하고 은퇴시킵니다.

마지막으로 새로 승인된 연결에서, 실제 리소스에 대해, 서버 검증을 켠 채로 결과를 증명하세요. 인증서 검증을 완화해야만 동작하는 것은 키 문제를 고친 것이 아닙니다. 그것을 네트워크 계층으로 옮겼을 뿐이고, 나중에 더 나쁜 증상으로 나타납니다.

• 세 갈래: 인증 필요, 영구 무효, 공급자 측 일시적.
• 재시도로 이득을 보는 것은 세 번째뿐이며, 그것도 자체 재시도 정책에 따를 때만입니다.
• 대체 등록은 접근을 복구하고, 데이터 삭제는 그 선택지를 없앱니다.
• 새 연결과 정상적인 서버 신원 검증으로 확인하세요.