Por qué una puerta de cortafuegos ligada al estado de la VPN no es una regla de ping solo por el túnel

Imagine una regla de cortafuegos que activa el ICMP echo para la dirección pública del servidor cada vez que hay un perfil de VPN conectado. Se lee como «ping solo por el túnel», y esa lectura es errónea de una forma que importa. La regla no restringe quién puede llegar al host; cambia qué responde la interfaz pública mientras otra conexión está activa. Son dos políticas distintas, y una de ellas amplía la exposición sin hacer ruido.

La regla que cree que escribió

El requisito previsto suele ser estrecho: el sistema de monitorización, o el único administrador de la VPN, debe poder confirmar que el servidor está vivo. Escrito como una frase, suena a control de acceso al túnel. Escrito como un objeto de cortafuegos, se convierte en una condición en el perfil público, porque es ahí donde llega la solicitud echo.

Cuando la condición es un estado de conexión y no una dirección de origen, el conjunto de remitentes permitidos ya no es el conjunto de pares de la VPN. Cualquiera que pueda llegar a la dirección pública puede enviar una solicitud echo mientras la puerta está abierta. El túnel no se convirtió en el camino; el túnel se convirtió en el interruptor.

Quienes promueven esta idea normalmente no mienten sobre el efecto que querían. Necesitaban una comprobación que solo respondiera cuando el enlace está sano, y la salud del enlace era más fácil de observar a través de la VPN. El error es tratar una señal de disponibilidad como una decisión de acceso y luego automatizarlo.

Qué controla realmente la puerta

Este diseño fusiona dos cosas independientes, y separarlas es la mayor parte de la corrección. La primera es el alcance: qué dirección local, qué direcciones remotas, qué protocolo y qué tipo de ICMP. La segunda es la condición: si el objeto de regla está habilitado en este momento. El alcance es lo que un cortafuegos evalúa por paquete; la condición es lo que un script escribe en el almacén de políticas, y ambos se concilian con relojes completamente distintos.

Si el requisito es realmente solo pares de la VPN, el alcance lo responde sin ninguna lógica de estado de conexión: ate la regla a la interfaz del túnel o al rango de direcciones del túnel, limite las direcciones remotas al grupo de clientes y especifique el tipo echo en lugar de «ICMP». Esa regla sigue siendo correcta cuando no hay ninguna VPN activa y no puede abrirla un perfil ajeno.

Si el requisito es realmente una puerta pública, dígalo en el texto de la política, porque los criterios de aceptación cambian. Una puerta pública debe nombrar el perfil exacto, definir qué significa «conectado» y declarar que los remitentes públicos están dentro del alcance por diseño. La mayor parte de la confusión desaparece en el momento en que alguien se ve obligado a escribir esa frase.

Construya el objeto una vez y luego conmútelo

Aprovisione de antemano una sola regla con una identidad estable, deshabilitada, y deje que el controlador cambie solo su estado de habilitación. Crear reglas por el nombre para mostrar en cada ejecución es como un almacén de políticas acaba con cinco objetos casi idénticos y sin forma fiable de quitarlos.

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

El nombre es el identificador duradero; el nombre para mostrar es documentación que una persona puede editar. Concilie por -Name y el script deja de producir duplicados. La misma forma de comando cubre el caso IPv6 con -Protocol ICMPv6 -IcmpType 128, que es una regla aparte porque los números de tipo echo difieren entre las dos familias.

Mantenga la familia de direcciones y el tipo de ICMP explícitos por una segunda razón: -Protocol ICMPv4 sin un tipo permite todos los mensajes ICMPv4 que el perfil admite, incluidos los que nunca quiso aceptar. Nombrar el tipo 8 estrecha la regla a la solicitud echo, que es lo único que envía una comprobación de accesibilidad.

Donde la automatización contradice la intención

Sondear un perfil de cliente cada pocos minutos no puede producir una frontera inmediata. Entre la caída de la conexión y el siguiente sondeo, la regla sigue respondiendo en la dirección pública; entre la subida de la conexión y el siguiente sondeo, no. Reconocer ese retraso es honesto, y afirmar que el diseño impone un invariante estricto no lo es.

Hay una trampa de alcance en la propia comprobación de estado. Get-VpnConnection informa de los perfiles de cliente configurados en la máquina, por defecto para el usuario actual y para todos los usuarios con -AllUserConnection. No informa de los usuarios remotos que en este momento marcan hacia un servidor RRAS; esa es otra observación con otro comando. Una puerta construida sobre la incorrecta no está conectada a nada.

Luego cubra los estados que nadie programa: arranque con la regla ya habilitada de una ejecución anterior, caída del controlador con la puerta abierta y perfil borrado mientras su regla sigue viva. Cada uno necesita un valor por defecto definido, y el valor seguro para un permiso público es deshabilitado. Si el requisito no tolera la ventana de sondeo, una regla ligada al estado es el instrumento equivocado y la aplicación pertenece al túnel, no a la interfaz pública.

Por último, pruebe la solicitud pública dos veces, una con la conexión seleccionada activa y otra con ella caída, desde un host que no esté en la VPN. Un ping correcto desde dentro del túnel no demuestra nada sobre esta política, y esa es la medición que la mayoría de los despliegues omite.