Añadir una regla de permiso para RDP no reduce tu acceso por VPN

El plan suena razonable: deja intacto el permiso existente para Escritorio remoto y añade uno pequeño para el único cliente VPN que debería tener acceso. El Firewall de Windows no funciona así. Las reglas no son una lista ordenada en la que gana la entrada más específica, y un permiso estrecho junto a uno amplio no cambia nada, porque el amplio sigue admitiendo a todos los que ya admitía. Restringir el servicio significa editar el permiso que ya hace el trabajo.

La regla que añades no es la regla que importa

El Firewall de Windows evalúa todas las reglas de entrada aplicables en los almacenes de directivas que afectan al equipo y luego decide si alguna permite el tráfico y si algún bloqueo la anula. Añadir una regla añade un permiso; no elimina ni matiza los permisos que ya existen.

Así que la pregunta nunca es qué has añadido. Es qué contiene la directiva efectiva después de fusionar la directiva local, la directiva de dominio y los valores predeterminados del perfil. Una estación de trabajo con una sola regla local es fácil de razonar; un servidor unido a un dominio, no.

Por eso también un administrador puede hacer un cambio que parece correcto, probarlo desde el equipo equivocado y concluir que funcionó. El origen excluido nunca se probó. Una prueba que solo demuestra el éxito demuestra menos de la mitad de aquello para lo que servía el cambio.

Averigua qué dirección ve el servidor

Antes de delimitar nada, observa una sesión permitida en el host de Windows y anota la dirección de origen que informa el servidor. No siempre es la dirección que el cliente cree tener.

Si la pasarela VPN conserva las direcciones de los clientes, el servidor ve la dirección del túnel del cliente y una regla limitada por dirección tiene sentido. Si la pasarela traduce, cada cliente llega como la dirección de la pasarela, y limitar a esa dirección da acceso a todos los clientes que hay detrás. Entonces la regla es precisa sobre lo equivocado.

Esos dos diseños necesitan respuestas distintas. El primero puede expresarse en una regla de firewall; el segundo debe aplicarse donde la identidad todavía existe, es decir, en el propio VPN o en una pasarela autenticada delante del servicio.

Un filtro de firewall no puede recuperar una identidad que la traducción de red descartó, por mucho cuidado con que se escriba la dirección.

Cambia el propietario de la regla efectiva

Inspecciona la directiva de entrada efectiva y encuentra cada regla que actualmente admite tráfico RDP, incluidas las reglas cuyo nombre para mostrar nunca menciona el puerto 3389. Las reglas limitadas por servicio y por aplicación también cuentan, y también el transporte UDP que habilitan algunas implementaciones de RDP.

Después edita las reglas existentes a través del almacén que las posee. Una edición local de una regla que también define la directiva de dominio puede fusionarse, ignorarse o sobrescribirse, y vale la pena saber cuál de esos casos ocurre antes de confiar en ella.

Estos comandos encuentran las reglas activas, muestran el filtro de direcciones asociado a una de ellas y previsualizan un cambio de ámbito:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

Los nombres de regla aquí son marcadores de lo que encontró la revisión, y el indicador de previsualización existe para que una errata en una dirección no te deje fuera del servidor que estás editando.

Bloquear y luego permitir es un modelo distinto

La costumbre de otros firewalls es escribir un bloqueo amplio y luego un permiso estrecho encima. En Windows un bloqueo explícito generalmente gana a un permiso, así que ese orden produce un servicio al que nadie puede llegar en lugar de una excepción para un cliente. El resultado es una interrupción que parece un servicio RDP roto. En realidad es un error de precedencia, y el arreglo es quitar el bloqueo en lugar de añadir otro permiso.

Mantén el comportamiento predeterminado de bloqueo de entrada en los perfiles activos y, en su lugar, restringe los permisos concretos. Eso deja el equipo con una postura comprensible en lugar de dos reglas contradictorias cuya interacción depende de detalles de precedencia.

Demuéstralo con un segundo origen

Prueba desde el cliente permitido y desde un origen que ahora debería fallar. Una sola conexión correcta demuestra solo que la ruta permitida funciona; no dice nada sobre la exclusión que acabas de hacer.

Repite la prueba por IPv6 si el servidor lo tiene habilitado, porque una intención solo para IPv4 puede convivir con un permiso amplio para IPv6 que nadie miró.

Por último, mantén la autenticación separada de la accesibilidad. La autenticación de nivel de red, los derechos de la cuenta y las restricciones de inicio de sesión siguen decidiendo quién puede usar la sesión, y el firewall solo decide quién puede preguntar. Quitar un dispositivo más adelante debería quitar tanto su inscripción en el VPN como este permiso de red, o la dirección que delimitaste acabará perteneciendo a otra persona.