acredito que o problema dele era o divert any to any... fazendo regra mais específica resolveu, certo? :)
Eu costumo usar o PF e o IPFW, o segundo pra fazer proxy transparente + TPROXY Em 13/10/10 12:28, Rodrigo Mosconi escreveu: > Pode sim > > De fato, é possível usar os 3 filtros juntos (IPF, PF, e IPFW). Mas > basta um block/deny num deles para negar a comunicação. > > Nada te impede de usar o nat do PF, em conjunto com os filtros do IPFW. > > É possível usar o filtro e nat do PF, por exemplo, em conjunto dos > recursos avançados do IPFW (jail, user,...). > > Em 13 de outubro de 2010 11:55, Marcelo Gondim > <gon...@linuxinfo.com.br> escreveu: >> Opa Alessandro, >> >> Eu poderia em um primeiro momento usar apenas o NAT do pf junto com as >> regras de filtragem do ipfw? Ou teria que fazer todas as regras no pf mesmo? >> >> []´s >> >> -------------------------------------------------- >> From: "Alessandro de Souza Rocha"<etherlin...@gmail.com> >> Sent: Wednesday, October 13, 2010 9:56 AM >> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" >> <freebsd@fug.com.br> >> Subject: Re: [FUG-BR]Performance estranha e quedas na conexão >> >>> porque vc nao usa o pf pra fazer nat ao inveis de usa natd. >>> >>> Em 13 de outubro de 2010 09:33, Renato Frederick >>> <ren...@frederick.eti.br> escreveu: >>>> Precisa fazer o divert "from any to any"? >>>> >>>> O ideal seria 2 regras, uma para out, outra para in e especificando >>>> endereços de origem/destino. >>>> >>>> Outra dúvida, os clientes internos precisam sair com nat pro pgsql? >>>> >>>> talvez reescrever a regra seja interessante, até para economia de >>>> cpu/memória(já que um divert all from any to any empurra pro natd tudo >>>> que >>>> passe pelo firewall e venha de ip´s reservados). >>>> >>>> []s >>>> >>>> >>>> >>>> >>>> >>>> -----Mensagem Original----- >>>> From: Antonio Modesto >>>> Sent: Wednesday, October 13, 2010 8:49 AM >>>> To: Lista Brasileira deDiscussãosobre FreeBSD (FUG-BR) >>>> Subject: Re: [FUG-BR]Performance estranha e quedas na conexão >>>> >>>> Tambem tive um problema parecido, e também eram regras erradas no NATD. >>>> >>>> On Tue, 2010-10-12 at 23:52 -0300, Marcelo Gondim wrote: >>>> >>>>> Opa fazendo testes aqui em casa já descobri o problema da queda de >>>>> conexão >>>>> que pode resolver tanto o problema do putty quanto do PostgreSQL. O >>>>> problema >>>>> está mesmo no NAT. Estava fazendo a regra sem o keep-state e fazia como >>>>> stateless a saída e a entrada da comunicação dessa forma fazendo uma >>>>> regra >>>>> como abaixo resolveu o problema das quedas e quem sabe também poderá >>>>> resolver o problema da performance. :) >>>>> >>>>> ipfw add divert 8668 all from any to any out via re0 keep-state >>>>> >>>>> Dessa forma a conexão com o putty se manteve e não caiu mais como se >>>>> fosse >>>>> um time-out >>>>> >>>>> Assim que tiver feito os outros testes avisarei aqui. :) >>>>> >>>>> -------------------------------------------------- >>>>> From: "Marcelo Gondim"<gon...@linuxinfo.com.br> >>>>> Sent: Tuesday, October 12, 2010 10:38 PM >>>>> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" >>>>> <freebsd@fug.com.br> >>>>> Subject: Re: [FUG-BR]Performance estranha e quedas na conexão >>>>> >>>>>> Oi Rodrigo, >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Rodrigo Mosconi"<free...@mosconi.mat.br> >>>>>> Sent: Tuesday, October 12, 2010 2:22 PM >>>>>> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" >>>>>> <freebsd@fug.com.br> >>>>>> Subject: Re: [FUG-BR]Performance estranha e quedas na conexão >>>>>> >>>>>>> Marcelo, >>>>>>> >>>>>>> Em 12 de outubro de 2010 01:18, Marcelo Gondim >>>>>>> <gon...@linuxinfo.com.br> escreveu: >>>>>>>> Olá pessoal, >>>>>>>> >>>>>>>> Estou fazendo uma migração aqui de um servidor Firewall Linux CentOS >>>>>>>> 5.5 >>>>>>>> para um FreeBSD 8.1-STABLE. Passei o dia fazendo todas as regras >>>>>>>> equivalentes entre o Netfilter/IPTables para o ipfw/natd. Todos os >>>>>>>> acessos >>>>>>>> funcionaram, tanto filtros quanto NAT, mas aconteceram 2 coisas >>>>>>>> estranhas >>>>>>>> e >>>>>>>> vim aqui recorrer à experiência de vocês, que tem mais tempo e >>>>>>>> bagagem >>>>>>>> com >>>>>>>> FreeBSD. :) >>>>>>>> >>>>>>>> A configuração básica é essa: >>>>>>>> >>>>>>>> Internet<-----> Firewall FreeBSD<-----> rede do cliente (Aplicação >>>>>>>> em >>>>>>>> Delphi) >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> Servidor PostgreSQL >>>>>>>> >>>>>>>> 1) Primeira coisa que aconteceu, o acesso da aplicação Delphi dele >>>>>>>> para >>>>>>>> a >>>>>>>> base PostgreSQL ficou muito mas muito mais lento e no Firewall não >>>>>>>> estou >>>>>>>> fazendo qualquer controle de tráfego. Achei estranho e voltei para o >>>>>>>> CentOS >>>>>>>> e a aplicação voltou ao normal e sua velocidade. >>>>>>>> >>>>>>>> 2) Outra coisa estranha que ocorre: o cliente está com aplicação >>>>>>>> conectada >>>>>>>> na base e depois de um tempo sem fazer nada no sistema, quando ele >>>>>>>> vai >>>>>>>> fazer >>>>>>>> algo, dá um erro de SQL dizendo que o servidor perdeu a conexão como >>>>>>>> se >>>>>>>> a >>>>>>>> conexão tivesse sido fechada por time-out. Isso também ocorre com o >>>>>>>> putty, >>>>>>>> tipo fiz um acesso ssh pelo putty no servidor postgresql. Se eu >>>>>>>> ficar >>>>>>>> um >>>>>>>> tempo com o putty parado, sem digitar nada, a conexão cai também. >>>>>>>> Fiz >>>>>>>> o >>>>>>>> mesmo teste voltando para o CentOS e os erros não ocorreram e nem a >>>>>>>> conexão >>>>>>>> ssh caiu no putty. >>>>>>>> >>>>>>>> Alguém saberia dar uma luz sobre essa situação, tipo se a velocidade >>>>>>>> estaria >>>>>>>> relacionada à algum tunning e se essas quedas na conexão tcp por >>>>>>>> time-out >>>>>>>> tem algum ajuste também? >>>>>>>> >>>>>>>> []´s a todos e agradeço desde já qualquer luz :) >>>>>>> >>>>>>> 1- Há nat entre os clientes e a base PG? É um cenário parecido com o >>>>>>> email anterior da lista? >>>>>>> >>>>>> >>>>>> Sim sim é mesmo cenário. Existe o nat entre o cliente e a base, no >>>>>> programa >>>>>> dele ele faz o acesso ao IP público e o mesmo é traduzido pelo nat >>>>>> para >>>>>> 192.168.10.2. >>>>>> O nat pode estar causando essa lentidão? >>>>>> >>>>>>> 2- O acesso à internet é IP dinâmico? Caso positivo, o script de FW é >>>>>>> executado >>>>>>> o link sobe? Um flush do ipfw limpa todos os estados, o que derruba >>>>>>> as conexões. >>>>>> >>>>>> O IP é fixo e o script faz um ipfw -f flush antes de carregar as >>>>>> regras. >>>>>> Até >>>>>> pensei na hora que a conexão com a base havia caído no momento em que >>>>>> rodei >>>>>> o script mas mesmo sem rodar o script a conexão cai. :( será que >>>>>> pode >>>>>> ter >>>>>> à ver com o polling como coloquei num e-mail anterior? Também vou >>>>>> fazer >>>>>> o >>>>>> teste de retirar todo o Firewall e deixar só o NAT para ver se a >>>>>> performance >>>>>> normaliza e as conexões ficam estáveis. >>>>>> >>>>>>> >>>>>>> 3- Já pensou em usar o PF no lugar do IPFW? >>>>>>> >>>>>> >>>>>> Poderia até usar mas achei estranho o que aconteceu e acredito que >>>>>> seja >>>>>> alguma falha na minha configuração e não no ipfw em si. De qualquer >>>>>> forma >>>>>> pretendo estudar o pf como outra alternativa à firewall. :) >>>>>> >>>>>>> Att, >>>>>>> >>>>>>> Rodrigo Mosconi >>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> ------------------------- >>>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>>>> >>>>> ------------------------- >>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>>>> >>>> >>>> Antonio Modesto >>>> >>>> Gerente de TI >>>> >>>> >>>> Praça Getúlio Vargas, 77 – Sala 308 – Centro >>>> >>>> Santo Antônio do Monte – MG – CEP: 35560-000 >>>> (37) 3281-2800 >>>> >>>> isimp...@isimples.com.brhttp://www.isimples.com.br >>>> >>>> >>>> Aviso:Esta mensagem e quaisquer arquivos em anexo podem conter >>>> informações confidenciais e/ou >>>> >>>> privilegiadas. Se você não for o destinatário ou a pessoa autorizada a >>>> receber esta mensagem, por favor, não >>>> >>>> leia, copie, repasse, imprima, guarde, nem tome qualquer ação baseada >>>> nessas informações. Notifique o >>>> >>>> remetente imediatamente por e-mail e apague a mensagem permanentemente. >>>> Atenção: embora a Isimples >>>> >>>> Telecom, tome seus cuidados para garantir a ausência de vírus neste >>>> e-mail, a empresa não se responsabiliza >>>> >>>> por quaisquer perdas ou danos decorrentes do uso da mensagem e seus >>>> anexos. A segurança e ausência de >>>> >>>> erros na transmissão do e-mail não podem ser garantidas, já que as >>>> informações podem ser interceptadas, >>>> >>>> corrompidas, perdidas, destruídas, atrasadas, chegarem incompletas, ou, >>>> ainda, conter vírus. Recomendamos >>>> >>>> checar se o e-mail e seus anexos contém vírus, uma vez que nem a >>>> Isimples Telecom ou o remetente se >>>> >>>> responsabilizam pela transmissão destes. >>>> >>>> >>>> >>>> ------------------------- >>>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>>> >>>> ------------------------- >>>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>>> >>> >>> >>> >>> -- >>> Alessandro de Souza Rocha >>> Administrador de Redes e Sistemas >>> FreeBSD-BR User #117 >>> Long live FreeBSD >>> >>> Powered by .... >>> >>> (__) >>> \\\'',) >>> \/ \ ^ >>> .\._/_) >>> >>> www.FreeBSD.org >>> ------------------------- >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> ------------------------- >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd