[FUG-BR] Performance estranha e quedas na conexão
Rodrigo Mosconi
freebsd em mosconi.mat.br
Quarta Outubro 13 12:28:43 BRT 2010
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.
>>>
>>>
>>>
>>> -------------------------
>>> 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
>
Mais detalhes sobre a lista de discussão freebsd