Mac VPN utun 인터페이스는 살아 있는데 트래픽이 실패한다고요? ifconfig를 확인하세요

VPN에 연결하고 ifconfig를 실행해 주소가 붙은 utun4 항목을 찾았습니다. 필요한 사이트는 여전히 시간 초과가 납니다. 이 간극은 정상입니다: 목록은 가상 인터페이스가 존재함을 증명할 뿐, 클라이언트가 그것을 소유한다거나, 관심 있는 경로가 그것을 선택한다거나, 패킷이 그곳을 통과한다는 것을 뜻하지는 않습니다. 아무것도 설치하기 전부터 utun 항목이 세 개나 있던 노트북에서 잘못된 터널을 탓하며 오후를 보낸 뒤로 저는 인터페이스 이름을 믿지 않습니다.

utun 줄에 실제로 담긴 것

전체 그림이 필요하면 ifconfig -a를 실행하세요. 인수 없이 호출하면 ifconfig는 현재 살아 있는 인터페이스만 출력하므로, 시작에 실패한 터널은 사람들이 티켓에 붙이는 출력에서 빠질 수 있습니다. ifconfig -l는 이름만 돌려주며, 연결 후 새 utun이 나타났는지 확인하는 가장 빠른 방법입니다.

유용한 세부 정보는 단일 인터페이스를 읽는 데 있으며, 연결된 터널은 보통 이렇게 보입니다.

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

세 개의 필드가 답을 담고 있습니다. UP와 RUNNING는 커널이 그 인터페이스를 사용할 의사가 있음을 말해 줍니다. POINTOPOINT에 --> 피어 주소가 더해진 것이 물리 링크가 아니라 터널의 서명입니다. mtu 값은 "연결되다가 멈춘다"는 보고의 한 부류 전체를 설명하는데, utun 인터페이스는 보통 줄어든 MTU로 올라오고, 여러 macOS 빌드에서는 1380이며, 클라이언트가 이를 덮어쓸 수 있기 때문입니다. 필드 목록은 짧아서 Apple이 함께 배포하는 ifconfig 매뉴얼을한 번 훑어보면 충분합니다.

인터페이스 뒤의 프로세스 찾기

ifconfig는 소유 애플리케이션이라는 개념이 없습니다. VPN 클라이언트 두 개, 시스템 서비스, 지난주에 남은 터널이 모두 이 수준에서는 똑같아 보이는 항목을 만듭니다. 제 Mac에서도 utun0부터 utun3까지는 아무것도 설정하기 전부터 있었으며, Continuity와 iCloud Private Relay도 터널을 사용하고, 그중 어느 것도 여러분이 문제를 겪는 연결이 아닙니다.

시스템에 구성을 등록하는 터널이라면 scutil --nc list가 가장 빠른 상관관계이며, 각 구성을 상태 및 서비스 ID와 함께 출력하고 연결된 것은 그렇게 표시됩니다.

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

구성을 등록하지 않고 자체 터널 프로세스를 돌리는 클라이언트는 거기에 절대 나타나지 않습니다. Tunnelblick과 명령줄 openvpn 인스턴스가 그 그룹에 속하므로 프로세스 표도 확인하세요: ps -Ao pid,comm | grep -i openvpn. 프로세스가 터널을 소유하면 utun 번호는 그 프로세스에만 속합니다.

경로를 시험하기 전에 주소를 시험하세요

인터페이스는 쓸 만한 주소 없이 살아 있을 수 있습니다. IPv6 전용 프로필은 링크 로컬 fe80:: 항목만 보여 주고 inet 줄에는 아무것도 없으며, 밀어 넣은 주소를 적용하지 못한 클라이언트도 정확히 같은 모양을 남깁니다. 목적지가 IPv4인데 터널에 IPv4 주소가 없다면 라우팅 질문은 이미 끝난 것입니다.

