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" <[email protected]> Sent: Tuesday, October 12, 2010 10:38 PM To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" <[email protected]> Subject: Re: [FUG-BR]Performance estranha e quedas na conexão > Oi Rodrigo, > > -------------------------------------------------- > From: "Rodrigo Mosconi" <[email protected]> > Sent: Tuesday, October 12, 2010 2:22 PM > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" > <[email protected]> > Subject: Re: [FUG-BR]Performance estranha e quedas na conexão > >> Marcelo, >> >> Em 12 de outubro de 2010 01:18, Marcelo Gondim >> <[email protected]> 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
