Wellington Terumi Uemura wrote:
>> 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.
>
>Coloque seus servidores direto na internet ent�o, d� o mesmo efeito.
Com um firewall na frente, criando uma DMZ.
>> Tem muito provedor por a� que faz isso. N�o vejo problema algum.
>
>Sim, claro que tem, por isso veja o exemplo da telef�nica que est�
>listada em tudo quanto � blacklist da internet e nem mesmo o Terra que
>� da telef�nica aceita emails da sua pr�pria rede.
O fato de usar IPs privativos n�o tem nada a ver com o fato de estar
listada em blacklists. Isso � causado por spams.
>> FTP � um exemplo.
>
>O problema do FTP j� foi resolvido faz tempo.
Mas � um exemplo de necessidade de carregar um m�dulo extra para resolver
um problema que n�o existiria se o IP fosse p�blico.
>Entendo, mas o problema da sua proposta � colocar IP's v�lidos dentro
>da rede e o mais importante, que estes IP's perten�am a voc� e
>dependendo da quantidade de servidores internos estes n�o ser�o
>suficientes.
Sim. Eu assumi, na minha resposta, que o Carlos tinha o bloco de IPs. Se
j� tem os IPs, para que n�o usar?
Novamente, a minha recomenda��o resume-se a: quando poss�vel, coloque os
IPs p�blicos nos servidores. Evite o NAT tanto quanto poss�vel.
� claro que existem casos em que isso n�o � poss�vel. A� o NAT � o
quebra-galho que funciona -- mas n�o deixa de ser quebra-galho para o
problema real de n�o ter os IPs.
>> 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.
>
>J� v� que seu problema se resume b�sicamente em FTP, temos dois
N�o. Eu quis ilustrar um problema maior. O caso do FTP est� resolvido
porque existe o ip_conntrack_ftp/ip_nat_ftp no kernel do Linux.
O caso do H.323, voc� resolve com um proxy H.323 (mais um servi�o rodando,
mais mem�ria e carga, maior lat�ncia, mais um ponto de vulnerabilidade).
Eu quis ilustrar o problema de um protocolo gen�rico qualquer,
principalmente no caso de conex�es criptografadas.
>> 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?
>
>� muito relativo, o erro pode haver tanto com uma ou nenhuma regra, eu
>posso montar uma super regra de firewall e n�o configurar o servidor
>corretamente e vice versa.
Isso eu tenho que concordar.
>Vamos colocar do ponto de vista do usu�rio ent�o, j� que NAT � t�o
>ruim ent�o � mais l�gico para voc� fazer com que um escrit�rio com 500
>computadores todos tenham IP's v�lidos, para n�o quebrar a
>"conectividade global" mas quebrar o bolso de quem paga por isso n�o
>tem problema.
Isso mesmo.
Como eu coloquei no fim da mensagem, estou falando do ponto de vista
te�rico. Num mundo ideal, todo mundo teria tantos IPs quantos precisasse.
Infelizmente n�o � a realidade. E justamente porque n�o � a realidade �
que surgiu o NAT. Como disse acima, NAT � um quebra-galho para o problema
real, da falta de IP.
>Ou mesmo o usu�rio de internet que tem tr�s computadores em casa, s�
>para n�o quebrar a conectividade global o ideal tem que pagar tr�s
>vezes mais s� para ter IP's v�lidos nos seus computadores.
Idealmente, ele n�o pagaria nada a mais por isso. Ter 1, 50 ou 1000 IPs
deveria custar exatamente a mesma coisa.
Essa � uma das propostas do IPv6. Prop�e-se as seguintes aloca��es para
usu�rios finais:
- /128: quando se sabe com certeza absoluta que 1, e apenas 1 IP ser�
necess�rio.
- /64: quando se sabe com certeza que o usu�rio ter� apenas 1 �nica rede.
O total de IPs alocados � de 18.446.744.073.709.551.616.
- /48: aloca��o padr�o. S�o 65.536 redes de 18.446.744.073.709.551.616 IPs
(ou 1.208.925.819.614.629.174.706.176 IPs).
Provedores devem procurar aloca��es maiores, come�ando em /35 (ou 8192
aloca��es /48).
Deixe-me repetir mais uma vez: se voc� tem os IPs, use-os.
--
Thiago Macieira - thiago (AT) macieira (DOT) info
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
3. Ac seo woruld wear� geborod, sw� se Scieppend cwea� "Gewurde Unix" and
wundor fremede and him "Unix" genemned, ��t is se rihtendgesamnung.
---------------------------------------------------------------------------
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
