Boa noite !... vamos lá, como já dizia o famoso "Jack", vamos por partes....
Marco, concordo e não concordo (explica tudo né :p)... assim.... Fazer o redirecionamento através de views ou outra coisa qualquer relativo a DNS é a solução perfeita ?... não, definitamente.. o mundo não é tão perfeito assim, pelo o que eu entendi do email anterior do colega em relação a duvida, o email do Mario tem sua funcionalidade, veja bem, vou destacar que o que eu entendi, é que existem DUAS redes diferentes, entre a LAN e a DMZ e não MESMA REDE (o que torna o firewall um roteador entre essas redes, portanto, passa tudo por ele), como voce recomenda na leitura do RDR (eu já chego ai e te explico que mesmo nessa situação o DNS não é o mundo perfeito.). Portanto, efetuar um rdr a partir da interface LAN de uma rede completamente diferente da DMZ para a DMZ em si é totalmente valido e a principio não vejo problemas para aplicar tal regra. Bom, agora vamos supor que as redes são iguais, algo como: 1 - IP do cliente = 192.168.1.50 2 - IP do gateway (fw) = 192.168.1.1 3 - IP do Servidors = 192.168.1.100 (200.x.x.1 via rdr no fw) Fica claro ai que se o cliente requisitar uma conexao para 200.x.x.1 e existir o rdr no firewall, ele ate vai redirecionar, mas vai haver confusão no momento da resposta, já que o cliente esta na mesma rede do servidor, etc... isso é visivel e teoricamente um DNS view resolveria o problema em parte, resolvendo o nome do serviço com o IP direto do servidor. Porque digo "em parte" ? ... bom, ai entra a questão do DNS, imagine uma situação de um cliente da rede que utilize notebook, como ele é movel, precisa estar conectado em varios tipos de redes diferentes.. e conheço muita gente que deixa um ip de dns publico já configurado no mesmo. Conclusão: isso falharia para o caso do DNS, já que exige que a maquina tenha o DNS que contenha as views. Portanto, dependendo do caso (já tive que fazer isso e ainda bem que existem ferramentas assim), tive que fazer escutar o serviço no firewall, para redirecionar para o servidor. Para esses casos, existe essas ferramentas: [r...@desktop] /usr/ports/net/rinetd# cat pkg-descr rinetd redirects TCP connections from one IP address and port to another. rinetd is a single-process server which handles any number of connections to the address/port pairs specified in the file /etc/rinetd.conf. Since rinetd runs as a single process using nonblocking I/O, it is able to redirect a large number of connections without a severe impact on the machine. This makes it practical to run TCP services on machines inside an IP masquerading firewall. rinetd does not redirect FTP, because FTP requires more than one socket. rinetd also supports basic allow/deny access control and logging. [r...@desktop] /usr/ports/net/redir# cat pkg-descr Redir is a port redirector. It can run under inetd or standalone. Redir also supports tcp wrappers. WWW: http://sammy.net/~sammy/hacks/ Não é muito bonito ter que recorrer a isso, mas quebra o galho quando o cenário não ajuda muito e é inevitavel que tenha que colocar redes diferentes ou mesmo configurar uma vlan e não vai ter jeito, sendo o firewall o gateway da rede, a requisição vai ter que passar por ele ! é isso.... abraços Em 9 de junho de 2010 02:26, Marco Botelho <mafbote...@gmail.com> escreveu: >> >> On Tuesday 08 June 2010 23:11:20 Marco Botelho wrote: >> > Boa noite! >> > >> > Na minha opinião, não faz muito sentido você usar uma solução de >> > redirecionamento onde servidor e clientes estão no mesmo segmento de >> rede. >> > Basta uma resolução de nome correta para seus clientes. Nesta solução de >> > redirecionamento, você está deixando seus clientes irem até ao firewall >> > externo para depois voltarem de onde vieram! Você estará criando outros >> > problemas. >> > >> > Veja no link a seguir o que é, opções e exemplos de como usar view no >> bind. >> > http://www.zytrax.com/books/dns/ch7/view.html >> > >> > Até mais. >> > >> > Marco Botelho >> > http://twitter.com/botelho >> >> Firewall interno ! >> >> E na pratica, o cliente so vai lá ate o primeiro arp, depois creio que >> fique >> indo direto. Alem do mais, pra reolver o nome ele vai ter que ir no DNS >> (local >> ou não) pelo memos uma vez tambem. >> >> Por favor, apenas uma crítica construtiva: Uma boa pratica das listas >> FreeBSD >> "no top post" bem que poderia ser adotada por aqui tambem. >> >> Desculpe por ter deslocado seu texto pra cá. >> >> []s, >> >> -- >> Mario Lobo >> http://www.mallavoodoo.com.br >> FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winfoes FREE) >> > > Mário, boa noite! > > Quando puder leia o tópico Redirecionamento e Reflexão disponível no link a > seguir: > http://www.openbsd.org/faq/pf/pt/rdr.html > > Inclusive neste tópico é sugerido o uso do DNS "Split-Horizon". > > Se fizer da maneira que você sugeriu terão problemas. Problema de aplicação > se resolve na camada de aplicação. > > Até mais. > > Marco Botelho > http://twitter.com/botelho > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 2642-3799 / 7582-0594 Blog: http://www.luizgustavo.pro.br ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd