Saída separada: pool VPN em usb0, tráfego do gateway em eth0

Os clientes ligam-se e autenticam-se, e depois o tráfego deles sai pelo uplink errado, porque a única rota predefinida na máquina pertence ao próprio gateway. Substituir essa rota predefinida quebraria as atualizações e o acesso de gestão da máquina, por isso a seleção tem de ser mais estreita do que «todo o tráfego». A forma viável é uma regra de política baseada no endereço de origem interno do pool de clientes, que aponta para uma segunda tabela de encaminhamento dona do WAN alternativo. A partir daí, a lista de verificação trata de completude e de comportamento em caso de falha, não da regra em si.

Confirme que o endereço de origem sobrevive até à decisão de encaminhamento

Uma regra de política que corresponde a um intervalo de origem só dispara quando o pacote ainda transporta essa origem no momento da consulta. O tráfego de clientes encaminhado fá-lo, desde que nada a montante o tenha reescrito antes do encaminhamento. O tráfego gerado pelo próprio gateway não o faz, e é exatamente por isso que a rota predefinida do gateway pode ficar onde está.

É aqui que os testes locais enganam. Um curl executado no gateway é um fluxo gerado localmente com o endereço do gateway, por isso usa a tabela principal e não prova nada sobre o caminho do cliente. Teste a partir de um cliente ligado, ou gere tráfego com uma origem que pertença realmente ao pool.

Comece por escrever os valores reais: o prefixo do pool, a interface de túnel que o transporta, o endereço e o próximo salto do segundo WAN, e o número de tabela que pretende usar. Limpe as regras antigas de qualquer tentativa anterior antes de acrescentar novas, porque regras duplicadas com prioridades diferentes produzem falhas que parecem aleatórias.

Construa uma tabela selecionada que esteja completa

Uma tabela não é uma rota predefinida com um amigo. Precisa de rotas suficientes para que cada consulta se resolva dentro dela, incluindo a rota conectada da sub-rede WAN para que o próximo salto seja alcançável. Para um pool 10.77.0.0/24 em tun1, um endereço WAN 203.0.113.20/24 com próximo salto 203.0.113.1, e a tabela 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

A regra fica numa prioridade abaixo de qualquer regra apanha-tudo existente, por isso os clientes correspondentes atingem primeiro a tabela 600 e todo o resto cai na tabela principal. A referência de ip-rule descreve por completo o modelo de consulta ordenada e a sintaxe do seletor.

Depois pense no que a tabela não contém. Um destino que só tem rota na tabela principal, como uma sub-rede de gestão alcançável por eth0, não será encontrado na tabela 600 e não voltará à principal assim que aí exista uma rota predefinida. Se esses caminhos importam, acrescente-os explicitamente à tabela selecionada, o que costuma ser a resposta correta para uma tabela de saída VPN.

Mantenha o tráfego do próprio ouvinte fora da política

O ouvinte OpenVPN tem a sua própria ligação externa, transportada pelo uplink por onde o cliente o alcançou. Esse tráfego tem de manter o caminho de volta com que chegou, e uma regra ampla que cubra o endereço público do servidor ou toda a interface de túnel pode arrastá-lo para a tabela alternativa. Limite a regra ao pool interno e a nada mais.

A filtragem do caminho inverso merece uma vista de olhos pelo mesmo motivo. Quando as respostas aos clientes saem por usb0 enquanto o pedido chegou por outro link, uma configuração rígida de rp_filter pode descartar pacotes que a política de encaminhamento considera válidos. Verifique os valores efetivos de sysctl nas duas interfaces antes de concluir que a regra falhou.

A ordem também importa em relação a tudo o resto na máquina. As pontes Docker, um segundo VPN e qualquer regra preexistente de uma imagem de fornecedor acrescentam prioridades, por isso leia a lista completa de regras em vez de assumir que a prioridade 100 está sozinha.

Faça o encaminhamento e a tradução concordarem com a rota

O encaminhamento escolhe um uplink; não concede permissão para encaminhar. O núcleo tem de ter o encaminhamento IPv4 ativo, e a firewall tem de aceitar a direção do cliente para o WAN e o tráfego de retorno. Uma tabela correta com uma cadeia FORWARD que descarta o fluxo produz o mesmo sintoma que uma rota em falta, e por isso ambos são verificados na mesma passagem.

Se o segundo WAN não encaminhar um pool privado de volta para si, traduza a origem nessa saída. Para uma interface com endereço dinâmico, a escolha habitual é uma regra masquerade estreita limitada ao pool e à interface:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

O âmbito importa aqui mais do que o alvo. Uma regra masquerade que corresponda a qualquer interface de saída também reescreverá tráfego que sai corretamente por eth0, e isso esconde erros de encaminhamento em vez de os corrigir. A tradução corre depois da decisão de encaminhamento, por isso nunca pode reparar um pacote enviado para o uplink errado.

A sobrecarga do túnel também exige atenção quando os caminhos diferem. Se os clientes negociarem um MSS TCP grande e o WAN alternativo tiver uma MTU mais baixa ou um túnel lá dentro, os segmentos grandes encravam enquanto os pequenos funcionam. Limitar o MSS no caminho de encaminhamento transforma isso num comportamento previsível em vez de um bloqueio intermitente.

Decida o que acontece quando usb0 desaparece

Uma tabela vazia não é um estado de fecho em caso de falha. Se a rota correspondente desaparecer, a consulta continua para a regra seguinte, chega à tabela principal e toma a rota predefinida de eth0. O tráfego que devia sair pelo segundo WAN sai silenciosamente pelo primeiro, o que numa implantação com encaminhamento por política costuma ser o resultado que menos quer.

Onde esse recuo é inaceitável, acrescente uma rota terminal explícita na tabela 600, como uma rota predefinida blackhole, ou descarte o pool na firewall enquanto a interface estiver em baixo. Qualquer das duas é uma decisão que pode escrever; o silêncio não é.

A persistência é o último ponto. Quem detiver ambas as ligações, seja o gestor de rede, um script despachante ou o ciclo de vida da ligação, tem de recriar as rotas e a regra em cada reconexão sem acrescentar duplicados. Verifique com um pedido de um cliente real e um pedido separado do gateway, confirme a saída observada em ambos, depois retire o segundo WAN e veja qual dos dois resultados que desenhou acontece realmente. O IPv6 precisa da sua própria tabela, regra e tradução; a regra IPv4 acima não diz nada sobre isso.