서버를 바꿀 때 kill switch가 트래픽을 끊는 이유

더 가까워 보이는 서버를 골라 연결을 누르면, 새 터널이 올라오기 전에 브라우저가 로딩을 멈춥니다. 아이콘은 연결 중 상태로 바뀌고 모든 탭이 시간 초과될 때까지 그대로 있습니다. 이 멈춤은 보통 설계대로 동작하는 kill switch입니다. 클라이언트에 트래픽을 보낼 터널이 없는 동안 트래픽이 차단되는 것입니다. 이 멈춤이 받아들일 만한지는 클라이언트가 그 몇 초 동안 무엇을 하는지, 그리고 차단이 해제되었다고 말할 때 실제로 해제되는지에 달려 있습니다.

클라이언트는 두 서버 사이에서 무엇을 하는가

엔드포인트 전환은 스위치 하나가 아니라 여러 단계입니다. 클라이언트는 현재 터널을 해체하고, 차단 규칙을 갱신하고, 새 엔드포인트를 확인해 터널 밖에서 도달한 다음, 새 경로를 설치하고 차단을 해제합니다. 사용자가 느끼는 간격은 첫 단계와 마지막 단계 사이에 있습니다.

여기서는 속도보다 순서가 더 중요합니다. 차단 규칙이 새 엔드포인트에 대한 예외보다 먼저 적용되면 클라이언트는 핸드셰이크를 마치지 못하고 시간 초과까지 연결 중 상태로 남습니다. 예외가 이전 서버 주소의 복사본이라면 새 핸드셰이크는 다른 모든 아웃바운드 패킷처럼 보여 버려집니다. 두 경우 모두 브라우저에서는 똑같이 보이며, 그래서 육 초 뒤에 회복되는 전환과 결코 회복되지 않는 전환이 같은 원인을 공유할 수 있습니다.

새 엔드포인트에는 차단의 구멍이 필요합니다

터널을 세우려면 클라이언트가 물리 인터페이스로 새 서버의 주소와 포트에 패킷을 보내야 합니다. 예를 들어 일반적인 WireGuard 프로필은 UDP 51820, OpenVPN은 1194와 443이며, 이는 각자의 프로필이 지정하는 바에 따릅니다. 그 트래픽은 곧 만들어질 터널 안에 있지 않으므로, 일치하는 허용 규칙이 없으면 장치 전체에 적용된 차단이 그것을 삼켜 버립니다.

호스트 이름 기반 프로필에는 두 번째 조건이 붙습니다. 조회 자체입니다. 차단이 올라오기 전에 클라이언트가 엔드포인트를 확인하면 캐시된 주소를 쓸 수 있지만, 프로필이 주소를 교체하거나 캐시 항목이 오래되면 핸드셰이크는 허용 규칙이 덮지 않는 주소로 향합니다. IPv6는 이것을 눈에 보이게 합니다. 듀얼 스택 엔드포인트는 A 레코드와 AAAA 레코드를 모두 게시할 수 있고, v4 주소만 덮는 허용 규칙은 클라이언트가 차단된 v6 주소를 상대로 다시 시도하게 내버려 둡니다.

옵션 이름과 기본값은 클라이언트와 버전에 따라 다르므로 스크린샷으로 짐작하지 말고 해당 클라이언트의 문서화된 목록을 읽으십시오. OpenVPN Connect 설정 참조는 openvpn.net/connect-docs/app-settings-windows 에 있으며, 클라이언트가 차단과 분할 터널 옵션을 어떻게 설명하는지 보여 주는 한 가지 예입니다.

Fail-closed는 스위치가 아니라 상태 기계입니다

대부분의 클라이언트는 차단을 방화벽 정책으로 세 가지 상태에서 표현합니다. 터널이 올라가 트래픽이 터널을 지나고 차단이 없는 상태, 터널이 내려가 차단이 활성인 상태, 그리고 전환 중으로 차단이 활성이면서 엔드포인트에 대한 임시 예외가 있는 상태입니다. 버그는 세 번째 상태에 삽니다. 몇 초 안에 두 번 바뀌어야 하며, 그 상태를 벗어나지 못하는 모습은 영구 차단과 똑같이 보입니다.

