Adicionar uma regra de permissão RDP não reduz o seu acesso VPN

O plano parece razoável: deixe a permissão existente para a Área de Trabalho Remota como está e acrescente uma pequena para o único cliente VPN que deve ter acesso. O Firewall do Windows não funciona assim. As regras não são uma lista ordenada em que ganha a entrada mais específica, e uma permissão estreita ao lado de uma ampla não muda nada, porque a ampla continua a admitir todos os que já admitia. Restringir o serviço significa editar a permissão que já faz o trabalho.

A regra que acrescenta não é a regra que importa

O Firewall do Windows avalia todas as regras de entrada aplicáveis nos arquivos de políticas que se aplicam à máquina e depois decide se alguma permissão corresponde e se algum bloqueio a anula. Acrescentar uma regra acrescenta uma permissão; não remove nem especifica as permissões que já existem.

Portanto, a pergunta nunca é o que acrescentou. É o que contém a política efetiva depois de a política local, a política de domínio e os valores predefinidos do perfil serem combinados. Uma estação de trabalho com uma única regra local é fácil de raciocinar; um servidor associado a um domínio não é.

É também por isso que um administrador pode fazer uma alteração que parece correta, testá-la a partir da máquina errada e concluir que funcionou. A origem excluída nunca foi testada. Um teste que só prova sucesso prova menos de metade daquilo para que a alteração servia.

Descubra qual endereço o servidor vê

Antes de delimitar qualquer coisa, observe uma sessão permitida no anfitrião Windows e registe o endereço de origem que o servidor comunica. Não é sempre o endereço que o cliente pensa ter.

Se a gateway VPN preserva os endereços dos clientes, o servidor vê o endereço do túnel do cliente, e uma regra limitada por endereço faz sentido. Se a gateway traduz, cada cliente chega como o endereço da gateway, e limitar a esse endereço dá acesso a todos os clientes atrás dela. Então a regra é precisa sobre a coisa errada.

Estes dois desenhos precisam de respostas diferentes. O primeiro pode ser expresso numa regra de firewall; o segundo tem de ser aplicado onde a identidade ainda existe, ou seja, na própria VPN ou numa gateway autenticada à frente do serviço.

Um filtro de firewall não consegue recuperar uma identidade que a tradução de rede descartou, por muito cuidado com que o endereço seja escrito.

Mude o proprietário da regra efetiva

Inspecione a política de entrada efetiva e encontre cada regra que atualmente admite tráfego RDP, incluindo regras cujo nome apresentado nunca menciona a porta 3389. As regras limitadas por serviço e por aplicação também contam, tal como o transporte UDP que algumas implementações de RDP ativam.

Depois edite as regras existentes através do arquivo de políticas que as possui. Uma edição local de uma regra que a política de domínio também define pode ser combinada, ignorada ou substituída, e vale a pena saber qual desses casos acontece antes de confiar nela.

Estes comandos encontram as regras ativas, mostram o filtro de endereços associado a uma delas e pré-visualizam uma alteração 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 aqui são marcadores para o que a revisão encontrou, e o indicador de pré-visualização existe para que um erro de escrita num endereço não o deixe fora do servidor que está a editar.

Bloquear e depois permitir é um modelo diferente

O hábito de outras firewalls é escrever um bloqueio amplo e depois uma permissão estreita por cima. No Windows um bloqueio explícito geralmente ganha a uma permissão, pelo que essa ordem produz um serviço a que ninguém consegue chegar em vez de uma exceção para um cliente. O resultado é uma interrupção que parece um serviço RDP avariado. Na realidade é um erro de precedência, e a correção é remover o bloqueio em vez de acrescentar outra permissão.

Mantenha o comportamento predefinido de bloqueio de entrada nos perfis ativos e, em vez disso, restrinja as permissões específicas. Isso deixa a máquina com uma postura compreensível em vez de duas regras contraditórias cuja interação depende de detalhes de precedência.

Comprove-o com uma segunda origem

Teste a partir do cliente permitido e de uma origem que agora deve falhar. Uma única ligação bem-sucedida prova apenas que o caminho permitido funciona; não diz nada sobre a exclusão que acabou de fazer.

Repita o teste por IPv6 se o servidor o tiver ativado, porque uma intenção apenas IPv4 pode coexistir com uma permissão IPv6 ampla que ninguém olhou.

Por fim, mantenha a autenticação separada da acessibilidade. A Autenticação ao Nível da Rede, os direitos da conta e as restrições de início de sessão continuam a decidir quem pode usar a sessão, e a firewall decide apenas quem pode perguntar. Remover um dispositivo mais tarde deve remover tanto a sua inscrição VPN como esta permissão de rede, ou o endereço que delimitou acabará por pertencer a outra pessoa.