[FUG-BR] DNS
Luan Tasca - FUG
luanfug em gmail.com
Quarta Junho 9 10:55:04 BRT 2010
Marco Botelho wrote:
> 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 <
> luizgustavo em 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:
>>
>> [root em 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.
>>
>> [root em 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 <mafbotelho em 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: contato em 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
>
>
Deixa eu fazer um comentario para o pessoal entender melhor aqui, pois
nao estou conseguindo fazer, a rede interna ta no ip 192.168.0.X e o
servidor aonde ta o site que eu quero acessar pelo endereco
www.wmw.com.br/moldurarte ta no ip 192.168.0.49, lembrando que externo
eu abro o site e abre normal, mais interno nao ta abrindo, ele fica uma
tela branca.
Mais detalhes sobre a lista de discussão freebsd