Mac이 VPN 암호를 계속 묻습니다: 키체인일까요, 계정일까요?

Mac 잠금을 해제하고 VPN 클라이언트를 열면 터널이 시작되기도 전에 암호 시트가 나타납니다. 게이트웨이 암호를 입력하면 거부되거나 잠시 후 시트가 다시 나타납니다. 그런 다음 잠자기에서 깨어나거나, 로그아웃하거나, 클라이언트를 업데이트한 뒤 다시 묻습니다. 그 시트는 VPN 서버가 자격 증명을 요청하는 경우가 드물고, 보통 macOS가 로컬 기록을 읽거나 잠금 해제하거나 변경할 권한을 요청하는 것이며, 암호는 그 기록의 소유자에게 속하지 VPN 계정에 속하지 않습니다.

시트를 그 뒤에 있는 주체와 맞추세요

네 가지 프롬프트가 거의 똑같아 보이고 그중 하나만 게이트웨이와 관련됩니다. 문구, 접근을 요청하는 프로세스, 아래에 표시된 항목이 어느 것인지 알려줍니다.

로컬 접근에 관한 대화상자는 서버에 대해 아무것도 증명하지 않습니다. 게이트웨이의 거부는 공급업체의 오류 텍스트와 함께 클라이언트 안에 표시되며, 키체인 잠금 해제를 제안하는 시스템 시트로 표시되지 않습니다. 반대도 마찬가지로 흔합니다: 키체인 시트에 게이트웨이 암호를 입력하면 기록은 잠긴 채로 남고 실패한 시도가 하나 추가됩니다.

대화상자는 소유자, 저장소, 작업을 지정합니다

키체인 프롬프트는 가져오기에 관한 것이지 멀리 있는 무언가에 대한 인증이 아닙니다. Apple의 요청 대화상자 설명은 좁습니다: '한 번 허용', '항상 허용', '거부'는 해당 앱이 저장된 항목을 읽을 수 있는지 제어합니다. 셋 중 어느 것도 게이트웨이에서 권한을 부여하지 않으며 서버가 암호를 어떻게 보는지 바꾸지 않습니다.

요청자가 방금 업데이트된 클라이언트라면 재승인이 예상됩니다: 새 빌드는 더 이상 항목의 접근 제어 목록과 일치하지 않으므로 macOS가 다시 묻습니다. 진단 중에는 '한 번 허용'을 선택하세요. '항상 허용'은 해당 앱에 대한 영구 권한이며 예상하지 못한 도우미 프로세스에는 잘못된 답입니다; 바이너리가 직접 설치한 클라이언트가 아니면 거부하고 공급업체에 확인하세요.

관리자 승인을 요청하는 프롬프트는 세 번째 유형입니다. 변경되는 시스템 설정이나 보호된 저장소를 지정하며, 요구하는 자격 증명은 이 Mac의 관리자 계정입니다. 모든 개인 키체인 항목에 필요한 것은 아니며, 네트워크 구성 뒤에 있는 항목에는 보통 필요합니다 — 구성은 시스템에 속하고 로그인 세션에 속하지 않기 때문입니다.

Mac의 VPN 암호는 어디에 살 수 있나

키체인은 가능한 저장소 중 하나일 뿐 저장소의 정의가 아닙니다. 시스템 설정에서 만든 내장 VPN 구성은 자격 증명을 네트워크 구성과 함께 관리되는 시스템 설정으로 보관합니다. 타사 클라이언트는 보통 로그인 키체인에 항목을 보관합니다: 서비스 이름으로 키가 지정된 일반 암호이거나 서버, 프로토콜, 계정으로 키가 지정된 인터넷 암호입니다. 많은 최신 앱은 대신 데이터 보호 키체인을 사용하며, 그 항목은 키체인 접근에 절대 나타나지 않습니다.

사람들은 키체인 접근에서 VPN 이름을 찾고 아무것도 발견하지 못한 뒤 암호가 저장되지 않았다고 결론짓습니다. Apple의 TN3137 노트는 키체인 구현이 하나 이상 존재한다고 말합니다; 그 목록에 없는 것은 정상이며 항목이 깨졌다는 증거가 아닙니다.

