> DMZ = rede protegida por firewall, mas ainda acess�vel externamente, com > IPs p�blicos. DMZ � uma rede ou parte dela separada por um firewall que permite entrada ou sa�da de tr�fego determinadas por este. O fato de se usar ip v�lido ou restrito n�o tem nada haver com isso. > 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. Voc� entendeu o que quiz dizer. > 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.
> 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. > 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. N�o h� novidade nenhuma nisso. > FTP � um exemplo. O problema do FTP j� foi resolvido faz tempo. > 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. 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. > 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. [corta] > 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 servidores de FTP Windows por tr�s de um firewall linux (iptables) funcionando sem problemas, talvez com um pouco de boa vontade de pesquisar mais sobre o assunto possam tirar essa sombra do FTP de suas costas. Veja por exemplo esta documenta��o que lhe d� uma id�ia de como fazer as coisas funcionarem: http://www.chinalinuxpub.com/doc/www.siliconvalleyccie.com/linux-hn/ftp-server.htm H.323, SIP... tem mais algum que gostaria de de informar?? Talvez voc� n�o tenha visto ainda o site http://openh323proxy.sourceforge.net/ mas sem problemas... N�o me interessa o que o Linux, Windows, Machintosh, Unix, BSD's [....] pode ou n�o fazer, o que tem ou n�o tem suporte para tanto, o que me interessa � o que eles podem fazer, se um patch resolve meu problema �timo, se um Linux me atende �timo, caso contr�rio existem outras solu��es. > Para o SMTP eu concordo. Tente com o FTP ou um servi�o gen�rico qualquer, > cujo formato interno voc� n�o conhece. Eu estou bem com o FTP obrigado. > 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. > 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. 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. 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. Talvez com a padroniza��o do IPV6 seu sonho se torne realidade ou um pesadelo, pelo que eu l� o seu julgamento vem de alguma frusta��o de configura��o de servidores, pois NAT � ruim por causa do FTP H.323.... Concordo que NAT n�o � perfeito, assim como Linux n�o � e Windows/Machintosh/seu_OS_preferido_aqui tamb�m n�o ent�o, procure aquilo que lhe atenda e forne�a a solu��o que precisa. --------------------------------------------------------------------------- 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
