Perfiles de firewall frente a la salida VPN: por qué público no es una ruta
Un perfil de firewall elige qué conjunto de reglas se aplica. No dice nada sobre qué interfaz transportó el paquete, y un bloqueo explícito vence a un permiso más estrecho.
La regla suena precisa: permitir el tráfico local en el perfil privado y solo el tráfico VPN en el público. No lo es, porque un perfil de red elige qué conjunto de reglas de firewall se aplica y no dice nada sobre qué adaptador transportó un paquete. Tratar el nombre del perfil como un requisito de ruta es el error que hace que un diseño de salida restringida parezca terminado cuando no lo está.
Primero anote los flujos y después decida qué mecanismo puede imponer realmente cada uno. Esa lista de flujos es el único artefacto que sobrevive al siguiente cambio de reglas.
La categoría elige reglas, no rutas
Cuando Windows clasifica una red como pública o privada, el firewall aplica el conjunto de reglas configurado para ese perfil. La clasificación sigue a la red a la que se unió el adaptador, y el conjunto de reglas decide qué se permite en ella. Ninguno de esos hechos depende de si el tráfico de una aplicación usó el túnel. Esa independencia es toda la dificultad.
La elección de ruta la hace el enrutamiento, mediante la métrica de la interfaz y el prefijo que instala el túnel. Un perfil puede por tanto estar etiquetado como público mientras la conexión de una aplicación toma la ruta física, y el firewall seguirá informando de que se aplicó el conjunto de reglas público.
Por eso una regla limitada al perfil no puede significar solo túnel. Las dos propiedades las deciden componentes distintos y una no puede sustituir a la otra.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Un bloqueo explícito prevalece sobre un permiso más estrecho
La guía de Microsoft sobre reglas de firewall distingue un permiso como excepción a una acción de bloqueo predeterminada de un bloqueo explícito que entra en conflicto con un permiso. Los bloqueos explícitos ganan ese conflicto, y las reglas de salida obedecen la misma precedencia.
Así que la receta popular de añadir una regla que lo bloquea todo y confiar en un permiso más estrecho colocado encima no hace lo que su autor espera. El Firewall de Windows no resuelve el conflicto por el orden de reglas asignado por el administrador. El bloqueo simplemente se aplica, y la aplicación que se conecta informa de un tiempo de espera agotado. La regla que parecía la excepción nunca estuvo en juego.
La forma admitida es una política de denegación predeterminada con reglas de permiso aprobadas, donde cada permiso nombra un programa, un servicio o un destino con la precisión suficiente para poder revisarse. Ese diseño sobrevive a una auditoría, porque cada excepción es visible y ninguna depende del orden en que se creó.
Dos reglas que se contradicen son peores que una sola regla, porque el comportamiento resultante es correcto e inexplicable al mismo tiempo.
Dé a la política de salida un único propietario
Un cliente VPN compatible ya mantiene su propio comportamiento de bloqueo y sus propias excepciones de punto final. Añadir reglas manuales no coordinadas puede dejar a ese cliente fuera del túnel que necesita para configurarse, o dejar abierto un segundo camino que nadie notó.
Decida quién es dueño de la política de salida antes de escribir reglas: la propia configuración del cliente, una política de firewall gestionada o una lista local de excepciones documentada con un propietario. Después concilie las capas en lugar de apilar experimentos hasta que algo se conecte. Un propietario con nombre es también a quien se pregunta cuando dos capas discrepan.
Conserve un canal de recuperación antes de cambiar nada. Una máquina remota bloqueada fuera de su propia ruta de gestión es un resultado peor que el hueco de política que estaba cerrando. La regla de recuperación es más fácil de justificar cuando está escrita de antemano, y más fácil de encontrar cuando un cambio sale mal a una hora que nadie disfruta.
Pruebe cuatro resultados en lugar de leer la etiqueta
Una política es tan buena como los casos que distingue, así que trate la etiqueta del perfil como un punto de partida y no como un resultado. Cuatro resultados le dicen si funciona: la solicitud LAN prevista tiene éxito, una solicitud de internet cubierta tiene éxito, una solicitud directa prohibida falla, y el caso de fallo del túnel se comporta como se diseñó en lugar de retroceder en silencio. Anote los cuatro resultados junto al cambio de reglas. Un plan de pruebas con cuatro casos nombrados es lo bastante corto para ejecutarlo cada vez y lo bastante concreto para fallar ruidosamente.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
El primer comando muestra cómo se clasifica cada red conectada, lo que a menudo no es lo que supuso la persona que escribió la regla. El segundo muestra la acción predeterminada por perfil, y el tercero enumera los bloqueos de salida habilitados, incluidos los que anularán en silencio un permiso más estrecho.
Ejecute de nuevo los cuatro casos tras un cambio de red, porque un perfil puede reclasificarse cuando la máquina se une a otra red. Una etiqueta de perfil coincidente no es prueba de que la ruta fuera la que usted pretendía.