메커니즘은 플랫폼마다 다르고 실패 방식도 다릅니다. Windows Filtering Platform 필터에는 가중치가 있어서, 허용을 앞서는 차단 필터는 허용이 존재해도 패킷을 계속 버립니다. 또한 종료된 클라이언트 프로세스가 남긴 필터 는 앱이 사라진 뒤에도 기기를 오프라인으로 유지할 수 있습니다. macOS 클라이언트는 보통 pf 규칙을 앵커에 작성하며, 여기서 규칙 순서와 빠른 결정이 어떤 규칙이 적용될지 정합니다. Linux 클라이언트는 보통 drop 정책과 엔드포인트, 터널 인터페이스, 루프백에 대한 명시적 허용을 갖춘 nftables 또는 iptables 체인을 관리합니다. Android의 상시 VPN과 VPN 없이 연결 차단 옵션은 이 그룹에서 가장 엄격합니다. 운영 체제가 차단을 앱별이 아니라 기기 전체에 적용하기 때문입니다.

WireGuard에는 별도 설명이 필요합니다. AllowedIPs는 경로 선택자이지 차단기가 아닙니다. 어떤 목적지가 터널로 들어가는지를 정하며, 아직 터널이 없는 패킷이 Wi-Fi로 나가는 것을 막지는 않습니다. 방화벽 규칙이 없는 WireGuard 단독 구성에서 kill switch는 사실상 경로의 부재이며, 버려진 핸드셰이크 뒤에 실제 패킷이 물리 인터페이스로 나갈 수 있습니다.

아이콘을 보는 대신 간격을 측정하십시오

상태 표시등이 아니라 패킷을 관찰하십시오. Linux에서는 한 터미널에서 공인 주소로 느린 ping을 시작하고, 다른 터미널에서 물리 인터페이스의 터널 전송 포트를 잡으십시오.

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

둘 다 실행 중일 때 클라이언트에서 서버를 바꾸십시오. 세 가지가 중요합니다. ping이 멈추는 시간, 캡처가 핸드셰이크의 새 엔드포인트 도달을 보여 주는지, 그리고 트래픽이 클라이언트 상태가 연결됨으로 바뀌기 전에 돌아오는지 후에 돌아오는지입니다. ping 간격이 먼저 끝나면 차단이 너무 일찍 해제되었거나 표시가 인정하기 전에 터널이 올라간 것입니다. 간격이 더 늦게 끝나면 표시가 지나치게 낙관적입니다.

Windows에서는 netsh wfp show state 가 스냅샷을 작성하며, 클라이언트가 연결이 끊겼다고 주장하는 동안에도 남아 있는 차단 필터를 그 안에서 검색할 수 있습니다. macOS에서는 sudo pfctl -sr 가 로드된 규칙과 그 순서를 나열합니다. 어느 스냅샷이든 클라이언트 자체 로그와 맞춰 보십시오. ping에서 얻은 시간선이 차단이 늦게 끝났는지 아예 끝나지 않았는지 알려 줍니다.

정상적인 암전과 멈춘 차단

어느 정도의 중단은 이 기능의 목적이므로, 어떤 설정이든 바꾸기 전에 분류하십시오.

두 번째나 다섯 번째 줄에 해당하면 시험 삼아 kill switch를 끄지 마십시오. 경로 버그를 유출로 바꾸는 일입니다. 클라이언트 서비스를 다시 시작하거나, 프로세스 종료 후에도 필터가 남는 환경에서는 기기를 재부팅한 다음 차단이 사라지는지 보십시오. 사라진다면 결함은 차단 자체가 아니라 전환 중의 정리에 있습니다.

다음 전환 전에 네 가지를 확인하십시오. 엔드포인트 허용이 프로필이 확인하는 모든 주소 체계를 덮는지, 클라이언트 로그가 전환 완료를 보여 주는지, ping 시험이 아이콘이 아니라 간격을 측정하는지, 클라이언트를 종료하면 정상 연결이 돌아오는지입니다. 전환 중에 버티고 그 뒤에 풀어 주는 kill switch는 제 역할을 합니다. 너무 일찍 풀거나 결코 풀지 않는 것은 조사할 가치가 있습니다.