블로그로 돌아가기
·9분 분량·productdevbook

macOS에서 VPN 대역폭을 모니터링하는 방법

macOS에서 VPN 터널이 실제로 무엇을 실어 나르는지 확인하는 방법입니다. 앱별 트래픽, 암호화 오버헤드, 누수 탐지를 다룹니다.

  • VPN
  • macOS
  • Bandwidth
  • Privacy

VPN에 연결하고, 올바른 국가를 보고하는 웹 점검을 실행하고, 이제 모든 것이 터널링된다고 가정합니다. 이틀 후, 앱 중 하나가 — 가령 오래된 채팅 클라이언트나 동기화 에이전트 — 그 시간 내내 터널을 완전히 무시하고 공용 인터넷과 직접 통신해 왔음을 알아챕니다. VPN은 켜져 있었습니다. 누수는 터널이 올라오기 전에 물리적 인터페이스에 바인딩되어 절대 놓지 않았던 프로세스에 있었습니다.

macOS에서 VPN 대역폭을 모니터링하는 것은 일부는 VPN이 제 일을 하고 있는지 확인하는 것이고, 일부는 조용히 우회하는 앱을 잡는 것입니다. 이 글은 utun 인터페이스가 실제로 무엇인지, 내장 도구로 VPN 트래픽을 어떻게 읽는지, 누수를 어떻게 감지하는지, 터널이 추가하는 오버헤드를 어떻게 측정하는지 다룹니다. VPN 자체 대시보드가 충분히 알려주지 않아서 Mac에서 VPN 대역폭 모니터링을 검색해 왔다면, 아래의 도구 모음이 더 어려운 질문에 답합니다.

utun 인터페이스란 무엇인가

VPN 클라이언트가 macOS에 연결할 때, 보통 utun0, utun1, utun2 등의 이름으로 가상 인터페이스를 만듭니다. ("utun"은 "user tunnel"의 약자입니다.) VPN 프로세스는 OS가 그 인터페이스로 라우팅하는 패킷을 읽고, 암호화 및 캡슐화한 다음, 결과 래핑된 패킷을 물리적 인터페이스(보통 Wi-Fi의 경우 en0)를 통해 내보냅니다.

현재 무엇이 올라와 있는지 보려면 터미널에서 다음을 실행하세요.

ifconfig | grep -E "^(en|utun)" -A 3

다음과 같은 것이 보일 것입니다.

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
        inet 10.8.0.6 --> 10.8.0.1 netmask 0xffffff00

en0은 실제 네트워크입니다. utun0은 VPN입니다. 일부 VPN 클라이언트는 여러 utun 인터페이스(데이터 평면용 하나, 제어용 하나)를 만듭니다. 일부는 iOS 스타일 개인용 핫스팟 터널과의 충돌을 피하기 위해 utun9 이상을 만듭니다.

nettop으로 Mac VPN 대역폭 트래픽을 모니터링하는 방법

nettop은 macOS에 내장되어 있으며, 프로세스가 어느 인터페이스를 사용하는지 보는 가장 직접적인 방법입니다. 관련 호출:

sudo nettop -P -m route

이는 경로별로 그룹화된 각 프로세스의 연결을 보여줍니다. VPN을 통해 통신하는 프로세스는 utun 인터페이스를 통해 트래픽을 보여주고, 터널을 우회하는 프로세스는 en0(또는 이더넷이라면 en1)를 통해 보여줍니다.

1분 동안 nettop을 보고 물어보세요. 어떤 앱이 utun0을 사용하고 어떤 앱이 en0을 사용하는가? 모든 것이 터널을 통과하기를 의도했는데 en0에 Slack이 보인다면 그것이 누수입니다.

-P 플래그는 프로세스별로 집계합니다. -m route는 경로 열을 보여줍니다. 바이트 수에는 -x를 추가하세요. 주기적 새로 고침에는 -c와 지연을 추가하세요, 예를 들어 nettop -P -c 2.

ova가 VPN 트래픽에 대해 보여주는 것

ova 같은 앱별 모니터는 nettop이 보는 것과 같은 커널 통계를 보고 시간에 걸쳐 합산합니다. ova에서 "Slack"에 귀속된 대역폭은 Slack이 보낸 모든 것을 포함합니다. en0이든 utun0이든 프로세스별 합계를 바꾸지 않습니다. 그래서 ova는 "Slack이 얼마나 사용했는가"에 깔끔하게 답합니다. 현재 앱별 숫자를 인터페이스별로 분해하지는 않습니다. 그 수준의 세부사항이 필요하다면 nettop이 도구입니다.

대부분의 VPN 사용자에게는 그것으로 충분합니다. 보통 답을 원하는 질문은 다음과 같습니다.

  • "내 VPN 클라이언트 자체가 예상하는 대역폭을 사용하고 있는가?"
  • "지난 한 시간에 무언가 급증했는가?"
  • "지금 가장 무거운 앱은 어느 것인가?"

