iPhone을 충전하려고 연결하고 잠시 뒤 Mac의 VPN이 트래픽을 전달하지 않습니다. 시스템 설정에는 iPhone USB라는 새 서비스가 나타나고, 당장 눈에 보이는 조치는 그것을 삭제하는 것입니다. 그 조치는 자주 틀립니다. 이 서비스는 휴대폰의 개인용 핫스팟일 수도 있고, Xcode와 기기 도구가 휴대폰과 통신하는 데 쓰는 링크일 수도 있으며, 둘의 동작은 충분히 달라서 삭제 전에 식별이 먼저 와야 합니다.

1단계: 휴대폰이 실제로 만든 서비스를 읽기

시스템 설정을 열고 네트워크로 이동해, 휴대폰을 분리한 상태와 연결한 상태의 서비스 목록을 비교합니다. 현재 macOS에서는 서비스가 iPhone USB로 표시됩니다. 활성 상태인지, 서비스 순서에서 어디에 있는지, Mac이 기본 경로에 쓰는지 기록합니다. 서비스 순서가 중요한 이유는 macOS가 목적지에 도달할 수 있는 가장 높은 활성 서비스를 고르기 때문이며, 이름을 아는 서비스를 고르는 것이 아닙니다.

Apple의 개인용 핫스팟 안내 는 그 원리를 설명합니다. 휴대폰에서 개인용 핫스팟이 켜져 있는 동안 USB로 연결하면, 충전만 하려 했더라도 Mac이 휴대폰의 셀룰러 연결을 쓸 수 있습니다. 이것은 VPN 클라이언트의 결함이 아니라, 라우팅 테이블이 Wi-Fi보다 먼저 올라온 서비스를 따르는 것입니다.

서비스가 있지만 휴대폰을 연결한 상태에서 비활성으로 남는다면, 핫스팟이 아니라 충전 전용 연결이나 기기 링크를 보고 있을 가능성이 큽니다. 이 구분을 유지하세요. 다음 두 단계는 아이콘에서 추측하는 대신 그 구분을 시험합니다.

2단계: VPN 끝점이 어떤 경로를 쓰는지 확인

경로는 웹사이트가 아니라 VPN 서버의 확인된 주소로 읽습니다. route -n get 는 읽기 전용이며 커널이 사용할 인터페이스와 게이트웨이를 출력하고, 두 줄 모두 중요합니다.

scutil --dns | head -20
route -n get 203.0.113.10

위 주소는 문서용 자리 표시자입니다. 클라이언트가 표시하는 끝점으로 바꾸고, IPv6 끝점에는 route -n get -inet6 를 사용하세요. 휴대폰을 분리한 상태와 연결한 상태에서 출력을 비교하고, 두 번의 읽기 사이에 경로를 추가하거나 제거하지 마세요. 인터페이스가 en0에서 iPhone USB 인터페이스로 바뀌면 핫스팟 경로가 조회에서 이겼고 VPN의 외부 연결이 이제 셀룰러를 통해 갑니다.

경로 변경이 모든 실패를 설명하지는 않습니다. 새 경로의 MTU가 다르거나 통신사가 프로토콜을 차단하기 때문에, 클라이언트가 서버에는 도달하고도 나중에 터널 내부 트래픽에서 실패할 수 있습니다. 무엇이든 바꾸기 전에 클라이언트 자체의 오류를 읽으세요. 외부 핸드셰이크 시간 초과는 도달 가능성을 가리키고, 설정된 터널이 트래픽을 더 이상 전달하지 않으면 MTU, DNS, 정책을 가리킵니다.

3단계: 핫스팟과 기기 통신 링크 분리

Xcode 15 이후 버전은 USB로 연결된 기기와 링크 로컬 IPv6를 포함하는 네트워크 기반 채널로 통신하므로, 개발용 Mac에 인터넷 접속과 무관한 추가 인터페이스가 나타날 수 있습니다. Apple의 기술 노트 TN3158은 이 동작을 문서화하고 다음을 경고합니다. VPN이나 보안 필터링이 간섭할 수 있다. 이것은 핫스팟 문제의 반대입니다. 휴대폰이 인터넷을 제공해서 VPN이 깨지는 것이 아니라, VPN이 기기 연결을 붙잡아서 깨집니다.

