AmneziaWG Cascade: Configurando Dois Servidores para Acesso Direto a Sites Russos

Ter uma VPN própria em um servidor estrangeiro é conveniente, até que você precise acessar sites russos. Alguns deles simplesmente bloqueiam endereços estrangeiros, como bancos, portais governamentais e serviços de streaming. Outros sites podem abrir, mas com um roteamento desnecessário através do exterior e com um IP que não é o seu.

Na última publicação, apresentei uma solução geral – um cascade de dois servidores – e indiquei o guia para mais detalhes. Desde então, tenho recebido perguntas regulares sobre este esquema, então aqui está uma análise completa, passo a passo, de como montei o cascade e quais obstáculos encontrei. A ideia principal é: o cliente se conecta a um servidor, o tráfego russo sai para a internet diretamente deste servidor, e todo o resto é roteado através de um segundo servidor no exterior. Uma única conexão no telefone, com toda a lógica de divisão residindo no servidor. Isso é essencialmente um split tunneling no lado do servidor, o que significa que os clientes não precisam configurar nada.

Sobre a autoria: a ideia foi proposta por um dos usuários do instalador (glfenix no GitHub) em uma discussão do projeto. Eu montei o esquema em dois servidores limpos, testei, corrigi alguns pontos e desenvolvi esta instrução passo a passo. Agradeço a ele pela análise.

O que você vai precisar

• Dois VPS com Debian 12/13 ou Ubuntu 24.04/25.10 limpos, com acesso root em ambos.
• Servidor de Entrada (Inbound): Localizado na Rússia ou próximo a ela. Os clientes se conectam a ele, e os sites russos são acessados a partir de um endereço próximo.
• Servidor de Saída (Outbound): Um VPS estrangeiro comum.
• Ambos os servidores devem ter um IP público real. Um servidor atrás de NAT (CGNAT) do provedor não serve como servidor de entrada, pois não seria acessível de fora. Uma verificação rápida: o endereço retornado por curl -s ifconfig.me deve coincidir com o endereço na interface (ip -4 addr). Um caso especial com Hetzner e um gateway privado será abordado mais adiante.
• IPv6 desativado: o instalador o desativa por padrão. O cascade funciona via IPv4; com IPv6 ativado, o tráfego contornará a divisão.
• Sub-redes diferentes para os servidores. No meu caso, a entrada usa 172.16.17.1/24 e a saída usa 172.16.61.1/24.

Como o cascade divide o tráfego

A mecânica foi detalhada em um artigo anterior, mas aqui farei um breve resumo para facilitar a compreensão dos passos. O servidor de entrada inspeciona o endereço de destino de cada pacote. Se o endereço estiver na lista de redes russas, o pacote é enviado diretamente para a internet a partir do servidor de entrada. Caso contrário, ele é marcado com um rótulo (fwmark) e enviado através de um túnel para o servidor de saída. A lista de redes russas é obtida da zona aberta do ipdeny e carregada no ipset. Os clientes são adicionados ao servidor de entrada normalmente, usando manage add <nome>, sem necessidade de configuração adicional do lado deles.

Montagem do Cascade

Passo 1. Instalar o instalador em ambos os servidores

Em ambos os servidores, instale o amneziawg-installer (ele configura o AmneziaWG 2.0 com ofuscação e o firewall). Siga as instruções principais e execute-o de forma não interativa com as sub-redes desejadas:

bash
# No servidor de saída (exterior)
bash install_amneziawg.sh --yes --disallow-ipv6 --route-all --subnet=172.16.61.1/24

# No servidor de entrada (Rússia ou próximo)
bash install_amneziawg.sh --yes --disallow-ipv6 --route-all --subnet=172.16.17.1/24

O instalador configurará o encaminhamento e o NAT automaticamente, então não é necessário editar o arquivo de configuração do servidor. O script de roteamento adicionará apenas o que for necessário. No servidor de entrada, instale dois pacotes que podem não estar presentes em uma imagem mínima:

bash
apt update && apt install -y curl ipset

Passo 2. No servidor de saída: configurar o cliente para o servidor de entrada

O servidor de entrada se conectará ao servidor de saída como um cliente comum. Crie-o no servidor de saída:

bash
bash /root/awg/manage_amneziawg.sh add ru_host

Isso gerará o arquivo /root/awg/ru_host.conf. Copie este arquivo para o servidor de entrada por qualquer meio (scp, área de transferência). Dentro do arquivo, você encontrará uma configuração de cliente comum, incluindo o Endpoint (IP externo do servidor de saída) e AllowedIPs = 0.0.0.0/0. Anote o Endpoint, pois ele será necessário no script.

