![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Anterior: Tradução do Endereço de Rede (NAT)] [Conteúdo] [Próximo: Atalhos na Criação de Conjuntos de Regras]
Vejamos um exemplo:
rdr on tl0 proto tcp from any to any port 80 -> 192.168.1.20
Essa linha redireciona o tráfego TCP na porta 80 (servidor Web) para uma máquina na rede com o endereço 192.168.1.20. Portanto, mesmo que 192.168.1.20 esteja atrás do gateway dentro da rede, ela se torna acessível ao mundo externo.
A parte from any to any da linha rdr acima pode ser muito útil. Se você souber quais endereços ou sub-redes devem ter acesso ao servidor na porta 80, pode restringi-los assim:
rdr on tl0 proto tcp from 27.146.49.0/24 to any port 80 -> \
192.168.1.20
Isso redireciona somente a sub-rede especificada. Perceba que isso implica que você pode redirecionar diferentes máquinas para máquinas diferentes atrás do gateway. Isso pode ser muito útil. Por exemplo, você pode fazer com que usuários em lugares remotos acessem seus próprios computadores desktop usando a mesma porta e o mesmo endereço IP no gateway desde que você saiba de que endereço IP eles se conectarão:
rdr on tl0 proto tcp from 27.146.49.14 to any port 80 -> \
192.168.1.20
rdr on tl0 proto tcp from 16.114.4.89 to any port 80 -> \
192.168.1.22
rdr on tl0 proto tcp from 24.2.74.178 to any port 80 -> \
192.168.1.23
Uma faixa de portas também pode ser redirecionada dentro da mesma regra:
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20 port 6000
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20 port 7000:*
Esses exemplos mostram portas entre 5000 a 5500 (faixa inclusiva) sendo redirecionadas para 192.168.1.20. Na primeira regra, a porta 5000 é redirecionada para 5000, 5001 para 5001, etc. Na segunda regra, toda a faixa de portas é redirecionada para a porta 6000. E, na última regra, a porta 5000 é redirecionada para 7000, 5001 para 7001, etc.
A única exceção à regra é quando a palavra-chave pass é usada na regra rdr. Nesse caso, os pacotes redirecionados passam direto pelo sistema de filtragem: as regras de filtragem não são avaliadas para esses pacotes. Esse é um atalho para evitar a adição de regras de filtragem pass para cada regra de redirecionamento. Pense nisso como uma regra rdr normal (sem a palavra-chave pass) associada a uma regra de filtragem pass com a palavra-chave keep state. Contudo, caso queira habilitar opções de filtragem mais específicas, como synproxy, modulate state, etc., você ainda precisa usar regras pass dedicadas, já que essas opções não se encaixam em regras de redirecionamento.
Também fique ciente de que a tradução ocorre antes da filtragem; o sistema de filtragem vê os pacotes traduzidos como eles ficam após terem seus endereços IP e/ou portas alterados para corresponder ao endereço/à porta de redirecionamento especificado(a) na regra rdr. Considere o cenário:
Regra de redirecionamento:
rdr on tl0 proto tcp from 192.0.2.1 to 24.65.1.13 port 80 \
-> 192.168.1.5 port 8000
Pacote antes da regra rdr ser processada:
Pacote após a regra rdr ter sido processada:
O sistema de filtragem vê o pacote IP como ele se encontra após ter sido feita a tradução.
Esses riscos podem ser minimizados mantendo-se os sistemas acessados externamente confinados numa rede separada. Essa rede é geralmente chamada de Zona Desmilitarizada (DMZ - "Demilitarized Zone") ou Rede de Serviços Privada (PSN - "Private Service Network"). Dessa forma, caso o servidor Web seja comprometido, os efeitos podem ser limitados à rede DMZ/PSN pela filtragem cuidadosa do tráfego que terá permissão de entrar e sair da rede DMZ/PSN.
server = 192.168.1.40
rdr on $ext_if proto tcp from any to $ext_if port 80 -> $server \
port 80
Mas quando a regra de redirecionamento é testada por um cliente na LAN, ela não funciona. O motivo é que as regras de redirecionamento se aplicam apenas a pacotes que passam pela interface especificada (no exemplo, a interface externa $ext_if). Conectar-se ao endereço externo do firewall a partir de uma máquina na LAN, contudo, não significa que os pacotes passarão por sua interface externa. A pilha TCP/IP no firewall compara o endereço de destino do pacote chegando com seus próprios endereços e apelidos e detecta conexões para ela mesma tão logo que tenham passado pela interface interna. Esses pacotes não passam fisicamente pela interface externa, e a pilha TCP/IP não simula essa passagem de forma alguma. Portanto, o PF nunca vê esses pacotes na interface externa, e a regra de redirecionamento, especificando a interface externa, não se aplica.
Adicionar uma segunda regra de redirecionamento para a interface interna também não produz o efeito desejado. Quando um cliente local conecta-se ao endereço externo do firewall, o pacote inicial do handshake TCP atinge o firewall pela interface interna. A regra de redirecionamento é aplicada e o endereço de destino é substituído pelo do servidor interno. O pacote é transferido de volta pela interface interna e chega ao servidor interno. Mas o endereço de origem no pacote não foi traduzido, e ainda contém o endereço do cliente local, portanto o servidor envia suas respostas diretamente ao cliente. O firewall nunca vê as respostas, ficando sem chance de reverter a tradução apropriadamente. O cliente então recebe respostas de um endereço IP de onde ele nunca esperava, e por isso descarta os pacotes. O handshake TCP falha e nenhuma conexão pode ser estabelecida.
Mas ainda assim, geralmente é necessário que os clientes na LAN se conectem ao servidor interno da mesma forma que os clientes externos, e que o façam de maneira transparente. Existem várias soluções para esse problema:
É possível configurar servidores DNS para responder às pesquisas de clientes locais de maneira diferente das pesquisas externas, de forma que clientes locais receberão o endereço interno do servidor durante a resolução de nomes. Eles, portanto, se conectam diretamente ao servidor local, e o firewall não tem envolvimento. Isso reduz o tráfego local, já que os pacotes não precisam passar pelo firewall.
Acrescentar mais uma interface de rede ao firewall e mover o servidor local da rede cliente para uma rede dedicada (DMZ) permite o redirecionamento de conexões dos clientes locais da mesma maneira que o redirecionamento de conexões externas. O uso de redes separadas traz diversas vantagens, incluindo melhora na segurança devido ao isolamento do servidor das máquinas locais restantes. Caso o servidor (que em nosso caso é acessível pela Internet) seja comprometido, ele não terá acesso direto às máquinas locais porque todas as conexões devem agora passar pelo firewall.
Um proxy TCP genérico pode ser configurado no firewall, escutando na porta a ser redirecionada ou recebendo conexões redirecionadas na interface interna para a porta onde ele esteja escutando. Quando um cliente local se conecta ao firewall, o proxy aceita a conexão, estabelece uma segunda conexão com o servidor interno e transfere dados entre as duas conexões.
Proxies simples podem ser criados usando-se inetd(8) e nc(1). A entrada no /etc/inetd.conf a seguir cria um soquete que escuta no endereço de loopback (127.0.0.1) na porta 5000. As conexões são encaminhadas ao servidor 192.168.1.10 na porta 80. O redirecionamento é feito pelo usuário "proxy".
127.0.0.1:5000 stream tcp nowait proxy /usr/bin/nc nc -w \
20 192.168.1.10 80
A regra de redirecionamento a seguir transfere conexões na porta 80, na interface interna, para o proxy:
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
127.0.0.1 port 5000
Com uma regra NAT adicional na interface interna, a tradução de endereço que estava faltando no cenário acima pode ser remediada.
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
$server
no nat on $int_if proto tcp from $int_if to $int_net
nat on $int_if proto tcp from $int_net to $server port 80 -> \
$int_if
Isso faz com que o pacote inicial do cliente seja traduzido novamente quando retornar através da interface interna, substituindo o endereço de origem do cliente pelo endereço interno do firewall. O servidor interno responde para o firewall, que pode então reverter ambas as regras de tradução NAT e RDR ao transferir o pacote para o cliente. Essa construção é um tanto complexa, pois cria dois estados separados para cada conexão refletida. Deve-se tomar muito cuidado para evitar que a regra NAT atinja outro tráfego; por exemplo, conexões originadas de máquinas externas (através de outros redirecionamentos) ou do próprio firewall. Perceba que a regra rdr acima faz com que a pilha TCP/IP receba pacotes na interface interna com um endereço de destino dentro da rede interna.
De preferência, deve-se utilizar uma das soluções apresentadas anteriormente.
[Anterior: Tradução do Endereço de Rede (NAT)] [Conteúdo] [Próximo: Atalhos na Criação de Conjuntos de Regras]
![[voltar]](../../../images/back.gif){kind=small}
www@openbsd.org