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"<etherlin...@gmail.com> > Sent: Wednesday, October 13, 2010 2:34 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 > >> 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 >> <ren...@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 >>>> <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 >>> >> >> >> >> -- >> 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