[FUG-BR] Performance estranha e quedas na conexão

Marcelo Gondim gondim em linuxinfo.com.br
Quarta Outubro 13 11:55:22 BRT 2010


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" <etherlinkii em gmail.com>
Sent: Wednesday, October 13, 2010 9:56 AM
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" 
<freebsd em 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
> <renato em 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" <gondim em linuxinfo.com.br>
>>> Sent: Tuesday, October 12, 2010 10:38 PM
>>> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>>> <freebsd em fug.com.br>
>>> Subject: Re: [FUG-BR]Performance estranha e quedas na conexão
>>>
>>> > Oi Rodrigo,
>>> >
>>> > --------------------------------------------------
>>> > From: "Rodrigo Mosconi" <freebsd em mosconi.mat.br>
>>> > Sent: Tuesday, October 12, 2010 2:22 PM
>>> > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>>> > <freebsd em 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
>>> >> <gondim em 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 
>>
>>isimples em 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
> 


Mais detalhes sobre a lista de discussão freebsd