패킷 캡처 없이 두 가지 관찰로 사례를 나눌 수 있습니다. 첫째, 인터페이스에 라우팅 가능한 주소와 기본 경로가 있는지, 아니면 링크 로컬 fe80:: 주소만 있는지 확인합니다. 링크 로컬만 있으면 인터넷 경로가 없다는 뜻입니다. 둘째, VPN을 종료하고 Xcode가 기기에 다시 도달하는지 봅니다. 도달한다면 VPN의 경로나 콘텐츠 필터가 링크 로컬 트래픽을 붙잡는 것이고, 수정은 네트워크 패널이 아니라 분할 터널이나 필터 구성에 속합니다.

ifconfig | grep -A4 -E '^en[0-9]+:'
netstat -rn -f inet6 | head

인터페이스 이름만으로 판단하지 마세요. macOS는 기기가 연결될 때마다 이 인터페이스를 만들고 없애며, en 번호는 실행 중에 할당되므로 같은 Mac도 재시동이나 케이블 교체 뒤에 다른 번호를 보일 수 있습니다.

4단계: 한 번에 하나의 변수로 실패 재현

어떤 서비스가 관련됐는지 알면 고정된 순서로 문제를 재현합니다. 휴대폰을 분리하고 VPN을 연결한 상태에서 시작합니다. 개인용 핫스팟을 끈 채로 휴대폰을 연결하고, 네트워크 목록이 안정될 때까지 기다린 뒤 경로 조회를 다시 실행합니다. 분리하고, 개인용 핫스팟을 켜고, 다시 연결하고 반복합니다. 세 상태 각각의 인터페이스, 게이트웨이, 클라이언트 오류를 적어 두면 기억 대신 비교가 생깁니다.

VPN이 핫스팟 상태에서만 실패한다면 휴대폰을 그 경로에서 멀리 두세요. 충전 중에는 개인용 핫스팟을 끄거나, 서비스 순서에서 iPhone USB 서비스를 Wi-Fi 아래로 옮깁니다. 핫스팟을 끈 경우를 포함해 연결된 모든 상태에서 실패한다면 클라이언트가 네트워크 전환을 어떻게 처리하는지 보세요. 일부 클라이언트는 기본 서비스가 바뀌면 터널을 내리고 재연결이 필요합니다. 그것은 클라이언트 동작이며 휴대폰 결함이 아닙니다.

시도마다 한 가지씩 바꾸세요. 서비스 삭제, VPN 구성 초기화, 클라이언트 재설치를 같은 분에 하면 Mac은 동작하지만 무엇이 고쳤는지 알 수 없게 됩니다.

5단계: 무엇을 남기고 무엇을 확인할지 결정

기기 링크는 건드리지 마세요. Xcode가 쓰는 인터페이스를 제거해도 VPN 경로는 고쳐지지 않고, 다음 연결까지 기기 배포가 깨집니다. 핫스팟 서비스가 정말 필요 없다면 먼저 휴대폰에서 개인용 핫스팟을 끄세요. 그것이 문서화된 제어이며 재시동 후에도 유지됩니다.

서비스를 제거한다면 식별한 것을 제거하고 나서 두 가지를 확인합니다. VPN 끝점으로 가는 경로가 예상 인터페이스로 돌아왔는지, 터널이 인터넷뿐 아니라 내부 주소로도 트래픽을 전달하는지입니다. 서비스 순서와 클라이언트 버전을 기록하세요. macOS 업데이트가 휴대폰이 보이는 방식을 바꿀 수 있습니다.

그다음 실제로 본 실패를 분류합니다. 핸드셰이크 시간 초과, 터널이 올라온 뒤의 MTU 정체, 통신사에서 오는 DNS 응답은 세 가지 다른 문제이며 수정도 세 가지로 나뉩니다. USB 서비스는 세 경우 모두 방아쇠이고, 원인인 경우는 드뭅니다.

관련 글