Clientes VPN bloqueados pelo perfil Público da firewall do Windows

O seu túnel está ativo, o gateway responde ao ping e a partilha de ficheiros continua a expirar. Esta combinação raramente é um problema de encaminhamento: o Windows colocou a sub-rede do adaptador VPN no perfil Público, e todas as regras de permissão escritas para Privado ou Domínio nunca foram aplicadas. Já encontrei isto em portáteis que chegam ao escritório sem problemas e em servidores RRAS que servem todos os outros clientes, e a reparação é curta assim que se identifica o perfil em causa. Esta é a ordem em que trabalho, com a verificação que lhe diz quando parar antes do passo seguinte.

Descobrir em que perfil o tráfego chega realmente

A firewall do Windows não tem um único modo global. Cada interface ligada transporta uma categoria, e os pacotes de entrada são filtrados contra a categoria da interface por onde chegam, pelo que é o perfil do adaptador VPN que decide a que pode chegar um cliente em túnel, e não o adaptador Wi-Fi ou Ethernet ao lado. Leia os dois factos antes de alterar o que quer que seja:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

Numa instalação padrão de OpenVPN ou WireGuard, o adaptador VPN aparece como uma rede não identificada e cai em Público, que é o valor predefinido para qualquer rede que o Windows não consiga classificar: nenhum controlador de domínio respondeu sobre ela e nenhum perfil de gateway correspondeu. O nome da interface é irrelevante aqui, por isso chamar ao adaptador «VPN» ou «Corp» não muda nada. DomainAuthenticated exige uma máquina associada ao domínio , que consiga realmente alcançar um controlador de domínio através dessa interface; um túnel dividido que transporte apenas uma sub-rede não satisfaz o requisito.

Se a regra de que precisa já está limitada ao pool de VPN e já se aplica à categoria que acabou de ler, pare aqui: a filtragem não é a sua camada, e o próximo sítio a ver é a configuração do serviço. Essa verificação leva dez segundos e poupa uma hora de edição de regras. Os nomes das categorias e o que cada uma cobre estão documentados na referência de Get-NetConnectionProfile.

Confirmar a filtragem, não o encaminhamento, antes de editar regras

O ping é um teste fraco. O ICMP pode passar enquanto a porta do serviço é descartada, e um anfitrião pode responder a partir da LAN recusando o mesmo pedido pelo túnel. Teste a porta de que o cliente precisa, a partir do cliente:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Se o teste à porta falhar, separe as duas camadas. Uma falha de túnel ou de rota costuma manifestar-se como nenhuma resposta do endereço do gateway, ao passo que um descarte da firewall mostra um gateway que responde e uma porta de serviço que não responde. Num servidor Windows que publica o pool através do RRAS, execute o mesmo teste a partir de um cliente e leia o perfil do próprio servidor: a interface RAS pode estar numa categoria cujas regras de entrada nunca mencionam o intervalo de clientes, e é por isso que a máquina serve a sua LAN e recusa todos os clientes em túnel.

Quando o resultado continuar ambíguo, registe os descartes do perfil em causa e leia-os:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

As entradas que nomeiam o endereço e a porta do cliente com DROP são conclusivas e também lhe dizem qual regra faltava. Um registo vazio enquanto o SYN do cliente nunca aparece aponta para montante do anfitrião, por isso volte ao túnel, à regra NAT ou à rota do pool antes de tocar noutro objeto da firewall.

Limitar uma regra de entrada ao pool de clientes

A reparação é uma única regra de permissão de entrada cujo endereço remoto é o pool, não o mundo inteiro. A partir de uma sessão elevada:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Quando o serviço é um único binário, prefira uma regra limitada ao programa com -Program em vez de uma lista de portas; isso limita a exceção ao processo e também ao intervalo de origem.

A escolha do perfil é onde o mesmo erro se comete na direção contrária. -Profile Public chega quando o adaptador é Público e continua Público. -Profile Any é defensável quando o serviço tem de funcionar independentemente de como o Windows classifica o adaptador, mas apenas enquanto o âmbito remoto se mantiver. O que nunca é defensável é -RemoteAddress Any no perfil Público: essa regra acompanha o portátil em cada rede de café e de hotel a que se liga e abre a porta a quem quer que partilhe essa sub-rede.

Registe o pool ao lado da regra. -RemoteAddress 10.8.0.0/24 deixa silenciosamente de corresponder no dia em que o pool de VPN é renumerado, e a falha parece exatamente o bug original, e é por isso que custa uma segunda tarde. Dê às regras o nome do serviço e do intervalo de origem, mantenha-as juntas com -Group, e releia-as sempre que a definição do pool mudar. Um inventário de regras que consegue auditar num único ecrã vale mais do que uma regra correta que ninguém encontra.

Alterar a categoria apenas quando a categoria é a decisão

Mudar a interface para Privado também funciona, e é o padrão errado. O perfil Privado transporta uma longa lista de regras de permissão incorporadas, que cobrem partilha de ficheiros e impressoras, descoberta de rede, ambiente de trabalho remoto e mais conforme a linha de base, pelo que reclassificar o adaptador VPN ativa-as todas de uma vez para cada cliente do túnel. Uma regra limitada concede um serviço a um intervalo. Num portátil que também se liga a redes não fidedignas, essa diferença não é cosmética.

Há casos em que a classificação está genuinamente errada: um túnel sempre ativo ou site-to-site que transporta uma sub-rede de escritório é infraestrutura fidedigna, e marcar esse adaptador como Privado é uma decisão de conceção legítima, tomada uma vez por política e não por ticket. Quando o fizer, faça-o de forma explícita:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Num dispositivo gerido, verifique primeiro se uma Política de Grupo ou uma linha de base MDM detém a definição. Se detiver, a alteração local é revertida na atualização seguinte e gpresult /h indicará a política que a detém; corrija-a aí, e não no endpoint.

Verificar nas duas pontas e deixar rasto

Verifique o fluxo que o utilizador comunicou, a partir do cliente, depois da alteração:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Depois feche o ciclo nas coisas que se vão partir na semana seguinte. Reinicie o anfitrião e teste de novo, porque uma regra limitada ao perfil errado continua a funcionar até o adaptador voltar noutra categoria. Teste a partir de um segundo cliente, pois um cliente com uma concessão antiga pode esconder uma divergência de pool. Conte as regras que acrescentou contra as que removeu, porque as exceções sobrepostas são a forma de uma correção de duas linhas se transformar numa política de filtragem que ninguém consegue rever.

Antes de considerar o trabalho concluído:

• O perfil indicado na regra é o perfil da interface por onde o tráfego chega.
• O âmbito remoto é o pool de VPN, e esse pool corresponde ao que o servidor entrega realmente.
• Nenhuma regra que acrescentou usa -RemoteAddress Any no perfil Público.
• Nada foi desativado para o teste passar, e qualquer alteração de categoria regista quem a aprovou.