Só o firewall do Windows como interruptor de emergência da VPN: aguenta?
As regras por tipo de interface podem bloquear os adaptadores físicos, mas um túnel de terceiros costuma parecer com fio. Verifique a classificação, a rota do ponto final e depois o DNS.
Pergunte se o firewall do Windows pode, sozinho, servir de interruptor de emergência e obterá duas respostas confiantes e incompatíveis. Uma diz que a regra por tipo de interface faz todo o trabalho; a outra, que não funciona sem scripts. Ambas descrevem metade do mesmo mecanismo. O firewall consegue expressar o bloqueio, e se o resultado realmente falha fechado depende de três coisas: como o Windows classifica o adaptador do túnel, se a exceção do ponto final sobrevive e se a resolução de nomes e o IPv6 estão cobertos. Erre em qualquer uma e a máquina vaza ou perde toda a conectividade.
Três condições, nesta ordem
A primeira condição é a classificação, e ela decide se a regra que você quer é sequer expressável. As regras do firewall do Windows podem ser limitadas por tipo de interface: com fio, sem fio ou acesso remoto. Uma política que bloqueia o tráfego de saída nos tipos físicos e permite o túnel só funciona se o Windows reconhece o túnel como acesso remoto.
A segunda condição é a exceção do ponto final. Antes de existir qualquer túnel, o cliente precisa alcançar o servidor VPN pelo adaptador físico, então um bloqueio total nesse adaptador impede justamente a conexão que tornaria o bloqueio desnecessário. A exceção precisa nomear o servidor e a porta, e o pacote precisa sair pelo gateway físico em vez de entrar num túnel que ainda não está no ar.
A terceira é a cobertura. Um conjunto de regras que bloqueia IPv4 e esquece IPv6, ou que permite ao resolver local consultar o ponto final e portanto permite qualquer outra consulta, falha aberto exatamente na janela que o interruptor existe para cobrir. É uma lacuna de projeto, não um defeito do firewall. É também a lacuna que sobrevive a todo teste numa mesa.
A classificação é a primeira porta
Veja o que o Windows pensa dos adaptadores antes de escrever uma única regra. Uma conexão VPN nativa do Windows normalmente aparece como acesso remoto. Um cliente de terceiros que cria o próprio adaptador virtual costuma aparecer como com fio, o que significa que um bloqueio limitado a adaptadores com fio também bloqueia o túnel.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionO terceiro comando informa se já está em vigor um bloqueio de saída padrão, o que muda toda a forma do projeto. Se o padrão já é bloquear, você escreve regras de permissão em vez de exceções a uma base permissiva, e essa é uma postura muito mais fácil de raciocinar.
Se o seu adaptador de túnel se declara com fio, só o firewall não é a ferramenta certa para um projeto de falha fechada, e nenhum ajuste de regras muda isso. É o caso em que a segunda opinião de cada tópico do fórum está correta.
A exceção do ponto final precisa de uma rota, não só de uma regra
Suponha que a classificação funcione. A exceção são duas peças, e elas vivem em subsistemas diferentes. A regra do firewall permite o tráfego; a rota do host faz com que ele saia pela interface correta enquanto o túnel está desligado.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32Sem a rota, a exceção só ajuda enquanto uma rota padrão ainda aponta para o gateway físico. Quando o cliente instala a própria rota padrão e depois morre, os pacotes permitidos não têm para onde ir de forma sensata e a conexão não pode ser restabelecida. Essa falha parece um cliente quebrado e na verdade é uma rota ausente.
Mantenha a exceção tão estreita quanto o cliente permitir. Um endereço e uma porta são revisáveis; uma faixa que cobre toda a rede do provedor não é. Essa regra mais ampla também permite qualquer outra coisa hospedada no mesmo provedor, o que costuma ser mais do que você pretendia.
DNS e IPv6 são onde ele falha aberto
A resolução de nomes é o vazamento clássico. Se o ponto final for um nome de host, o cliente precisa resolvê-lo antes de o túnel existir, o que significa que o adaptador físico deve poder alcançar um resolver. Essa mesma permissão deixa sair qualquer outra consulta enquanto o túnel está desligado, e uma consulta basta para revelar o que você estava prestes a visitar.
IPv6 é o segundo. As regras escritas para IPv4 não cobrem a outra família, e muitos clientes instalam apenas rotas IPv4. Uma máquina com conectividade IPv6 nativa pode, portanto, continuar falando com a internet enquanto o lado IPv4 está firmemente bloqueado, e o interruptor informa sucesso o tempo todo.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
A terceira linha merece ser entendida em vez de contornada. Um firewall decide sobre pacotes, não sobre qual interface um aplicativo pediu para usar, e um programa que se vincula explicitamente pode ser difícil de conter. Isso é um argumento a favor de um interruptor do lado do cliente que opera abaixo do aplicativo, não de mais regras.
Teste parando o cliente, não puxando o cabo
O único teste significativo é o que imita a falha contra a qual você se protege. Pare o serviço, mate o processo ou desative o adaptador criado pelo cliente, e então tente alcançar a internet e um nome:
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443Os três deveriam falhar. Se o primeiro tiver êxito, o bloqueio não está em vigor; se o segundo tiver êxito onde o primeiro falhou, você tem um vazamento de DNS; se o terceiro tiver êxito, o IPv6 não está coberto. Cada resultado aponta exatamente para uma das lacunas acima.
Repita o teste após suspensão e retomada, porque o perfil do firewall pode mudar quando o Windows decide que uma rede é pública ou privada, e as regras limitadas a um perfil o acompanham. Um projeto que aguenta numa mesa e falha no trem é um projeto testado uma vez.
Se a porta de classificação ou a exigência de DNS tornam a abordagem somente firewall inviável, um interruptor do lado do cliente é a resposta honesta. Se o túnel termina num roteador, a política deveria pertencer ao roteador, porque uma regra ali cobre cada dispositivo atrás dele e não depende de como o Windows nomeia um adaptador.