종료와 연결 끊기: VPN에서 서로 다른 두 결과

메뉴에는 연결 끊기가 있고 창에는 닫기 버튼이 있으며 작업 관리자에는 작업 끝내기가 있습니다. 각각 VPN을 멈추는 방법처럼 보이지만, 각각 컴퓨터를 다른 상태로 남길 수 있습니다. 하나는 터널을 멈추고 차단을 그대로 두고, 다른 하나는 정상 종료의 일부로 모든 것을 정리하며, 세 번째는 백그라운드 구성 요소가 계속 실행되는 동안 화면만 숨길 수 있습니다. 이것들을 동의어로 취급하는 것이 바로 개인정보 보호 시험이 무슨 일이 있었는지에 대해 잘못된 결론에 도달하는 경로입니다.

어느 것이 어느 것인지 알 수 있는 유일하게 신뢰할 만한 곳은 클라이언트 문서입니다.

네 가지 제어, 어쩌면 네 가지 동작

연결 끊기는 보통 클라이언트를 상주시킨 채 터널을 해체하므로, 서비스나 트레이 구성 요소 또는 kill switch 규칙이 클릭 후에도 살아남을 수 있습니다. 그러면 많은 클라이언트가 트래픽 차단을 계속하는데, 클라이언트가 있는 동안 기기가 직접 접근으로 되돌아가서는 안 된다는 정책 때문입니다. 이 동작은 고장 난 네트워크처럼 보이지만 의도된 보호입니다.

종료는 애플리케이션을 끝내기 위한 것이며, 제대로 동작하는 클라이언트는 나갈 때 자신의 규칙을 제거합니다. 일부 설계는 대신 정책을 적용하는 별도 도우미를 남기는데, 이는 결함이 아니라 선택입니다. 창 닫기는 터널에 정의된 영향이 없는 화면 동작이고, 제공되는 경우 일시 중지는 자체 규칙을 가진 네 번째 동작입니다.

서버 측 장애는 완전히 다섯 번째 경로이며, 사용자가 실제로 가장 자주 마주치는 것이 바로 이것입니다.

각 동작 전후로 상태를 읽으세요

동작 전에 프로세스 목록, 서비스 상태, 방화벽 규칙을 기록하고 그 직후에 같은 기록을 반복하세요. 두 목록을 비교하면 인터페이스의 설명에 의존하지 않고 그 제어가 실제로 무엇을 했는지 알 수 있습니다.

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

규칙이 프로세스와 함께 사라진다면 클라이언트가 소유한 것입니다. 프로세스가 사라졌는데도 규칙이 남아 있다면 다른 무언가가 정책을 적용하고 있습니다. 그 구성 요소를 찾는 일이 어떤 변경보다 먼저이고, 멈춘 화면은 시스템 서비스에 대해 아무것도 말해 주지 않으므로 같은 순간에 서비스 상태도 기록하세요.

수동 연결 끊기는 충돌이 아닙니다

연결 끊기는 의도된 종료 경로를 실행하고, 충돌은 그것을 건너뜁니다. 따라서 한쪽의 결과는 다른 쪽에 적용되지 않으므로, 메뉴 항목을 사용한 시험은 클라이언트가 죽었을 때의 동작에 대한 주장을 뒷받침할 수 없습니다.

마찬가지로 충돌은 승인된 일시 중지에 대해 아무것도 알려 주지 않습니다. 이 세 가지 질문을 시험 계획과 이후에 적는 모든 것에서 분리해 두세요. 종료 경로는 정상 종료가 충돌이 남긴 규칙을 제거할 수 있는 이유도 설명합니다. 같은 버튼, 다른 코드, 다른 증거입니다.

정말로 필요한 사용 불가 상태를 고르세요

터널이 내려가 있을 때마다 트래픽이 차단된 채로 있어야 한다면, 관심 있는 특정 동작 중에 알려진 목적지로 무해한 트래픽을 보내 그 요구 사항을 확인하세요. 기기 전체에 대한 적용은 이름이 암시하는 것보다 좁은 경우가 많으므로 앱 예외와 로컬 네트워크 예외도 포함하세요. 그런 다음 오래된 상태가 나타나는 때가 대개 그때인 만큼, 재부팅 후에 무슨 일이 일어나는지 확인하세요.

목표가 평범한 직접 접근이라면 프로세스를 죽이거나 방화벽 전체를 끄는 대신 문서화된 제어를 사용하세요. 중단된 종료가 남긴 오래된 규칙은 의도적인 잠금과는 다른 문제이며 다른 복구가 필요합니다.

어느 구성 요소가 멈췄는지, 즉 터널인지 보이는 애플리케이션인지 아니면 정책을 적용하는 계층인지 적으세요. 그 한 문장이 이 제어들이 만드는 혼란의 대부분을 막습니다.