기록 유형도 서로 바꿀 수 없습니다. 계정 암호, 개인 키 암호 문구, 클라이언트 인증서, IPsec 공유 비밀은 각기 다른 방식으로 실패하고 다른 곳에서 복구됩니다; 저장된 암호를 다시 입력해도 거부된 인증서에는 아무 효과가 없습니다. Mac이 관리에 등록되어 있으면 프로필이 또 다른 소유자입니다: VPN 페이로드는 자격 증명을 운반하고 새로 고칠 때 다시 적용할 수 있으므로 로컬 항목 삭제는 관리자가 바꿀 때까지 일시적입니다.

로그인 암호와 키체인 암호가 어긋날 때

로그인 키체인은 보통 Mac 로그인 암호를 사용하므로 둘이 어긋날 수 있습니다. 관리자가 다른 계정에서 암호를 재설정하거나 복구 흐름이나 디렉터리 변경이 있으면 키체인이 이전 값에 잠긴 채 남을 수 있고, 그러면 macOS가 방금 설정하지 않은 암호를 묻습니다.

로그인할 때 시스템이 키체인을 잠금 해제하지 못했다는 경고가 보일 수 있습니다. 업데이트에는 이전 암호가 필요하며, 기억하면 괜찮고 기억하지 못하면 소용없습니다. 정직한 복구 방법은 두 가지입니다: 키체인 접근의 '편집' > '키체인 "login"의 암호 변경'을 사용하거나, 필요한 자격 증명을 다시 입력한 새 로그인 키체인을 만드는 것입니다. 두 번째 방법은 저장된 항목을 파괴합니다.

VPN 하나가 이전 자격 증명을 거부한다고 키체인 전체를 재설정하지 마세요: 관련 없는 계정이 사라지고 항목은 여전히 식별되지 않습니다.

명령 하나로 로컬인지 원격인지 문제가 정리됩니다: 키체인에 항목을 직접 물어보세요.

security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -g

클라이언트 설정의 서버와 계정을 사용하세요. 직접 키체인에 물었을 때 같은 승인 시트가 나타나면 프롬프트는 로컬이고 서버는 방관자입니다. 그런 항목이 없다면 클라이언트가 생각한 곳에 암호를 저장하지 않는 것입니다. -g 플래그는 비밀을 터미널에 출력하므로 화면 공유를 피하세요.

클라이언트가 실제로 읽는 기록을 업데이트하세요

게이트웨이에서 계정이 바뀌었다면 먼저 그곳에서 바꾼 다음 클라이언트 설정을 통해 저장된 기록을 업데이트하세요. 키체인 항목을 직접 편집하는 것은 신뢰할 수 없습니다: 클라이언트가 다른 서비스-계정 쌍을 읽을 수 있고 관리 프로필이 편집 내용을 덮어씁니다.

오래된 것으로 의심되는 항목은 아무것도 삭제하기 전에 서비스, 계정, 프로토콜을 맞추세요:

security delete-generic-password -s "Client Name" -a [email protected]

다른 연결의 비슷한 이름 항목을 삭제하는 것은 흔한 자초 장애입니다. 제거는 로컬에만 적용됩니다: 게이트웨이의 세션을 취소하지도, 기기 인증서를 해제하지도, 계정 암호를 바꾸지도 않습니다.

복구가 재시동 후에도 유지되는지 확인하세요

연결하고, 잠자기에서 깨어나고, 로그아웃했다가 다시 로그인한 뒤 한 번 재시동하세요. 시트가 없는 깨끗한 순서와 예상 계정을 표시하는 클라이언트 상태만이 의미 있는 증거입니다. 프롬프트가 돌아오는 지점이 놓친 계층을 알려줍니다: 업데이트 후라면 승인, 네트워크 변경 후라면 클라이언트 자체 프롬프트, 재시동 후라면 상태를 다시 적용하는 프로필입니다.

키체인을 다시 건드리기 전에 클라이언트에서 암호 기억 또는 항상 묻기 설정을 확인하세요. 일부 구성, 특히 사용자별 인증을 쓰는 IKEv2는 설계상 연결할 때마다 묻습니다; 키체인 복구로는 해결되지 않습니다.

변경한 항목, 그것을 소유한 저장소, 속한 계정을 적어 두면 다음 프롬프트를 몇 초 만에 파악할 수 있습니다. Apple의 키체인 접근 요청 페이지는 그 세 버튼이 무엇을 승인하는지에 대한 참고 자료입니다.