Linux 2.4 NAT HOWTO <author>Rusty Russell, lista de email <tt>netfilter@lists.samba.org</tt> <date>$Revision: 1.3 $ $Date: 2002/08/13 01:17:05 $ <abstract> Este documento descreve como fazer mascaramento de conexões, proxy transparente, repasse de portas, e outras formas de Network Address Translations com os kernels Linux 2.4. </abstract>  <toc>  <sect>Introdução<label id="intro"> Bem-vindo, gentil leitor. Você está para adentrar no mundo fascinante (e às vezes horrível) do NAT: Network Address Translation, e este HOWTO vai ser o seu guia para o Kernel Linux 2.4 e além. No Linux 2.4, uma infraestrutura para tratar pacotes foi introduzida, chamada `netfilter'. Uma camada no topo desta fornece o NAT, reescrito completamente dos kernels anteriores. (C) 2000 Paul `Rusty' Russel. Licenciada sob a GNU GPL. <sect>Onde está o Site Web e a Lista Oficiais? Existem três sites oficiais: <itemize> <item>Graças ao <url url="http://netfilter.filewatcher.org/" name="Filewatcher">. <item>Graças ao <url url="http://netfilter.samba.org/" name="The Samba Team e SGI">. <item>Graças ao <url url="http://netfilter.gnumonks.org/" name="Harald Welte">. </itemize> Para a lista de email oficial, veja o <url url="http://lists.samba.org/" name="Listserver do Samba">. <sect1>O que é Network Address Translation? Normalmente, os pacotes em uma rede viajam de sua origem (como o seu computador doméstico) para seu destino (como www.gnumonks.org) por muitos links diferentes: cerca de 19 de onde eu estou na Austrália. Nenhum destes links realmente altera o seu pacote: eles apenas passam ele adiante. Se um destes links faz NAT, então ele deve alterar a origem ou destino do pacote conforme ele passa. Como você pode imaginar, esta não é a forma que o sistema foi projetado para funcionar, e assim o NAT é quase um remendo. Geralmente o link que faz o NAT irá lembrar como o pacote foi alterado, e quando um pacote de resposta vier de volta, ele irá desfazer a alteração no pacote de resposta, e tudo vai funcionar. <sect1>Por Que Eu Quero Fazer NAT? Em um mundo perfeito, você não quer. Enquanto o mundo não é perfeito, as razões principais são: <descrip> <tag>Conexões de MODEM à Internet</tag>A maioria dos ISPs fornece a você um único endereço IP quando você disca para eles. Você pode mandar pacotes com qualquer endereço de origem que qusier, mas somente os pacotes com este endereço IP de origem irão retornar a você. Se você quer usar várias máquinas diferentes (como em uma rede doméstica) para conectar-se à Internet por este link, você vai precisar de NAT. Este é de longe o uso mais comum do NAT hoje, conhecido vulgarmente como `masquerading' (mascaramento) no mundo Linux. Eu chamo isto de SNAT, por que você muda o endereço de <bf/origem/ (source) do primeiro pacote. <tag>Múltiplos Servidores</tag>Algumas vezes você quer mudar o destino dos pacotes que chegam à sua rede. Frequentemente isto acontece por que (como acima), você só tem um endereço IP, mas quer que as pessoas possam acessar os computadores atrás do endereço de IP `real'. Se você reescrever o destino dos pacotes que chegam, você consegue administrar isto. Este tipo de NAT é chamado de port-forwarding (repasse de portas) nas versões anteriores do Linux. Uma variação comum é divisão de carga, onde o mapeamento é feito sobre um grupo de máquinas, dividindo os pacotes entre elas. Se você está fazendo isto em uma escala séria, você vai querer dar uma olhada no <url url="http://linuxvirtualserver.org/" name="Linux Virtual Server">. <tag>Proxy Transparente</tag>Algumas vezes você quer que todos os pacotes que passam pelo seu computador Linux sejam destinados a um programa no próprio computador Linux. Isto é usado para fazer proxies transparentes: um proxy é um programa que fica entre sua rede e o mundo exterior, arrastando a comunicação entre os dois. A parte transparente é por que sua rede nem sabe que está falando com um proxy, a menos, é claro, que o proxy não funcione. O Squid pode ser configurado para trabalhar deste jeito, e isto é chamado de redireção ou proxy transparente nas versões anteriores do Linux. </descrip> <sect>Os Dois Tipos de NAT Eu divido o NAT em dois diferentes tipos: <bf>Source NAT</bf> (SNAT) e <bf>Destination NAT</bf> (DNAT). O Source NAT acontece quando você altera o endereço de origem do primeiro pacote, isto é, você está mudando o endereço de onde a conexão está vindo. O Source NAT é sempre feito no post-routing, logo antes do pacote ser jogado na linha. O Masquerading é uma forma especializada de SNAT. O Destination NAT acontece quando você altera o endereço de destino do primeiro pacote, isto é, quanvo você está alterando o endereço para onde a conexão está indo. O Destination NAT é sempre feito antes do roteamento, quando o pacote acabou de sair da linha. O repasse de porta, compartilhamento de carga, e o proxy transparente são todas formas de DNAT. <sect>Tradução Rápida dos Kernels 2.0 e 2.2 Desculpe àqueles que ainda estão chocados com a transição do 2.0 (ipfwadm) para o 2.2 (ipchains). Tenho boas e más notícias. Primeiro, você pode simplesmente continuar usando o ipchains e o ipfwadm como antes. Para isto, você precisa que o insmod carregue os módulos `ipchains.o' ou `ipfwadm' encontrados na última distribuição do netfilter. Estes são mutuamente exclusivos (você foi avisado), e não devem ser combinados com quaisquer outros módulos do netfilter. Uma vez que estes módulos estejam instalados, você pode usar o ipchains e o ipfwadm normalmente, com as seguintes diferenças: <itemize> <item>A configuração de timeouts do mascaramento com ipchains -M -S, ou ipfwadm -M -s não faz nada. Uma vez que os timeouts naõ fazem mais parte da infraestrutura do novo NAT, isto não vai fazer diferença. <item>Os campos init_seq, delta e previous_delta na listagem detalhada do mascaramento são sempre zero. <item>Zerar e listar os contadores ao mesmo tempo com `-Z -L' não irá mais funcionar: os contadores não serão zerados. <item>A camada de compatibilidade com versões anteriores não escala muito bem para um grande número de conexões: não use ela para seu gateway corporativo! </itemize> Os hackers também irão notar: <itemize> <item>Você pode agora ligar-se às portas 61000-65095 mesmo se você está fazendo mascaramento. O código de mascaramento assume que qualquer coisa neste intervalo é `fair game', assim os programas não pode usá-las. <item>O hack (não documentado) `getsockname', que programas de proxy transpartente podem usar para descobrir o destino real das conexões não funciona mais. <item>O hack (não documentado) `bind-to-foreign-address' também não está implementado; ele era usado para completar a ilusão de proxy transparente. </itemize> <sect1>Eu só quero mascaramento! Socorro! É isto o que a maioria das pessoas quer. Se você tem uma conexão IP PPP discada (e se você não sabe, este é você), você simplesmente quer dizer ao seu computador que todos os pacotes vindo de sua rede interna devem parecer estar vindo do computador que faz o PPP dialup. <tscreen><verb> # Load the NAT module (this pulls in all the others) modprobe iptable_nat # In the NAT table (-t nat), Append a rule (-A) after routing # (POSTROUTING) for all packets going out ppp0 (-o ppp0) which says to # MASQUERADE the connection (-j MASQUERADE) iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # Turn on IP forwarding echo 1 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> Note que você não está fazendo qualquer filtro de pacotes aqui: para isso, veja o Filtro de Pacotes HOWTO: `Misturando NAT e Filtro de Pacotes'. <sect1>E sobre o ipmasqadm? Este tem uma base de usuários muito menor, por isto eu não me preocupei muito com compatibilidade com o mesmo. Você pode simplesmente usar o `iptables -t nat' para fazer o repasse de portas. Assim, por exemplo, no Linux 2.2 você teria feito: <tscreen><verb> # Linux 2.2 # Forward TCP packets going to port 8080 on 1.2.3.4 to 192.168.1.1's port 80 ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80 </verb></tscreen> Agora você deve fazer: <tscreen><verb> # Linux 2.4 # Append a rule before routing (-A PREROUTING) to the NAT table (-t nat) that # TCP packets (-p tcp) going to 1.2.3.4 (-d 1.2.3.4) port 8080 (--dport 8080) # have their destination mapped (-j DNAT) to 192.168.1.1, port 80 # (--to 19.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 </verb></tscreen> <sect>Controlando Para O Quê Fazer NAT Você precisa criar regras NAT que digam ao kernel quais conexões devem ser alteradas, e como alterar as mesmas. Para isto, usamo a super-versátil ferramenta <tt/iptables/, e dizemos à mesma para alterar a tabela NAT especificando a opção `-t nat'. A tabela de regras NAT contém duas listas chamadas `cadeias': cada regra é examinada em ordem até que ocorra uma correspondência. As duas cadeias são chamadas PREROUTING (para Destination NAT, quando os pacotes chegam), e POSTROUTING (para Source NAT, quando os pacotes saem). O seguinte diagrama iria ilustrar bem se eu tivesse algum talento artístico: <tscreen><verb> _____ _____ / \ / \ PREROUTING -->[Routing ]----------------->POSTROUTING-----> \D-NAT/ [Decision] \S-NAT/ | ^ | | | | | | | | | | | | --------> Local Process ------ </verb></tscreen> Em cada um dos pontos acima, quando um pacote passa, nós descobrimos a qual conexão ele está associado. Se é uma nova conexão, procuramos pela acdeia correspondente na tabela NAT para ver o quê fazer com ele. A resposta que for dada será aplicada a todos os futuros pacotes naquela conexão. <sect1>Seleção Simples usando iptables O <tt/iptables/ pede um certo número de opções padrão conforme listado abaixo. Todas as opções de dois-traços podem ser abreviadas, desde qeu o <tt/iptables/ consiga distinguir as opções possíveis. Se seu kernel tem o suporte a iptables como módulo, você precisará carregar o módulo ip_tables.o primeiro: `insmod ip_tables'. A opção mais importante aqui é a opção que seleciona a tabela, `-t'. Para todas operações NAT, você vai querer usar `-t nat' para a tabela NAT. A segunda opção mais importante a ser usada é o `-A' para anexar uma nova regra no fim da cadeia (por exemplo, `-A POSTROUTING'), ou `-I' para inserir uma no inídio (por exemplo, `-I PREROUTING'). Você pode especificar a origem (`-s' ou `--source') e o destino (`-d' ou `--destination') dos pacotes que você quer fazer NAT. Estas opções podem ser seguidas por um único endereço IP (por exemplo, 192.168.1.1), um nome (por exemplo, www.gnumonks.org), ou um endereço de rede (por exemplo, 192,168.1.0/24 ou 192.168.1.0/255.255.255.0). Você pode especificar a interface de entrada (`-i' ou `--in-interface') ou de saída (`-o' ou `--out-interface') para fazer a seleção, mas isto depende também de qual cadeia você está inserindo a regra: na cadeia PREROUTING, você somente pode selecionar a interface de entrada, e na cadeia POSTROUTING você só pode selecionar a interface de saída. Se você especificar a interface errada, o <tt/iptables/ vai retornar um erro. <sect1>Pontos Ótimos para Selecionar Quais Pacotes Alterar Foi dito acima que você pode especificar um endereço de origem e destino. Se você quer omitir a opção do endereço de origem, então qualquer endereço de fonte irá servir. Se você omitir a opção de endereço de destino, então qualquer endereço de destino vai servir. Você pode também indicar um protocolo específico ( `-p' ou `--protocol'), como TCP ou UDP, somente pacotes daquele protocolo serão selecionados pela regra. A razão principal para fazer isto é que ao especificar o protocolo tcp ou udp então existem outras opções que fiacm disponíveis: especificametne as opções `--source-port' e `--destination-port' (abreviadas como `--sport' e `--dport'). Estas opções permitem a você especificar qeu somente pacotes com uma certa porta de origem e destino serão selecionados pela regra. Ísto é bastante útil para redirecionar solicitações web (porta TCP 80 ou 8080) e deixando as outras portas de lado. Estas opções devem seguir a opção `-p' (que tem o efeito de carregar a biblioteca compartilhada da extensão para aquele protocolo). Você pode usar números de portas, ou um nome do arquivo /etc/services. Todas as diferentes qualidades que você pode selecionar em um pacote estão detalhadas em dolorosos detalhes na página manual (<tt>man iptables</tt>). <sect>Dizendo Como Alterar Os Pacotes Agora já sabemos como selecionar os pacotes que queremos alterar. Para completar nossa regra, precisamos dizer ao kernel exatamente o que queremos fazer com os pacotes. <sect1>Source NAT Você quer fazer Source NAT; mudar o endereço origem das conexões para algo diferente. Isto é feito na cadeia POSTROUTING, logo antes do pacote ser despachado. Este é um detalhe importante, uma vez que significa que qualquer coisa no próprio computador Linux (roteamento, filtro de pacotes) verá o pacote inalterado. Isto também significa que a opção `-o' (interface de saída) pode ser usada. O Source NAT é especificado usando `-j SNAT', e a opção `--to-source' especifica um endereço IP, um intervalo de endereços IP, e uma porta ou intervalo de portas opcionais (somente para os protocolos TCP e UDP). <tscreen><verb> ## Change source addresses to 1.2.3.4. # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4 ## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6 ## Change source addresses to 1.2.3.4, ports 1-1024 # iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023 </verb></tscreen> <sect2>Mascaramento Existe uma forma especializada de Source NAT chamada mascaramento: deve ser usada apenas para endereços IP dinâmicos, como linhas discadas padrão (para endereços Ip estáticos, use o SNAT acima). Você não precisa colocar o endereço de origem explicitamente com o mascaramento: ele irá usar o endereço de origem da interface do qual o pacote está vindo. Mas, mais importente, se o link cair, a conexão (que é perdida) é esquecida, o que significa menos problemas quando a conexão retorna com um novo endereço IP. <tscreen><verb> ## Masquerade everything out ppp0. # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE </verb></tscreen> <sect1>Destination NAT Isto é feito na cadeia PREROUTING, assim que o pacote chega. Isto significa que tudo o mais no seu computador Linux (roteamento, filtro de pacotes) irá ver o pacote indo para seu destino `real'. Isto também significa que a opção `-i' (interface de entrada) pode ser usada. O Destination NAT é especificado usando `-j DNAT', e a opção `--to-destination' especifica um endereço IP, um intervalo de endereços IP e uma porta ou intervalo de portas opcionais (somente para protocolos TCP e UDP). <tscreen><verb> ## Change destination addresses to 5.6.7.8 # iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8 ## Change destination addresses to 5.6.7.8, 5.6.7.9 or 5.6.7.10. # iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8-5.6.7.10 ## Change destination addresses of web traffic to 5.6.7.8, port 8080. # iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 \ -j DNAT --to 5.6.7.8:8080 </verb></tscreen> <sect2>Redireção Existe uma forma especializada de Destination NAT chamada redireção: é uma conveniência simples que é exatamente equivalente a fazer DNAT ao endereço da interface de entrada. <tscreen><verb> ## Send incoming port-80 web traffic to our squid (transparent) proxy # iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \ -j REDIRECT --to-port 3128 </verb></tscreen> Note que o Squid precisa ser configurado para saber que é um proxy transparente! <sect1>Mapeamentos em profundidade Existem algumas sutilezas em relação ao NAT que a maioria das pessoas não precisa tratar. Elas estão documentadas aqui para os curiosos. <sect2>Seleção de Múltiplos Endereços em um Intervalo Se for dado um intervalo de endereços IP, o endereço IP a usar é escolhido baseado no endereço IP menos usado para conexões que a máquina conhece. Com isto se consegue um balanço de carga primitivo. <sect2>Criando Mapeamentos Null NAT Você pode usar o destino `-j ACCEPT' para permitir uma conexão passar sem nenhum NAT acontecendo. <sect2>Comportamento Padrão do NAT O comportamento padrão é alterar a conexão o mínimo possível, dentro das limitações da regra dada pelo usuário. Isto significa que não serão feitos remapeamentos de portas a menos que seja necessário. <sect2>Mapeamento de Porta Origem Implícito Mesmo quando não é requisitado um NAT para uma conexão, a tradução porta de origem pode ocorrer implicitamente, se outra conexão tiver sido mapeada sobre a nova. Considere o caso de mascaramento, que é bastante comum: <enum> <item>Uma conexão web é estabelecida por um computador 192.1.1.1 da porta 1024 para www.netscape.com, porta 80. <item>Esta conexão é mascarada pela máquina que faz o mascaramento, para uar seu endereço IP (1.2.3.4). <item>A máquina que faz o mascaramento tenta fazer uma conexão web à www.netscape.com, porta 80, de 1.2.3.4 (o endereço da interface externa), porta 1024. <item>O código do NAT irá alterar a porta de origem da segunda conexão para 1025, assim as duas não irão colidir. </enum> Quando este mapeamento de porta de origem implícito ocorrer, as portas são dividias em três classes: <itemize> <item>Portas abaixo de 512 <item>Portas entre 512 e 1023 <item>Portas 1024 e acima. </itemize> Uma porta nunca será mapeada implicitamente para uma classe diferente. <sect2>O Que Acontece Quando o NAT Falha Se não hovuer uma forma de mapear de forma unívoca uma conexão solicitada por um usuário, ela será descartada. Isto também aplica-se a pacotes que não podem ser classificados como parte de nenhuma conexão, por que são malformados, ou o computador está sem memória livre, etc. <sect2>Mapeamentos Múltiplos, Overlaps e Colisões Você pode ter regras NAT que mapeiam pacotes no mesmo intervalo, o código do NAT é esperto o suficiente para evitar colisões. Portanto, ter duas regras que mapeiam os endereços de origem 192.168.1.1 e 192.168.1.2 para 1.2.3.4 está OK. Além disto, você pode fazer mapeamento em endereços IP reais e usados, desde que estes endereços passem pelo computador que faz o mapeamento também. Assim, se você tem um endereço de rede atribuído (1.2.3.0/24), mas tem uma rede interna usando aqueles endereços e uma usando os Endereços de Internet Privada 192.168.1.0/24, você pode simplesmente fazer o NAT ods endereços de origem 192.168.1.0/24 para a rede 1.2.3.0, sem receio de colisões: <tscreen><verb> # iptables t nat -A POSTROUTING -s 192.158.1.0/24 -o eth1 \ -j SNAT --to 1.2.3.0/24 </verb></tscreen> A mesma lógica aplica-se a endereços usados pela própria máquina que faz o NAT: é assim que o mascaramento funciona (compartilhando o endereço da interface entre pacotes mascarados e pacotes `reais' vindo da própria máquina). Mais, você pode mapear os mesmos pacotse em vários destinos diferentes, e eles serão compartilhados. Por exemplo, se você não quer mapear qualquer coisa sobre 1.2.3.5, pode fazer: <tscreen><verb> # 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 </verb></tscreen> <sect2>Alterando o Destino de Conexões Locais O código do NAT permite que você insira regras DNAT na cadeia OUTPUT, mas isto não tem suporte completo no 2.4 (pode ser feito, mas exige uma nova opção de configuração, alguns tesets, e alguma codificiação, de forma que, a menos que alguém contrate Rusty para escrever isto, eu não espero isto tão cedo). A limitação atual é que você somente opde alterar o destino para a máquina local (por exemplo, `-j DNAT --to 127.0.0.1'), e não para qualquer outra máquina, caso contrário as respostas não serão traduzidas corretamente. <sect>Protocolos Especiais Alguns protocolos não gostam de sofrer NAT. Para cada um destes protocolos, duas extensões devem ser escritas: uma para o controle de conexão do protocolo, e outro para o NAT em si. Na distribuição do netfilter, atualmente existem módulos para o ftp: ip_conntrack_ftp.o e ip_nat_ftp.o. Se você instalar estes módulos no seu kernel (com insmod ou compilando como parte do kernel), então fazer qualquer tipo de NAT em conexões FTP deve funcionar. Se você não fizer, entaõ você somente pode usar ftp passivo, e mesmo este não vai funcionar de uma forma confiável se você estiver fazendo mais que o Source NAT simples. <sect>Cuidados com o NAT Se você estiver fazendo NAT em uma conexão, todos os pacotes que passam em <bf/ambos/ os caminho (entrando e saindo da rede) devem passar pela máquina que faz o NAT, ou não vão funcionar de forma confiável. Em particular, o código de controle de conexões remonta os fragmentos, o que significa não somente que o controle de conexão não será confiável, mas seus pacotes podem não passar, pois os pacotes podem vir a ser recusados. <sect>Source NAT e Roteamento Se você estiver fazendo o SNAT, vai querer certificar-se que todos os pacotes das máquinas para os quais os pacotes que sofreram SNAT vão, enviem respostas de volta para a máquina que faz o NAT. Por exemplo, se você está mapeando alguns pacotes que saem no endereço 1.2.3.4, então o roteador externo deve saber que deve mandar todos os pacotes de resposta (os que tem <bf/destino/ 1.2.3.4) de volta para este computador. Isto pode ser feito das seguintes formas: <enum> <item>Se você está fazendo SNAT no próprio endereço do computador (para o qual o roteamento e tudo o mais já funciona), você não precisa fazer nada. <item>Se você estiver fazendo SNAT para um endereço não usado na LAN local (por exmeplo, você está mapeando para 1.2.3.99, um IP livre em sua rede 1.2.3.0/24), seu computador NAT tem que responder a solicitações ARP para aquele endereço além do seu próprio: a forma mais fácil de fazer isto é criar um IP alias: <tscreen><verb> # ip address add 1.2.4.99 dev eth0 </verb></tscreen> <item>Se você estiver fazendo SNAT em um endereço completamente diferenet, você terá que garantir que as máquinas para a qual os pacotes SNAT irão irá rotear estes endereços de volta à máquina que faz NAT. Isto já deve estar acontecendo se a máquina que faz NAT for o roteador padrão, caso contrário você terá que anunciar uma rota (se estiver rodando um protocolo de roteamento) ou acrescentar manualmente rotas para cada máquina envolvida. </enum> <sect>Destination NAT na Mesma Rede Se você estiver fazendo repasse de porta para a mesma rede, precisa certificar-se que tanto pacotes ruturos e pacotes de resposta passem pela máquina que faz o NAT (para que possam ser alterados). O código do NAT irá bloquear (desde a versão 2.4.0-test6) o pacote ICMP redirect que sai, que é produzido quando o pacote NAT é destinado á mesma interface da qual ele veio, mas o servidor que recebe a conexão ainda irá tentar responder diretamente ao cliente (que não irá reconhecer a resposta). O caso clássico é que o staff interno tenta acessar o servidor web `público', que é na verdade uma máquina que está atrás de um DNAT do endereço público (1.2.3.4) para uma máquina interna (192.168.1.1), parecido com este: <tscreen><verb> # iptables -t nat -A PREROUTING -d 1.2.3.4 \ -p tcp --dport 80 -j NAT --to 192.168.1.1 </verb></tscreen> Uma solução é rodar um servidor DNS interno que conhece o endereço Ip real (interno) do seu web site público, e repassar todas as outras solicitações para um servidor DNS externo. Isto significa que o log do seu servidor web irá apresentar os endereço IP interno corretamente. A outra forma é fazer com que a máquina que faz o NAT mapeie também o endereço IP para o seu próprio endereço para estas conexões, enganando o servidor e fazendo com que ele responda para ele. Neste exemplo, iremos fazer o seguinte (assumindo que o endereço interno da máquina que faz o NAT é 192.168.1.250): <tscreen><verb> # 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 </verb></tscreen> Como a regra do <bf/PREROUTING/ é executada primeiro, os pacotes serão realmente destinados ao servidor web interno: podemos dizer quais são os que vem da rede interna pelo endereço Ip de origem. <sect>Agradecimentos Agradeço primeiro à WatchGuard, e David Bonn, que acreditou na idéia do netfilter o suficiente para me dar suporte enquanto eu trabalhava nele. E a todo mundo que acompanharam minhas discussões, conforme eu aprendia sobre as complicações do NAT, especialmente os que leram meu diário. Rusty. </article>