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

Marcelo Gondim gondim em linuxinfo.com.br
Sexta Outubro 15 18:04:25 BRT 2010 

Pessoal fiz a migração aqui no cliente. Funcionou perfeitamente agora!!! 
Rápido e sem quedas.
A solução regras em ipfw + nat no pf ficou show de bola mesmo.  :)

PostgreSQL não apresenta mais lentidões e nem perdas de conexão com o 
software cliente.

A única mensagem que as vezes aparece nos logs e console é essa aqui:

ipfw: ipfw_install_state: entry already present, done

É normal essa mensagem? :D

[]´s a todos

--------------------------------------------------
From: "Renato Frederick" <renato em frederick.eti.br>
Sent: Wednesday, October 13, 2010 10:31 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 [resolvido]

> Tem que usar ftp-proxy sempre, tanto para conexoes de saida(cliente
> interno sofrendo nat -> internet) quanto pra conexoes de entrada(alguem
> na internet acessando um ftp seu).
> A exceção é se fizer um nat 1:1
>
> Dà uma olhada depois pra vc migrar as regras de firewall pra pf, não é
> tão complicado e simplifica usando 1 ferramenta só.
>
> ou, você pode também rever o natd do ipfw, no site da fug[1] tem um
> howto bem bacana, só ignore a parte de IPFW2(era pra versão antiga do
> Free que ainda usava IPFW1, a versão 2 foi incorporada a tempos).
>
> De qualquer maneira, é sempre bom ter noção de ferramentas de firewall,
> hoje mesmo tive que quebrar um galho com iptables :-P
>
> [1] http://www.fug.com.br/content/view/37/77/
>
>
>
> Em 13/10/10 22:15, Marcelo Gondim escreveu:
>> Pessoal fiz uns testes aqui e parece que era mesmo o nat do divert mal
>> configurado mesmo rsrsrs
>>
>> Como o que eu queria fazer estava bem confuso usando o divert, resolvi
>> seguir o conselho de alguns de vocês e usar o nat do PF.  :)
>>
>> Nesse caso fiz o misto de nat usando o pf e as regras de filtragem usando 
>> o
>> ipfw. os problemas que testei aqui no meu ambiente de testes se foram e 
>> tudo
>> funcionou normalmente. :D
>>
>> Ficou uma dúvida apenas e só vou conseguir testar mesmo lá do cliente que 
>> é
>> a seguinte: com relação ao FTP eu agora uso o ftp-proxy e nas regras do
>> pf.conf eu adiciono:
>>
>> nat-anchor "ftp-proxy/*"
>> nat on tun0 from 192.168.10.0/24 to any ->  (tun0)
>>
>> rdr-anchor "ftp-proxy/*"
>> rdr pass proto tcp from any to any port ftp ->  127.0.0.1 port 8021
>>
>> Dessa maneira o ftp funcionou perfeitamente mas se eu tivesse que usar a
>> regra binat, que vou ter que usar no cliente, para associar os IPs 
>> públicos
>> aos não públicos da rede de servidores... o ftp funcionaria normalmente 
>> sem
>> precisar do ftp-proxy ou teria que fazer algo complementar? Porque eu 
>> posso
>> precisar fazer um ftp de um servidor para a Internet.
>>
>> Resumindo: no binat o ftp funciona sem precisar do ftp-proxy?
>>
>> []´s a todos e agradeço muito pela ajuda e idéias que foram me passadas
>> aqui. :D
>>
>> --------------------------------------------------
>> From: "Alessandro de Souza Rocha"<etherlinkii em gmail.com>
>> Sent: Wednesday, October 13, 2010 2:34 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
>>
>>> Eu uso pf para nat e rdr de portas, ipfw para controle de banda e
>>> proxy transparent.
>>>
>>> Em 13 de outubro de 2010 13:41, Renato Frederick
>>> <renato em frederick.eti.br>  escreveu:
>>>> 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
>>>>> <gondim em 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"<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.
>>>>>>>>
>>>>>>>>
>>>>>>>>

Mais detalhes sobre a lista de discussão freebsd