Mac VPN, 콘텐츠 필터, Private Relay 중 무엇이 켜져 있나
Mac의 세 네트워크 계층은 설정에서 비슷해 보입니다. 출구 경로, 흐름 정책, 브라우징 범위로 VPN, 콘텐츠 필터, Private Relay를 구분합니다.
Mac에는 VPN 터널, 콘텐츠 필터, iCloud Private Relay가 동시에 설치되어 있을 수 있으며, 어느 것이 특정 연결을 만들고 있는지 알려 주는 것은 없습니다. 설정 패널도 비슷하고 아이콘도 비슷하며, 거의 모든 공급업체가 자기 제품을 네트워크 보안이라고 부릅니다. 세 가지 사실이 이들을 나눕니다. 트래픽이 이름을 댈 수 있는 원격 종단을 통해 나가는지, 정책 엔진이 개별 흐름에 허용-또는-차단 결정을 내리는지, 보호가 Safari에서 끝나는지입니다. 이 셋을 정리하면 내 VPN이 켜져 있나 하는 질문 대부분은 스스로 답이 나옵니다.
구성 요소를 식별하는 세 조건
첫 조건은 출구입니다. 터널 공급자는 패킷을 원격 게이트웨이에 넘기므로 공인 주소가 바뀌고, 프로파일이 그렇게 정하면 그 게이트웨이 뒤의 호스트에 접근할 수 있게 됩니다. 주소가 결코 바뀌지 않고 사설 서브넷도 열리지 않는다면, 메뉴 막대가 무엇이라 하든 동작하는 터널이 아닙니다.
둘째 조건은 결정입니다. 콘텐츠 필터는 흐름을 평가해 허용 또는 차단을 돌려줍니다. 범주 차단, 앱별 규칙, 고용주가 밀어 넣은 정책을 적용할 수 있고 판정을 기록할 수 있습니다. 혼자서 할 수 없는 것은 트래픽에 갈 곳을 주는 일입니다.
셋째 조건은 범위입니다. Private Relay는 기기 전체가 아니라 브라우징의 정해진 일부를 보호하며, 그 일은 당신이 누구인지와 무엇을 방문하는지를 분리하는 것이지 다른 네트워크에 두는 것이 아닙니다.
셋을 나란히 놓으면 경계를 놓치기 어렵습니다.
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
콘텐츠 필터는 정책 엔진이지 출구가 아닙니다
macOS에서 필터는 Apple의 필터 데이터 제공자 클래스 NEFilterDataProvider 위에 지어진 Network Extension으로 옵니다. 관리형 배포에서는 MDM이 밀어 넣고, 시스템 확장으로 설치되며, 시스템 설정 > 일반 > 로그인 항목 및 확장에서 한 번 승인됩니다. 이후 TCP 흐름을, 일부 구성에서는 UDP도 보며 각각에 판정을 돌려줍니다.
사람들을 헷갈리게 하는 것은 실패 방식입니다. 흐름을 차단하는 필터는 시간 초과, 멈춘 TLS 핸드셰이크, 재설정을 만들어 내며, 이는 올라왔지만 트래픽을 통과시키지 못하는 터널과 똑같이 보입니다. 공인 주소는 바뀐 적이 없습니다. 바꿀 출구가 애초에 없었기 때문입니다.
상용 클라이언트는 흔히 두 역할을 함께 담습니다. 설치 프로그램 하나가 터널 공급자와 필터를 함께 넣고, 차단은 필터가, 라우팅은 터널이 합니다. 그래서 앱 이름만으로는 어느 구성 요소가 연결을 거부했는지 알 수 없습니다. 확장 목록, 그다음 연결된 서비스, 그다음 클라이언트 로그 순서로 확인합니다.
Private Relay는 Safari를 덮지, 기기 전체를 덮지 않습니다
Private Relay는 자기가 덮는 브라우징을 서로 다른 주체가 운영하는 두 릴레이를 거쳐 보내므로, 어느 한 운영자도 당신의 신원과 목적지를 함께 갖지 않습니다. 이는 프라이버시 설계이지 터널이 아닙니다. 들어갈 게이트웨이도, 사설 서브넷도, 고른 국가에 출구 주소를 고정할 방법도 없습니다.
그 범위는 의도적으로 좁아 Safari 브라우징과 거기에 따르는 DNS 조회, 안전하지 않은 HTTP 로드를 덮습니다. 터미널 세션, 메일 클라이언트, 채팅 앱, 게임 런처는 그 밖에 있습니다. 터미널에서 확인했을 때 여전히 접속 네트워크 주소가 보이고 Safari가 릴레이 주소를 보인다면, 그것이 예상된 결과이며 고장 난 설치가 아닙니다.
가용성에는 조건이 있습니다. iCloud+ 요금제가 필요하고, 모든 지역에서 제공되지 않으며, 관리형 네트워크가 릴레이 접근을 차단할 수 있고 그 경우 Safari는 직접 연결로 돌아갑니다. 현재 범위에 대해서는 Apple의 Private Relay 개요가 기준입니다. VPN 프로파일이 연결되어 그 트래픽을 나르고 있다면 릴레이가 그 위에 겹쳐지지 않습니다. 경로는 프로파일이 정합니다.
증거는 올바른 순서로 읽습니다
서비스 상태부터 시작합니다. 가장 값싼 신호이기 때문입니다. scutil --nc list는 구성된 VPN 서비스와 각각의 연결 여부를 출력합니다. 프로파일은 한 번도 연결되지 않은 채 몇 년을 그 자리에 있을 수 있고, 사람들은 흔히 그것을 터널로 셉니다.
다음으로 인터페이스와 경로를 봅니다. ifconfig는 utun 인터페이스를 보여 주지만, 그 존재만으로는 증명하는 바가 적습니다. macOS가 VPN 말고도 여러 목적으로 utun을 쓰기 때문입니다. 중요한 것은 기본 경로가 그중 하나로 들어가는지이며, route -n get default가 이를 보고합니다.
이름 해석의 경우 scutil --dns가 시스템이 실제로 사용할 리졸버를 나열하며, DNS 프록시 제공자도 거기에 나타납니다. dig +short example.com과 dig +short example.com @1.1.1.1을 비교하면 응답하는 리졸버와 가로채이는 리졸버가 갈립니다.
확장 활동은 통합 로그에 도달합니다. log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m입니다. 찾는 것은 어느 확장이 시작되었는지, 관심 있는 흐름에 대해 필터가 판정을 보고했는지이지 외울 줄이 아닙니다.
무엇이든 끄기 전에 증상을 좁힙니다
먼저 실패를 분류합니다. 해석되지 않는 이름, 즉시 거부되는 연결, 시간 초과까지 매달리는 연결은 서로 다른 세 관찰이며 책임자도 셋입니다. 해석은 리졸버나 DNS 프록시를 가리킵니다. 즉시 거부는 필터 규칙을 가리킵니다. 침묵은 보통 라우팅, 또는 올라왔지만 전달하지 않는 터널을 가리킵니다.
관리형 Mac에서는 필터가 조직의 것이라고 가정합니다. VPN을 시험하려고 필터를 끄면 관찰하려던 구성 요소를 없애는 셈이고, MDM은 다음 확인에서 흔히 되돌려 놓습니다. 무엇이든 바꾸기 전에 관리자에게 정책 이름을 묻고, 시스템 전체가 아니라 실패한 그 앱으로 시험합니다.
함정이 하나 더 있습니다. VPN을 시험하려고 Private Relay를 끄는 것은 해외 트래픽에 대해 아무것도 알려 주지 않습니다. 릴레이는 애초에 그 트래픽을 덮지 않았기 때문입니다. 각 계층은 자기가 실제로 지배하는 앱에서 시험해야 합니다.
이 목록을 따라가며 처음 실패하는 항목에서 멈춥니다.
scutil --nc list가 기대하는 서비스를 연결됨으로 보여 줍니까?- 터미널에서 보이는 공인 주소가 접속 네트워크가 준 주소와 다릅니까?
- 필터 확장이 설치되어 있고, 실패하는 흐름에 대해 판정을 기록했습니까?
- 실패가 Safari에서만입니까? 그렇다면 터널을 탓하기 전에 릴레이 범위를 확인합니다.
네 가지가 모두 통과하는데도 앱이 실패한다면 문제는 네트워크 계층 위에 있습니다. 프록시 설정, 인증서 신뢰, 또는 앱 수준 허용 목록입니다.