Só o firewall de Windows como interruptor de corte da VPN: aguanta?
As regras por tipo de interface poden bloquear os adaptadores físicos, pero un túnel de terceiros adoita parecer cableado. Comprobe a clasificación, a ruta do extremo e despois o DNS.
Pregunte se o firewall de Windows pode actuar por si só como interruptor de corte e obterá dúas respostas seguras e incompatibles. Unha di que a regra por tipo de interface fai todo o traballo; a outra, que non funciona sen scripts. Ambas describen a metade do mesmo mecanismo. O firewall pode expresar o bloqueo, e que o resultado falle realmente pechado depende de tres cousas: como clasifica Windows o adaptador do túnel, se sobrevive a excepción do extremo e se están cubertos a resolución de nomes e IPv6. Falle nunha delas e a máquina filtrará ou perderá toda conectividade.
Tres condicións, nesta orde
A primeira condición é a clasificación, e decide se a regra que quere é sequera expresable. As regras do firewall de Windows poden limitarse por tipo de interface: cableada, sen fíos ou acceso remoto. Unha política que bloquea o tráfico saínte nos tipos físicos e permite o túnel só funciona se Windows recoñece o túnel como acceso remoto.
A segunda condición é a excepción do extremo. Antes de que exista túnel ningún, o cliente debe chegar ao servidor VPN pola tarxeta física, así que un bloqueo total desa tarxeta impide xusto a conexión que faría innecesario o bloqueo. A excepción debe nomear o servidor e o seu porto, e o paquete debe saír pola pasarela física en vez de entrar nun túnel que aínda non está levantado.
A terceira é a cobertura. Un conxunto de regras que bloquea IPv4 e esquece IPv6, ou que permite ao resolutor local a consulta do extremo e por tanto permite calquera outra consulta, falla aberto xusto na xanela que o interruptor existe para cubrir. É unha lagoa de deseño, non un fallo do firewall. Tamén é a lagoa que sobrevive a cada proba nun escritorio.
A clasificación é a primeira porta
Mire que pensa Windows dos adaptadores antes de escribir unha soa regra. Unha conexión VPN nativa de Windows adoita aparecer como acceso remoto. Un cliente de terceiros que crea o seu propio adaptador virtual adoita aparecer como cableado, o que significa que un bloqueo limitado a adaptadores cableados tamén bloquea o túnel.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionO terceiro comando indica se xa rexe un bloqueo saínte predeterminado, o que cambia toda a forma do deseño. Se o predeterminado xa é bloquear, vostede escribe regras de permiso en lugar de excepcións a unha base permisiva, e esa é unha postura moito máis fácil de razoar.
Se o seu adaptador de túnel se declara cableado, só o firewall non é a ferramenta axeitada para un deseño de fallo pechado, e ningún axuste de regras o cambia. É o caso en que a segunda opinión de cada fío do foro é correcta.
A excepción do extremo necesita unha ruta, non só unha regra
Supoñamos que a clasificación funciona. A excepción son dúas pezas, e viven en subsistemas distintos. A regra do firewall permite o tráfico; a ruta do host fai que saia pola interface correcta mentres o túnel está baixado.
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/32Sen a ruta, a excepción do extremo só axuda mentres unha ruta predeterminada siga apuntando á pasarela física. Cando o cliente instala a súa propia ruta predeterminada e logo morre, os paquetes permitidos non teñen onde ir con sentido e a conexión non se pode restablecer. Ese fallo parece un cliente roto e en realidade é unha ruta ausente.
Manteña a excepción tan estreita como permita o cliente. Un enderezo e un porto son revisables; un rango que cobre toda a rede do provedor non o é. Esa regra máis ampla tamén permite calquera outra cousa aloxada no mesmo provedor, que adoita ser máis do que pretendía.
DNS e IPv6 son onde falla aberto
A resolución de nomes é a fuga clásica. Se o extremo é un nome de host, o cliente debe resolvelo antes de que exista o túnel, o que significa que hai que permitir ao adaptador físico chegar a un resolutor. Ese mesmo permiso deixa saír calquera outra consulta mentres o túnel está baixado, e unha consulta abonda para revelar que estaba a piques de visitar.
IPv6 é o segundo. As regras escritas para IPv4 non cobren a outra familia, e moitos clientes só instalan rutas IPv4. Unha máquina con conectividade IPv6 nativa pode, por tanto, seguir falando con internet mentres o lado IPv4 está firmemente bloqueado, e o interruptor informa de éxito todo o tempo.
| 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 |
A terceira fila merece entenderse en lugar de sortearse. Un firewall decide sobre paquetes, non sobre que interface pediu usar unha aplicación, e un programa que se liga explicitamente pode ser difícil de conter. Iso é un argumento a favor dun interruptor do lado do cliente que opera por baixo da aplicación, non de máis regras.
Probe detendo o cliente, non tirando do cable
A única proba significativa é a que imita o fallo contra o que se protexe. Deteña o servizo, mate o proceso ou desactive o adaptador que creou o cliente, e logo intente chegar a internet e a un nome:
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 443As tres deberían fallar. Se a primeira ten éxito, o bloqueo non está vixente; se a segunda ten éxito onde fallou a primeira, ten unha fuga de DNS; se a terceira ten éxito, IPv6 non está cuberto. Cada resultado apunta exactamente a unha das lagoas anteriores.
Repita a proba tras suspender e retomar, porque o perfil do firewall pode cambiar cando Windows decide que unha rede é pública ou privada, e as regras limitadas a un perfil ségueno. Un deseño que aguanta nun escritorio e falla nun tren é un deseño probado unha vez.
Se a porta de clasificación ou o requisito de DNS fan inviable o enfoque de só firewall, un interruptor do lado do cliente é a resposta honesta. Se o túnel remata nun enrutador, a política debería ser do enrutador, porque unha regra alí cobre cada dispositivo que ten detrás e non depende de como Windows etiquete un adaptador.