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

Paulo Henrique paulo.rddck em bsd.com.br
Segunda Abril 20 08:03:49 BRT 2009


Apenas para mudar o titulo para resolvido?

Renato Frederick escreveu:
> 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.
>
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
>   



Mais detalhes sobre a lista de discussão freebsd