macOS의 서비스 순서는 VPN 경로를 제어하지 않는다

웹사이트에서 무언가 실패하면 동료가 서비스 순서가 있다는 것을 떠올리고 Wi-Fi를 Ethernet 위로 끌어 올린다. 아무것도 바뀌지 않는다. 그 목록은 VPN 목적지가 어디로 가는지 결정한 적이 없기 때문이다. Apple은 VPN 연결을 일반 연결보다 우선하고 이 재정렬에서 제외하므로, 이 스위치는 질문된 것보다 좁은 질문에 답한다. 실패에는 선택된 경로와 리졸버가 필요하고, 새로운 순위가 필요하지 않다.

서비스 순서가 바꾸는 것과 절대 건드리지 않는 것

«서비스 순서 설정»은 시스템 설정, 네트워크의 동작 메뉴에 있으며, 둘 이상이 활성일 때 일반 연결의 순위를 매긴다. 그 순위가 기본 서비스를 고르고, 이것이 기본 경로와 리졸버 동작의 일부를 제공한다. 이는 동등한 것들 사이의 결정이며, 터널 뒤의 사설 목적지를 위한 스위치가 아니다. Wi-Fi와 USB Ethernet 어댑터가 있는 노트북은 이것을 합당한 질문에 답하는 데 쓰고, 그 질문은 터널에 관한 것이 아니다.

VPN 프로필은 포함 경로, 제외 목적지, 때로는 앱별 규칙을 담고, 이것들이 터널에 무엇이 들어가는지 결정한다. 순서 메뉴는 그것들을 편집하지 않는다. 그래서 분할 터널 프로필은 VPN이 여전히 모든 물리 인터페이스보다 위에 있는 채로 공용 트래픽을 밖에 둘 수 있다. Wi-Fi를 맨 위로 끌어도 사설 대역이 도달 가능해지지 않고, 프로필이 이미 포함한 목적지를 막을 수도 없다. 목록은 인터페이스를 옮기고, 프로필은 프리픽스를 옮긴다. Apple은 이 우선순위를 네트워크 서비스 순서 페이지에 문서화하며, 무엇이든 재정렬하기 전에 한 번 읽을 가치가 있다.

기기가 실제로 선택한 경로를 읽어라

특정 주소가 어디로 가는지 route get 10.20.4.10으로 기기에 물어보고, IPv6의 경우 route -n get -inet6 2001:db8::10으로 반복하라. 두 체계는 별개의 결정이므로 동작하는 IPv4 경로는 v6에 대해 아무것도 말해주지 않고, 직접 연결된 서브넷이나 더 구체적인 프리픽스는 어쨌든 일반 연결 레이블을 이긴다. 레이블이 사람들을 계속 오도하는 이유가 바로 이것이다.

출력이 터널 인터페이스를 지목하면 프로필이 목적지를 잡은 것이고 순서는 무관하다. 물리 인터페이스를 지목하면 프로필이 잡지 못한 것이고, 아무리 끌어도 프리픽스 표는 바뀌지 않는다. 두 출력 모두 기기가 사용할 소스 주소도 지목하며, 두 번의 실행을 비교할 때 인용해야 할 필드가 바로 그것이다. 무엇이든 바꾸기 전에 출력을 저장하라. 나중에 남는 유일한 증거다.

DNS는 인터페이스가 아니라 이름으로 해석한다

스코프가 있는 리졸버와 도메인별 리졸버는 답이 인터페이스별이 아니라 이름별로 다를 수 있음을 뜻한다. scutil --dns는 시스템이 실제로 사용하는 리졸버 구성을 스코프 항목까지 포함해 출력한다. 서비스 순서는 어느 서비스가 기본 리졸버를 제공하는지에 영향을 주지만, 이름별 스코프가 그래도 이길 수 있다.

그래서 주소로의 ping은 되는데 호스트 이름이 실패하거나 그 반대일 수 있다. 범인을 고르기 전에 두 출력을 모두 읽어라.

프로필을 바꾸고, 그다음 두 출력을 다시 읽어라

목적지 정책을 바꿔야 할 때 주인은 VPN 프로필이다. 포함 경로, 제외 경로, 그리고 공급자가 지원하는 분할 터널 규칙이다. 대신 인터페이스를 바꾸면 논쟁만 옮겨진다. 원격으로 관리되는 Mac에서는 먼저 현재 네트워크 상태를 저장하라. 닿을 수 없는 기기에서 터널을 잃는 것은 롤백이 아니라 출장이다.

실패를 재현하고, 경로를 읽고, 리졸버를 읽고, 한 가지만 바꾼 다음, 같은 두 출력을 다시 읽어라. 여러 서비스와 프로필을 한꺼번에 뒤섞으면 고친 사람조차 설명할 수 없는 기기가 남는다. 의도한 변경에 두 출력이 일치하면 테스트는 끝난다. 여전히 어긋나면 프로필과 기기가 서로 다른 두 정책을 말하고 있는 것이며, 바꿔야 할 것은 프로필이다.