Linux 2.4 NAT HOWTO Rusty Russell, mailing list netfilter@lists.samba.org Tradução para Português do Brasil: Guilherme Ude Braz (guilherme@linuxplace.com.br) Revision: 1.14 Date: 2001/05/26 20:26:48 Este documento descreve como fazer masquerading, proxy transparente, redirecionamento de portas, e outras formas de Troca de Endreço de Rede (Network Address Translations) com os kernels Linux 2.4. ______________________________________________________________________ Índice geral 1. Introdução 2. Onde encontrar o site oficial e a mailing list? 2.1 O que é Network Address Translation (Troca de Endereço de Rede)? 2.2 Porque utilizar NAT? 3. Os dois tipos de NAT 4. Pequenas notas dos Kernels 2.0 e 2.2 4.1 Socorro! Eu só quero masquerading! 4.2 E o ipmasqadm? 5. Controlando o que será submetido a NAT 5.1 Seleção simples utilizando iptables 5.2 Pontos mais específicos sobre o tratamento dos pacotes 6. E agora, como tratar os pacotes? 6.1 Source NAT 6.1.1 Masquerading 6.2 Destination NAT 6.2.1 Redirecionamento 6.3 Algumas curiosidades menos utilizadas... 6.3.1 Seleçao de múltiplos endereços em um range 6.3.2 Criando mapeamentos NAT nulos 6.3.3 Comportamento padrão do NAT 6.3.4 Mapeamento de portas de origem implícito 6.3.5 O que ocorre quando NAT falha 6.3.6 Mapeamentos múltiplos, overlap e conflitos 6.3.7 Alterando destino de pacotes gerados localmente 7. Protocolos especiais 8. Algumas prevenções sobre NAT 9. Source NAT e roteamento 10. Destination NAT para a mesma rede 11. Agradecimentos ______________________________________________________________________ 1. Introdução Bemvindo, gentil leitor. Você está prestes a entrar no fascinante (e algumas vezes horrendo) mundo do NAT: Network Address Translation (Troca de Endereço de Rede), e esse HOWTO será seu guia para kernels Linux 2.4 e futuros. No Linux 2.4, uma estrutura para lidar com pacotes foi introduzida, seu nome é 'netfilter'. Uma camada externa provê NAT, completamente reimplementada em relação a kernels anteriores. (C) 2000 Paul `Rusty' Russell. Licenciado sob a GNU GPL. 2. Onde encontrar o site oficial e a mailing list? Estes são os sites oficiais: · Agradecimentos para Filewatcher . · Agradecimentos para The Samba Team and SGI . · Agradecimentos paraHarald Welte . Para a mailing list oficial do Netfilter vá em Netfilter List . 2.1. O que é Network Address Translation (Troca de Endereço de Rede)? Normalmente, pacotes em uma rede viajam de sua origem (por exemplo, o computador de usa casa) para seu destino (por exemplo, www.gnumonks.org) através de vários links. Nenhum destes links realmente alteram seu pacote: eles apenas reenviam o mesmo. Se algum destes links fizesse NAT, eles iriam alterar a origem ou o destino do pacote. Como você pode imaginar, esta não é a forma pela qual seu sistema foi feito para trabalhar, logo NAT é sempre algo complexo. Geralmente a máquina que faz NAT vai relembrar-se como o pacote foi alterado, e quando um pacote de resposta segue o caminho inverso, a máquina irá fazer a alteração reversa naquele pacote resposta, é assim que as coisas funcionam. 2.2. Porque utilizar NAT? Em um mundo perfeito, você não usaria. Por enquanto, as razões são: Conexões com a Internet via modem A maioria dos provedores de acesso te dá um único endereço IP quando você conecta. Você pode mandar pacotes com qualquer endereço de origem que você quiser, mas apenas respostas para pacotes com esse endereço de origem retornarão para você. Se você quiser utilizar mais de uma máquina (uma rede local na sua casa) para conectar na Internet através deste único link, você precisará de NAT. Esta é a maneira de NAT mais utilizada atualmente, e é conhecida como Masquerading no mundo Linux. Eu chamo isso de SNAT, porque você altera o endereço de origem do primeiro pacote. Múltiplos Servidores Às vezes, você quer mudar o destino dos pacotes que chegam na sua rede. Frequentemente isto ocorre porque (como dito acima) você tem apenas um endereço IP, mas quer que as pessoas alcancem servidores atrás do que tem o endereço IP real. Reescrevendo o destino dos pacotes que chegam, é possível implementar isso. Uma variação comum disto é load-sharing, na qual a carga de pacotes é dividida entre máquinas. este tipo de NAT era chamado de port-forwarding em versões anteriores do Linux. Proxy Transparente Às vezes você pretende que cada pacote que atravesse sua máquina Linux é destinado a um programa específico. Isto é utilizado para fazer proxies transparentes: um proxy é um programa que fica entre sua rede e o mundo extertno, controlando a comunicação entre os mesmos. O termo transparente refere-se ao fato de que sua rede não saberá que está lidando com um proxy, a não ser, é claro, que seu proxy não funcione :). O Squid pode ser configurado de forma a trabalhar desta maneira, e isto é chamado de redirection ou transparent proxying em versões Linux anteriores. 3. Os dois tipos de NAT Eu divido NAT em duas categorias distintas: NAT de Origem (Source NAT) (SNAT) e NAT de Destino (Destination NAT) (DNAT). Source NAT ocorre quando o endreço de origem do primeiro pacote é alterado: por exemplo, quando se muda de onde vem uma conexão. Source NAT sempre ocorre no momento de post-routing, logo antes que o pacote deixe o firewall. Masquerading é uma forma especializada de SNAT. Destination NAT ocorre quando o endereço de destino do primeiro pacote é alterado: por exemplo, quando se altera o destino final de uma conexão. Destination NAT sempre ocorre no momento de pre-routing, quando o primeiro pacote está prestes a entrar no firewall. Port forwarding, load sharing, e proxy transparente são forma de DNAT. 4. Pequenas notas dos Kernels 2.0 e 2.2 Peço desculpas àqueles que ainda esperam para fazer a transição das versões 2.0 (ipfwadm) e 2.2 (ipchains). Há notícias boas e ruins. Primeiramente, pode-se usar ipchains ou ipfwadm como antes. Para fazer isto, carregue os módulos do kernel `ipchains.o' ou `ipfwadm.o' que estão na sua distribuição do netfilter. Tais módulos são incompatíveis (você está avisado!), e não podem ser utilizados em conjunto com quaisquer outros módulos do netfilter. Tendo estes módulos instalados, ipchains e ipfwadm podem ser utilizados normalmente, com as seguintes diferenças: · Configurar masquerading timeouts com ipchains -M -S, ou ipfwadm -M -s não adianta. Uma vez que os timeouts são maiores na nova infraestrutura NAT, isso não faz muita diferença. · Os campos init_seq, delta e previous_delta no verbose masquerade listing são sempre zero. · Zerar e escutar os contadores ao mesmo tempo `-Z -L' não funciona mais: os contadores não serão zerados. Hackers também notarão: · É possível bloquear as portas 61000-65095 até fazendo masquerading. O código de masquerading code assumia que não havia ataques neste port range, abrindo uma brecha de segurança. · O hack (não documentado)`getsockname', que permitia que programas transparent proxy achassem o destino real dos pacotes, não funciona mais. · O hack (não documentado) 'bind-to-foreign-address' também não foi implementado; ele era utilizado para completar o serviço de proxy transparente. 4.1. Socorro! Eu só quero masquerading! Masquerading é o que a maioria das pessoas quer. Se você tem um IP dinâmico via PPP (se você não sabe, você tem um), e quer apenas passar para sua máquina que todos os pacotes vindos da sua rede interna deve parecer que têm como origem sua máquina com uma conexão dialup PPP. # Carregar o módulo NAT (isso carrega todos os outros. modprobe iptable_nat # Na tabela NAT (-t nat), adicionar uma regra (-A) após o routing # (POSTROUTING) para todos os pacotes saindo por ppp0 (-o ppp0) dizendo para # MASCARAR a conexão (-j MASQUERADE). iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # Habilitar IP forwarding echo 1 > /proc/sys/net/ipv4/ip_forward Note que você não está filtrando nenhum pacote aqui: para isso, veja o Packet Filtering HOWTO (Como fazer filtragem de pacotes): `Misturando NAT e Filtragem de Pacotes'. 4.2. E o ipmasqadm? O ipmasqadm era utilizado por um menor número de usuários, então não me preocupei muito com a compatibilidade de versões anteriores. Você pode utilizar `iptables -t nat' para fazer port forwarding. No Linux 2.2 você faria: # Linux 2.2 # Transformar pacotes TCP indo para a porta 8080 de 1.2.3.4 para a porta 80 de 192.168.1.1's ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80 Agora, você faria: # Linux 2.4 # Adicionar uma regra em pre-routing (-A PREROUTING) para a tabela NAT (-t nat) na qual # pacotes TCP (-p tcp) indo para 1.2.3.4 (-d 1.2.3.4) na porta 8080 (--dport 8080) # têm seu destino trocado (-j DNAT) para 192.168.1.1, porta 80 # (--to 192.168.1.1:80). iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 8080 \ -j DNAT --to 192.168.1.1:80 Se você quer que esta regra altere também as conexões locais (a NAT box tentando conectar-se via telnet com o endereço 1.2.3.4 porta 8080, ela chegará no endereço 192.168.1.1 porta 80), você pode inserir a mesma regra na chain OUTPUT (que serve para pacotes de saídagerados localmente): # Linux 2.4 iptables -A OUTPUT -t nat -p tcp -d 1.2.3.4 --dport 8080 \ -j DNAT --to 192.168.1.1:80 5. Controlando o que será submetido a NAT Você precisa criar regras NAT as quais dirão ao kernel quais conexões serão alteradas, e como alterá-las. Para fazer isso, utiliza-se o versátil iptables e dizemos a ele para alterar a tabela NAT ao especificar a opção `-t nat'. As regras da tabela NAT contêm três listas chamadas `chains': cada regra é examinada em ordem, até que alguma delas corresponda-se com o pacote analizado. As três 'chains' são chamadas PREROUTING (para Destination NAT, quando os pacotes estão prestes a entrar), POSTROUTING (para Source NAT, assim que os pacotes saem), e OUTPUT (para Destination NAT de pacotes gerados localmente. O diagrama abaixo ilustraria isso perfeitamente se eu tivesse talento artístico: :) _____ _____ / \ / \ PREROUTING -->[Decisão ]----------------->POSTROUTING-----> \D-NAT/ [de Roteamento] \S-NAT/ | ^ | __|__ | / \ | | OUTPUT| | \D-NAT/ | ^ | | ----> Processamento Local ---- Em cada um dos pontos acima, quando um pacote passa, é verificado a conexão com a qual ele está associado. Se é uma nova conexão, é verificada a chain correspondente na tabela NAT para ver o que fazer com a mesma. A resposta dada será idêntica para todos os outros pacotes relacionados com tal conexão. 5.1. Seleção simples utilizando iptables iptables tem um número de opções padrão conforme a lista abaixo. Todas as opções com dois hífens (--) podem ser abreviadas, desde que o iptables ainda possa diferenciá-las das demais opções disponíveis. Se seu kernel tem suporte a iptables via módulos, você precisará carregar o módulo ip_tables.o antes com o seguinte comando: `insmod ip_tables'. A opção mais importante é a seleção da tabela com `-t'. Para todas as operações NAT, será necessária a opção `-t nat' para a tabela NAT. A segunda mais importante é a opção '-A', que adiciona uma nova regra no fim da chain (`-A POSTROUTING'), ou `-I' para adiconá-la no início (eg. `-I PREROUTING'). Você pode especificar a origem (`-s' or `--source') e o destino (`-d' or `--destination') dos pacotes que sofrerão NAT. Tais opções podem ser seguidas de um simples endereço IP ( 192.168.1.1), um nome (www.gnumonks.org), ou um endereço de rede (192.168.1.0/24 ou 192.168.1.0/255.255.255.0). Também podem ser especificadas as interfaces de entrada (`-i' ou `--in-interface') ou de saída (`-o' ou `--out-interface'). Qual das interfaces que poderá ser especificada dependerá da chain que receberá a regra: em PREROUTING você pode selecionar apenas a interface de entrada, e em POSTROUTING (e OUTPUT) apenas a interface de saída é selecionada. Se você fizer a opção errada, o iptables restornará um erro. 5.2. Pontos mais específicos sobre o tratamento dos pacotes Foi dito acima que podem ser especificados endreços de origem e destino. Se o endereço de origem foi omitido, a regra servirá para qualquer origem. Se o endereço de destino for omitido, a regra serviá para qualquer destino. Um protocolo específico também pode ser indicado (`-p' or `--protocol'), como o TCP ou o UDP. Ao selecionar um protocolo, apenas pacotes do mesmo se encaixarão na regra. A principal razão para selecionar um protocolo, é que isso permite algumas opções extras. Especificamente as opções `--source-port' e `--destination-port' (abreviadas como `--sport' and `--dport'). Essas opções permitem especificar que apenas pacotes com certa porta de origem e destino se encaixarão na regra. Isso é útil para redirecionamento de requisições web (porta TCP 80 ou 8080). Todas essas opções devem seguir a `-p' (a qual carrega uma biblioteca compartilhada para aquele protocolo). Podem ser usados os números das portas ou um nome do arquivo /etc/services. Todas as outras formas de se selecionar um pacote estão descritas em detalhes na página de manual do iptables (man iptables). 6. E agora, como tratar os pacotes? Agora já sabemos como escolher os pacotes a serem tratados. Para completar, precisamos dizer ao kernel o que fazer com estes pacotes. 6.1. Source NAT 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 6.1.1. Masquerading 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 6.2. Destination NAT 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 6.2.1. Redirecionamento 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! 6.3. Algumas curiosidades menos utilizadas... Há alguns refinamentos do NAT os quais a maioria das pessoas nunca utilizará. Eles estão aqui documentados apenas para os curiosos. 6.3.1. Seleçao de múltiplos endereços em um range 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. 6.3.2. Criando mapeamentos NAT nulos Você pode utilizar `-j ACCEPT' para aceitar uma conexão sem que haja nenhuma espécie de NAT. 6.3.3. Comportamento padrão do 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. 6.3.4. Mapeamento de portas de origem implícito 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: 1. Uma conexão web estabelecida pela máquina 192.1.1.1 vinda da porta 1024 para www.netscape.com porta 80. 2. Tal conexão é mascarada pela máquina de masquerading a fim de usar o endreço de IP de origem 1.2.3.4, que é o endereço de origem da máquina que realiza o masquerading. 3. A máquina que faz o masquerading tenta realizar a conexão web com www.netscape.com porta 80 vinda de 1.2.3.4 (endereço de origem da interface de saída) porta 1024. 4. O código de NAT alterará a porta de origem da segunda conexão para a porta 1025, assim as duas conexão não conflitarão. Quando esse mapeamento de origem implícito ocorre, as portas são divididas em três classes: · Portas menores que 512 · Ports entre 512 e 1023 · Portas acima de 1024. Uma porta NUNCA será mapeada implicitamente para uma classe diferente. 6.3.5. O que ocorre quando NAT falha 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. 6.3.6. Mapeamentos múltiplos, overlap e conflitos 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 6.3.7. Alterando destino de pacotes gerados localmente 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. 7. Protocolos especiais Alguns protocolos não se dão muito bem com NAT. Para cada um destes protocolos, duas extensões tiveram de ser escritas; uma para o acompanhamento do protocolo, e a outra para o atual NAT. Dentro da distribuição do netfilter, há atualmente módulos para ftp: ip_conntrack_ftp.o e ip_nat_ftp.o. Se você carregar esses módulos para dentro de seu kernel (ou compilá-los permanentemente), qualquer tipo de NAT em conexões FTP deve funcionar. Se não funcionar, você só pode utilizar ftp passivo, e talvez nem isso funcione de forma confiável se você está fazendo mais que um simples Source NAT. 8. Algumas prevenções sobre NAT Se você está fazendo NAT em uma conexão, todos os pacotes passando nas duas direções (entrando e saindo da rede) DEVEM passar pela máquina responsável pelo NAT, ou nada funcionará confiavelmente. Particularmente, o código de acompanhamento de conexões remonta fragmentos, o que significa que além do acompanhamento de conexões, toda a rede pode ter problemas, uma vez que os fragmentos serão detidos. 9. Source NAT e roteamento Se você está fazendo SNAT, você vai querer ter certeza de que toda máquina destino dos pacotes SNAT'ed vai responder para a máquina que está fazendo NAT. Por exemplo, se você está mapeando alguns pacotes que estão saindo com o endereço de origem 1.2.3.4, o roteador externo precisa saber que as respostas devem ser enviadas para 1.2.3.4. Isso pode ser feito das seguintes formas: 1. Se você está fazendo SNAT para o próprio endereço da máquina que realiza NAT (para a qual o roteamento e todos os outros serviços já funcionam), nada precisa ser feito. 2. Se você está fazendo SNAT para um endereço inutilizado na sua rede local (por exemplo, você está mapeando para 1.2.3.99, um endereço livre na sua rede 1.2.3.0/24 network), sua máquina responsável pelo NAT terá de responder a requisiçoes ARP para aquele endereço (1.2.3.99) assim como responde os destinados a ela própria. A maneira mais fácil de implementar isso é criando um apelido de IP (alias), conforme esse exemplo: # ip address add 1.2.3.99 dev eth0 3. Se você está fazendo SNAT para um endereço completamente diferente, você terá de ter certeza que as máquinas atingidas pelos pacotes SNAT'ed rotearão tal endereço de volta para a máquina responsável por NAT. Isso já está implementado se a NAT box é o gateway padrão da LAN, caso contrário você terá de esclarecer uma rota (caso você esteja utilizando algum protocolo de roteamento) ou adicionar rotas manualmente em cada máquina envolvida. 10. Destination NAT para a mesma rede Se você está fazendo portforwarding para a mesma rede, você precisa ter certeza que pacotes de requisição e de resposta passarão pela máquina responsável por NAT (podendo então serem alterados). O código NAT vai agora (desde 2.4.0-test6), bloquear redirecionamento de saída ICMP que ocorre quando o pacote NAT'ed sai pela mesma interface pela qual entrou, mas o servidor que recebeu ainda tentará responder diretamente para o cliente (que não vai reconhecer a resposta). O caso clássico ocorre quando as máquinas internas tentam acessar o web server `público', que na verdade sofre DNAT do endereço externo (1.2.3.4) para uma máquina interna (192.168.1.1), como descrito abaixo: # iptables -t nat -A PREROUTING -d 1.2.3.4 \ -p tcp --dport 80 -j DNAT --to 192.168.1.1 Uma maneira é rodar um servidor DNS interno que sabe os endereços IP reais (internos) do seu web site público, e repassa todas as outras requisições para um servidor DNS externo. Isso significa que o log no seu web server mostrará os endereços IP internos corretamente. A outra forma é dizer à máquina responsável por NAT que mapeie o endereço IP de origem para o seu próprio nessas conexões. Nesse exemplo, faríamos o seguinte (assumindo que o endereço interno da NAT box seja 192.168.1.250): # iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \ -p tcp --dport 80 -j SNAT --to 192.168.1.250 Devido ao fato de que a chain PREROUTING é analizada antes, os pacotes já estarão destinados para o web server interno: podemos dizer quais conexões têm origem interna pelo endereço IP de origem. 11. Agradecimentos Primeiramente, gostaria de agradecer à WatchGuard, e ao David Bonn, aqueles que acreditaram na idéia do netfilter e me apoiaram enquanto eu o desenvolvia. E a todos aqueles que me levantaram enquanto eu aprendia sobre a feiura do NAT, especialmente àqueles que leram meu diário. Rusty E eu, (Guilherme Ude, tradutor para o Português do Brasil) gostaria de agradecer a todo o time da LinuxPlace, ao pessoal do dicionário Merriam-Webster (http://www.m-w.com) que muito me ajudou nesta tradução e a todas as pessoas que sempre acreditaram em mim. Muito obrigado! Tradutor para o Português do Brasil: Guilherme Ude Braz (guilherme@linuxplace.com.br).