Encadear duas VPNs: o que isso esconde e quanto custa

Dois túneis aninhados não tornam você anônimo. Eles dividem as observações entre dois provedores, então nenhum dos dois vê seu endereço residencial e seu destino ao mesmo tempo. É um benefício real, porém estreito, e vem com problemas de roteamento, DNS e MTU que aparecem na primeira vez que você depende dele.

1. Decida para que serve o segundo salto

Escreva o objetivo em uma frase antes de configurar qualquer coisa. Se for para seu provedor de internet não ver quais sites você visita, um túnel basta. Se for para nenhum provedor sozinho conseguir ligar seu endereço ao seu tráfego, são necessários dois. Se for para ninguém conseguir identificar você, nenhum número de saltos chega lá.

A corrente é tão forte quanto o registro do provedor mais fraco e os dados de conta que ambos mantêm. Pagamentos, e-mail de cadastro e telemetria do aplicativo ficam totalmente fora do túnel.

2. Torne o endpoint interno alcançável através do túnel externo

A falha usual é que o túnel interno nunca estabelece. Uma conexão externa em modo túnel completo é dona da rota padrão, então a tentativa do cliente interno de alcançar seu próprio endpoint é engolida pelo túnel externo e descartada ou posta em laço. O endpoint interno precisa de uma rota explícita pela interface externa, instalada antes de o cliente interno iniciar. Caso contrário, o handshake corre contra a rota e perde.

O WireGuard mostra o mesmo conflito pelo outro lado. O AllowedIPs de cada peer decide quais destinos entram nesse túnel, então uma interface interna que reivindica todos os endereços também reivindica o endpoint externo, a menos que uma rota mais específica vença. AllowedIPs sobrepostos em duas interfaces é uma configuração em que um lado perde silenciosamente.

O encadeamento em contêineres torna a separação explícita e a armadilha óbvia. Um contêiner com seu próprio namespace, sua própria rota padrão e um cliente dentro dele encaminha o que o host envia a ele; o host não passa a usar esse caminho sozinho. Ative o encaminhamento, adicione uma rota para o túnel do contêiner e aponte o serviço para o endereço do contêiner.

3. Mantenha o DNS no mesmo caminho

O DNS tem de viajar para onde o tráfego viaja. Se o provedor interno empurra resolvedores e o host ainda consulta os locais, essas consultas revelam exatamente os sites que o túnel deveria esconder. Verifique com uma captura em cada interface de túnel em vez de confiar no painel de status do cliente. Um vazamento aqui é invisível na navegação normal e óbvio numa captura.

Projetos de DNS dividido tornam isso mais difícil, porque uma consulta a um nome local pode legitimamente pertencer fora do túnel. Escreva a lista de exceções de propósito, em vez de descobri-la pelo resolvedor que por acaso respondeu.

4. Defina o MTU antes que os usuários descubram por você

O MTU é a outra vítima previsível. Duas encapsulações subtraem dois cabeçalhos, e um túnel externo que já baixou o MTU do caminho deixa menos espaço dentro. Os sintomas são conhecidos: requisições pequenas passam, transferências grandes e handshakes TLS travam.

ip link set dev wg1 mtu 1280 é a solução bruta, e limitar o MSS no forwarder é a mais elegante. Repetir a conexão não é solução nenhuma.

5. Teste a falha que você realmente vai ter

Quebre o túnel externo de propósito e veja o que acontece. Uma corrente que cai silenciosamente para um caminho direto quando o salto externo morre é pior do que nenhuma corrente, porque vaza exatamente no momento em que você acreditava estar coberto. Um kill switch que para todo o tráfego é o comportamento a buscar. Registre o resultado, pois você não vai querer redescobri-lo no meio de um incidente.

Latência e um segundo ponto de falha são os custos permanentes. Dois saltos também significam duas filas de suporte quando algo quebra numa hora inconveniente.