eth0:0 é um rótulo, não um dispositivo: corrija a correspondência SNAT

Uma regra NAT que deveria dar a um pool de clientes VPN o seu próprio endereço público está em zero pacotes, enquanto o mesmo pool continua a sair com a origem errada. A regra normalmente não erra o endereço; erra a interface. -o eth0:0 aponta para um dispositivo que não existe, porque eth0:0 é um rótulo associado a um endereço em eth0. Olhar para os contadores é a forma mais rápida de confirmar isso, e a correção é menor do que a investigação sugere.

Verifique como o kernel chama o dispositivo

Leia as duas vistas separadamente antes de mudar qualquer coisa:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

A lista de ligações mostra interfaces. A lista de endereços pode mostrar um segundo endereço IPv4 que carrega o rótulo eth0:0, e o dispositivo desse endereço continua a ser eth0. O manual de endereços do iproute2 trata o rótulo como um nome do endereço, não como uma segunda ligação, e é exatamente essa distinção que sustenta todo o problema.

A história explica a confusão. A antiga ifconfig eth0:0 sintaxe parecia mesmo uma nova interface, e scripts dessa época ainda se referem a uma. Num sistema atual, o alias é um rótulo sobre um endereço, e nada no caminho de encaminhamento ou do netfilter o trata como um ponto de saída separado.

Verifique com o que a regra realmente coincidiu

Leia os contadores junto com a lista de regras em vez de os tirar da memória:

iptables -t nat -L POSTROUTING -v -n --line-numbers

Uma regra cujo contador de pacotes fica em zero enquanto flui tráfego correspondente não está a ser avaliada, e uma condição de interface de saída que nomeia eth0:0 é uma causa comum. O dispositivo de saída escolhido pela rota é eth0, pelo que uma condição que procura outro nome nunca se torna verdadeira, seja qual for o endereço de origem que o kernel escolheu.

Mude a condição para o dispositivo real e deixe o rótulo de fora. Se precisar de distinguir dois pools de clientes que partilham esse dispositivo, distinga-os por prefixo de origem, não por um nome de interface que não pode existir. Duas regras com correspondências -s que não se sobrepõem são legíveis e testáveis; uma regra com um dispositivo fictício não é nem uma nem outra. Dê a cada regra um comentário que nomeie o pool, porque daqui a seis meses o prefixo sozinho não dirá a ninguém porque é que ela está lá.

Verifique a rota que escolheu o dispositivo

O NAT de postrouting corre depois de a rota já ter escolhido uma interface de saída, portanto a interface na regra tem de ser a que a rota escolheu. Pergunte ao kernel diretamente com ip route get para um endereço de cliente representativo e leia tanto o dispositivo como a origem que ele reporta.

Se a resposta nomear eth0, a parte da interface da regra está resolvida. Se nomear um dispositivo de túnel, o pacote nunca chega à regra que está a editar, e a pesquisa passa para a tabela de encaminhamento e as suas prioridades. Uma regra que nunca coincide porque o pacote saiu noutro sítio parece, na saída dos contadores, igual a uma regra com um dispositivo mal escrito. Confirme qual dos dois casos tem antes de editar seja o que for, porque o segundo precisa de uma alteração de encaminhamento e não de texto.

Escolha a origem traduzida de propósito

Depois de o dispositivo estar correto, o endereço de origem é uma decisão separada. Isto é apenas um pool IPv4 ilustrativo e um endereço de exemplo:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Escrever um endereço em --to-source não faz com que alguém o encaminhe de volta para si. O fornecedor a montante ou o dono do endereço tem de entregar as respostas desse endereço a este host, e o endereço tem de ser um que esteja autorizado a usar. Se não for, a regra coincide e traduz e as respostas continuam a ir para outro sítio.

Mudar o endereço de origem não é o mesmo que mudar a ligação a montante. Quando o requisito real é um caminho físico diferente, a política de encaminhamento tem de selecionar primeiro esse caminho; o SNAT reescreve depois a origem no dispositivo que a política escolheu. Mais rótulos em eth0 não dão nem a rota nem a autorização.

Verifique com uma ligação que acabou de abrir

Abra uma nova ligação de cliente em vez de reutilizar uma existente. O rastreio de ligações guarda a tradução que registou no início do fluxo, pelo que uma sessão antiga pode continuar a usar o endereço de origem anterior e fazer parecer avariada uma regra nova correta. Veja o contador a subir e depois observe a origem traduzida no cabo ou na extremidade remota.

Para vários pools que partilham uma interface, dê a cada um uma correspondência de origem explícita e o seu próprio endereço de tradução, mantenha-os na configuração gerida da firewall e anote a ordem em que são avaliados. Depois registe o que verificou: o dispositivo obtido com ip route get, o contador que mexeu e a origem que o lado remoto viu. Esse registo responde ao relatório seguinte sem repetir a confusão do alias.