Filtro de tráfico VPN o regla IPsec: dónde Windows aplica un puerto

Un usuario de VPN de Windows debería llegar a HTTPS en un servidor y no a SMB en el mismo servidor, y una ruta no puede expresar eso. Ambas solicitudes llevan la misma dirección de destino, así que el prefijo que envía el tráfico al túnel también lleva el flujo que querías excluir. Separarlos exige una regla que examine algo más fino que el destino.

Dos intenciones distintas se construyen con dos mecanismos de Windows distintos. Mezclarlos produce una directiva que parece completa mientras aplica la mitad de lo que pretendías.

Una ruta no puede separar dos servicios en una dirección

El enrutamiento nativo de VPN se basa en prefijos: decide qué destinos viajan por el túnel y cuáles quedan fuera. Es la herramienta correcta para mantener una subred dentro y otra fuera, y es ciega a los puertos por construcción. Un filtro de tráfico en el perfil VPN añade una segunda dimensión: hace coincidir protocolo, dirección remota y puerto remoto para lo que puede cruzar esa interfaz. Una regla IPsec trabaja en un tercer lugar y expresa qué flujos requieren protección y con quién se autentican. Las tres responden preguntas distintas y ninguna sustituye a las otras.

Empieza escribiendo la frase que pretendes. Permitir solo HTTPS es una frase de acceso, mientras que exigir IPsec para HTTPS es una frase de protección, y las dos llevan a una configuración distinta.

La restricción de acceso y el requisito de protección divergen

Una restricción de acceso dice qué puede usar la interfaz y se aplica permitiendo un conjunto y denegando todo lo demás. Un requisito de protección dice qué flujos deben ir cifrados y autenticados y se aplica negociando asociaciones de seguridad que coincidan con ellos. El primero produce una solicitud bloqueada cuando algo no está en la lista, mientras que el segundo produce una conexión que o bien lleva la protección exigida o bien no se establece. Tratar uno como el otro es como una directiva acaba sin bloquear nada o sin proteger nada.

La consecuencia práctica es que una lista de filtros es un conjunto cerrado. Una vez existe una lista en el perfil, el tráfico por esa interfaz que no coincide con ninguna entrada se rechaza, así que DNS, los intercambios de autenticación y cualquier dependencia que la aplicación necesite requieren sus propias entradas. Añadir una regla amplia para silenciar los rechazos reabre toda la interfaz y cancela la restricción en silencio. La lista debe ser tan corta como el requisito permita y tan completa como la aplicación exija.

Construye la lista de filtros como un conjunto completo

Los perfiles VPNv2 llevan la lista de filtros por separado de la lista de rutas, y sus entradas son propiedades del perfil, no comandos. Para el ejemplo de HTTPS la entrada necesita el protocolo 6, la dirección remota y el puerto remoto, desplegados por el canal de administración o ProfileXML para el tipo de perfil en uso. La definición del filtro de tráfico VPNv2 de Microsoft afirma que las condiciones dentro de una regla se combinan mientras que identificadores de regla separados actúan como alternativas.

TrafficFilterList/0/Protocol            = 6
TrafficFilterList/0/RemoteAddressRanges = 10.60.4.20/32
TrafficFilterList/0/RemotePortRanges    = 443
RouteList/0/Address                     = 10.60.4.0/24

Los valores de puerto de esa lista describen el puerto del servicio en el extremo remoto, y el puerto local debe quedar sin restringir para que el puerto de origen efímero del cliente no se filtre. Hacerlo al revés produce una regla que no coincide con nada y un rompecabezas que se lleva una tarde.

Escribe la ruta y el filtro como dos decisiones separadas. La ruta decide que se llega a este servidor por el túnel, y el filtro decide qué servicios pueden usar ese camino.

Demuestra ambos resultados con dos solicitudes

Prueba el flujo permitido y el flujo denegado por separado, y lee el fallo en lugar de la página que falta. Un rechazo que llega rápido es una decisión de directiva, mientras que un tiempo de espera es más probablemente una ruta que falta o un servicio que no escucha. Los comandos de abajo ejecutan ambas solicitudes y muestran las reglas vigentes.

Test-NetConnection 10.60.4.20 -Port 443
Test-NetConnection 10.60.4.20 -Port 445
Get-NetIPsecRule -DisplayName *Vpn*
Get-VpnConnection -Name Corp

Un rechazo rápido en la prueba SMB con una prueba HTTPS correcta es el resultado que el filtro debía producir. Un rechazo en ambos puertos significa que a la lista le falta algo que la sesión necesita, y un tiempo de espera en ambos apunta al enrutamiento más que al filtrado. Si los flujos protegidos muestran ninguna asociación de seguridad en la salida de IPsec, el requisito de protección no se cumple aunque la conexión tenga éxito. Lee las cuatro salidas juntas, porque cada una por separado sostiene una historia distinta.

Registra el perfil efectivo, el conjunto de reglas y la directiva del par junto con los resultados. Las notas históricas de compatibilidad sobre clientes de Windows antiguos no describen qué admiten las funciones de perfil administrado de hoy en una puerta de enlace concreta. El comportamiento específico de cada versión pertenece al registro, no a la suposición.