Fail-open ou fail-closed: o que decide um kill switch de VPN
Os dois termos descrevem o que acontece quando o túnel já não existe, não quão forte é a cifragem. O âmbito que escolher decide se o tráfego vaza de facto.
O mito é que fail-closed é a configuração segura e fail-open a descuidada. Ambos descrevem o que acontece ao tráfego quando o túnel desaparece, e nenhum altera quão bem esse túnel cifra. Uma política fail-closed com uma longa lista de exceções pode vazar mais do que uma política fail-open num dispositivo que nunca sai da rede do escritório. Escolha o resultado que consegue explicar à pessoa que é dona do tráfego.
O rótulo descreve um resultado, não uma força
O vocabulário vem dos sistemas de controlo: fail-open permite a operação quando um componente falha, fail-closed nega-a. Aplicado a uma VPN, o componente que falha é o túnel, e a questão é se o tráfego pode continuar por outro caminho. A escolha da cifra, o comprimento da chave e o protocolo são decisões separadas.
A confusão persiste porque um kill switch soa a funcionalidade de segurança, e os fornecedores vendem-no como tal. Mecanicamente é uma regra de encaminhamento e de firewall que bloqueia o tráfego que o túnel devia transportar, implementada no cliente, no sistema operativo ou na gateway. A camada que a aplica também define a sua cobertura, e uma regra numa camada não cobre outra. Uma regra na gateway não pode proteger um portátil que já passou para outra rede.
Como é cada resultado
A mesma política pode comportar-se de forma muito diferente consoante a falha que encontrar, por isso compare os eventos e não os rótulos.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
A última linha é a que apanha quem presume que um kill switch é um único interruptor. Uma regra escrita para a tabela de rotas IPv4 deixa a rota predefinida IPv6 intacta, e a aplicação pode usá-la à vontade.
O âmbito decide se há fuga
Pergunte o que a política cobre antes de perguntar qual é o modo. Uma regra por aplicação protege uma app e mais nada, uma regra para todo o dispositivo protege tudo exceto as exceções, e uma regra na gateway só protege o tráfego que chega a essa gateway. O DNS precisa da sua própria decisão, porque uma consulta enviada a um resolvedor local pode revelar nomes mesmo quando a carga útil está bloqueada.
As exceções de rede local existem para impressoras, transmissão de ecrã e portais cativos, e cada uma é um buraco no bloqueio. Documente-as ao lado da política, porque quem herdar a configuração lerá fail-closed como absoluto caso contrário.
Reconectar e bloquear também são controlos separados. Um cliente pode reconectar-se automaticamente sem nunca bloquear, ou bloquear sem reconectar, e a combinação determina o que um utilizador vive durante uma interrupção.
Prove-o durante uma transição
Testar o estado estável não prova nada. Derrube o túnel de propósito e experimente a aplicação que devia estar protegida, e depois verifique se chegou à rede. Compare o indicador do cliente com o resultado, porque um indicador que ainda diz ligado é exatamente o caso para o qual a política existe. Se a aplicação protegida conseguir, o nome do modo não importa; tem uma fuga.
Repita desde um arranque a frio antes de iniciar sessão, numa mudança de Wi-Fi para rede móvel e com a app protegida em segundo plano. Se o bloqueio for aplicado pelo processo do cliente, teste também o que acontece quando esse processo é morto em vez de fechado de forma limpa.
Por fim, verifique o caminho de limpeza. Se um cliente for desinstalado enquanto as suas regras estão ativas, use o procedimento de remoção documentado pelo fornecedor em vez de desativar a firewall do sistema operativo, que remove proteção não relacionada sem responder a quem pertence a regra restante.