ova는 도우미 프로세스 접기와 함께 한눈에 세 가지 모두를 알려주므로, Slack 도우미 PID는 별도의 행으로 나타나지 않습니다. VPN 클라이언트 자체(Tailscale, Mullvad, ProtonVPN, NordVPN 등)는 자체 라인으로 나타나며, 그 숫자는 물리적 링크를 통해 나가는 래핑/암호화된 합계입니다.

앱별 기록
ova는 스크럽 가능한 기록을 유지하므로 VPN 활성화 전후의 대역폭을 비교할 수 있습니다. 차이가 암호화 오버헤드입니다.

누수 감지

VPN 누수는 앱의 트래픽이 터널을 우회하고 인터넷으로 직접 가는 경우입니다. 원인:

  • 앱이 VPN이 올라오기 전에 경로를 캐시했고 여전히 사용하고 있습니다.
  • VPN이 특정 목적지(LAN, 멀티캐스트, 특정 서버로의 DNS)를 라우팅하지 않습니다.
  • macOS의 "로컬 네트워크 제외" 토글이 그것이 말하는 일을 하고 있습니다.
  • VPN이 분할 터널링되어 있고 특정 앱이 우회 목록에 있습니다.
  • IPv6가 활성화되어 있고 VPN이 IPv4만 라우팅합니다(흔한 원인).

진단 루프:

  1. VPN이 연결된 채로 nettop -P -m route를 실행하고, 터널링되었어야 할 프로세스가 en0 트래픽을 보여주는지 지켜보세요.
  2. 프로세스별 대역폭에 대해 ova와 교차 점검하세요. 프로세스가 ova에서 트래픽을 보여주지만 nettop에서 utun 행이 없다면 누수되고 있는 것입니다.
  3. 네트워크 수준에서 확인하세요. 브라우저에서 ipleak.net 또는 dnsleaktest.com을 방문하세요. 보고된 IP는 집/사무실이 아니라 VPN 출구여야 합니다.
  4. 특히 DNS의 경우 scutil --dns | grep nameserver를 실행하세요. 나열된 네임 서버는 ISP의 것이 아니라 VPN의 것이어야 합니다.

특히 IPv6의 경우 가장 안전한 설정은 IPv6를 명시적으로 라우팅하는 VPN이거나 연결되어 있는 동안 시스템 전체에서 IPv6를 비활성화하는 것입니다. 네트워크별 비활성화: 시스템 설정 > 네트워크 > 내 네트워크 > 세부사항 > TCP/IP > IPv6 구성 > 링크 로컬만.

VPN 오버헤드 측정

VPN은 두 가지 방식으로 오버헤드를 추가합니다. 처리량(실제 회선 속도의 더 적은 부분을 얻음)과 지연 시간(각 왕복이 추가 홉을 거침)입니다.

처리량 오버헤드

암호화 세금은 프로토콜에 따라 다릅니다.

  • WireGuard: 빠른 링크에서 일반적으로 5~10% 오버헤드. Apple Silicon에서 하드웨어 가속됨.
  • OpenVPN: 15~30% 오버헤드. CPU 바운드, 높은 속도에서 WireGuard보다 느림.
  • IKEv2/IPsec: 10~20% 오버헤드. macOS 네이티브 지원.
  • 독점 프로토콜(Lightway, WireGuard 기반의 NordLynx 등): 대략 WireGuard 수준의 효율성.

측정하려면: VPN을 끈 채로 속도 테스트를 실행하고 결과를 기록하세요. VPN을 켠 채로 같은 테스트를 끄기 테스트 엔드포인트와 같은 메트로 지역의 서버로 실행하세요. 비율이 오버헤드입니다. 두 테스트 동안 ova를 사용하세요. 속도 테스트 클라이언트에 대해 보여지는 앱별 트래픽은 애플리케이션 계층 처리량이어야 합니다. VPN 테스트 동안 시스템 전체 속도는 암호화 프레임 때문에 더 높습니다.

지연 시간 오버헤드

VPN을 끄고 ping 8.8.8.8을 실행하고 정상 상태 RTT를 기록하세요. VPN을 연결하고 다시 ping 8.8.8.8을 실행하세요. 차이가 암호화하고, VPN 출구로 이동하고, 돌아오는 왕복 비용입니다. 일반적인 수치:

  • 같은 도시의 VPN 출구: +5 ~ +15ms.
  • 다른 국가의 VPN 출구: 지리에 따라 +50 ~ +200ms.
  • 다른 대륙의 VPN 출구: +150 ~ +400ms.

이는 대부분 피할 수 없는 물리입니다. 도쿄로 터널링하고 왕복 비용을 들이지 않을 수는 없습니다.

VPN 자체의 대역폭 사용 식별

VPN 클라이언트 프로세스 자체는 ova에서 자체 행으로 나타납니다. "Mullvad VPN," "Tailscale," "ProtonVPN" 등. 거기서 보는 숫자는 물리적 링크를 통해 나가는 암호화된 래핑된 합계입니다. "VPN이 얼마나 실제 인터넷 대역폭을 소비하는가"에 대한 적절한 숫자입니다.

