VPN 앱이 충돌했습니다: 킬 스위치는 아직 켜져 있나요?

클라이언트 창이 사라지고, 트레이 아이콘도 없어지고, 브라우저가 로드되거나 되지 않는, 사용자가 가장 먼저 보는 상황에서 시작하세요. 그 관찰만으로는 차단이 살아남았는지 알 수 없습니다. 답은 어느 구성 요소가 규칙을 들고 있는지, 그 구성 요소가 창과 함께 죽었는지, 플랫폼이 시행을 앱 밖에 두는지에 달려 있습니다. 창에서 프로세스로, 다음 방화벽으로, 다음 실제 경로로 나아가세요.

먼저 재부팅하지 마세요, 재부팅은 보통 증거를 파괴하기 때문입니다.

아직 실행 중인 것부터 시작하세요

무엇이든 만지기 전에 프로세스 목록을 여세요. 데스크톱 클라이언트는 보통 UI 프로세스와 서비스 또는 데몬으로 나뉘고, 전자의 충돌이 후자를 반드시 멈추지는 않습니다. Windows에서는 서비스가 아직 목록에 있을 수 있고, Linux에서는 유닛이 아직 활성일 수 있으며, Android에서는 동의가 주어지면 터널이 시스템 소유가 됩니다. 이 세 가지 사실을 그 순서로 읽으세요.

데몬이 살아 있으면 터널도 살아 있을 가능성이 크고, 사라진 창은 겉모습일 뿐입니다.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

차단은 앱이 아니라 시행하는 쪽에서 읽으세요

클라이언트가 방화벽 규칙을 삽입해 킬 스위치를 구현한다면, 그 규칙은 운영체제에 속하고 규칙을 만든 프로세스가 끝난 뒤에도 남습니다. 그러면 충돌은 끌 인터페이스도 없이 차단된 상태로 남겨 두며, 이는 보호보다 고장 난 네트워크처럼 보입니다. 반대로 차단이 클라이언트 자체의 패킷 경로 안에 있다면, 프로세스를 죽이는 순간 차단도 사라집니다.

Android는 이를 또 다르게 다루는데, lockdown이 있는 always-on VPN은 플랫폼 설정이므로 차단은 앱 프로세스와 무관하게 유지되고, 시스템이 서비스를 다시 시작할 수 있습니다. 데스크톱 클라이언트와 같다고 가정하지 말고 정확한 동작은 플랫폼 문서를 확인하세요.

정상 종료와 충돌을 구분하세요

일반적인 Quit은 보통 클라이언트의 종료 경로를 실행해 규칙을 제거하고 터널을 의도적으로 닫습니다. 충돌은 그 경로를 건너뛰고 시행자가 이미 설치한 것을 남깁니다. 차이는 프로세스 종료에 대한 규칙 타임스탬프와, 소유자 없는 오래된 터널 인터페이스가 아직 있는지에서 드러납니다.

그 차이가 복구 방법을 정하는데, 정상 종료는 새 연결이 필요할 수 있고, 충돌은 남은 규칙을 클라이언트의 지원되는 복구 작업으로 제거하는 것 이 필요할 수 있습니다.

다른 제어를 깨지 않고 복구하세요

문서화된 워크플로로 클라이언트를 다시 시작한 뒤 요구 사항의 양쪽, 즉 터널이 트래픽을 나르고 차단이 필요한 때 여전히 적용되는지를 모두 확인하세요. 연결을 되찾으려고 방화벽 전체를 비우면 무관한 제어까지 사라지므로, 그 거래는 좀처럼 남는 장사가 아닙니다.

충돌이 반복되면 클라이언트 버전, 플랫폼 빌드, 공급업체가 요청하는 범위의 로그를 모으세요. 다른 계정의 클라이언트 프로필, 개인 키, 전체 연결 로그는 충돌 보고서에 필요하지 않으며, 이를 포함하면 지원 사례가 데이터 처리 문제가 됩니다.

충돌 한 번은 유출의 증거가 아닙니다. 증거는 정책이 막아야 했던 경로로 나가는 패킷이 클라이언트가 꺼진 순간 관측된 것입니다. 무해한 목적지로 의도적으로 시험하고, 어느 시행 계층이 버텼는지 적어 두세요.