Mac VPN이 «연결 해제 중»에 멈춤: 실제로 무엇이 돌고 있나

연결 해제는 전환이지 멈춘 터널이 아니다. 해제를 소유한 구성 요소를 확인하고 경로와 DNS를 읽으며, 프로세스를 광범위하게 종료하는 일은 피한다.

«연결 해제 중»은 클라이언트가 터널을 해체하는 동안 보고하는 상태이며 트래픽이 멈췄다는 판정이 아니다. Mac에서는 그 해체가 짧은 순서로 진행되고, 연결을 소유한 구성 요소가 응답한 뒤에야 레이블이 바뀐다. 어느 단계가 도우미, 플러그인, 정책 결정을 기다리면 인터페이스가 사라진 뒤에도 레이블이 그대로 남거나, 메뉴가 아직 표시하는 동안 터널이 계속 전달할 수 있다. 표시를 «해체 진행 중, 결과 불명»으로 다루고 어느 쪽이 사실인지 가려낸다.

두 고장은 메뉴 막대에서는 똑같이 보이고 반대의 대응을 요구한다. 하나는 터널이 여전히 패킷을 나르고 표시만 낡은 경우다. 다른 하나는 터널은 사라졌지만 별도 정책이 트래픽을 막아 둔 경우이며, 이는 대개 의도된 것이다. 경로와 DNS 상태가 어떤 메뉴 조작보다 빠르게 둘을 갈라낸다.

레이블이 추적하는 것

VPN 클라이언트는 작은 상태 기계를 유지하고, 메뉴 막대는 그 투영이다. macOS가 직접 관리하는 연결에서는 그 기계가 시스템 VPN 프레임워크에 있다. 앱이 관리하는 터널에서는 앱과 그 권한 있는 도우미에 있다. 중지의 마지막 단계는 소켓을 닫는 것이 아니다. 터널을 동작하게 만든 것을 놓아주는 일이다. utun 인터페이스, 그것을 가리키던 경로, 클라이언트가 삽입한 확인자 항목, 그리고 연결 중에 트래픽을 막던 방화벽 규칙이나 정책이다.

이 단계들은 분리되어 있어 중지는 어느 하나에서든 막힐 수 있다. 응답을 멈춘 도우미, 두 번째 인터페이스도 요구하는 경로, 다른 프로필이 소유한 확인자 항목은 모두 클라이언트를 기다리게 할 수 있다. 레이블은 클라이언트 자체의 진행에 대한 보고이므로 의도에 관해서는 권위 있고 네트워크에 관해서는 믿을 수 없다.

연결을 소유한 구성 요소를 찾아라

기본 구성에서는 scutil --nc list가 시스템이 아는 서비스와 그 상태를 출력하고, scutil --nc status "Work VPN"가 한 서비스의 세부 정보를 준다. 타사 앱이 보유한 터널은 그 목록에 아예 나타나지 않을 수 있다, 그래서 빈 결과는 아무것도 연결되지 않았다는 증거가 아니다.

프로필이 앱의 것이라면 그 앱의 상태 보기와 문서화된 «연결 해제» 제어를 믿는다. 창을 닫는 것은 중지 요청이 아니다. 백그라운드 도우미가 터널을 소유한다면 아이콘은 사라지고 도우미가 인터페이스를 살려 둔다. Apple의 VPN 설정 참조 는 기본 제어 항목과 관리되는 설정의 출처를 다룬다.

인터페이스, 경로, DNS를 읽어라

세 가지 확인으로 연결을 건드리지 않고 질문의 대부분에 답할 수 있다. 함께 해석하는 것이 중요하다. 어느 하나만으로는 오해를 부른다.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30
  • utun 인터페이스가 있고 기본 또는 분할 경로가 그곳을 지나며 확인자가 공급자를 가리킨다. 터널은 아직 올라가 있고 레이블이 낡았다.
  • utun이 없고 평범한 기본 경로가 있으며 DNS는 DHCP에서 오고 인터넷이 없다. 연결 해제 시 차단하는 정책이 제 역할을 하는 중이다.
  • utun도 경로도 없고 확인자는 여전히 공급자를 가리킨다. 해체가 중간에 멈췄고 DNS가 정리해야 할 잔여물이다.

그다음 터널로만 응답해야 하는 내부 호스트에 요청 하나를, 공개 호스트에 요청 하나를 보낸다. 도달 가능성은 확인을 측정 작업으로 바꾸지 않고 정책과 잔여 상태를 갈라놓는다. 경로가 아직 응답하면 원격 작업을 먼저 저장하고, 원격으로 관리하는 머신에서 네트워크를 바꾸기 전에 두 번째 접속 경로를 마련한다.

광범위한 종료와 프로필 삭제가 왜 오해를 부르나

pppd, racoon, configd 같은 프로세스 이름은 특정 구현에 속한다. 이것을 종료하면 다른 연결에 영향을 줄 수 있고, 경로와 utun 인터페이스를 남기며, 어느 단계에서 막혔는지에 대한 기록도 남기지 않는다. 오래된 프로세스 이름도 현재 프로필을 소유한다는 증거가 아니다.

프로필을 지우고 다시 만드는 것은 막힌 전환을 정리하는 것보다 큰 변경이다. 무엇이 실패했는지 설명하지 않은 채 관리되는 설정과 로컬 신원 자료를 버릴 수 있고, 감독되는 Mac에서는 그저 복원될 수도 있다. 삭제는 정말로 낡은 구성에 남겨 두고 대신 전환을 진단한다.

흔적을 남기는 중지 순서

아래 순서는 연결 자체의 제어를 책임자로 두고 막힘이 다시 오면 기록을 만든다. 표시 문제를 네트워크 변경으로 바꾸지 않게도 해 준다.

  1. 원격 작업을 저장하고, Mac이 원격이라면 다른 방법으로 도달할 수 있는지 확인한다.
  2. 클라이언트 이름, 버전, 프로필을 적는다. log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'로 짧은 구간을 수집한다. 오래된 릴리스는 기록을 덜 남기므로 막힌 직후에 실행한다.
  3. 문서화된 «연결 해제» 제어를 사용하고 기다린 다음 인터페이스와 경로 확인을 반복한다.
  4. 레이블이 낡았지만 터널이 내려가 있다면 그대로 두고 프로세스를 강제하는 대신 클라이언트가 갱신하게 한다.
  5. 해체가 정말로 막혔다면 클라이언트를 다시 시작하고, 작업을 저장한 뒤 Mac 재시동을 계획한다. 관리되는 머신에는 관리자의 절차가 필요하다.

복구 후 평범한 기본 경로와 DHCP 확인자가 돌아왔는지, 차단된 트래픽이 복원되었는지 아니면 의도적으로 여전히 차단되어 있는지 확인한다. 프로필과 클라이언트 버전을 증상과 함께 기록해, 다음 발생이 메뉴 막대의 추측이 아니라 증거에서 시작되게 한다.

관련 글