Onde fica o NAT da VPN no before.rules do UFW e como testá-lo

Uma regra NAT que funciona quando digitada num shell falha quando colada no before.rules, porque esse arquivo não é um script. É um documento no formato de restauração com seções de tabela, declarações de cadeia e um marcador COMMIT para cada tabela. Uma linha no lugar errado ou aborta toda a restauração ou descarta silenciosamente regras que você acreditava existirem. O procedimento abaixo coloca o fragmento onde o framework o espera e prova o resultado antes da próxima recarga.

Um comando de shell não é um arquivo de restauração

Uma linha que começa com iptables -t nat é uma instrução para o binário iptables, enquanto o arquivo que o UFW lê é a descrição de um conjunto de regras completo. A diferença não é cosmética: o formato de restauração precisa saber em que tabela está, quais cadeias existem e onde a tabela termina. Um comando colado nesse documento é ou um erro de sintaxe ou, pior, uma regra anexada à tabela errada. O framework carrega esses arquivos por meio de ferramentas de restauração justamente porque são declarativos e não sequenciais.

O documento também é carregado como um todo, então uma seção malformada pode impedir a aplicação do resto do arquivo. Por isso um pequeno erro num fragmento NAT leva junto as regras de filtragem, e é assim que uma mudança de firewall se torna uma indisponibilidade.

Coloque o fragmento dentro da seção de tabela existente

Um fragmento NAT tem uma forma, e a forma importa mais do que o texto da regra dentro dela. O cabeçalho da tabela abre a seção, as declarações de cadeia estabelecem os contadores, as regras seguem e um COMMIT fecha a seção.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

O pool e a interface acima são marcadores para os seus valores; a estrutura é a parte que vale a pena copiar. Se o arquivo já contém uma seção *nat, adicione a regra dentro dessa seção em vez de abrir uma segunda, porque o formato espera um COMMIT por tabela e duas seções para a mesma tabela são um reparo esperando acontecer. Mantenha intactas as definições de cadeia da distribuição, incluindo as que o fornecedor adicionou para sua própria integração. O manual do framework UFW documenta os arquivos before, user e after junto com o requisito de um COMMIT correspondente.

Se o arquivo estiver vazio, não o preencha a partir de um tutorial. Confirme qual pacote o possui e qual é a política ativa de fato, porque um arquivo persistente vazio não prova que o kernel não tenha regras, e um conjunto de regras carregado não prova que a próxima recarga terá um arquivo completo para ler. Restaure primeiro a linha de base suportada e depois reaplique as mudanças do site por cima.

Teste o candidato sem aplicá-lo

A ferramenta de restauração pode analisar e construir um conjunto de regras sem aplicá-lo, e esse é o teste mais barato disponível. Execute-a contra uma cópia protegida em vez do arquivo ativo, e leia o texto do erro em vez de apenas o status de saída. Uma falha de análise nomeia uma linha e geralmente uma tabela, o que é mais do que uma recarga falha dirá a você.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Passar nessa verificação prova que o documento é analisado e nada mais. Não prova que o candidato ainda contém todas as cadeias das quais o UFW depende, que permite apenas as fontes pretendidas ou que a administração remota continua acessível. São revisões separadas, e a última merece uma segunda sessão aberta antes de começar.

Escolha a ferramenta que corresponde ao backend instalado e à família de endereços. Um host que executa o backend nft através da camada de compatibilidade precisa do comando correspondente, e as regras IPv6 vivem num arquivo completamente diferente.

Mantenha encaminhamento, NAT e política de acesso separados

A tradução de origem resolve um problema de endereçamento e não concede nada. O encaminhamento é uma permissão separada controlada por um sysctl e pela tabela de filtragem, e é a que as pessoas esquecem quando um túnel encaminha mas não passa tráfego. A política de acesso é uma terceira decisão sobre quais fontes podem alcançar quais serviços, e nenhuma regra NAT a expressa. Manter as três separadas é o que torna uma falha diagnosticável em vez de um único sintoma vago.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Leia essas três saídas juntas, não uma de cada vez. Uma regra masquerade com o encaminhamento desativado produz um cliente que se conecta e não alcança nada, o que do lado do cliente parece exatamente uma falha de roteamento e envia as pessoas para o arquivo errado. A tabela de filtragem também é onde um accept excessivamente amplo se esconde, então verifique a política padrão dela enquanto estiver ali.

Verifique uma recarga, uma recusa e uma perda de VPN

Três observações compõem um teste de aceitação completo: a recarga é bem-sucedida, uma operação de cliente permitida funciona e uma requisição que deveria ser recusada é de fato recusada. A terceira é a que costuma ser omitida, e é a única evidência de que a política está fazendo alguma coisa.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Depois teste a falha para a qual você projetou. Derrube o túnel e observe o que o host faz, porque uma política que só funciona enquanto a VPN está ativa é uma política com uma dependência não declarada. Recarregue mais uma vez depois para provar que é o arquivo, e não um estado de execução remanescente, que produz o resultado funcional.

O NAT IPv4 não diz nada sobre IPv6, então declare a cobertura pretendida para as duas famílias na mesma nota da regra. O objetivo é uma política gerenciada coerente, e um fragmento que por acaso foi analisado não é prova dela.