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
[EMAIL PROTECTED]
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)
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
