Wellington Terumi Uemura wrote:
>Mas n�o entendo sua l�gica, qual a diferen�a da sua configura��o com a
>tradicional DMZ?
DMZ = rede protegida por firewall, mas ainda acess�vel externamente, com
IPs p�blicos.
>Lembrando que ip's v�lidos s�o rote�veis na internet!
Todo IP (v4) � rote�vel, exceto os inv�lidos, tais como 0.0.0.0 ou
255.255.255.255. At� mesmo o 127.0.0.1 � rote�vel e roteado.
>Outro ponto importante, o seu esquema � inseguro pelo fato de revelar
>atrav�s de IP's v�lidos que voc� tem al�m de clientes, servidores com
>v�rios IP's v�lidos.
Em algum lugar voc� quis dizer privativos. Acho que foi o segundo. E n�o
s�o servidores: s�o apenas roteadores.
E qual � o problema em revelar alguns IPs privativos no meio? Faz alguma
diferen�a? N�o ser�o acess�veis e n�o t�m nenhum servi�o rodando. S�o
apenas roteadores.
Tem muito provedor por a� que faz isso. N�o vejo problema algum.
>O fato de um servidor ter um ip inv�lido na
>internet n�o significa que ele n�o vai funcionar, desde que,
>configurado por uma pessoa capacitada ele deve funcionar de forma
>totalmente transparente para o usu�rio.
Ou seja: al�m de configurar o IP da forma tradicional, o administrador
dever� carregar os m�dulos de NAT, configurar os servi�os com os IPs
externos, proxies, etc. E al�m disso, s� poder� utilizar os daemons que
forem capazes de funcionar atr�s de NAT.
FTP � um exemplo.
>De uma maneira ou de outra mesmo voc� n�o gostando de NAT voc� nessa
>sua configura��o est� fazendo NAT,
N�o h� NAT algum na minha proposta.
>por isso n�o entendo sua l�gica,
>que diferen�a tem fazer NAT de ip inv�lido para v�lido e ip v�lido
>para ip inv�lido e ip v�lido novamente??? No final voc� tem um network
>overhead desnecess�rio...
N�o h� NAT.
>
>Seu exemplo
> Internet ----| roteador |--------------| firewall |---------| rede
> interna 200.x.x.1 192.168.0.1 192.168.0.2 200.x.x.4
> 200.x.x.0/24
Certo. H� apenas roteamento.
>
>Meu exemplo
>Internet ----| roteador |----------| firewall |------------------| rede
> interna x.x.x.x__200.x.x.x___200.x.x.x___192.168.x.x__192.168.x.x/x
>
>No seu exemplo voc� tem que fazer 2 processos de NAT e 2 roteamentos,
N�o. H� apenas roteamento.
>IP v�lido > Ip inv�lido > IP V�lido
N�o. � apenas roteamento.
Acompanhe a proposta de rotas que eu fiz. O processo inteiro existe sem
NAT. Existe apenas uma rede privativa entre o roteador e o firewall que
usa IPs privativos.
Poderia muito bem usar IPs p�blicos tamb�m. Ali�s, dependendo do roteador,
voc� pode colocar o mesmo IP nas duas interfaces.
>Por quest�es de funcionalidade, internamente ter um ip inv�lido n�o
>deve reduzir em nada as funcionalidades dos servidores....
Suponha um servi�o gen�rico qualquer que transmita no seu trem de bits o
endere�o IP para uma conex�o secund�ria. Mais ou menos como o FTP: o
cliente pede "abra conex�o secund�ria" e o servidor responde "ok, o IP �
x.x.x.x e a porta � Y".
Isso n�o funciona atr�s de NAT, a n�o ser que:
1) o daemon em quest�o seja capaz de contactar um proxy
ou
2) o servidor de NAT seja capaz de identificar a conversa passando e
alterar o conte�do da mesma, fazendo o NAT do IP sendo informado e
preparando-se para a conex�o secund�ria.
Imagine agora que o protocolo seja criptografado e a op��o #2 seja
imposs�vel. Ou ent�o que n�o haja suporte no firewall-NAT para tal
protocolo gen�rico, ao contr�rio do FTP.
Imagine ainda mais que o daemon em quest�o � o �nico do g�nero, n�o
suporta proxies e troc�-lo seja impratic�vel.
Voc� est� numa situa��o em que um servidor atr�s de NAT simplesmente n�o
funciona. Se quiser um exemplo concreto, eu posso lhe dar um: H.323.
Existe um patch para ele para os Netfilter, mas no kernel padr�o do
Linux, ele n�o � suportado.
>Vamos por
>exemplo pegar o cabe�alho de uma mensagem que envie de dentro do meu
>servidor para o gmail.
Estamos falando de conex�es de fora para dentro.
De dentro para fora n�o h� problema algum com NAT.
>Received: by 10.54.5.65 with SMTP id 65cs11337wre;
> Sat, 12 Feb 2005 09:32:13 -0800 (PST)
>Received: by 10.38.89.1 with SMTP id m1mr44718rnb;
> Sat, 12 Feb 2005 09:32:13 -0800 (PST)
Esses IPs privativos s�o do GMail?
>Voc� n�o v� nenhum sinal de informa��o do servidor interno no
>cabe�alho, como o IP 10.1.1.19 ou mail.empresa.local
Porque a conex�o foi de dentro para fora. E o protocolo de SMTP n�o requer
conex�es secund�rias, como o FTP o faz.
SMTP n�o � um caso cr�tico.
>Se feito corretamente como mostra o exemplo os resultados ser�o os
>mesmos que o meu sem ter nenhuma perda de funcionalidade.
Para o SMTP eu concordo. Tente com o FTP ou um servi�o gen�rico qualquer,
cujo formato interno voc� n�o conhece.
Mas voc� teve de configurar uma regra extra (a do NAT) que n�o seria
necess�ria caso o servidor de SMTP tivesse um IP p�blico. Em qual dos
dois casos � mais prov�vel haver algum engano de configura��o: com 0 ou 1
regras?
>No caso do nosso amigo que deseja intercalar um firewall na rede as
>op��es de regras valem para a sua configura��o, s� n�o sendo
>necess�rio a linha que tem a op��o de NAT uma vez que voc� vai
>trabalhar com IP's v�lidos dos dois lados, mas o ideal mesmo seria
>trabalhar com ip inv�lido atr�s do firewall.
N�o concordo e expus minhas raz�es acima.
Al�m disso, tenho que dizer � NAT � ruim para a Internet como um todo. O
ideal seria que ele n�o existisse e todo mundo tivesse os IPs dos quais
precisa.
Com NAT, a conectividade global � quebrada porque nem todos os n�s da rede
s�o acess�veis por todos os outros n�s.
(Estou falando do ponto de vista te�rico, n�o do pr�tico)
--
Thiago Macieira - thiago (AT) macieira (DOT) info
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
2. T� cennan his weorc gearu, ymbe se circolwyrde, wear� se c�gbord and se
leohtspeccabord, and �a m�s c�mon lator. On �one d�g, he hine reste.
---------------------------------------------------------------------------
Esta lista � patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br
Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br
Regras de utiliza��o da lista: http://linux-br.conectiva.com.br
FAQ: http://www.zago.eti.br/menu.html
