Por que o adaptador VPN fica no perfil público da firewall

O túnel está ativo, a conta foi autenticada no domínio e o Windows continua a etiquetar a ligação como pública. Por isso, uma regra da firewall escrita para o perfil de domínio não se aplica e a partilha de ficheiros permanece inacessível. A tentativa habitual de correção é colocar o adaptador em privado, o que altera as regras aplicáveis sem alterar nada na autenticação. Tanto a etiqueta como a correção são amplamente mal compreendidas, e separá-las exige três comandos.

A conta que se ligou não é a categoria da rede

Durante uma ligação VPN são tomadas duas decisões diferentes e é fácil confundi-las. O gateway decide se a conta pode ligar-se. O Windows decide como classificar a rede resultante, e essa classificação determina que regras da firewall se aplicam à interface.

Uma autenticação de domínio bem-sucedida no gateway é uma prova sobre a conta. Não é prova de que o ponto final tenha autenticado a rede junto de um controlador de domínio, e é exatamente isso que a categoria de domínio representa.

É por isso que uma máquina pode estar integrada num domínio, ligar-se com uma conta de domínio e ainda assim mostrar Público. A classificação é uma determinação local sobre a rede, não uma afirmação sobre as credenciais que abriram o túnel. A conta pode ser perfeitamente válida enquanto a etiqueta fica onde começou.

Três categorias, uma das quais não pode definir

O Windows expõe três categorias e apenas duas podem ser atribuídas por um administrador. A terceira é decidida pelo sistema operativo depois de autenticar a rede com êxito junto de um controlador de domínio.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

O terceiro comando falha, e esse é o comportamento documentado e não um problema de permissões. A referência do próprio cmdlet indica que a categoria de domínio não pode ser atribuída desta forma, porque o Windows a deriva da autenticação de domínio. Ver o erro é uma confirmação útil de que a categoria é uma consequência e não uma definição.

Leia o primeiro comando no ponto final cujo tráfego está bloqueado. A classificação da interface do próprio gateway não diz nada sobre como cada estação de trabalho que se liga classificou o seu túnel.

As regras seguem o perfil para o qual foram escritas

Depois de conhecer a categoria, o acesso em falta costuma explicar-se sozinho. Cada regra da firewall do Windows tem um âmbito de perfil, e uma regra limitada ao domínio não se aplica quando a interface é pública. Três comandos transformam isso numa resposta e não numa teoria, e o terceiro apanha o caso em que o perfil nunca foi o problema:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

O segundo comando é o que transforma um relatório vago numa correção. Se a regra estiver limitada a um intervalo de endereços remotos que não inclui o conjunto de VPN, mudar o perfil também não ajudará.

Verifique também a ação de entrada predefinida. Numa máquina onde a entrada está bloqueada por predefinição, uma regra de permissão ausente produz silêncio em vez de recusa. Do lado do cliente isso parece idêntico a uma falha de encaminhamento, e é por isso que tantos destes pedidos começam com a suposição errada.

Determine que máquina aplica a regra

Antes de mudar uma categoria, estabeleça onde está a ocorrer o bloqueio. O servidor que aloja a partilha pode ter a sua própria firewall, e as suas regras aplicam-se ao tráfego que chega do conjunto de VPN, independentemente de como o cliente etiquetou o adaptador. Uma recusa ali é invisível para qualquer comando local que execute, e o lado do cliente apenas relata que o recurso não está disponível. Teste as regras próprias do destino antes de tocar na classificação do cliente.

Teste do cliente para a porta específica e depois compare com um teste a partir de outro anfitrião na mesma VPN. Se ambas falharem, o problema está no destino ou no caminho. Se apenas uma falhar, a diferença é local a essa máquina e a categoria de perfil torna-se uma causa plausível.

Tenha também em conta a direção. Uma regra que permite SMB de entrada não faz nada por um cliente cuja própria regra de saída bloqueia o mesmo tráfego. A partir de uma janela do Explorador de ficheiros as duas falhas são indistinguíveis, por isso teste cada direção separadamente antes de editar o que quer que seja.

O que fazer em vez de reetiquetar tudo

Tornar privada uma rede não identificada para satisfazer uma regra ampla é uma alteração real com consequências reais. O perfil privado normalmente permite mais descoberta e mais tráfego de entrada do que o público.

Se o objetivo é deixar um serviço específico chegar aos clientes VPN, limite a regra por endereço remoto em vez de por perfil. Isso exprime a intenção com precisão, funciona independentemente da classificação e não depende de o Windows adivinhar corretamente um adaptador virtual. Sobrevive também a uma atualização do cliente que reclassifique a interface. Escreva o conjunto na regra e a pessoa seguinte poderá ler a intenção sem perguntar.

Se a categoria de domínio é realmente esperada e nunca aparece, isso é uma investigação separada. Verifique se a máquina está integrada no domínio, se consegue chegar a um controlador de domínio através do túnel e se o canal seguro está saudável. Esses três comandos respondem a isso sem uma única alteração ao registo:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Esses três respondem se o ponto final poderia ter autenticado a rede. Se não conseguir chegar a um controlador, a categoria de domínio nunca será atribuída, por muitas vezes que o adaptador seja reiniciado. A regra da firewall que estava a seguir nunca foi o problema real, e a etiqueta era um sintoma de um caminho quebrado, não uma causa.