VPN 상태에 연동된 방화벽 게이트가 터널 전용 ping 규칙이 아닌 이유

지정된 VPN 프로필이 연결될 때마다 서버의 공용 주소에 대해 ICMP echo를 켜는 방화벽 규칙을 상상해 보자. 이것은 «터널을 통한 ping만»처럼 읽히지만, 그 읽기는 중요한 방식으로 틀렸다. 규칙은 누가 호스트에 도달할 수 있는지를 제한하지 않고, 다른 연결이 우연히 살아 있는 동안 공용 인터페이스가 무엇에 응답하는지만 바꾼다. 이것은 서로 다른 두 정책이며, 그중 하나는 조용히 노출을 넓힌다.

당신이 작성했다고 생각하는 규칙

의도된 요구 사항은 대개 좁아서, 모니터링 시스템이나 VPN의 유일한 관리자가 서버가 살아 있음을 확인할 수 있어야 한다. 문장으로 쓰면 터널에 대한 접근 제어처럼 들린다. 방화벽 객체로 쓰면 공용 프로필의 조건이 되는데, echo 요청이 도착하는 곳이 바로 거기이기 때문이다.

조건이 출발지 주소가 아니라 연결 상태가 되는 순간, 허용되는 발신자 집합은 더 이상 VPN 피어 집합이 아니다. 공용 주소에 도달할 수 있는 사람은 누구든 게이트가 열려 있는 동안 echo 요청을 보낼 수 있다. 터널이 경로가 된 것이 아니라, 터널이 스위치가 된 것이다.

이 아이디어를 홍보하는 사람들은 대개 원했던 효과에 대해 거짓말하지 않는다. 링크가 건강할 때만 응답하는 확인이 필요했고, 링크의 건강은 VPN을 통해 관찰하는 것이 가장 쉬웠다. 실수는 가용성 신호를 접근 결정으로 취급한 뒤 자동화하는 것이다.

게이트가 실제로 제어하는 것

이 설계는 두 개의 독립적인 것을 융합하며, 그것을 분리하는 것이 수정의 대부분이다. 첫째는 어떤 로컬 주소, 어떤 원격 주소, 어떤 프로토콜, 어떤 ICMP 유형인지라는 범위다. 둘째는 규칙 객체가 지금 이 순간 활성화되어 있는지라는 조건이다. 범위는 방화벽이 패킷마다 평가하는 것이고, 조건은 스크립트가 정책 저장소에 기록하는 것이며, 둘은 전혀 다른 시계에서 조정된다.

요구 사항이 정말로 VPN 피어뿐이라면, 범위만으로 연결 상태 논리 없이 답할 수 있어 규칙을 터널 인터페이스나 터널 주소 범위에 묶고, 원격 주소를 클라이언트 풀로 제한하고, «ICMP» 대신 echo 유형을 지정하면 된다. 그 규칙은 VPN이 하나도 올라와 있지 않을 때도 올바르며, 무관한 프로필이 열 수 없다.

요구 사항이 정말로 공용 게이트라면 수용 기준이 달라지므로 정책 문서에 그렇게 적어야 한다. 공용 게이트는 정확한 프로필을 지목하고, «연결됨»의 의미를 정의하고, 공용 발신자가 설계상 범위 안에 있음을 밝혀야 한다. 누군가 그 문장을 쓰도록 강요받는 순간 혼란의 대부분은 사라진다.

객체를 한 번 만들고 그다음 토글하라

안정적인 식별자를 가진 규칙 하나를 비활성 상태로 미리 마련하고, 컨트롤러는 활성 상태만 바꾸게 하라. 실행할 때마다 표시 이름으로 규칙을 만드는 것이 바로 정책 저장소에 거의 동일한 객체 다섯 개가 남고 이를 제거할 신뢰할 방법이 없어지는 경로다.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

이름은 영구 식별자이고 표시 이름은 사람이 편집할 수 있는 문서다. -Name 로 맞추면 스크립트는 중복을 만들지 않는다. 같은 명령 형태가 IPv6 사례를 -Protocol ICMPv6 -IcmpType 128 로 다루지만, echo 유형 번호가 두 계열에서 다르므로 별도 규칙이다.

주소 계열과 ICMP 유형을 명시하는 두 번째 이유는, -Protocol ICMPv4 가 유형이 없으면 프로필이 허용하는 모든 ICMPv4 메시지를 허용하며 받아들일 생각이 없던 것까지 포함되기 때문이다. 유형 8을 지목하면 규칙이 echo 요청으로 좁혀지고, 도달성 점검이 보내는 것은 그것뿐이다.

자동화가 의도와 모순되는 곳

몇 분마다 클라이언트 프로필을 폴링하는 것으로는 즉각적인 경계를 만들 수 없다. 연결이 끊긴 뒤 다음 폴링까지 규칙은 여전히 공용 주소에서 응답하고, 연결이 올라온 뒤 다음 폴링까지는 응답하지 않는다. 그 지연을 인정하는 것은 정직하지만, 설계가 엄격한 불변식을 강제한다고 주장하는 것은 정직하지 않다.

상태 확인 자체에 범위 함정이 있다. Get-VpnConnection 는 머신에 구성된 클라이언트 프로필을 기본적으로 현재 사용자에 대해, -AllUserConnection 를 붙이면 모든 사용자에 대해 보고하지만, 현재 RRAS 서버에 다이얼인한 원격 사용자는 보고하지 않는다. 그것은 다른 cmdlet으로 하는 다른 관측이다. 잘못된 쪽에 기반해 만든 게이트는 아무것에도 연결되어 있지 않다.

그다음 이전 실행에서 규칙이 이미 활성화된 채로 시작하는 경우, 게이트가 열린 상태에서 컨트롤러가 죽는 경우, 규칙은 살아 있는데 프로필이 삭제되는 경우처럼 아무도 스크립트하지 않는 상태를 다뤄야 한다. 각각에 정의된 기본값이 필요하고, 공용 허용에 대한 안전한 기본값은 비활성이다. 요구 사항이 폴링 창을 정말 견딜 수 없다면 상태 연동 규칙은 잘못된 도구이며, 시행은 터널 쪽에 속한다.

마지막으로 공용 요청을, 선택한 연결이 올라온 상태에서 한 번, 내려간 상태에서 한 번, VPN에 없는 호스트에서 두 번 시험하라. 터널 내부에서 성공한 ping은 이 정책에 대해 아무것도 증명하지 않으며, 그것이 대부분의 배포가 건너뛰는 측정이다.