Passo 3. No servidor de entrada: configurar o túnel para o servidor de saída

Coloque o arquivo de configuração copiado em /etc/amnezia/amneziawg/awg1.conf e edite duas linhas:

• Na seção [Interface], adicione Table = off. Isso impede que awg-quick configure as rotas automaticamente, pois nosso script cuidará do roteamento.
• Remova a linha DNS = ..., pois ela não é necessária no servidor.

Defina as permissões corretas e inicie o túnel:

bash
chmod 600 /etc/amnezia/amneziawg/awg1.conf
systemctl start awg-quick@awg1
awg show awg1

A saída de awg show awg1 deve mostrar latest handshake, indicando que a conexão com o servidor de saída está estabelecida. O ping para o endereço interno do servidor de saída pode não funcionar neste momento, o que é normal, pois a rota para ele será criada em uma tabela separada na próxima etapa.

Passo 4. O script de roteamento

A lógica de divisão de tráfego é implementada em um único script bash no servidor de entrada, /root/awg/awg-routing.sh. Este script é idempotente, o que significa que pode ser executado várias vezes, e a cada execução ele atualiza a lista de redes russas. O script completo está disponível no guia do cascade. Vamos analisar os principais componentes:

• Atualização da lista de redes russas: A lista de redes russas é carregada no ipset através de um conjunto temporário com substituição atômica para evitar um período em que o conjunto esteja vazio:

  bash
  ipset create ru hash:net -exist
  # ... carregar redes de uma lista baixada para um conjunto temporário ru_tmp ...
  ipset swap ru_tmp ru

• Tabela de roteamento separada e regra de marcação: O tráfego marcado é roteado através do túnel awg1.

  bash
  undefined

ip route replace default dev awg1 table 100 ip rule add fwmark 0x1 table 100 priority 10000 ```

• Marcação do tráfego dos clientes: Pacotes destinados a redes russas são roteados diretamente (RETURN antes da marcação), enquanto todo o restante é marcado. A ordem é importante, com RETURN vindo antes de MARK:

  bash
  undefined

iptables -t mangle -I PREROUTING 1 -i awg0 -s 172.16.17.0/24 -m set --match-set ru dst -j RETURN iptables -t mangle -A PREROUTING -i awg0 -s 172.16.17.0/24 -j MARK --set-mark 0x1 ```

• Rota para o servidor de saída: A rota para o próprio servidor de saída deve ser mantida fora do túnel para evitar loops de pacotes no awg1.

O script possui duas salvaguardas importantes: primeiro, se a lista de redes russas não for baixada e estiver vazia, o script para com um erro, evitando uma divisão silenciosamente quebrada. Segundo, um tratamento específico para gateways /32, que será discutido adiante.

Defina sua sub-rede de cliente e o IP externo do servidor de saída no início do script e execute-o:

bash
chmod +x /root/awg/awg-routing.sh
bash /root/awg/awg-routing.sh

Passo 5. Autostart após reinicialização

Um problema comum na configuração inicial era que as rotas não eram restauradas após a reinicialização, exigindo intervenção manual. Isso é resolvido com um único serviço systemd que depende de ambos os túneis, garantindo que a roteamento seja iniciado estritamente após eles:

/etc/systemd/system/awg-routing.service:

ini
[Unit]
Description=Cascading Split Routing
After=awg-quick@awg0.service awg-quick@awg1.service network-online.target
Requires=awg-quick@awg0.service awg-quick@awg1.service
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/root/awg/awg-routing.sh

[Install]
WantedBy=multi-user.target

Execute os seguintes comandos para recarregar o systemd e habilitar o serviço:

bash
systemctl daemon-reload
systemctl enable awg-quick@awg1 awg-routing

O parâmetro Requires garante que o roteamento não será iniciado se o túnel para o servidor de saída falhar. Testes de reinicialização confirmaram que os túneis, tabelas e listas são configurados automaticamente.

A lista de redes russas muda com o tempo, portanto, é recomendável reiniciar o serviço semanalmente para atualizá-la. Isso pode ser feito com um cron job:

bash
echo '0 5 * * 1 root systemctl restart awg-routing' > /etc/cron.d/awg-routing-refresh

Verificando o funcionamento da divisão de tráfego

A maneira mais fácil de verificar é através dos contadores do iptables. No servidor de entrada, zere os contadores, crie ambos os tipos de tráfego a partir de um cliente e observe:

bash
# No servidor de entrada: zerar contadores
iptables -t mangle -Z PREROUTING

