Kill switch no Windows sem software extra: perfis ou rotas?

Os perfis da firewall seguem a categoria da rede, as rotas seguem o adaptador. Compare os dois e depois teste o caso de falha com o túnel ausente e o ícone a mentir.

O cliente morre a meio de um download e o ícone da bandeja desaparece. A transferência continua pela ligação de casa. É exatamente essa sequência que justifica a existência de um kill switch, e o Windows consegue aproximar-se de um sem um segundo produto.

Dois métodos merecem ser conhecidos. Falham em sítios diferentes, e nenhum é uma resposta completa.

Método um: permitir o programa num único perfil

A firewall do Windows limita as regras aos perfis Domain, Private e Public. O truque é dar uma categoria ao adaptador do túnel e outra ao adaptador físico. Depois escreve uma regra de saída que permite o programa protegido no perfil do túnel e o bloqueia em todos os outros locais. A firewall lê a categoria, não o nome do adaptador.

Primeiro ponha a ligação VPN em Private e a rede física em Public. Depois acrescente uma regra de bloqueio para o programa que se aplique aos perfis que não quer. A seguir confirme a atribuição com Get-NetConnectionProfile, porque é essa atribuição que a regra segue.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

A fraqueza é estrutural. Uma regra de perfil segue a categoria, por isso quando o Windows reclassifica uma rede de hotel o bloqueio pode deixar de se aplicar. Nada na lista de regras muda quando isso acontece.

Método dois: remover a rota predefinida física

A abordagem por rotas é mais grosseira e muito mais fácil de auditar. Anote o gateway físico, deixe a VPN instalar a sua própria rota predefinida com uma métrica mais baixa e depois elimine a predefinida física. Mais nada poderá transportar tráfego.

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

Quando o cliente morre, a rota da VPN desaparece com o seu adaptador. A máquina fica offline em vez de vazar, e é isso que um kill switch deve produzir.

Dois detalhes decidem se aguenta uma semana. O DHCP repõe o gateway sempre que a ligação oscila. Um adaptador físico com endereço estático evita essa surpresa. O endereço do próprio servidor VPN também tem de continuar alcançável. Sem esse caminho para o anfitrião o cliente nunca consegue voltar a ligar-se após a queda que ativou o bloqueio.

Método três: sem gateway, uma rota persistente para o anfitrião

A terceira opção começa por limpar o gateway das definições do adaptador. Depois substitui-o uma única rota persistente até ao ponto final da VPN. A máquina pode então falar com o servidor e com mais nada até o túnel subir.

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

Restaurar o gateway restaura a internet normal, o que torna isto num interruptor limpo de ligar e desligar. Não depende de um script que vigie eventos da interface. Também não se importa com a forma como a rede é categorizada.

O preço é um isolamento total enquanto o túnel está em baixo. As atualizações param, e o próprio download que motivou o exercício também. Num portátil de trabalho isso costuma estar certo, enquanto numa máquina pessoal é uma decisão a tomar deliberadamente.

Porque é que o ícone do globo não prova nada

O Windows comunica a acessibilidade através de uma sonda contra um ponto final da Microsoft. Essa sonda não diz nada sobre o seu túnel. Um túnel ligado pode estar atrás de um globo que comunica ausência de internet, e um morto pode mostrar uma ligação saudável.

Teste matando o processo do cliente e depois tente alcançar um endereço público por número. Uma consulta de nome pode ser respondida a partir da cache, por isso nem o ícone nem uma resposta DNS são prova.

O que registar após uma queda real

Execute o teste como uma sequência e não como uma verificação única. Mate o processo em vez de desligar e depois experimente um endereço numérico nas duas famílias. Restaure o cliente a seguir e confirme que ainda alcança o seu próprio servidor pela rota que manteve.

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

Repita a sequência após suspensão, após uma mudança de Wi-Fi e após a passagem de cabo para sem fios. É nessas transições que falham ao mesmo tempo o método do perfil e o comportamento do DHCP. Uma regra que aguenta numa secretária não aguenta necessariamente num hotel.

Escreva o passo de anulação ao lado de cada regra e rota. A Microsoft documenta a criação de regras de saída na sua referência de regras da firewall do Windows, e essa é uma fonte melhor do que um tutorial apenas com capturas de ecrã.

Artigos relacionados