Opa!
> -----Mensagem original----- > De: [email protected] [mailto:[email protected]] 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