유용한 점검: 어느 순간이든 VPN의 보고된 대역폭은 그것을 사용하는 다른 모든 앱의 합에 암호화 오버헤드를 위한 작은 비율을 더한 것과 대략 같아야 합니다. 크게 다르다면 다른 무언가가 있는 것입니다 — 분할 터널링, 누수, 또는 VPN 클라이언트가 유지 보수 작업(키 회전, 피어 발견)을 하고 있는 것.

ova 작동 모습 보기

한눈에 볼 수 있는 메뉴 바 대역폭 모니터 — 로컬, 서명, 약 3MB.

macOS용 다운로드

항상 켜진 VPN: 함정

여러 VPN 클라이언트는 터널이 끊기면 모든 트래픽을 차단하는 "킬 스위치" 또는 "항상 켜짐" 모드를 제공합니다. 유용하지만 의외의 일이 있습니다.

  • 절전에서 깨어난 후 첫 몇 초는 터널이 다시 설정되기 전에 차단되지 않은 트래픽이 있을 수 있습니다. 일부 클라이언트는 이를 명시적으로 잡습니다. 다른 것은 그렇지 않습니다.
  • Wi-Fi 네트워크 변경(집에서 커피숍으로 이동)은 짧은 끊김을 트리거합니다. 킬 스위치가 잡아야 하지만 구현은 다양합니다.
  • 일부 앱은 적극적인 재연결 로직을 가지고 있습니다. 터널이 다운되어 있을 때 100ms마다 재시도합니다. 그것은 터널이 돌아왔을 때 재연결 시 대역폭 급증입니다.

VPN을 켠 채로 절전에서 깨어난 직후에 ova를 지켜보세요. 패턴은 보통 다음과 같습니다. VPN 클라이언트 자체가 다시 핸드셰이크하면서 작은 급증을 보이고, 5~30초 안에 개별 앱이 자체 소켓을 재연결하면서 급증하기 시작합니다. 깨우기 시 200MB 급증을 본다면, 그것은 일반적으로 한꺼번에 따라잡는 Slack/Discord/iMessage입니다.

앱별 라우팅과 분할 터널

일부 VPN 클라이언트는 특정 앱만 터널을 통해 라우팅하는 것을 지원합니다. 사용 사례는 "내 토렌트 클라이언트는 Mullvad를 통해 보내되, Slack은 직접 가게 해서 화상 통화에 VPN 지연 시간이 추가되지 않게 하라"입니다.

nettop으로 분할 터널 규칙 검증:

sudo nettop -P -m route

분할 터널링된 앱은 en0 트래픽만 보여야 합니다. 터널링된 앱은 utun만 보여야 합니다. 같은 프로세스에 둘 다 나타난다면 규칙이 깔끔하게 강제되지 않는 것입니다. 보통 앱이 규칙 변경 이전의 장수 소켓을 잡고 있기 때문입니다. 앱을 다시 시작해 정리하세요.

여러 VPN 연결 모니터링

파워 유저는 때때로 두 개의 VPN을 동시에 실행합니다. 예를 들어, 내부 회사 서비스에 접근하기 위한 Tailscale에 더해 일반 인터넷 프라이버시를 위한 상업용 VPN(Mullvad, Proton). macOS는 라우팅 테이블을 통해 이를 처리합니다. 더 구체적인 경로(Tailscale의 100.64.0.0/10)가 더 넓은 것(상업용 VPN의 기본 경로)보다 이깁니다.

ifconfig에서 여러 utun 인터페이스를 볼 것입니다. 라우팅 테이블을 읽으려면 netstat -rn | head -30을 사용하세요. 처음 일치하는 경로가 이깁니다. ova는 어느 터널을 구별하지 않고 총 앱별 대역폭을 보여줍니다. 그것을 위해서는 nettop의 -m route 뷰가 참조입니다.

다음에 할 일

Mac VPN 대역폭을 처음부터 끝까지 모니터링하는 10분 감사:

  1. VPN을 연결합니다.
  2. 메뉴 바에서 ova를 열고 현재 활성 앱을 기록합니다.
  3. 터미널에서 sudo nettop -P -m route를 실행합니다.
  4. 교차 점검: ova에서 의미 있는 대역폭을 보여주는 모든 앱은 nettop에서 utun0(또는 VPN이 사용하는 어떤 utun이든) 아래에 연결이 나타나야 합니다. 그 프로세스의 어떤 en0 트래픽이든 누수 후보입니다.
  5. ipleak.net을 방문해 IP와 DNS가 VPN을 통해 나가는지 확인합니다.
  6. 끊고, 속도 테스트를 실행하고, 다시 연결하고, 또 다른 테스트를 실행합니다. 오버헤드를 계산합니다.

이를 통해 VPN이 실제로 생각하는 일을 하고 있는지, 오버헤드가 실제로 얼마나 비용을 들이는지, 어떤 앱을 주시할지 알게 됩니다. 그것이 VPN 클라이언트의 메뉴 바에 있는 "연결됨" 표시기보다 더 강한 답입니다.