[FUG-BR] RES: RES: RES: IPFW, protocolos obscuros, protocolos criptografados etc.

[Renato Frederick]

Opa!


> -----Mensagem original-----
> De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br] Em
> nome de Trober
> Enviada em: domingo, 19 de abril de 2009 19:01
> Para: FUG-BR
> Assunto: Re: [FUG-BR] RES: RES: IPFW, protocolos obscuros, protocolos
> criptografados etc.
> 
> Olá a todos.
> 
> Resolvido o problema! Atribuí máscara e funcionou lindamente :D

Aeeeeeeeeeeeeeee :)


> 
> A dúvida que ficou é a razão de alguns criarem a regra para depois
> criarem
> o pipe. Se John Venn e eu não estivermos errados, a precedência e a
> pertinência deveriam ser obedecidas.
> 
> Vejo, por aí, muitos exemplos (estranhos), assim:
> 
>     #Download
>     ipfw add 1001 pipe 1 all from any to $varIP
>     ipfw pipe 1 config bw 256Kbit/s mask dst-ip 0xffffffff
> 
> Na minha lógica, se vou criar um regra associada a um pipe, este deve
> existir ANTES da atribuição, conforme abaixo:
> 
>     #Download
>     ipfw pipe 1 config bw 256Kbit/s mask dst-ip 0xffffffff
>     ipfw add 1001 pipe 1 all from any to $varIP
> 
> Então, John Venn revirou-se no caixão ou não? hehe
> 

Se você jogar pro pipe 1 e ele não existir, o tráfego ficará 'bloqueado'. Porque se não tem pipe, ele não vai sair. Tem que existir um pipe, mesmo que seja 0Kb(ilimitao).
no 1o exemplo, até o script chegar na linha de pipe, o tráfego do cliente ficará cortado.
No 2o caso, o pipe é criado primeiro, então o cliente não sente a interrupção.

Mas na verdade, como sempre há um ipfw flush no inicio da regra e o processamento do ipfw.rules é tão rápido, normalmente fica 'elas por elas' e o cliente não sente a interrupção(bom, downloads ativos normalmente são resetados...) e pode haver uma desconexão no MSN que o usuário não percebe, só os contatos dele, mas isto tbm se deve ao fato de limpar a regra do NAT.