Mac VPN이 연결 끊기를 누른 직후 스스로 다시 연결됩니다

연결 끊기를 누르면 작동하지만, 십 초 뒤에 터널이 어쨌든 돌아옵니다. 그 루프는 VPN 클라이언트가 잘못 동작하는 경우는 드물고, 항상 “내려갔나?”라는 한 가지 질문만 하고 연결로 답하던 복구 스크립트입니다. 사용자가 답한 질문과 시스템이 보고하는 질문을 분리하면, 수정은 더 긴 대기 대신 작은 상태 조각이 됩니다.

두 가지 질문, 하나가 아님

이 프로필이 지금 연결되어 있어야 하는가, 그리고 시스템은 현재 무엇을 보고하는가? 서로 다른 소유자를 가진 서로 다른 질문이며, 복구 정책은 행동하기 전에 둘 다 필요합니다. 의도는 도구가 결정하고 기억하는 것입니다. 관찰된 상태는 플랫폼이 알려 주는 것입니다.

행들을 사례 목록이 아니라 정책으로 읽으십시오. 두 번째 행은 대부분의 스크립트가 빠뜨리는 행이며, 모니터를 자기가 옳다고 우기는 기계와 구분하는 유일한 행입니다.

관찰된 상태는 선호가 아닙니다

Apple의 Network Extension 상태 모델은 connecting, connected, disconnecting, disconnected, recovery 상태를 보고합니다. 다섯 가지 모두 연결을 설명합니다. 그중 어느 것도 “사용자가 이 프로필을 일시 중지된 채로 두라고 요청했다”고 말하지 않는데, 그것은 연결 상태가 전혀 아니기 때문입니다. 그 프레임워크 위에 구축되지 않은 클라이언트는 자체 지원 제어와 상태 호출을 노출하며, 같은 경계선을 자기 어휘로 긋습니다.

결과적으로 연결 끊김 상태는 결코 단독으로 해석될 수 없습니다. 그것은 적어도 세 가지 중 하나를 뜻하는데, 터널이 끊겼거나, 사용자가 멈췄거나, 시스템이 시도 사이에 있는 것입니다. 오직 자신의 의도 기록만이 그것들을 구별할 수 있습니다. 그 기록을 적어 두고, 재부팅을 견뎌야 한다면 재시작 사이에 보관하고, 나중에 로그 줄에서 추론하는 대신 사용자가 행동하는 그 순간에 갱신하십시오.

scutil --nc list
scutil --nc status "Office VPN"

이 프로필을 시작할 수 있는 다른 주체

헬퍼가 약속한 일시 중지는 같은 프로필의 다른 소유자만큼만 강합니다. On Demand 규칙, 관리형 구성 또는 두 번째 클라이언트가 모두 연결을 요청할 수 있으며, 헬퍼는 기록된 그대로 동작하는 동안에도 고장 난 것처럼 보일 것입니다.

프로필을 시작할 수 있는 모든 메커니즘을 찾으십시오 일시 중지를 존중하겠다고 약속하기 전에, 어느 것이 이기는지 적어 두십시오. 관리형 서비스가 개인 일시 중지 옵션을 의도적으로 제공하지 않는다면, 그것은 정책에 대한 관리자의 결정이지 스크립트가 관리와 싸워 메워야 할 틈이 아닙니다.

재시도를 지루하게 만드십시오

시도 횟수를 제한하고 각 시도가, 네트워크가 돌아왔거나, 게이트웨이가 응답했거나, 자격 증명 프롬프트가 완료된 것처럼 바뀐 무언가에 반응하게 하십시오. 사용할 수 없는 게이트웨이, 만료된 신원, 거부된 두 번째 요소에는 세 가지 다른 응답이 필요하지만, 촘촘한 루프는 세 가지 모두에 같은 응답을 줍니다.

빠른 재시도가 화면에서 실제로 무엇을 만들어 내는지 보십시오. 사용자가 닫는 반복 대화 상자는 하나의 명확한 실패 메시지보다 나쁘며, 사람들에게 프롬프트를 읽지 않고 클릭하게 훈련시킵니다.

일시 중지와 트래픽 정책은 별개의 약속입니다

사용자가 일시 중지한 터널은 종종 트래픽을 의도적으로 차단된 채로 두는데, 그것이 kill switch 스타일 정책의 요점입니다. 즉 일시 중지는 정확히 한 가지, 복구가 멈춘다는 것만 약속해야 합니다. 네트워크가 허용하는 것을 조용히 바꾸어서는 안 됩니다.

트래픽 동작은 따로 결정하고, 일시 중지 컨트롤 옆에 문서화하며, 터널이 일시 중지되었든 실패했든 없든 일관되게 유지하십시오. 그렇지 않으면 사용자는 연결 끊기를 누르면 예측할 수 없는 일이 일어난다고 배우게 되고, 다음 지원 티켓은 “가끔 뚜렷한 이유 없이 작동을 멈추는” 네트워크에 관한 것이 됩니다.