LocalSubnet numa regra de firewall SMB não abrange clientes VPN

Os desktops do escritório chegam à partilha, os utilizadores de VPN ficam sem tempo, e a mesma conta funciona a partir de um hotspot do telemóvel. As permissões da partilha raramente são a diferença; o endereço que chega ao servidor de ficheiros costuma ser. Uma regra limitada a LocalSubnet admite as sub-redes próprias ligadas ao servidor, e um pool VPN encaminhado à parte não é uma delas. Dois desenhos fecham a lacuna, e deixam registos muito diferentes.

Dois desenhos, um sintoma

O primeiro desenho adiciona o pool VPN à condição de endereço remoto da regra. O servidor vê então o endereço de túnel de cada cliente, pelo que os seus registos podem distinguir um utilizador remoto de outro. O segundo desenho encaminha o tráfego VPN através de uma gateway que o traduz para um endereço LAN antes de o servidor o ver. Isso restaura a conectividade e remove a distinção no mesmo passo.

A tabela descreve papéis e não endereços, e são os seus próprios prefixos que decidem que linha se aplica. Imprima os valores reais do servidor em vez de copiar um exemplo de uma publicação de blogue:

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength

A tabela é uma ajuda à decisão, não uma afirmação sobre cada implementação. Um anfitrião com interfaces extra, uma segunda ligação de site ou outra máscara tem um conjunto local diferente.

A referência New-NetFirewallRule da Microsoft documenta as condições de endereço remoto e a palavra-chave LocalSubnet. Leia-a antes de decidir que a palavra-chave significa todos os endereços privados, porque não significa.

Compare o que o servidor recebe realmente

Leia a regra efetiva em vez daquela que alguém julga ter criado. Verifique que está ativada, que se aplica ao perfil ativo e que a sua condição de endereço remoto corresponde à origem que o servidor vê. Uma regra ativada apenas no perfil Domain não faz nada quando o adaptador passou para Public após uma mudança de rede.

Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

O primeiro comando imprime os filtros de endereço associados às regras de partilha de ficheiros, e o segundo mostra que perfis estão ativos e como é tratado o tráfego de entrada não correspondente. Procure também uma regra de bloqueio e uma política gerida centralmente. As regras de bloqueio têm precedência sobre as de permissão, e uma política que desativa a fusão de regras locais pode tornar inerte uma nova exceção local.

É o caso em que a regra parece correta na consola e não tem qualquer efeito sobre o tráfego. Verifique a atribuição de perfil ao mesmo tempo, porque um portátil que se juntou a outra rede pode passar para o perfil Public sem que ninguém toque na firewall.

Teste o transporte antes do início de sessão

Separe a acessibilidade da autenticação. Um listener em TCP 445 prova que um serviço está ligado à porta; não prova que um pacote remoto consiga chegar-lhe. Uma ligação TCP concluída, por sua vez, ainda nada diz sobre a configuração da sessão SMB ou as permissões da partilha. Teste o handshake dos dois lados antes de editar uma regra.

Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed

O primeiro comando indica se um handshake TCP tem êxito a partir da máquina onde o executa, e o segundo acrescenta o endereço resolvido e os detalhes da interface. Execute-o a partir do cliente VPN e de um desktop do escritório, e compare. O ping não responde a nenhuma das perguntas, porque o ICMP pode estar bloqueado enquanto o SMB está aberto, ou permitido enquanto a firewall descarta 445.

Se o handshake falha apenas a partir da VPN, o âmbito de origem é o principal suspeito. Se tem êxito e a partilha continua a recusá-lo, passe ao diagnóstico da sessão e das permissões SMB em vez de editar regras de firewall.

Quando o NAT de origem elimina a distinção

Com tradução no caminho, o servidor não consegue distinguir clientes VPN individuais pelo endereço. Cada utilizador remoto chega como a gateway. Qualquer autorização que dependa de os distinguir tem de ser aplicada onde as suas identidades ainda são visíveis, o que normalmente significa o concentrador VPN ou um proxy autenticador. A regra de firewall pode admitir tráfego; não pode restaurar uma distinção que a tradução removeu.

Depois de esse endereço de gateway ser permitido, cada utilizador remoto fica registado sob um único endereço, pelo que a regra concede o pool inteiro a quem consiga chegar à gateway. Se uma decisão por utilizador for importante, mantenha os endereços originais visíveis ou transfira a decisão para uma camada que ainda conheça o utilizador. Caso contrário, cada utilizador remoto herda as permissões do único endereço que o servidor consegue ver, e o rasto de auditoria deixa de os conseguir distinguir. Isso é uma decisão de desenho, não um detalhe da firewall.

Escolha deliberadamente entre os dois desenhos. Limite a regra ao pool VPN real quando o servidor tem de ver quem se ligou, e aceite o caminho traduzido apenas quando o servidor realmente não precisa dessa informação. Registe o intervalo de origem escolhido junto à regra, porque a próxima pessoa a depurar isto vai olhar primeiro para a tabela de endereços.