MTU는 따로 점검할 가치가 있습니다. 이 실패는 크기 문제처럼 보이지 않습니다: 인증은 통과한 뒤 큰 전송이 시작되자마자 조용해지는 연결처럼 보이기 때문입니다. 분할되면 안 되는 프로브를 패킷이 인터페이스 MTU에 맞는 크기로 보내세요(MTU가 1400이면 페이로드는 1372바이트):

ping -D -s 1372 10.8.0.5

응답이 오면 그 크기의 패킷이 터널을 통과한다는 뜻입니다. 작은 핑은 성공하는데 침묵한다면 MTU나 경로에서 ICMP를 떨어뜨리는 무언가를 가리키며, 인증은 인터페이스가 생기기 전에 이미 끝났으므로 아닙니다.

목적지가 터널을 고르는지 증명하세요

중요한 질문은 utun4가 존재하는지가 아니라 특정 주소로 가는 트래픽이 그곳으로 나가는지입니다. route -n get는 단일 목적지에 대해 답하고 사용할 게이트웨이와 인터페이스를 출력합니다:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

같은 명령이 en0를 보고한다면, 스플릿 터널링 구성은 시킨 대로 동작 중이며 인터페이스를 아무리 들여다봐도 바뀌지 않습니다. 다음을 사용하세요 netstat -rn -f inet 기본 경로와 전체 표를 한눈에 볼 필요가 있을 때.

패킷이 실제로 움직이는지는 카운터가 판정합니다. netstat -ib는 utun 항목을 포함해 인터페이스별 패킷 및 바이트 합계를 보고하며, 숫자는 누적되므로 간격을 두고 두 번 읽어 비교하세요:

netstat -ib | grep utun4

애플리케이션이 계속 재시도하는데 카운터가 멈춰 있다면 커널이 패킷을 한 번도 인터페이스에 넘기지 않은 것입니다. 애플리케이션이 계속 실패하는데 카운터가 양방향으로 오른다면 조사는 터널 반대편으로 옮겨 갑니다.

utun이 전혀 나타나지 않을 때

성공한 것처럼 보인 로그인 뒤에 인터페이스 목록이 비어 있다면 보통 터널이 시작되지 않은 것이지, ifconfig가 그것을 숨기는 것이 아닙니다. 클라이언트 자체의 상태를 보고, 그다음 시스템의 상태를 보세요: 한 번도 승인되지 않았거나 업데이트 후 macOS가 비활성화한 Network Extension은 인터페이스를 남기지 않습니다. 승인은 시스템 설정의 로그인 항목 및 확장 기능에 있으며, 거기에 오래된 항목이 있으면 무엇이든 다시 설치하기 전에 한 번 다시 토글할 가치가 있습니다.

utun 번호는 재연결마다 안정적이지 않습니다. 십 분 전에 utun5가 있던 자리에 utun4가 올 수 있는데, 오래된 인터페이스가 해체되고 커널이 다음 빈 인덱스를 내주기 때문입니다. 이름을 고정해 둔 스크립트는 그 순간 조용히 깨집니다; 대신 주소나 경로로 맞추세요.

읽는 쪽은 읽기 전용으로 두세요. sudo ifconfig utun4 down는 터널을 끊고, 전체 터널 프로필에서는 원격 세션까지 함께 가져가는데, 증거를 모으려던 상황에서는 나쁜 거래입니다. 여기서 필요한 것 중 root가 필요한 것은 없으며, 플래그와 주소, 카운터 읽기는 모두 일반 사용자로 됩니다.

다음에 Mac 터널이 말을 안 들으면 점검을 순서대로 하세요: ifconfig -l로 utun이 나타났는지 확인하고, 플래그와 주소, MTU를 읽고, 프로세스에 귀속시키고, route -n get에 목적지가 어느 인터페이스를 쓰는지 묻고, 그다음 netstat -ib가 움직이는지 보세요. 각 단계는 서로 다른 계층을 배제하며, 처음으로 잘못 나오는 지점이 고칠 곳입니다.