Agora já sabemos como escolher os pacotes a serem tratados. Para completar, precisamos dizer ao kernel o que fazer com estes pacotes.
Você quer fazer Source NAT; mudar o endereço de origem das conexões para algo diferente. Isso é feito na chain POSTROUTING, logo antes de que o pacote saia da máquina. Isso é um detalhe muito importante, pois significa que qualquer tarefa da sua máquina Linux (routing, packet filtering) verá o pacote inalterado. Isso também significa que a opção `-o'(interface de saída) pode ser utilizada.
Source NAT é especificado com `-j SNAT', e a opção `--to-source' demonstra um endereço IP, um range de endereços IP, e uma porta opcional ou um range de portas (apenas para os protocolos TCP e UDP).
## Mudando o endereço de origem para 1.2.3.4.
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
## Mudando o endereço de origem para 1.2.3.4, 1.2.3.5 ou 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6
## Mudando o endereço de origem para 1.2.3.4, portas 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023
Há um caso especial de Source NAT chamado masquerading, que só deve ser utilizado para endereços IP dinâmicos, como as conexões dialup (para endereços IP estáticos, utilize SNAT descrito acima).
No masquerading, não é necessário explicitar o endereço de origem: será utilizado o endereço de origem da interface de saída do pacote. Mas o mais importante é que se o link cair, o endereço de origem que estava sendo utilizado é descartado, dando lugar ao novo endereço de origem da interface quando o link for restabelecido.
## Mascarando tudo que sai pela interface ppp0.
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
DNAT é feito na chain PREROUTING, assim que o pacote chega; isso significa que todas as outras tarefas da sua máquina Linux (routing, packet filtering) verão o pacote já indo para seu destino verdadeiro. A opção `-i' (interface de entrada) pode ser utilizada.
Para alterar o destino de pacotes gerados localmente, a chain OUTPUT deve ser utilizada, mas isso não é muito utilizado (além disso, mudar o destino para outro local que não a própria máquina Linux ainda não funciona -- Abril 2001).
Destination NAT é especificada utilizando `-j DNAT', e a opção `--to-destination' especifica um endereço IP, um range de IPs, e uma porta opcional ou um range de portas (apenas para protocolos TCP e UDP).
## Mudando destino para 5.6.7.8
# iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8
## Mudando destino para 5.6.7.8, 5.6.7.9 ou 5.6.7.10.
# iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8-5.6.7.10
## Mudando destino do tráfego web para 5.6.7.8, porta 8080.
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 \
-j DNAT --to 5.6.7.8:8080
## Redirecionar pacotes locais com destino a 1.2.3.4 para loopback.
# iptables -t nat -A OUTPUT -d 1.2.3.4 -j DNAT --to 127.0.0.1
Há um caso especializado de Destination NAT chamado redirecionamento: é uma simples conveniência, a qual equivale a fazer DNAT para o endereço da própria interface de entrada.
## Mandando tráfego web da porta-80 para nosso squid proxy (transparente)
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
-j REDIRECT --to-port 3128
Lembre-se que o squid precisa ser configurado para saber que está sendo um proxy transparente!
Há alguns refinamentos do NAT os quais a maioria das pessoas nunca utilizará. Eles estão aqui documentados apenas para os curiosos.
Se um range de endereços IP é dado, o IP escolhido para uso é o que está sendo menos utilizado pelas conexões conhecidas. Isso porvê um balanceamento de carga (load-balancing) bem primitivo.
Você pode utilizar `-j ACCEPT' para aceitar uma conexão sem que haja nenhuma espécie de NAT.
O comportamento padrão é alterar a conexão o mínimo possível, modificando apenas o definido pelo usuário nas suas regras. Isso significa que as portas não serão remapeadas a não ser que as regras mandem que elas sejam.
Mesmo quando nenhum tipo de NAT é requisitado para uma conexão, a alteração da porta de origem pode ocorrer de forma implícita, quando uma conexão requisita uma porta que está em uso. Considere um caso de masquerading, que gera esse tipo de situação:
Quando esse mapeamento de origem implícito ocorre, as portas são divididas em três classes:
Uma porta NUNCA será mapeada implicitamente para uma classe diferente.
Se não há formas de mapear uma conexão conforme requisitado pelo usuário, a mesma será descartada (DROP). Isso também se aplica a pacotes que não foram classificados como parte de qualquer conexão, devido a malformação, ou falta de memória da máquina, etc.
Você pode ter regras NAT que mapeiam pacotes para o mesmo range; o código NAT suficientemente inteligente para evitar conflitos. Não há nenhum problema em mapear os endereços de origem 192.168.1.1 e 192.168.1.2 para 1.2.3.4.
Além disso, você pode mapear para endereços IP reais e utilizados, desde que tais endereços passem pela máquina responsável pelo mapeamento. Então, se você tem uma rede válida (1.2.3.0/24), mas possui uma rede interna que utilize um IP privado (192.168.1.0/24), você pode realizar SNAT do endereço 192.168.1.0/24 para a rede 1.2.3.0, sem medo de quaisquer conflitos:
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT --to 1.2.3.0/24
A mesma lógica se aplica aos endereços utilizados pela própria máquina que realiza NAT: essa é a forma que o masquerading funciona (compartilhando o endereço da interface de saída entre os pacotes mascarados e os gerados localmente).
Você também pode mapear os mesmos pacotes para alvos distintos, e estes serao compartilhados. Por exemplo, se você não quer mapear NADA para o endereço 1.2.3.5, você faria:
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254
Se o destino de um pacote gerado localmente é alterado (pela chain OUTPUT), e isso leva o pacote a passar por uma interface diferente, e então o endereço de origem também é alterado para o endereço da interface de saída. Por exemplo, mudando o destino de um pacote loopback para sair por eth0 irá resultar na mudança do endereço de origem de 127.0.0.1 para o endereço de eth0; ao contrário dos outros mapeamentos de origem (que são feitos depois de tudo, na chain POSTROUNTING) esse é realizado imediatamente. Naturalmente, todos esses mapeamentos são revertidos no momento que os pacotes de resposta chegam.