Luiz, bom dia! Independente do endereçamento IP do DNS, seja privado ou público, ou mesmo cliente móvel ou fixo em sua rede LAN, ele deveria configurar o DNS para responder conforme a origem do resolver, utilizando para isto views. Com esta sugestão ele resolveria a parte do problema referente a resolução de nomes interna ou externa.
Fazendo desta forma não haverá necessidade de fazer redirecionamento de LAN para LAN. Os clientes internos e o servidor estão na mesma rede, só não sabem disso. :) Isto foi o que entendi do esquema de rede passado anteriormente. Minhas observações nesta thread são referentes ao redirecionamento de LAN para LAN. As conexões externas, originadas na Internet, ele terá que continuar a fazer o redirecionamento para o servidor interno. Até mais. Marco Botelho http://twitter.com/botelho Em 9 de junho de 2010 01:08, Luiz Gustavo S. Costa < luizgust...@luizgustavo.pro.br> escreveu: > 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/ <http://sammy.net/%7Esammy/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 > > ------------------------- > > -- > 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