Perfis de firewall versus saída VPN: por que público não é um caminho

A regra soa precisa: permitir o tráfego local no perfil privado e apenas o tráfego VPN no público. Não é, porque um perfil de rede escolhe qual conjunto de regras de firewall se aplica e não diz nada sobre qual adaptador transportou um pacote. Tratar o nome do perfil como requisito de caminho é o erro que faz um desenho de saída restrita parecer concluído quando não está.

Primeiro anote os fluxos, depois decida qual mecanismo pode realmente impor cada um deles. Essa lista de fluxos é o único artefato que sobrevive à próxima mudança de regras.

A categoria escolhe regras, não rotas

Quando o Windows classifica uma rede como pública ou privada, o firewall aplica o conjunto de regras configurado para esse perfil. A classificação segue a rede à qual o adaptador se conectou, e o conjunto de regras decide o que é permitido nela. Nenhum desses fatos depende de o tráfego de um aplicativo ter usado o túnel. É essa independência que constitui toda a dificuldade.

A escolha do caminho é feita pelo roteamento, pela métrica da interface e pelo prefixo que o túnel instala. Um perfil pode, portanto, estar rotulado como público enquanto a conexão de um aplicativo segue o caminho físico, e o firewall ainda assim relatará que o conjunto de regras público foi aplicado.

Por isso uma regra limitada ao perfil não pode significar apenas túnel. As duas propriedades são decididas por componentes diferentes e uma não pode substituir a outra.

Um bloqueio explícito prevalece sobre uma permissão mais estreita

As orientações da Microsoft sobre regras de firewall distinguem uma permissão como exceção a uma ação de bloqueio padrão de um bloqueio explícito que conflita com uma permissão. Os bloqueios explícitos vencem esse conflito, e as regras de saída obedecem à mesma precedência.

Assim, a receita popular de adicionar uma regra que bloqueia tudo e contar com uma permissão mais estreita colocada acima dela não faz o que seu autor espera. O Firewall do Windows não resolve o conflito pela ordem de regras atribuída pelo administrador. O bloqueio simplesmente se aplica, e o aplicativo que se conecta relata tempo esgotado. A regra que parecia a exceção nunca esteve em jogo.

A forma suportada é uma política de negação padrão com regras de permissão aprovadas, em que cada permissão nomeia um programa, um serviço ou um destino com precisão suficiente para ser revisada. Esse desenho sobrevive a uma auditoria, porque cada exceção é visível e nenhuma depende da ordem em que foi criada.

Duas regras que se contradizem são piores que uma só regra, porque o comportamento resultante é correto e inexplicável ao mesmo tempo.

Dê à política de saída um único proprietário

Um cliente VPN compatível já mantém seu próprio comportamento de bloqueio e suas próprias exceções de endpoint. Adicionar regras manuais não coordenadas pode deixar esse cliente fora do túnel de que precisa para se configurar, ou deixar aberto um segundo caminho que ninguém notou.

Decida quem é dono da política de saída antes de escrever regras: a configuração do próprio cliente, uma política de firewall gerenciada ou uma lista local de exceções documentada com um proprietário. Depois concilie as camadas em vez de empilhar experimentos até algo conectar. Um proprietário nomeado é também a quem se pergunta quando duas camadas discordam.

Preserve um canal de recuperação antes de mudar qualquer coisa. Uma máquina remota trancada fora do próprio caminho de gerenciamento é um resultado pior do que a lacuna de política que você estava fechando. A regra de recuperação é mais fácil de justificar quando está escrita de antemão, e mais fácil de encontrar quando uma mudança dá errado em uma hora que ninguém aprecia.

Teste quatro resultados em vez de ler o rótulo

Uma política vale o que valem os casos que ela distingue, então trate o rótulo do perfil como ponto de partida e não como resultado. Quatro resultados dizem se ela funciona: a solicitação LAN pretendida tem sucesso, uma solicitação de internet coberta tem sucesso, uma solicitação direta proibida falha, e o caso de falha do túnel se comporta como projetado em vez de recuar silenciosamente. Anote os quatro resultados ao lado da mudança de regras. Um plano de testes com quatro casos nomeados é curto o bastante para ser executado sempre e específico o bastante para falhar ruidosamente.

Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias
Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction
Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block |
  Select-Object DisplayName,Profile

O primeiro comando mostra como cada rede conectada é classificada, o que muitas vezes não é o que a pessoa que escreveu a regra supôs. O segundo mostra a ação padrão por perfil, e o terceiro lista os bloqueios de saída habilitados, incluindo os que anularão silenciosamente uma permissão mais estreita.

Execute os quatro casos novamente após uma mudança de rede, porque um perfil pode ser reclassificado quando a máquina entra em outra rede. Um rótulo de perfil correspondente não é prova de que o caminho era o que você pretendia.