Multi-hop no WireGuard com dois servidores seus: o que traz na realidade

O multi-hop é uma das funcionalidades mais eficazmente promovidas nas VPN comerciais: dois servidores em vez de um, para que nenhuma extremidade fique com o quadro completo. O raciocínio é sólido e vale a pena compreendê-lo bem antes de replicar a montagem em infraestrutura sua, porque aquilo que lhe dá valor não sobrevive ao auto-alojamento.

O que a técnica faz

O seu cliente liga-se ao servidor A. O servidor A não chega à internet em seu nome; reencaminha o seu tráfego, ainda cifrado, para o servidor B. É o servidor B que fala com o destino.

O benefício anunciado decorre de quem sabe o quê. O servidor A vê o seu endereço real mas apenas sabe que está a falar com B. O servidor B vê o destino mas recebe tráfego de A e não de si. Nenhum deles detém as duas metades.

É genuinamente assim que funciona, e é por isso que a funcionalidade existe.

Porque é que o auto-alojamento quebra o argumento

Eis a parte que o entusiasmo costuma saltar.

A separação acima só faz sentido se A e B forem operados de forma independente. Os fornecedores comerciais apoiam-se nisso: servidores diferentes, por vezes empresas diferentes, jurisdições diferentes, nenhum operador único a deter os dois registos.

Se alugar as duas instâncias VPS por si próprio, na sua conta, pagas com o seu cartão, o ponto comum é você. Quem for capaz de obrigar ou comprometer o seu fornecedor de alojamento consegue ver as duas extremidades da cadeia, porque ambas as extremidades são suas e estão ligadas pela mesma identidade de faturação. A propriedade que torna o multi-hop digno de ser pago num contexto comercial é precisamente aquela que não consegue reproduzir sozinho.

Ter isto claro conta mais do que a configuração, porque é o que decide se a configuração vale sequer a pena.

O que continua mesmo assim a dar-lhe

Dois benefícios sobrevivem ao auto-alojamento, e ambos são operacionais em vez de promessas de anonimato.

Dispersão jurisdicional. Se o salto A estiver num país e o salto B noutro, um pedido legal notificado a um fornecedor de alojamento produz apenas metade da rota. É uma propriedade real e é o argumento mais forte a favor de encadear os seus próprios servidores. Não é anonimato, é atrito.

Resiliência. Se um fornecedor bloquear um intervalo de portas, o limitar ou tiver uma falha, uma cadeia dá-lhe um sítio para onde reencaminhar. As montagens de salto único falham por completo quando falha o seu único fornecedor.

Se nenhuma dessas duas coisas o preocupa, um único salto bem configurado é a melhor decisão de engenharia, e é a recomendação honesta para a maioria de quem está a ler isto.

Como funciona realmente o encaminhamento

O WireGuard não tem qualquer noção de salto. Encadear é inteiramente um exercício de encaminhamento, e o manual do wg-quick descreve as peças.

O wg-quick infere todas as rotas a partir da lista de allowed IPs dos peers e acrescenta-as automaticamente à tabela de encaminhamento do sistema. Quando uma dessas rotas é uma rota predefinida, 0.0.0.0/0 ou ::/0, usa ip-rule para gerir a substituição da gateway predefinida.

Esse comportamento é cómodo com um túnel e é exatamente o que tem de controlar com dois. Daí decorrem três pontos.

A máquina intermédia tem de reencaminhar, não de terminar. O salto A precisa do reencaminhamento IP ativado e de uma rota em direção ao salto B. É um relé, não um destino.

O segundo endpoint tem de continuar acessível fora do primeiro túnel. Se o túnel do salto A capturar 0.0.0.0/0, os pacotes destinados ao endpoint do salto B podem acabar dentro do túnel que é suposto transportá-los. É o clássico ciclo de encaminhamento, e é por isso que o manual documenta a opção Table: off desativa por completo a criação de rotas, e auto, o valor predefinido, acrescenta as rotas e ativa o tratamento especial das rotas predefinidas. Assumir o controlo manual significa normalmente Table = off mais rotas explícitas.

Os hooks tratam do resto. PostUp e PreDown são fragmentos de script executados pelo bash antes e depois de levantar ou desmontar a interface, usados habitualmente para regras de firewall, e %i é substituído pelo nome da interface. É aí que pertencem as regras de reencaminhamento e qualquer encaminhamento por políticas.

O custo, dito com clareza

Cada pacote atravessa agora duas máquinas e é cifrado e decifrado duas vezes. A latência sobe, e numa cadeia que atravessa dois continentes sobe de forma notória.

Duplicou também a sua superfície operacional. Dois servidores para corrigir, dois conjuntos de chaves para rodar, dois sítios onde uma má configuração pode deitar fora o seu tráfego em silêncio ou, pior, deixá-lo fugir para fora do túnel. O nosso guia sobre a prevenção de fugas de DNS com o WireGuard aplica-se aqui a dobrar.

O resumo honesto

O multi-hop funciona, e a versão comercial do argumento é coerente: dois servidores operados de forma independente, nenhum deles a deter as duas metades.

Aloje os dois por si e passa a ser o elo entre eles, o que elimina a propriedade de anonimato e deixa dois benefícios reais: dispersão jurisdicional e resiliência. Para uns compensam a latência e para outros não.

Se o construir, o trabalho está no encaminhamento e não no WireGuard em si: reencaminhamento no salto intermédio, manter o segundo endpoint fora do primeiro túnel e assumir o controlo manual da tabela de encaminhamento em vez de deixar que dois túneis reclamem ambos a rota predefinida.

O comportamento do wg-quick aqui descrito, incluindo a inferência das rotas a partir dos allowed IPs dos peers, o uso de ip-rule na presença de uma rota predefinida, a opção Table com os seus valores off e auto, e os hooks PostUp e PreDown, provém da página de manual wg-quick(8), verificada no momento da escrita. O raciocínio sobre o que o auto-alojamento muda é análise e não documentação, e deve ser ponderado face ao seu próprio modelo de ameaça. As ligações comerciais têm o atributo rel="sponsored nofollow"; pode aplicar-se uma comissão de afiliação, sem custo adicional para si.