Solo el firewall de Windows como interruptor de corte de la VPN: ¿aguanta?
Las reglas por tipo de interfaz pueden bloquear los adaptadores físicos, pero un túnel de terceros suele parecer cableado. Compruebe la clasificación, la ruta del extremo y después el DNS.
Pregunte si el firewall de Windows puede actuar por sí solo como interruptor de corte y obtendrá dos respuestas seguras e incompatibles. Una dice que la regla por tipo de interfaz hace todo el trabajo; la otra, que no funciona sin scripts. Ambas describen la mitad del mismo mecanismo. El firewall puede expresar el bloqueo, y que el resultado falle realmente cerrado depende de tres cosas: cómo clasifica Windows el adaptador del túnel, si sobrevive la excepción del extremo y si están cubiertos la resolución de nombres e IPv6. Falle en cualquiera de ellas y la máquina filtrará o perderá toda conectividad.
Tres condiciones, en este orden
La primera condición es la clasificación, y decide si la regla que quiere es siquiera expresable. Las reglas del firewall de Windows pueden limitarse por tipo de interfaz: cableada, inalámbrica o acceso remoto. Una política que bloquea el tráfico saliente en los tipos físicos y permite el túnel solo funciona si Windows reconoce el túnel como acceso remoto.
La segunda condición es la excepción del extremo. Antes de que exista túnel alguno, el cliente debe llegar al servidor VPN por el adaptador físico, así que un bloqueo total de ese adaptador impide justo la conexión que haría innecesario el bloqueo. La excepción debe nombrar el servidor y su puerto, y el paquete debe salir por la puerta de enlace física en lugar de entrar en un túnel que aún no está levantado.
La tercera es la cobertura. Un conjunto de reglas que bloquea IPv4 y olvida IPv6, o que permite al resolutor local la consulta del extremo y por tanto permite cualquier otra consulta, falla abierto justo en la ventana que el interruptor existe para cubrir. Es una laguna de diseño, no un fallo del firewall. También es la laguna que sobrevive a cada prueba en un escritorio.
La clasificación es la primera puerta
Mire qué piensa Windows de los adaptadores antes de escribir una sola regla. Una conexión VPN nativa de Windows suele aparecer como acceso remoto. Un cliente de terceros que crea su propio adaptador virtual suele aparecer como cableado, lo que significa que un bloqueo limitado a adaptadores cableados también bloquea el túnel.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionEl tercer comando indica si ya rige un bloqueo saliente predeterminado, lo que cambia toda la forma del diseño. Si el valor predeterminado ya es bloquear, usted escribe reglas de permiso en lugar de excepciones a una base permisiva, y esa es una postura mucho más fácil de razonar.
Si su adaptador de túnel se declara cableado, solo el firewall no es la herramienta adecuada para un diseño de fallo cerrado, y ningún ajuste de reglas lo cambia. Es el caso en que la segunda opinión de cada hilo del foro es correcta.
La excepción del extremo necesita una ruta, no solo una regla
Supongamos que la clasificación funciona. La excepción son dos piezas, y viven en subsistemas distintos. La regla del firewall permite el tráfico; la ruta del host lo hace salir por la interfaz correcta mientras el túnel está caído.
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/32Sin la ruta, la excepción del extremo solo ayuda mientras una ruta predeterminada siga apuntando a la puerta de enlace física. Cuando el cliente instala su propia ruta predeterminada y luego muere, los paquetes permitidos no tienen adónde ir con sentido y la conexión no puede restablecerse. Ese fallo parece un cliente roto y en realidad es una ruta ausente.
Mantenga la excepción tan estrecha como permita el cliente. Una dirección y un puerto son revisables; un rango que cubre toda la red del proveedor no lo es. Esa regla más amplia también permite cualquier otra cosa alojada en el mismo proveedor, que suele ser más de lo que pretendía.
DNS e IPv6 son donde falla abierto
La resolución de nombres es la fuga clásica. Si el extremo es un nombre de host, el cliente debe resolverlo antes de que exista el túnel, lo que significa que hay que permitir al adaptador físico llegar a un resolutor. Ese mismo permiso deja salir cualquier otra consulta mientras el túnel está caído, y una consulta basta para revelar qué estaba a punto de visitar.
IPv6 es el segundo. Las reglas escritas para IPv4 no cubren la otra familia, y muchos clientes solo instalan rutas IPv4. Una máquina con conectividad IPv6 nativa puede, por tanto, seguir hablando con internet mientras el lado IPv4 está firmemente bloqueado, y el interruptor informa de éxito todo el tiempo.
| 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 |
La tercera fila merece entenderse en lugar de sortearse. Un firewall decide sobre paquetes, no sobre qué interfaz pidió usar una aplicación, y un programa que se enlaza explícitamente puede ser difícil de contener. Eso es un argumento a favor de un interruptor del lado del cliente que opera por debajo de la aplicación, no de más reglas.
Pruebe deteniendo el cliente, no tirando del cable
La única prueba significativa es la que imita el fallo contra el que se protege. Detenga el servicio, mate el proceso o desactive el adaptador que creó el cliente, y luego intente llegar a internet y a un nombre:
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 443Las tres deberían fallar. Si la primera tiene éxito, el bloqueo no está vigente; si la segunda tiene éxito donde falló la primera, tiene una fuga de DNS; si la tercera tiene éxito, IPv6 no está cubierto. Cada resultado apunta exactamente a una de las lagunas anteriores.
Repita la prueba tras suspender y reanudar, porque el perfil del firewall puede cambiar cuando Windows decide que una red es pública o privada, y las reglas limitadas a un perfil lo siguen. Un diseño que aguanta en un escritorio y falla en un tren es un diseño probado una vez.
Si la puerta de clasificación o el requisito de DNS hacen inviable el enfoque de solo firewall, un interruptor del lado del cliente es la respuesta honesta. Si el túnel termina en un router, la política debería ser del router, porque una regla allí cubre cada dispositivo que tiene detrás y no depende de cómo Windows etiquete un adaptador.