VPN 목록을 열고 다른 저장된 항목을 고르면 새 출구 주소가 되고 나머지는 그대로인 깔끔한 교체를 기대합니다. 바로 이 가정을 먼저 버려야 합니다. macOS에서 저장된 VPN은 프리셋이 아니라 완전한 네트워크 서비스이므로, 서비스를 바꾸면 라우팅과 DNS, 인증이 동시에 달라질 수 있습니다. 메뉴 막대는 어떤 서비스가 활성인지 알려 줄 뿐, 그 아래 터널이 의도한 대로인지는 알려 주지 않습니다.

저장된 목록은 프로필 선택기가 아니다

시스템 설정 > 네트워크의 각 항목은 별도의 서비스이며, 자체 서버 주소와 계정, 인증 방식, DNS 서버, 그리고 'VPN 연결을 통해 모든 트래픽 보내기' 같은 옵션을 가집니다. 이전 버전에서는 시스템 환경설정에 같은 목록이 있습니다. 두 항목이 같은 호스트 이름을 가리켜도 다르게 동작할 수 있는 것은,프로토콜이나 클라이언트 확장이 터널 구축 방식을 결정하기 때문입니다.

서드파티 클라이언트는 별도 목록을 유지합니다. Tunnelblick은 자체 폴더에서 구성을 읽고, WireGuard는 자체 터널 목록을 두며, OpenVPN Connect는 프로필을 앱 안에 저장합니다. 어떤 것은 구성을 시스템에 등록하고, 어떤 것은 모든 것을 앱 안에 두어 내장 목록에 전혀 나타나지 않습니다. 따라서 '저장된 것으로 전환'은 프로필을 어떤 앱이 소유하느냐에 따라 다른 동작을 뜻합니다.

scutil --nc list 시스템 구성에 등록된 VPN 서비스를 따옴표로 묶인 이름과 함께 출력합니다. 전환을 스크립트로 만들 때는 바로 그 이름을 쓰고, 목록이 모든 서드파티 터널을 포괄한다고 가정하지 마십시오.

전환이 실제로 바꾸는 것

활성 서비스가 바뀌면 네 가지가 함께 움직입니다. 그 서비스가 모든 트래픽을 보낸다면 기본 경로가 새 터널을 따르고, 리졸버 목록은 서비스가 지정한 DNS 서버로 바뀌며, 새 연결은 새 터널 주소를 출발지로 삼고, 사용되는 자격 증명은 새 서비스의 것이 됩니다. 네이티브 구성과 앱 프로필은 같은 게이트웨이에서 끝나더라도 서로 바꿔 쓸 수 없습니다.

What you assumeWhat the system does
Same server name means same tunnelProtocol, certificate and account are per service
All traffic follows the active VPNOnly when Send all traffic over VPN is on
DNS switches with the VPNOnly if that service defines DNS servers
Disconnect ends the connectionOn Demand or a management profile can reconnect
Open sessions survive the switchTCP sessions tied to the old address stall

사람들을 헷갈리게 하는 것은 DNS 부분입니다. macOS는 리졸버 순서를 유지하고,scutil --dns 어떤 리졸버가 어느 인터페이스에서 쓰이는지 보여 줍니다. DNS 서버를 설정하지 않은 VPN 서비스는 Wi-Fi 리졸버가 계속 응답하게 둘 수 있어서, 새 공인 주소를 얻고도 DNS 동작은 예전 그대로여서 전환이 반쯤만 된 것처럼 결론 내리게 됩니다.

예전 구성이 다시 돌아오는 이유

연결을 끊었는데 같은 서비스가 잠시 뒤 다시 연결된다면 먼저 On Demand를 보십시오. 요청 시 연결 규칙은 앱이 일치하는 도메인을 확인할 때 서비스를 되살릴 수 있고, 관리 프로필도 같은 규칙을 강제할 수 있습니다. 항목을 지우는 것으로는 거의 해결되지 않는데, 프로필로 설치한 구성은 보통 다음 프로필 갱신 때 되돌아오고 수동 구성은 서비스가 사라져도 암호를 Keychain에 남길 수 있습니다.

두 번째 서비스를 시작한다고 해서 첫 번째가 항상 멈추지는 않습니다. 클라이언트와 프로토콜에 따라 터널 두 개와 경로 두 세트가 남을 수 있고, 어느 쪽이 트래픽을 나르는지는 마지막에 누른 아이콘이 아니라 서비스 순서와 경로의 구체성이 결정합니다. 전환이 일어났다고 보기 전에 인터페이스를 확인하십시오.

체크 표시가 아니라 터널을 확인하라

설정을 건드리기 전에 시스템 자체의 관점을 따라가 보십시오.scutil --nc status "Name" 시스템이 무엇이라고 보는지 알려 주고,ifconfigutun 인터페이스에 주소가 있는지 보여 주며,netstat -rn -f inet 기본 경로가 어디를 가리키는지 보여 주고,scutil --dns 실제로 사용 중인 리졸버를 보여 주니, 그다음 새 연결을 열어 출구 주소를 확인하십시오. 이미 로그인한 페이지는 예전 터널에 묶인 소켓을 계속 쓸 수 있기 때문입니다.

DNS가 여전히 로컬 네트워크에서 응답한다면 서비스의 설정된 서버와 리졸버 목록을 비교하십시오. 기본 경로가 여전히 물리 인터페이스를 가리킨다면 그 서비스는 분할 터널이거나 완전히 연결되지 않은 것입니다. 둘 다 구성의 결과이지 고장 난 클라이언트의 증거가 아닙니다.

놀라움을 피하는 전환 순서

  1. 현재 서비스와 프로필이 이를 관리하는지 기록하십시오.
  2. 두 터널이 공존할 수 없다면 먼저 연결을 끊으십시오.
  3. 대상에 연결하고 '연결 중'이 아니라 '연결됨'을 기다리십시오.
  4. 기본 경로와 리졸버 목록, 새 출구 주소를 확인하십시오.
  5. 긴 세션을 유지하는 앱을 다시 시작하십시오.

새 항목이 그 점검을 통과할 때까지 예전 항목을 남기고, 같은 레이블이 다음 장애의 원인을 밝히기 어렵게 만들므로 각 항목에 서로 다른 이름을 붙이십시오. Apple의 Mac 도움말은 네이티브 쪽을Mac에서 VPN 연결 설정하기에서 설명하며, 관리되는 구성을 편집하기 전에 확인해야 할 참고 자료입니다.

선택이 되돌아가면 먼저 정책이나 On Demand로 다루십시오. 구성의 소유자와 자동 연결 설정 여부를 확인한 뒤, 서비스를 바꾸는 것인지 프로필과 싸우는 것인지 판단하십시오.

관련 글