Mac의 VPN 확장 기능이 활성화되어 있나요? 확인할 세 곳

메뉴 막대는 연결됨을 보고하는데 확장 기능 목록은 여전히 해당 구성 요소를 활성화되지 않은 것으로 표시한다. 두 판독값 모두 같은 Mac에서 나오며, 서로 다른 사실을 기술하고 있을 뿐 어느 쪽도 거짓말이 아니다. macOS는 VPN 클라이언트에 대해 최소 세 가지 별개의 상태를 유지하는데, 지원 스레드가 이를 하나의 표현으로 뭉뚱그리기 때문에 조언이 재설치와 재구성 사이를 오가는 것이다. 실제로 어떤 상태가 빠져 있는지 알면 어림짐작으로 보내던 오후가 몇 분짜리 점검으로 바뀐다.

이 상태들은 위치뿐 아니라 소유자도 다르다. 하나는 운영 체제의 확장 기능 레지스트리에 속하고, 하나는 기기가 따르는 정책에 속하며, 하나는 클라이언트 자체의 세션에 속한다. 소유자가 다르기 때문에 그중 하나에 적용한 수정이 나머지 둘을 바꾸는 일은 드물다.

하나의 이름으로 불리는 세 가지 상태

어느 것을 먼저 읽는지가 목록 자체보다 중요하다 — 한 번도 활성화되지 않은 구성 요소는 연결될 수 없으므로 레지스트리부터 시작하고, 그다음 활성화가 애초에 가능한지 결정하는 정책을 읽고, 마지막으로 세 가지 중 세션을 기술하는 유일한 항목인 클라이언트를 읽는다. 그 순서의 위쪽에서 어긋나면 아래의 모든 증상이 설명되고, 아래쪽에서 어긋나면 위의 둘은 그대로 남는다.

구분의 구체적인 예: 활성화된 것으로 읽히는 레지스트리 항목과 연결되지 않는 클라이언트가 함께 있으면 프로필이나 서버를 의심해야 하며 확장 기능이 아니다. 반대 조합, 즉 아무것도 표시하지 않는 레지스트리 옆에 활성화된 클라이언트가 있는 경우는 보통 보고 있는 앱이 트래픽을 나르는 앱이 아니라는 뜻이다. 무엇이든 건드리기 전에 어떤 조합을 관찰했는지 적어 두어라.

아이콘을 믿지 않고 확장 기능 찾기

최신 릴리스는 네트워크 확장 기능을 시스템 설정의 일반, 로그인 항목 및 확장 기능 아래에 나열한다. 제품이나 게시자 이름이 붙은 항목을 찾아 메뉴 막대 표시가 아니라 그 옆의 스위치를 읽어라. 레이블과 위치는 macOS 버전마다 이동했으므로 오래된 기사의 스크린숏이 아니라 자신의 릴리스에 맞는 공급업체 지침을 따르라. 항목이 아예 없다면 그 구성 요소는 설치된 적이 없다는 뜻이며 프로필을 편집해도 나타나지 않는다.

systemextensionsctl list
log show --last 10m --predicate 'subsystem == "com.apple.networkextension"' --style compact

첫 번째 명령은 무엇이 설치되어 있고 각 확장 기능이 활성화되었다고 보고하는지 보는 가장 빠른 방법이다. 두 번째는 활성화가 거부되는 이유를 보여 준다 — 거부는 보통 사용자 인터페이스에 도달하지 않는 정책이나 서명 관련 불만으로 나타나기 때문이다. 무엇이든 바꾸기 전에 거부 텍스트를 읽어라 — 로그 줄에는 구성 요소와 흔히 그 이유가 적혀 있으며, 그것이 바로 지원 사례에 필요한 정보다. 중요하다고 생각하는 구절이 아니라 줄 전체를 복사하라 — 버전과 식별자는 줄의 양 끝에 있기 때문이다.

클라이언트는 인정하고 목록은 인정하지 않는 것

확장 기능이 확인되면 클라이언트에 프로필과 세션이 있는지 물어라 — 연결 없는 저장된 프로필은 구성 문제이고, 트래픽을 나르지 않는 연결은 라우팅이나 정책 문제이기 때문이다. 셋을 하나로 취급하면 내내 작동하던 구성 요소를 다시 설치하러 돌아가게 된다.

scutil --nc list
scutil --nc status "Work VPN"

목록은 구성된 서비스와 그 연결 상태를 보여 주고, 상태 호출은 이름이 지정된 한 서비스의 상태와 마지막 오류를 보여 준다. 다시 설치하기 전에 그 텍스트와 macOS 버전을 기록하라 — 재설치는 증거를 파괴하고 흔히 같은 실패를 재현하기 때문이다.

정책이 스위치를 소유할 때

관리되는 Mac에서는 구성 프로필이 확장 기능을 고정된 상태로 유지할 수 있으며 스위치는 설계상 회색으로 바뀐다. 사용할 수 없는 스위치는 우회할 버그가 아니라 정책의 선언이다. 거기에 이르려고 프로필이나 관리 등록을 삭제하면 기기의 보안 태세가 바뀌고, 다음 체크인에서 되돌려지며, 준수하다고 자체 보고하면서 정작 준수하게 만든 제어가 빠진 기기를 남긴다. 그 결과는 원래 문제보다 나쁘다 — 증상과 함께 원인까지 감추기 때문이다.

확장 기능 식별자, 정확한 거부 텍스트, 버전을 함께 관리자에게 요청을 가져가라. 관리되는 배포에서는 보통 네트워크 확장 기능을 몇 분 안에 중앙에서 승인할 수 있으며, 이는 우회 방법보다 빠르고 나중에 감사할 수 있다.

실제 애플리케이션에서 수정 증명하기

지원되는 수정을 한 뒤에는 메뉴 막대 배지가 아니라 그 VPN이 존재하는 이유인 애플리케이션에 다시 연결해 테스트하라. 그다음 터널 밖에 남아야 할 트래픽이 실제로 여전히 밖에 남는지 확인하라 — 모든 것을 조용히 라우팅하는 수정은 의도한 변경과 다른 변경이기 때문이다. 실제 애플리케이션에서의 몇 분짜리 테스트는 재현할 수 없는 배지보다 값지다.

그 목록에 있는 동안 한 가지 주의할 점이 있다 — 콘텐츠 필터도 네트워크 확장 기능이다. 사이트 하나만 실패할 때 패널의 모든 확장 기능을 끄는 것은 다른 애플리케이션의 무관한 필터링을 깨뜨리는 무딘 조치이며, 비교했을 구성 요소를 없애 다음 진단을 어렵게 만든다. 건드리기 전에 게시자와 역할로 확장 기능을 식별하고, 세 상태 중 어느 것이 실제로 잘못이었는지 적어 두어라.