[FUG-BR] DNS
Luan Tasca - FUG
luanfug em gmail.com
Quarta Junho 9 11:33:39 BRT 2010
Será que isso via resolver pra mim? porque o endereco que quero acessar
é www.site.com.br/pasta e nao diretamente o site, e ali onde tá
200.x.x.x seria o ip do www.site.com.br ?
> Luiz Gustavo S. Costa wrote:
>
> Então, duas opções:
>
> - Dns views (terá que forçar os seus clientes de rede usarem o seu DNS)
> - Usar um redir da vida (fica transparente para os clientes)
>
> instala o rinetd (/usr/ports/net/rinetd), e configura o arquivo de configuração:
>
> # echo '127.0.0.1 10080 192.168.0.x 80' >> /usr/local/etc/rinetd.conf
> # echo 'rinetd_enable="YES"' >> /etc/rc.conf
> # /usr/local/etc/rc.d/rinetd start
> * Onde 192.168.0.x é o ip do servidor interno para acesso através dos clientes.
>
> criar uma regra de firewall:
>
> IPFW:
> # ipfw add 100 fwd 127.0.0.1,10080 tcp from 192.168.0.0/24 to
> 200.x.x.x 80 (me corrijam se tiver errado, tem um bom tempo que não
> uso ipfw)
> PF:
> # rdr on $if_int proto tcp from 192.168.0.0/24 to 200.x.x.x port 80 ->
> 127.0.0.1 port 10080
>
> pronto, fica transparente para os clientes
>
> É bonito isso ??? não, não acho, mas é mais funcional do que usar
> views do bind e outra, seria bonito se o conceito de DMZ realmente
> fosse usado, servidor em uma classe de ip diferente da lan, via outra
> interface ou vlan... mas como eu disse em um email anterior... nem
> sempre o mundo é perfeito !
>
> é isso...
>
>
> Em 9 de junho de 2010 14:55, Luan Tasca - FUG <luanfug em gmail.com> escreveu:
>
>> 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.
>> -------------------------
>> 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