Mac이 스스로 VPN에 다시 연결됩니다: 요청 시 규칙 확인

VPN 연결을 끊었는데 삼십 초 뒤 메뉴 막대 아이콘이 다시 돌아옵니다. 유령이 아닙니다: macOS의 요청 시 규칙은 네트워크가 바뀌거나 규칙이 다루는 이름을 무언가가 조회할 때 연결을 시작하며, 그 규칙은 한 번도 작성한 적 없는 프로필에 들어 있을 수 있습니다. 아래 점검을 순서대로 하는 편이 클라이언트를 다시 설치하는 것보다 빠릅니다. 규칙은 정책이므로, 맞서기 전에 정책을 읽으십시오.

규칙이 실제로 지켜보는 것

요청 시 규칙에는 두 가지 결정 지점이 있습니다: Mac이 연결된 네트워크와, 무언가가 해석하려는 도메인입니다. 둘 중 어느 쪽이든 터널을 올릴 수 있어서, 내부 이름을 조회하는 것만으로 아무도 열지 않은 VPN이 시작됩니다. 배포에는 사람이 없어도 되는 인증도 필요하므로, 관리되는 플릿에서는 인증서 기반 방식이 주류를 이룹니다.

시스템 정책과 별개로 앱별 재연결 옵션이 있을 수 있으므로, 첫 질문은 어떤 메커니즘이 터널을 다시 연결했는가입니다. 먼저 시스템 정책을, 다음으로 클라이언트를, 마지막으로 연결 끊기를 누른 사람을 확인하십시오. 책임져 보이는 클라이언트 환경설정의 대부분은 그렇지 않습니다. 이 순서가 중요한 이유는 시스템 정책이 기본으로 이기기 때문이며, 클라이언트 수준 설정은 정책이 다루지 않는 경우만 설명할 수 있습니다.

정책의 주인과 제거의 대가

둘 중 하나를 바꾸기 전에 설치된 프로필과 지원되는 클라이언트 제어를 읽으십시오. Mac이 관리되고 있다면 조건이 어딘가에 문서화되어 있으므로, 그 문서를 요청하는 편이 바깥에서 SSID와 도메인을 역설계하는 것보다 낫습니다.

Mac의 신뢰 자료는 그것을 쓰는 다른 모든 서비스와 공유되므로, 폐기는 첫 단계가 아니라 마지막 단계입니다. 규칙을 소유한 프로필을 제거한 다음, 인증서를 건드리기 전에 규칙이 더 이상 작동하지 않는지 확인하십시오. 절반만 제거된 프로필이야말로 사람들이 동작이 무작위라고 결론짓는 이유입니다. 무엇이 설치되었는지 보여 주는 두 명령은 남겨 둘 만합니다:

profiles show -type configuration
scutil --nc list

재연결이 증명하지 않는 것

요청 시 재연결은 틈에 대해 아무것도 말하지 않습니다: 터널이 올라오는 동안 별도 정책이 붙잡지 않으면 트래픽은 여전히 물리 인터페이스로 나갈 수 있습니다. 터널이 존재하기 전에 차단하는 것은 터널을 시작하는 것과 다른 설정입니다. 빠르게 재연결하는 기계도 첫 몇 초 동안은 유출될 수 있습니다.

경로 범위는 세 번째 질문인데, 터널을 시작하는 규칙은 어떤 프리픽스를 나르는지에 대해 아무것도 말하지 않습니다. 재연결이 완전한 커버리지를 뜻한다고 가정하지 말고 연결이 무엇을 라우팅하는지 확인하십시오. 일부러 시험해 보십시오: 클라이언트를 종료하고, 서비스가 멈춘 것을 확인한 다음, 규칙이 지켜야 할 자원을 요청하십시오.

아이콘이 아니라 방아쇠를 기록하십시오

네트워크 참여, 앱 실행, 사설 이름 해석, 잠자기에서 깨어남 등 무엇이 터널을 올렸는지 적으십시오. 순서가 증거이므로, 일어났다는 사실만이 아니라 언제 일어나는지에 주목하십시오. 구체적인 방아쇠는 아이콘 스크린샷보다 값집니다.

그다음 연결이 올라온 뒤 자원을 확인하십시오. 메뉴 막대는 서비스가 돌고 있음을 증명할 뿐, 필요한 목적지가 그 너머로 닿는다는 것을 증명하지 않습니다. 둘은 지극히 평범한 이유로 어긋날 수 있으며, 다른 곳을 가리키는 경로도 그중 하나입니다.

규칙이 잘못된 연결을 시작할 때

시작하면 안 될 때 시작하는 연결은 대개 낡은 프로필, 의도보다 넓은 도메인 조건, 또는 같은 네트워크를 두고 다투는 두 구성에서 옵니다. 세 가지 모두 설치된 구성에 보이며, 서비스를 껐다 켜서 더 분명해지는 것은 없습니다.

방아쇠와 프로필 소유자, 의도한 동작을 정책을 관리하는 사람에게 가지고 가십시오. Apple의 요청 시 동작 문서가 그 대화의 공통 어휘이며, 논쟁보다 짧습니다. 제거가 아니라 정책 변경을 요청하면 양쪽 모두 작동하는 구성을 유지합니다.