Engadir unha regra de permiso para RDP non reduce o teu acceso por VPN

O plan soa razoable: deixa intacto o permiso existente para Escritorio remoto e engade un pequeno para o único cliente VPN que debería ter acceso. O Firewall de Windows non funciona así. As regras non son unha lista ordenada na que gaña a entrada máis específica, e un permiso estreito xunto a un amplo non cambia nada, porque o amplo segue admitindo a todos os que xa admitía. Restrinxir o servizo significa editar o permiso que xa fai o traballo.

A regra que engades non é a regra que importa

O Firewall de Windows avalía todas as regras de entrada aplicables nos almacéns de directivas que afectan o equipo e despois decide se algunha permite o tráfico e se algún bloqueo a anula. Engadir unha regra engade un permiso; non elimina nin matiza os permisos que xa existen.

Así que a pregunta nunca é que engadiches. É que contén a directiva efectiva despois de fusionar a directiva local, a directiva de dominio e os valores predeterminados do perfil. Unha estación de traballo cunha soa regra local é doada de razoar; un servidor unido a un dominio, non.

Por iso tamén un administrador pode facer un cambio que parece correcto, probalo desde o equipo equivocado e concluír que funcionou. A orixe excluída nunca se probou. Unha proba que só demostra éxito demostra menos da metade daquilo para o que servía o cambio.

Averigua que enderezo ve o servidor

Antes de delimitar nada, observa unha sesión permitida no host de Windows e anota o enderezo de orixe que informa o servidor. Non sempre é o enderezo que o cliente cre que ten.

Se a pasarela VPN conserva os enderezos dos clientes, o servidor ve o enderezo do túnel do cliente e unha regra limitada por enderezo ten sentido. Se a pasarela traduce, cada cliente chega como o enderezo da pasarela, e limitar a ese enderezo dá acceso a todos os clientes que hai detrás. Entón a regra é precisa sobre o equivocado.

Eses dous deseños necesitan respostas distintas. O primeiro pódese expresar nunha regra de firewall; o segundo debe aplicarse onde a identidade aínda existe, é dicir, no propio VPN ou nunha pasarela autenticada diante do servizo.

Un filtro de firewall non pode recuperar unha identidade que a tradución de rede descartou, por moi coidadosamente que se escriba o enderezo.

Cambia o propietario da regra efectiva

Inspecciona a directiva de entrada efectiva e atopa cada regra que actualmente admite tráfico RDP, incluídas as regras cuxo nome para amosar nunca menciona o porto 3389. As regras limitadas por servizo e por aplicación tamén contan, e tamén o transporte UDP que habilitan algunhas implementacións de RDP.

Despois edita as regras existentes a través do almacén que as posúe. Unha edición local dunha regra que tamén define a directiva de dominio pode fusionarse, ignorarse ou sobrescribirse, e paga a pena saber cal deses casos ocorre antes de confiar nela.

Estes comandos atopan as regras activas, amosan o filtro de enderezos asociado a unha delas e 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

Os nomes de regra aquí son marcadores do que atopou a revisión, e o indicador de previsualización existe para que unha errata nun enderezo non te deixe fóra do servidor que estás editando.

Bloquear e despois permitir é un modelo distinto

A costume doutros firewalls é escribir un bloqueo amplo e despois un permiso estreito encima. En Windows un bloqueo explícito xeralmente gaña a un permiso, así que esa orde produce un servizo ao que ninguén pode chegar en lugar dunha excepción para un cliente. O resultado é unha interrupción que parece un servizo RDP roto. En realidade é un erro de precedencia, e a solución é quitar o bloqueo en lugar de engadir outro permiso.

Mantén o comportamento predeterminado de bloqueo de entrada nos perfís activos e, no seu lugar, restrinxe os permisos concretos. Iso deixa o equipo cunha postura comprensible en lugar de dúas regras contraditorias cuxa interacción depende de detalles de precedencia.

Demóstrao cunha segunda orixe

Proba desde o cliente permitido e desde unha orixe que agora debería fallar. Unha soa conexión correcta demostra só que a ruta permitida funciona; non di nada sobre a exclusión que acabas de facer.

Repite a proba por IPv6 se o servidor o ten habilitado, porque unha intención só para IPv4 pode convivir cun permiso amplo para IPv6 que ninguén mirou.

Por último, mantén a autenticación separada da accesibilidade. A autenticación de nivel de rede, os dereitos da conta e as restricións de inicio de sesión seguen decidindo quen pode usar a sesión, e o firewall só decide quen pode preguntar. Quitar un dispositivo máis adiante debería quitar tanto a súa inscrición no VPN como este permiso de rede, ou o enderezo que delimitaste acabará pertencendo a outra persoa.