페일오픈과 페일클로즈드: VPN 킬 스위치가 결정하는 것
두 용어는 터널이 사라진 뒤에 무슨 일이 일어나는지를 설명할 뿐, 암호화가 얼마나 강한지는 말하지 않는다. 선택한 범위가 트래픽이 실제로 새는지를 결정한다.
페일클로즈드가 안전한 설정이고 페일오픈이 부주의한 설정이라는 것은 속설이다. 둘 다 터널이 사라진 뒤 트래픽에 무슨 일이 일어나는지를 설명하며, 어느 쪽도 그 터널의 암호화 품질을 바꾸지 않는다. 예외 목록이 긴 페일클로즈드 정책은 사무실 네트워크를 한 번도 벗어나지 않는 기기에서 페일오픈 정책보다 더 많이 샐 수 있다. 트래픽의 주인에게 설명할 수 있는 결과를 고르자.
라벨은 강도가 아니라 결과를 설명한다
이 용어는 제어 시스템에서 왔으며, 페일오픈은 구성 요소가 고장 났을 때 작동을 허용하고 페일클로즈드는 그것을 거부한다. VPN에 적용하면 고장 나는 구성 요소는 터널이고, 문제는 트래픽이 다른 경로로 계속되도록 허용할지다. 암호 선택, 키 길이, 프로토콜은 별개의 결정이다.
혼란이 남는 이유는 킬 스위치가 보안 기능처럼 들리고, 공급업체가 그렇게 팔기 때문이다. 구조적으로는 터널이 실어야 했던 트래픽을 막는 라우팅 및 방화벽 규칙이며, 클라이언트, 운영 체제, 또는 게이트웨이에서 구현된다. 어느 계층이 이를 강제하든 그 계층이 적용 범위도 정하며, 한 계층의 규칙은 다른 계층을 덮지 않는다. 게이트웨이 규칙은 이미 다른 네트워크로 옮긴 노트북을 보호하지 못한다.
각 결과는 어떻게 보이는가
같은 정책이라도 어떤 장애를 만나느냐에 따라 매우 다르게 동작할 수 있으니, 라벨이 아니라 사건을 비교하자.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
마지막 행은 킬 스위치가 하나의 스위치라고 가정하는 사람을 잡는 행이다. IPv4 경로 테이블을 위해 작성된 규칙은 IPv6 기본 경로를 그대로 두고, 애플리케이션은 그것을 거리낌 없이 사용할 수 있다.
새는지는 범위가 결정한다
어떤 모드인지 묻기 전에 정책이 무엇을 덮는지 물어보자. 애플리케이션별 규칙은 한 앱만 보호하고 그 밖의 것은 보호하지 않으며, 기기 전체 규칙은 예외를 뺀 모든 것을 보호하고, 게이트웨이 규칙은 그 게이트웨이에 도달하는 트래픽만 보호한다. DNS는 로컬 리졸버로 보낸 질의가 페이로드가 차단되어 있어도 이름을 드러낼 수 있어 별도의 결정이 필요하다.
로컬 네트워크 예외는 프린터, 화면 공유, 캡티브 포털을 위해 존재하며, 각각은 차단의 구멍이다. 구성을 물려받은 사람이 그렇지 않으면 페일클로즈드를 절대적인 것으로 읽을 것이므로 정책 옆에 기록하자.
재연결과 차단도 별개의 제어다. 클라이언트는 한 번도 차단하지 않고 자동 재연결할 수 있고, 재연결 없이 차단할 수도 있으며, 그 조합이 장애 중 사용자가 겪는 것을 결정한다.
전환 중에 증명하라
안정 상태를 시험하는 것은 아무것도 증명하지 않는다. 터널을 일부러 떨어뜨리고 보호되어야 할 애플리케이션을 시험한 뒤, 그것이 네트워크에 도달했는지 확인하자. 클라이언트의 표시가 여전히 연결됨이라고 나오는 것이 바로 이 정책이 존재하는 이유의 상황이므로, 표시와 결과를 비교하자. 보호된 애플리케이션이 성공하면 모드의 이름은 중요하지 않고, 새고 있는 것이다.
로그인 전 콜드 부팅부터, Wi-Fi에서 셀룰러로 전환할 때, 그리고 보호된 앱을 백그라운드에 둔 채로 반복하라. 차단을 클라이언트 프로세스가 강제한다면, 그 프로세스를 정상 종료가 아니라 강제 종료했을 때 무슨 일이 일어나는지도 시험하자.
마지막으로 정리 경로를 확인하자. 규칙이 활성인 상태에서 클라이언트를 제거한다면 무관한 보호까지 사라지고 남은 규칙의 주인이 누구인지도 답하지 못하는 운영 체제 방화벽을 끄는 대신, 공급업체가 문서화한 제거 절차를 사용하자.