Mac VPN 클라이언트: Network Extension 대 System Extension

Apple의 두 용어가 같은 것을 가리키는 것처럼 쓰이고, 그 혼동이 사람들을 잘못된 설정 패널로 보냅니다. Network Extension은 VPN 터널, 프록시, 필터를 구현하는 지원되는 방법이라는 기능을 설명합니다. System Extensions는 사용자 공간 확장의 전달과 승인 방식을 설명합니다. 현대의 Mac VPN 클라이언트는 보통 둘 다 필요하므로 어느 한 레이블만으로는 증상을 설명할 수 없습니다. 둘을 구분하면 어떤 구성 요소를 살펴보고 어떤 승인 단계를 기대할지 알 수 있습니다.

두 질문, 하나의 레이블이 아님

구성 요소가 어떻게 설치되는지 묻기 전에 무엇을 하는지 물으십시오. 기능은 어떤 공급자 클래스가 존재하는지, 따라서 어떤 코드가 패킷을 처리하는지 결정합니다. 전달 방식은 바이너리가 어떻게 도착하고 어떻게 승인되며 상태가 어디에 기록되는지 결정합니다. 제품은 이전 릴리스에서 시스템 확장을 전달하지 않고도 패킷 터널을 구현할 수 있고, 터널이 아닌 다른 것을 구현하는 시스템 확장을 전달할 수도 있습니다.

커널 확장은 사람들이 섞는 세 번째 용어입니다. 권한 있는 네트워크 코드를 실행하는 옛 방식이었고, 다른 승인이 필요했으며, Apple은 수년간 개발자들을 그곳에서 멀어지게 해 왔습니다. 커널 확장 승인 절차를 현대 클라이언트에 적용하면 결코 나타나지 않을 대화상자에 시간을 낭비합니다.

사용 중인 macOS 버전에 대한 공급업체의 배포 노트를 읽으십시오 이전 릴리스의 포럼 게시물 대신에. 아키텍처는 여러 번 바뀌었고 지침은 빠르게 낡습니다. 커널 확장 승인을 언급하는 노트는 제품의 다른 시대를 설명합니다.

Network Extension이 제공하는 것

이 프레임워크는 VPN 트래픽용 패킷 터널, 애플리케이션별 흐름용 앱 프록시, 트래픽 검사용 콘텐츠 필터, 리졸버 동작용 DNS 프록시 처리 등 일반적인 네트워크 작업을 위한 공급자 유형을 제공합니다. 공급자 유형이 확장이 할 수 있는 일을 결정하며, 두 공급자를 전달하는 클라이언트는 두 가지 다른 작업을 하고 있을 수 있습니다.

진단할 때 이것이 중요한 이유는 같은 연결 증상이 터널, 필터, DNS 프록시 어디서든 올 수 있기 때문입니다. 웹사이트 차단은 필터 결정이고, 사설 서브넷에 도달하지 못하는 것은 보통 터널 결정이며, 잘못된 주소를 해석하는 것은 보통 리졸버 결정입니다. 공급자 유형을 지목하면 어떤 로그도 읽기 전에 검색 범위가 좁아집니다.

프레임워크 자체는 어떤 프라이버시 태도를 함의하지 않습니다. 사용자 공간 확장에도 권한, 구성, 운영자가 있으므로 아키텍처를 신뢰 신호가 아니라 구현 세부 사항으로 다루십시오. 엔드포인트를 누가 운영하고 무엇을 수집하도록 구성되었는지 물으십시오.

System Extensions가 바꾸는 것

이 방식은 권한 있는 코드를 커널에서 사용자 공간으로 옮기고, 운영체제가 동의를 요청하는 방식을 바꿉니다. 활성화는 설치와 별개의 단계이며 사용자나 MDM 프로필이 이를 허용해야 합니다. 설치되지만 결코 활성화되지 않는 클라이언트 Applications 폴더에 있는 것처럼 보이지만 연결에는 아무 일도 하지 않습니다.

상태는 앱이 아니라 시스템이 기록하므로 조회할 수 있다는 점이 유용합니다. 아래 명령은 시스템이 아는 확장과 그 활성화 상태를 나열합니다.

systemextensionsctl list
scutil --nc list

첫 번째 명령은 구성 요소가 설치되고 활성화되었는지 답합니다. 두 번째는 시스템이 보유한 VPN 구성을 나열하며, 이는 다른 질문이고 연결 프로필이 깨진 것이 아니라 없을 때 중요한 경우가 많습니다.

주어진 증상에 무엇을 살펴볼까

설정 패널을 열기 전에 증상을 계층에 맞추십시오. 구성이 없으면 프로필 질문이고, 설치되었지만 비활성인 구성 요소는 전달 질문이며, 트래픽을 통과시키지 못하는 활성 구성 요소는 기능 질문입니다.

마지막 두 행에서 로그 스트림은 공통 증거입니다. 네트워크 확장 하위 시스템을 읽으면 어떤 공급자가 흐름을 처리했는지 알 수 있고, 필터 결정은 터널 실패와 다르게 보이는데, 사용자가 둘 다 VPN 고장이라고 표현해도 마찬가지입니다.

log show --last 10m --predicate 'process == "nesessionmanager"'

메뉴 막대에 아이콘이 있다고 해서 확장이 활성이라고 결론내지 마십시오. 아이콘은 실패한 활성화 후에도 남고, 오래된 아이콘은 지원 요청이 잘못된 곳에서 시작되는 가장 흔한 이유 중 하나입니다. 대신 시스템이 기록하는 활성화 상태를 읽으십시오.

승인, MDM 그리고 커널 확장 신화

관리되는 Mac에서는 승인 단계가 MDM 프로필에 속하며, System Settings에서 Allow를 클릭한 사용자도 업데이트되지 않은 정책에 막힐 수 있습니다. 사용자에게 무엇이든 클릭하도록 요청하기 전에 해당 플릿에서 어떤 방식이 확장을 승인하는지 데스크톱 팀에 물으십시오.

관리되지 않는 Mac에서는 승인 프롬프트가 한 번 나타나며, 확장을 다시 설치할 때까지 거부가 영구적일 수 있습니다. 그 동작은 OS 업그레이드 전에는 클라이언트가 작동했지만 지금은 결코 설정되지 않는 연결을 보고하는 기계를 설명합니다.

배포하는 클라이언트의 공급자 유형, 활성화 상태, 승인 방식을 적어 두십시오. 이 세 가지 사실은 기능 대 전달 논쟁을 다시 열지 않고도 Mac VPN에 관한 대부분의 향후 질문에 답합니다.