Mac VPN이 매번 Keychain 접근을 요청하는 이유
Mac VPN의 각 프롬프트를 어떤 구성 요소가 띄우는지 파악하고, 중복 연결 시도를 멈추며, 전체 키체인을 재설정하지 않고 Keychain 접근을 복구하세요.
Connect를 한 번 클릭하면 로그인 창이 하나만 떠야 합니다. Mac에서는 흔히 세 개가 뜨고, 같은 소유자인 경우는 드뭅니다: 로컬 자격 증명 프롬프트의 소유자는 키체인이고, VPN 게이트웨이는 인증을, 클라이언트는 자체 알림을 소유합니다. 모든 것을 조용히 만드는 스위치를 찾는 대신 각 창을 고유한 수정이 있는 별도 결함으로 다루세요. 아래 절차는 한 번의 의도적인 연결 시도를 거치고 반복할 수 있는 점검으로 끝납니다.
설정을 바꾸기 전에 각 대화상자의 소유자를 이름 붙이세요
첫 단계는 구성이 아니라 기록입니다. 연결을 한 번 시도하고 나타나는 각 창마다 네 가지 항목을 적으세요: 대화상자에 표시된 앱 이름, 비밀을 뺀 정확한 텍스트, 나타난 단계, 그리고 취소했을 때 무슨 일이 있었는지입니다. 이런 세 줄이면 제가 본 거의 모든 보고를 포괄합니다.
소유자가 올바른 수정을 결정하며, 잘못된 수정이 보통 프롬프트 하나를 셋으로 만듭니다:
| Window | Who owns it | Correct fix | What not to do |
|---|---|---|---|
| “wants to use your confidential information stored in…” | The item's access control list in your login keychain | Approve the specific client helper, once, after checking the name | Resetting the login keychain, or granting Always Allow to every application |
| “Sign in to <organization>” or an MFA push | The gateway's identity provider | Use the client's supported session renewal, or re-authenticate | Scripting a fixed password or code into the client |
| “Connection failed”, “Update required”, a policy banner | The client or your organization | Read the first error and fix its cause | Hiding notices by editing a preference file the client rewrites |
같은 시도 안에서 돌아오는 프롬프트는 다음 시도에서 돌아오는 것과 다른 신호입니다. 전자는 보통 연결이 사용자 아래에서 다시 시작되었음을 뜻하고, 후자는 보통 저장된 자격 증명이 다시 요구되고 있음을 뜻합니다. 키체인을 건드리기 전에 어느 쪽인지 적어 두세요 — 둘은 거의 공통점이 없습니다.
터널을 시작하는 것이 몇 개인지 알아내세요
Mac에서 같은 VPN을 시작할 수 있는 메커니즘은 네 가지입니다: 메뉴 막대 동작, 로그인 항목, On Demand 규칙, 그리고 스크립트나 에이전트입니다. 둘이 함께 작동하면 첫 번째가 아직 인증을 기다리는 동안 두 번째 시작이 도착해 중복 창이 생기고 진척이 없습니다. 먼저 무엇이 구성되어 있는지 나열하세요: scutil --nc list 시스템 설정이 아는 VPN 서비스를 현재 상태와 함께 출력합니다. 자체 네트워크 확장을 제공하는 클라이언트는 프로필을 앱 안에 보관해 거기에 나타나지 않을 수 있으므로 클라이언트 자체의 연결 목록도 확인하세요.
다음으로 경쟁하는 시작 요인을 찾으세요. scutil --nc show "Work VPN" 내장 서비스의 구성 사전을 On Demand 규칙까지 포함해 출력합니다 — 인터페이스가 바뀔 때마다 다시 연결하는 규칙은 Wi-Fi가 이동하거나 디스플레이가 네트워크 스택을 깨울 때마다 터널을 다시 시작하고 인증 프롬프트를 다시 엽니다. 시스템 설정 > 일반 > 로그인 항목에서 로그인 항목을 확인하고, 사용자별 에이전트를 다음으로 나열하세요 ls ~/Library/LaunchAgents. MDM이 관리하는 보안 스택에 속한 것은 그대로 두세요 — 제거하면 보통 다음 확인에서 되돌려집니다.
시도 중에 실제로 무엇이 실행되는지 보려면: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. 하나를 기대하는 곳에 클라이언트 도우미가 둘이면 "왜 프롬프트가 두 번 떴나"를 어떤 자격 증명 문제보다 훨씬 자주 설명합니다.
키체인을 재설정하지 않고 Keychain 접근을 복구하세요
프롬프트는 VPN 프로토콜이 아니라 저장된 항목의 접근 제어 목록에서 나옵니다. 각 항목은 어떤 앱이 묻지 않고 읽을 수 있는지 기록합니다. 클라이언트 업데이트 후에는 묻는 도우미의 이름이나 서명이 달라졌는데 항목은 아직 옛것을 나열하고 있어서 macOS가 연결마다 다시 묻습니다. 그 한 항목에 대해 새 도우미를 승인하는 것이 전부이며, 모든 앱을 승인하는 것은 아닙니다.
VPN을 건드리지 않고 ACL이 원인임을 확인할 수 있습니다: security find-generic-password -s "service-name" -g 같은 항목을 터미널에서 읽습니다. 그 명령도 프롬프트를 띄운다면 대화상자는 키체인의 것이고 터널은 방아쇠일 뿐입니다. Apple의 세 버튼에 관한 안내 — 한 번 허용, 항상 허용, 거부 — 는 거부가 프롬프트를 다음 시도가 아니라 즉시 다시 뜨게 하기 때문에 한 번 읽을 가치가 있습니다.
잘못된 도우미를 승인했다면 Keychain Access에서 항목을 열고 Access Control로 전환해 그 항목을 제거하세요 — 그것이 롤백입니다. 로그인 키체인을 삭제하거나 그것을 다시 만드는 복구 도구를 실행하면 관련 없는 암호도 버리게 되며 문제보다 훨씬 큰 변경입니다.
로그인과 정책 단계를 그것을 소유한 흐름에 두세요
브라우저 로그인이나 MFA 챌린지는 게이트웨이에 속합니다. 조직이 세션 지속성이나 인증서 기반 인증을 제공한다면, 더 드물게 인증하는 지원되는 방법이므로 그것을 사용하세요. 클라이언트에 고정 코드를 입력하거나 프롬프트가 절대 뜨지 않도록 스크립트에 암호를 저장하면 대화형 요소를 정적 비밀로 바꾸게 되고 다음에 정책이 바뀔 때 실패합니다.
조직 알림은 억제해서는 안 되는 유일한 범주입니다. 보통 상태 점검이나 허용 가능한 사용 확인을 강제하며, 숨기면 터널이 작동하는 동안에도 기기가 규정을 벗어날 수 있습니다. 오류 대화상자는 다른 범주입니다: 첫 번째 오류 텍스트를 보관하세요 — 두 번째 대화상자는 대개 재시도 후 같은 실패를 보고하는 것뿐입니다.
한 번의 시도로 확인하고, 그다음 재부팅 후에 확인하세요
중복 시작 요인을 제거하고 키체인 항목을 복구한 뒤 한 번만 시도하세요: 메뉴 막대 도우미를 포함한 모든 클라이언트 인스턴스를 종료하고 한 번 연결한 다음 창을 세세요. 원하는 것은 항목이 다시 만들어졌다면 키체인 승인과 한 번의 인증 단계뿐입니다. 그 이상은 아닙니다. scutil --nc status "Work VPN" 내장 서비스에 대해 Connected를 보고해야 합니다.
그다음 한 번 재부팅하고 반복하세요. 재부팅 후에만 돌아오는 프롬프트는 자격 증명이 아니라 로그인 항목이나 On Demand 규칙을 가리키고, 세션 안에서 돌아오는 것은 ACL이나 두 번째 시작 요인을 가리킵니다. 두 번의 과정 후에도 반복된다면 관리자에게 건넬 유용한 것은 첫 시도의 세 줄 표입니다 — 소유자, 정확한 텍스트, 단계 — 대화상자 스크린샷이 아닙니다.
목표는 프롬프트를 줄이는 것이지 조용하게 만드는 것이 아닙니다. 권한 부여 단계를 숨기는 연결은 더 이상 감사할 수 없는 연결이며, 다음 인증서 교체 때 어느 구성 요소가 실패하는지 모른 채 마주하게 됩니다.