# No cliente: acessar um site estrangeiro (via saída) e um endereço russo (diretamente)
curl https://ifconfig.me      # Deve mostrar o IP externo do servidor de saída
ping -c3 77.88.55.242         # Endereço russo (Yandex)

# No servidor de entrada: verificar os contadores
iptables -t mangle -L PREROUTING -n -v
# RETURN (match-set ru dst)  <- Pacotes para a Rússia aumentaram (diretamente)
# MARK   (MARK set 0x1)      <- Outros pacotes aumentaram (via saída)

Se o curl ifconfig.me no cliente mostrar o IP de saída e o contador RETURN aumentar para endereços russos, o cascade foi configurado corretamente. O MTU não exigiu ajustes manuais, pois a dupla encapsulação se encaixa nos tamanhos padrão, e testes de transferência de dados não apresentaram perdas.

Obstáculos encontrados

Aqui estão alguns problemas comuns que encontrei ou que foram relatados por outros usuários:

• Todo o tráfego, incluindo o russo, passa pelo exterior: Verifique a lista de redes russas no ipset. Deve haver milhares de entradas. Se for zero, a lista não foi baixada. O script foi projetado para parar com um erro nesses casos. Se o www.ipdeny.com estiver bloqueado pelo seu provedor, o script usará um snapshot do repositório do projeto.
• Algum site russo ainda abre através do exterior: A divisão é baseada no IP de destino. Sites que residem fisicamente em hospedagem estrangeira ou atrás do Cloudflare podem ter IPs estrangeiros e não estar na lista de redes russas, sendo roteados para o servidor de saída. Se o site bloquear IPs estrangeiros, ele não abrirá. Verifique um site específico com getent hosts <nome.ru> e, em seguida, ipset test ru <endereço> para cada IP. Se o IP for russo mas não estiver no ipset, a lista está incompleta. Se for estrangeiro, é o comportamento esperado e só pode ser resolvido no lado do site.
• Google e YouTube lentos, mesmo com saída estrangeira: Parte dos caches do Google e YouTube está em endereços russos e é roteada diretamente, fazendo com que o Google veja um IP russo. Isso não é resolvido de forma confiável com a substituição de DNS. Se você precisa que o Google sempre passe pela saída, suas redes devem ser roteadas para lá, contornando o RETURN. Detalhes estão no guia.
• Taxa de upload significativamente menor que a de download: Se o download estiver normal e o upload cair drasticamente, o gargalo provavelmente está no trecho de entrada para saída. Meça a velocidade direcionadamente: no servidor de saída, execute iperf3 -s; no servidor de entrada, execute iperf3 -c <IP do servidor de saída> (upload) e iperf3 -c <IP do servidor de saída> -R (download). Uma baixa velocidade de upload indica um problema entre os servidores, como limitação de tráfego do hoster, peering ruim ou limites de entrada no servidor de saída.
• Script falha com Nexthop has invalid gateway: Isso pode ocorrer com hosters como Hetzner, onde o IP público é atribuído como /32 e o gateway padrão está fora da sub-rede do servidor. A versão mais recente do script trata isso adicionando o flag onlink. Certifique-se de que o IP público está realmente no servidor (ip -4 addr deve coincidir com curl -s ifconfig.me).
• IPv6 contorna a divisão: O esquema funciona via IPv4. Mantenha o IPv6 desativado.
• DNS passa pela saída: As consultas DNS do cliente (por padrão, Cloudflare) são enviadas através do servidor de saída. Os endereços IP russos obtidos são então acessados diretamente. Isso é normal e não afeta a divisão.

Para quem o cascade não é necessário

Se você precisa do acesso dividido apenas para si mesmo, configurar o AllowedIPs diretamente no cliente é mais simples. O cascade é justificado quando a divisão de tráfego precisa ser mantida no servidor e ser igual para todos os usuários. Por isso, o cascade não está integrado ao instalador principal e requer esta instrução separada.

Conclusão

Configurar um cascade AmneziaWG com dois servidores é um processo que pode ser concluído em uma noite: duas instalações padrão, um túnel entre os servidores, um script de roteamento e um serviço systemd. Após a configuração, os sites russos serão acessados diretamente de um endereço russo, enquanto todo o restante será roteado através de um servidor estrangeiro, e todo o sistema sobreviverá a reinicializações automaticamente.

O script completo, a análise passo a passo e as perguntas frequentes estão disponíveis no guia do cascade: https://github.com/bivlked/amneziawg-installer/blob/main/CASCADE.md

O propósito de tudo isso e outros problemas comuns são abordados no artigo anterior: https://habr.com/ru/articles/1051054/

O projeto em si (instalador e gerenciamento): https://github.com/bivlked/amneziawg-installer