Kill switch en Windows sin software extra: ¿perfiles o rutas?

El cliente muere a mitad de una descarga y el icono de la bandeja desaparece. La transferencia sigue por la conexión de casa. Esa secuencia es la razón por la que existe un kill switch, y Windows puede aproximarlo sin un segundo producto.

Dos métodos merecen conocerse. Fallan en sitios distintos, y ninguno es una respuesta completa.

Método uno: permitir el programa en un solo perfil

El cortafuegos de Windows limita las reglas a los perfiles Domain, Private y Public. El truco consiste en dar una categoría al adaptador del túnel y otra al adaptador físico. Después se escribe una regla de salida que permite el programa protegido en el perfil del túnel y lo bloquea en todos los demás sitios. El cortafuegos lee la categoría, no el nombre del adaptador.

Primero ponga la conexión VPN en Private y la red física en Public. Luego añada una regla de bloqueo para el programa que se aplique a los perfiles que no quiera. Después confirme la asignación con Get-NetConnectionProfile, porque es esa asignación la que sigue la regla.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

La debilidad es estructural. Una regla de perfil sigue la categoría, así que cuando Windows reclasifica una red de hotel el bloqueo puede dejar de aplicarse. Nada de la lista de reglas cambia cuando eso ocurre.

Método dos: eliminar la ruta predeterminada física

El enfoque de rutas es más contundente y mucho más fácil de auditar. Anote la puerta de enlace física, deje que la VPN instale su propia ruta predeterminada con una métrica más baja y luego borre la predeterminada física. Nada más podrá transportar tráfico.

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

Cuando el cliente muere, la ruta de la VPN se va con su adaptador. La máquina queda sin conexión en lugar de filtrar, y eso es lo que debe producir un kill switch.

Dos detalles deciden si aguanta una semana. El DHCP devuelve la puerta de enlace cada vez que el enlace parpadea. Un adaptador físico con dirección estática evita esa sorpresa. La dirección del propio servidor VPN también debe seguir siendo alcanzable. Sin esa ruta hacia el host, el cliente no podrá reconectarse nunca tras la caída que activó el bloqueo.

Método tres: sin puerta de enlace, una ruta persistente al host

La tercera opción empieza borrando la puerta de enlace de los ajustes del adaptador. Después la sustituye una única ruta persistente hasta el punto final de la VPN. La máquina puede entonces hablar con el servidor y con nada más hasta que el túnel se levante.

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

Restaurar la puerta de enlace restaura el internet normal, lo que lo convierte en un interruptor limpio de encendido y apagado. No depende de un script que vigile los eventos de la interfaz. Tampoco le importa cómo se categorice la red.

El coste es un aislamiento total mientras el túnel está caído. Las actualizaciones se detienen, y también la propia descarga que motivó el ejercicio. En un portátil de trabajo suele ser correcto, mientras que en una máquina personal es una decisión que conviene tomar a propósito.

Por qué el icono del globo no demuestra nada

Windows informa de la accesibilidad mediante una sonda contra un punto final de Microsoft. Esa sonda no dice nada sobre su túnel. Un túnel conectado puede estar detrás de un globo que informa de que no hay internet, y uno muerto puede mostrar una conexión sana.

Pruébelo matando el proceso del cliente y luego intente alcanzar una dirección pública por número. Una consulta de nombre puede responderse desde la caché, así que ni el icono ni una respuesta DNS son pruebas.

Qué registrar tras una caída real

Ejecute la prueba como una secuencia y no como una sola comprobación. Mate el proceso en lugar de desconectar y luego pruebe una dirección numérica en ambas familias. Restaure el cliente después y confirme que sigue alcanzando su propio servidor por la ruta que conservó.

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

Repita la secuencia tras la suspensión, tras un cambio de Wi-Fi y tras pasar de cable a inalámbrico. Esas transiciones son donde fallan a la vez el método del perfil y el comportamiento del DHCP. Una regla que aguanta en un escritorio no aguanta necesariamente en un hotel.

Escriba el paso de deshacer junto a cada regla y ruta. Microsoft documenta la creación de reglas de salida en su referencia de reglas del cortafuegos de Windows, y esa es una fuente mejor que un tutorial solo con capturas de pantalla.