Duas apps VPN ao mesmo tempo: qual kill switch se aplica realmente?
Um segundo cliente VPN nunca herda o kill switch do primeiro. Três condições decidem qual política se aplica e como verificar a sua.
Dois clientes VPN podem funcionar lado a lado, mas os seus kill switches não se fundem numa única política. Cada cliente instala regras para o seu próprio túnel, e nenhum sabe que o outro existe. Aconteceu-me com um cliente de trabalho ligado primeiro: a segunda aplicação não conseguia terminar o handshake, ficou em «Connecting» durante dez minutos e o primeiro túnel transportou tudo em silêncio. Se a segunda aplicação fica protegida depende de três condições, não de ambos os ícones dizerem «Ligado».
A que âmbito está realmente limitado um kill switch
Nada no sistema operativo tem um único sinalizador de kill switch. Um cliente que anuncia um instala um conjunto de regras: descartar tudo o que não saia pelo meu túnel e, muitas vezes, fechar em falso quando o túnel desaparece. No Linux é normalmente uma cadeia nftables ou iptables, no Windows um conjunto de filtros do Windows Filtering Platform, no Android e iOS o encaminhamento próprio do serviço de túnel mais a definição do sistema que bloqueia ligações sem VPN. O guia de VPN do Android descreve esse modelo de serviço, se quiser a visão da plataforma.
O âmbito é a parte que importa. Uma regra como permitir apenas pacotes na interface de saída wg0 não se importa se existe um segundo túnel. Se outro cliente levantar wg1, as regras do primeiro cliente tratam esses pacotes como tráfego normal: habitualmente descartados, ocasionalmente permitidos. De qualquer forma, é o primeiro cliente que decide, e não faz ideia de que uma segunda aplicação está à espera.
Três condições que decidem quem fica coberto
Não precisa de enumerar todas as combinações. Três perguntas resolvem-no em poucos minutos.
- A plataforma permite sequer um segundo túnel? A maioria dos telefones Android e dos iPhone aceita apenas um serviço VPN ativo por perfil de utilizador, pelo que a segunda aplicação nunca tem um túnel nem aplica nada. Fica com uma só política, a da aplicação que ganhou o lugar.
- Que processo é dono da rota predefinida? O Windows, o macOS e o Linux transportam dois túneis sem problema. A rota predefinida pertence ao cliente que a configurou por último ou com a melhor métrica, e o outro cliente está ligado mas inativo. No Linux, o modo de rota predefinida do wg-quick usa encaminhamento por política com uma tabela privada e uma regra fwmark, pelo que um segundo túnel wg-quick acrescenta uma regra concorrente em vez de substituir a primeira.
- O segundo cliente consegue chegar ao seu próprio servidor? Se o primeiro kill switch for de negação por omissão, o ponto final exterior da segunda aplicação é apenas mais um destino descartado. Volta a tentar em silêncio e nunca reporta um erro.
A versão curta, para os fóruns de suporte:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Duas dessas linhas parecem idênticas a partir do ícone da bandeja, e é por isso que o ícone é a pior prova disponível aqui.
O que falha primeiro, e como se parece
Um cliente preso em «Connecting» enquanto o outro está saudável é quase sempre fome de ponto final: o kill switch em execução descarta o handshake do segundo cliente para o seu próprio servidor. Confirme-o a baixo custo pausando as regras de bloqueio do primeiro cliente durante uma tentativa. Se o segundo se ligar de imediato, a pergunta fica respondida.
O DNS é a segunda falha. Os clientes definem a configuração do resolvedor para a sua própria interface, e alguns substituem simplesmente a lista global. Com os dois túneis ativos, as consultas podem sair por um lado enquanto o resolvedor pertence ao outro. Desligue qualquer das aplicações e a sobrevivente fica com um servidor de nomes inalcançável: as páginas bloqueiam durante um minuto e depois voltam a resolver, enquanto a VPN continua a mostrar-se ligada.
A terceira é o oscilar de rotas. As reconexões reordenam a rota predefinida, e um kill switch ligado a uma interface não a segue. O tráfego que estava dentro do túnel há um momento corresponde agora a uma regra de descarte, o que do lado do utilizador se lê como uma VPN que deixa de funcionar ao acaso.
Verificar qual política está realmente em vigor
Faça isto com tráfego inofensivo, não com algo de que sentiria falta.
No Linux, pergunte ao kernel quem ganha e a que se liga a firewall. ip -4 route show default indica o túnel que detém a saída. ip rule show mostra se o encaminhamento por política está em jogo. sudo nft list ruleset | grep -n oifname mostra se os descartes estão ligados a um nome de interface, a uma marca ou a toda a cadeia de saída.
No Windows, a mesma história vive na métrica de rota e na lista de filtros: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric e Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". No macOS, netstat -rn -f inet | head -5 e scutil --dns | head -20.
Depois faça o passo que as pessoas saltam: pare o túnel de propósito e confirme que o tráfego que espera falhar falha mesmo. Um ícone ligado é um estado da interface, não uma imposição.
Quando dois clientes são o desenho errado
Se o único requisito por trás da segunda aplicação é mais proteção, remova-a. Duas políticas de bloqueio que interagem são menos previsíveis do que uma, e cada reconexão é uma oportunidade de acabar num estado que nenhum fornecedor testa.
Se precisa genuinamente de encadeamento, como um gateway empresarial alcançado por um salto comercial, escolha um desenho com um único ponto de imposição. Isso significa normalmente um router ou um único cliente que suporte a cadeia, não duas aplicações de ambiente de trabalho a competir pela mesma rota predefinida. Num dispositivo gerido, mantenha o cliente autorizado e trate tudo o resto como fora de âmbito, independentemente do que ele mostra na bandeja.
Lista de verificação antes de manter os dois
Percorra esta lista por ordem; o primeiro item que falhar é o que deve corrigir.
- Confirme que exatamente um cliente detém a rota predefinida e o resolvedor.
- Se quer o segundo cliente ativo, permita explicitamente o ponto final do seu servidor e volte a verificar após cada atualização do cliente.
- Anote o resultado esperado quando qualquer dos túneis cai e teste esse caso específico.
- Verifique o caminho de falha após um reinício, quando a ordem de arranque é diferente.
- Num perfil gerido, pare e pergunte ao proprietário antes de acrescentar seja o que for.
Se o terceiro passo falhar, a resposta honesta é que só um cliente lhe está a dar uma política. Decida de qual confia e deixe o outro ir.