[FUG-BR] Dúvida Natd (fluxo de pacotes pelo ipfw)

[Rodolfo Zappa]

Luiz Otavio Souza escreveu:
> Rodolfo Zappa escreveu:
>   
>> (...)
>>   
>> Ok, mas o pacote é reavaliado desde o início das regras, ou a partir do 
>> ponto do divert?
>>
>> O problema que eu tenho é o seguinte: eu quero bloquear ou liberar 
>> pacotes da minha lan para a internet, baseados no ip de origem. Mas, 
>> após passar pelo natd, o pacote perde a referência do ip de origem, e a 
>> terceira regra abaixo, nunca é acionada.
>>
>> ${ipfw} 100 divert natd ip from any to any via ${ext_if}
>> ${ipfw} 101 chek-state
>> ${ipfw} 102 allow tcp from 192.168.0.25 to any 80 out via ${ext_if}
>>
>> Estou estudando o IPFW, acho a sintaxe maravilhosa e simples, os 
>> controles de banda facílimos de aprender, mas o fluxo do pacote pelo 
>> firewall, quando tem um divert para o natd,  são muito mal documentados 
>> e completamente diferentes do PF, IPF e até do IPTABLES do netfilter.
>>
>> Por exemplo, no netfilter o fluxo é assim (simplificando):
>>
>>  nat prerouting --> forward --> nat postrouting
>>
>> e quando eu quero liberar ou bloquear um pacote, baseado na origem, uso 
>> a chain forward, que memso depois de pasara pelo nat, não perde a 
>> referência do ip de origem.
>>
>> Alguém tem um bom doc sobre ipfw + natd, mostrando o fluxo dos pacotes 
>> pelo firewall?
>>
>> Patrick, pode dar uma mãozinha de novo?
>>
>>   
>>     
> Rodolfo,
>
> Os são pacotes enviados para o natd através do divert no ipfw e voltam 
> (do natd para o ipfw) na mesma regra, o processamento continua a partir 
> da linha do natd.
>
> Mas seu problema é que você esta procurando pelo pacote depois que ele 
> já foi nateado e ai realmente você perde a referencia ao IP interno.
>
> É só fazer a regra utilizando a interface interna e não a externa.
>
> O fluxo do ipfw (com duas placas e pacotes passando da rede interna para 
> a rede externa) é o seguinte: in via intif -> out via intif -> in via 
> outif -> out via outif.
>
> Já o fluxo do natd é o seguinte:
>
> - O IP de origem é substituido apenas em pacotes que estão saindo pela 
> interface (out via outif) e é criado um estado para essa "tradução".
>
> - Já os pacotes chegando na interface (in via outif) são verificados 
> contra a tabela de estados do natd e caso seja identificado como um 
> pacote traduzido ele é nateado de volta (o IP de destino dessa vez é 
> alterado para o IP interno utilizando as informações salvas na tabela de 
> estado).
>
> Ou seja, para o natd funcionar são necessárias duas linhas:
>
> # ipfw add divert natd ip from 192.168.0.0/24 to any out via bge0 # => 
> faz o nat de saída
> # ipfw add divert natd ip from any to 200.200.200.200 in via bge0 # => 
> faz o nat do retorno
>
> Considerando que sua rede interna seja 192.168.0.0/24 e o IP do seu 
> servidor seja 200.200.200.200.
>
> Como nem sempre o servidor tem IP fixo, a maioria dos exemplo simplifica 
> essas duas regras em uma única (como nos exemplos em /etc/rc.firewall), 
> mas isso normalmente acaba passando mais trafego do que o preciso pelo 
> natd (o trafego que não precisa ser nateado é ignorado, mas consome 
> alguns recursos extras, já que o natd roda no espaço usuário e os 
> pacotes precisam ser copiados do kernel para o natd e depois reinjetados 
> pelo natd através de outra copia no sentido inverso).
>
> []s
> Luiz
> PS: Regras check-state e stablished após o natd são potencialmente 
> "perigosas", elas passam os pacotes baseados no estado de cada conexão e 
> podem confundir bastante. Faça todo trabalho sujo (fwd por exemplo) logo 
> depois do natd para evitar problemas.
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
> !DSPAM:8,46d19726816441013332718!
>
>
>   

Luiz,

Muito grato pela informação!!!

Mas gostaria também de ler mais sobre o assunto. Neste aspecto em 
particular, o handbook é bem fraco. Já vi o ipfw-howto e o ipfw-advanced 
howto, e eles se atém muito a sintaxe, em vez da lógica do firewall 
(como o fluxo).

Além disso, muito pouca documentação sobre ipfw + natd, ambas 
documentações tratam deles em separado, ou em ambientes pobres, para 
exemplos.

Até hoje não consegui formar uma opinião, sobre a viabilidade do uso do 
natd para ambientes grandes (mais de 300 usuários simultâneos), se ele 
comporta (obviamente, num mesmo hardware que hoje tem o pf).

Apesar do pf estar atendendo, tenho cogitado mudar para o ipfw, por 
conta do maior controle de pacotes e traffic shapping do ipfw, mas o 
natd é de tirar o sono.

Pelo menos pra mim, as regras com natd não são tão claras quanto as 
regras do nat com o pf.

A propósito, alguém na lista comentou que o ipfw no freebsd 7 vem com 
nat builtin no kernel. É verdade? Faz sentido?

-- 
Cordialmente,

Rodolfo Zappa

Archive TSP - Total Solution Provider
Nosso negócio é garantir que a sua rede de informações não pare!

(21) 2567-1842
rodolfo em archive.com.br
http://www.archive.com.br

"Se a gente se lança sem vigor, sete de dez ações tomadas não dão certo. É extremamente difícil tomar decisões num estado de agitação. Por outro lado, se sem se preocupar com as conseqüências menores, abordamos os problemas com o espírito afiado como uma lâmina, sempre encontramos a solução em menos tempo do que é necessáio para respirar sete vezes." Nabeshima Naoshige (1538-1618)