Windows 방화벽만으로 VPN 킬 스위치가 될까?
인터페이스 유형 규칙으로 물리 어댑터를 차단할 수 있지만 서드파티 터널은 흔히 유선으로 보입니다. 분류, 엔드포인트 경로, 다음으로 DNS를 확인하십시오.
Windows 방화벽이 단독으로 킬 스위치 역할을 할 수 있는지 물으면 자신감 있는 상반된 답 두 개가 돌아옵니다. 하나는 인터페이스 유형 규칙이 전부 해낸다고 하고, 다른 하나는 스크립트 없이는 안 된다고 합니다. 둘 다 같은 메커니즘의 절반을 설명합니다. 방화벽은 차단을 표현할 수 있지만 결과가 실제로 페일 클로즈되는지는 세 가지에 달려 있습니다: Windows가 터널 어댑터를 어떻게 분류하는지, 엔드포인트 예외가 살아남는지, 이름 확인과 IPv6가 가려지는지입니다. 하나라도 틀리면 기기는 유출되거나 모든 연결을 잃습니다.
세 가지 조건, 이 순서로
첫째 조건은 분류이며 원하는 규칙이 애초에 표현 가능한지를 결정합니다. Windows 방화벽 규칙은 인터페이스 유형으로 범위를 좁힐 수 있습니다: 유선, 무선, 원격 액세스입니다. 물리 유형에서 아웃바운드 트래픽을 차단하면서 터널을 허용하는 정책은 Windows가 터널을 원격 액세스로 인식할 때만 작동합니다.
둘째 조건은 엔드포인트 예외입니다. 터널이 존재하기 전에 클라이언트는 물리 어댑터를 통해 VPN 서버에 도달해야 하므로 그 어댑터를 전면 차단하면 차단을 불필요하게 만들 연결 자체를 막습니다. 예외는 서버와 포트를 지정해야 하고, 패킷은 아직 올라오지 않은 터널이 아니라 물리 게이트웨이를 통해 나가야 합니다.
셋째는 커버리지입니다. IPv4를 차단하고 IPv6를 잊거나, 엔드포인트 조회를 위해 로컬 리졸버를 허용해 결과적으로 다른 모든 조회를 허용하는 규칙 집합은 킬 스위치가 존재하는 바로 그 창에서 열린 채 실패합니다. 이는 설계 공백이며 방화벽의 버그가 아닙니다. 또한 책상 위의 모든 테스트를 통과하는 공백입니다.
분류가 첫 번째 관문입니다
규칙을 하나도 쓰기 전에 Windows가 어댑터를 어떻게 보는지 확인하십시오. 기본 Windows VPN 연결은 보통 원격 액세스로 나타납니다. 자체 가상 어댑터를 만드는 서드파티 클라이언트는 흔히 유선으로 나타나며, 이는 유선 어댑터로 범위를 좁힌 차단이 터널도 차단한다는 뜻입니다.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction세 번째 명령은 기본 아웃바운드 차단이 이미 시행 중인지 알려 주며, 이는 설계의 전체 형태를 바꿉니다. 기본값이 이미 차단이라면 관대한 기준에 대한 예외가 아니라 허용 규칙을 쓰는 것이며, 그쪽이 훨씬 추론하기 쉬운 입장입니다.
터널 어댑터가 유선으로 보고되면 페일 클로즈 설계에 방화벽만으로는 적절한 도구가 아니며, 규칙을 아무리 조정해도 바뀌지 않습니다. 모든 포럼 스레드의 두 번째 의견이 옳은 경우가 이것입니다.
엔드포인트 예외에는 규칙만큼 경로도 필요합니다
분류가 작동한다고 가정합니다. 예외는 두 조각이며 서로 다른 하위 시스템에 있습니다. 방화벽 규칙은 트래픽을 허용하고, 호스트 경로는 터널이 내려간 동안 올바른 인터페이스로 나가게 합니다.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32경로가 없으면 엔드포인트 예외는 기본 경로가 아직 물리 게이트웨이를 가리키는 동안에만 도움이 됩니다. 클라이언트가 자체 기본 경로를 설치한 뒤 죽으면 허용된 패킷은 갈 만한 합리적인 곳이 없고 연결을 다시 세울 수 없습니다. 그 실패는 고장 난 클라이언트처럼 보이지만 실제로는 빠진 경로입니다.
예외는 클라이언트가 허용하는 만큼 좁게 유지하십시오. 주소 하나와 포트 하나는 검토 가능하지만 공급자 네트워크 전체를 덮는 범위는 그렇지 않습니다. 그 넓은 규칙은 같은 공급자에 호스팅된 다른 모든 것도 허용하며, 보통 의도보다 많습니다.
DNS와 IPv6가 열린 채 실패하는 지점입니다
이름 확인은 전형적인 유출입니다. 엔드포인트가 호스트 이름이면 클라이언트는 터널이 존재하기 전에 이를 확인해야 하므로 물리 어댑터가 리졸버에 도달하도록 허용해야 합니다. 같은 허용이 터널이 내려간 동안 다른 모든 조회를 내보내며, 조회 하나면 무엇을 방문하려 했는지 드러나기에 충분합니다.
IPv6가 두 번째입니다. IPv4용으로 쓴 규칙은 다른 패밀리를 덮지 않으며 많은 클라이언트가 IPv4 경로만 설치합니다. 따라서 기본 IPv6 연결이 있는 기기는 IPv4 쪽이 단단히 차단된 동안에도 인터넷과 대화를 계속할 수 있고, 킬 스위치는 내내 성공을 보고합니다.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
세 번째 행은 피하기보다 이해할 가치가 있습니다. 방화벽은 패킷에 대해 결정합니다—애플리케이션이 어떤 인터페이스를 쓰겠다고 했는지가 아니라 패킷 자체를 보며, 명시적으로 바인딩하는 프로그램은 통제하기 어려울 수 있습니다. 이는 애플리케이션 아래에서 동작하는 클라이언트 측 킬 스위치를 지지하는 논거이며, 규칙을 더 늘리라는 근거가 아닙니다.
케이블을 뽑지 말고 클라이언트를 멈춰 시험하십시오
의미 있는 유일한 시험은 보호하려는 실패를 흉내 내는 것입니다. 서비스를 멈추고, 프로세스를 죽이고, 클라이언트가 만든 어댑터를 비활성화한 뒤 인터넷과 이름에 도달해 보십시오:
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443셋 모두 실패해야 합니다. 첫 번째가 성공하면 차단이 시행되지 않은 것이고, 첫 번째가 실패한 곳에서 두 번째가 성공하면 DNS 유출이 있으며, 세 번째가 성공하면 IPv6가 가려지지 않은 것입니다. 각 결과는 위 공백 중 정확히 하나를 가리킵니다.
절전과 복귀 후에 시험을 반복하십시오: Windows가 네트워크를 공용인지 사설인지 판단하면 방화벽 프로필이 바뀔 수 있고 프로필에 범위를 둔 규칙은 그것을 따르기 때문입니다. 책상에서는 버티고 기차에서는 실패하는 설계는 한 번 시험한 설계입니다.
분류 관문이나 DNS 요건 때문에 방화벽 단독 접근이 불가능하다면 클라이언트 측 킬 스위치가 정직한 답입니다. 터널이 대신 라우터에서 끝난다면 정책은 라우터가 가져야 합니다: 거기서 규칙 하나가 뒤의 모든 기기를 덮고 Windows가 어댑터를 무엇이라 부르는지에 의존하지 않기 때문입니다.