Dois clientes VPN, dois endereços públicos: faça o SNAT coincidir

Dois clientes VPN podem sair por dois endereços IPv4 públicos diferentes, e a regra que faz isso é mais curta do que a maioria espera. O que a faz funcionar não é a sintaxe do iptables, mas o estado do pacote quando chega à cadeia de saída: o endereço de origem ali ainda tem de distinguir os clientes. Se um masquerade anterior já juntou os dois num único endereço, nenhuma regra por cliente pode recuperar a distinção. Resolva primeiro essa questão e depois escreva a tradução.

Qual identidade sobrevive até ao gateway

A regra corresponde ao endereço de origem do pacote, não a um nome de utilizador VPN nem ao nome apresentado por uma aplicação cliente. Tudo o que traduz o pacote mais cedo no percurso determina o que a sua regra ainda pode ver. Execute a tabela nat por ordem e encontre o ponto em que a origem ainda é por cliente.

iptables -t nat -S POSTROUTING

Leia essa lista do topo. Uma regra de masquerade perto do topo reescreve a origem de cada fluxo correspondente, e as entradas por cliente colocadas a seguir correspondem a um endereço que já não existe. Quando dois dispositivos LAN partilham um túnel e chegam como um único endereço interno, o desenho tem de mudar antes da firewall: mantenha os seus intervalos de origem separados ou dê a cada um o seu próprio endereço interno.

Associe a atribuição do endereço interno ao cliente autenticado. Entregar esse endereço a outro dispositivo entrega também a política de saída, e a tradução de origem não é uma prova de identidade por si só.

A tradução não pode inventar um endereço

Cada endereço público tem de ser atribuído ou encaminhado para este ponto de saída, e as respostas têm de encontrar o caminho de volta. Uma regra que envia tráfego de um endereço para o qual ninguém encaminha de volta é descartada no extremo oposto ou respondida a um host que nunca a pediu. Uma instância de fornecedor de nuvem tem normalmente o endereço público traduzido para um endereço de interface privada antes de o pacote sair, pelo que a origem SNAT tem de ser o endereço que o fornecedor aceitará, não o valor que a consola mostra. Leia o modelo de endereços do fornecedor e siga-o em vez de copiar o valor público para cada pacote.

Na prática, isso significa verificar o prefixo encaminhado na consola do fornecedor antes de tocar na firewall, e usar o endereço de interface privada como origem da tradução quando a correspondência é um para um. Os endereços dos exemplos abaixo vêm dos intervalos de documentação, pelo que a primeira coisa a substituir é o próprio texto do endereço.

Insira antes do masquerade genérico

Confirme a interface de saída e a cadeia atual antes de acrescentar qualquer coisa. A primeira decide que pacotes a regra pode corresponder, e a segunda mostra o que já está à frente dela.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

O primeiro comando indica a interface por onde um pacote para a internet sai realmente. O segundo imprime a cadeia com números de linha. A entrada de masquerade genérica é a linha acima da qual se deve permanecer.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

As duas regras acima correspondem cada uma a um endereço interno, limitam a correspondência à interface de saída e definem a origem explicitamente. Insira em vez de acrescentar: na posição 1 são avaliadas antes da linha de masquerade. A ordem entre as duas não importa porque as suas origens diferem. Substitua ens3 pelo que o comando de rota reportou, e mantenha outros gestores de firewall longe dos mesmos hooks, pois duas ferramentas a escrever uma tabela é a razão habitual para uma regra correta não ter efeito.

Prove a origem com um novo fluxo

O NAT com estado liga uma tradução quando um fluxo começa e reutiliza-a para pacotes posteriores, pelo que uma sessão aberta antes da alteração mantém a origem antiga depois da alteração. Só uma ligação iniciada de novo prova a regra.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Leia a direção de resposta dessa entrada: o destino é o endereço que o extremo remoto vê como origem. Compare-o com o endereço público que pretendia, e trate uma entrada que transporta o endereço antigo como prova de um fluxo iniciado demasiado cedo, não de uma regra avariada. Peça ao cliente que abra uma nova ligação e depois repita a consulta. Esvaziar toda a tabela de seguimento para forçar o teste interrompe todas as outras sessões no gateway.

A tradução continua a não escolher a rota, a não deixar passar o fluxo pelo filtro e a não publicar um serviço de entrada. Uma rota errada e uma regra de permissão ausente continuam a falhar depois de uma regra SNAT perfeita. Verifique também o IPv6 e qualquer caminho de saída secundário, e depois anote os pares interno-para-público na documentação da firewall, para que a próxima alteração parta do mapeamento e não do texto da regra.