“Qual a diferença de eu ter um servidor que roteie IP’s validos para as maquinas clientes e ter um servidor com NAT ativado distribuindo IP’s do tipo nao valido para clientes e ter um servidor distribuindo IP’s Via DHCP. Diferenças do Tipo: Que tipo de aplicaçoes os clientes usam sem restriçoes tipo IRC, FTP, NetMeeting (Som e Imagem) e outros.”
A diferença fundamental entre usar IP’s reais para todos os micros da rede e usar NAT para compartilhar uma só conexão é puramente econômico, não é questão de discutir o que é melhor ou pior, mas simplesmente de usar da melhor forma possível o que se têm.
Hoje em dia só os provedores e algumas empresas alugam links com faixas inteiras de endereços IPs válidos. Para os usuários domésticos e pequenas empresas as únicas conexões disponíveis são o ADSL e o cabo, onde em ambos os casos você recebe um único IP válido. A excessão fica por conta do Sppedy Business, onde você tem a opção de fazer várias assinaturas no provedor e obter um IP válido e uma conexão de 256k completa para cada micro, todas passando pelo mesmo modem ADSL, que permite uma banda total de entre 2 e 8 megabits. Mas, esta opção não é tão usada justamente por causa do custo.
Existem duas formas de compartilhar uma única conexão, usar um proxy manual (fora de moda hoje em dia) e usar NAT.
No caso dos proxys manuais temos por exemplo o Analog-X (for Windows) que apresento neste tutorial:
https://guiadohardware.info/tutoriais/040/
Ao usar um proxy manual você precisa configurar o nevegador e outros programas nos clientes para acessarem através do proxy, informando o endereço IP do micro da rede que está rodando o programa e a porta usada por ele. Você precisa fazer isso em cada micro e em cada programa que for acessar a Web. Dái o nome “proxy manual” 🙂 Existem proxys bem mais completos como por exemplo o Squid, onde você pode implantar todo tipo de regra para limitar e monitorar as páginas que cada usuário pode acessar, especificar horários, etc. é um trabalho manual muito grande, mas é útil em ambientes onde é necessário ter este tipo de controle.
Nos clientes você deve especificar o endereço do proxy dentro da rede local e a porta que você configurou para cada protocolo. Esta configuração deve ser feita programa por programa ou seja, você precisa configurar o Navegador, o cliente de FTP, o leitor de e-mails, etc. um de cada vez:
O proxy trabalha recebendo as requisições de cada cliente dentro da rede interna e encaminhando-a para a o endereço apropriado na Internet. Ao receber a resposta os pacotes são encaminhados ao cliente. como tudo passa pelo proxy, ele pode “examinar” as conexões, que é justamente o que lhe permite estabelescer regras no Squid e em outros programas. Você pode bloquear todas as páginas que tenham a expressão “XXX” ou “hardcore” por exemplo.
O proxy também pode ser configurado para fazer um cache com as páginas acessadas pelos clientes, o que pode ajudar a diminuir o trafego de dados na conexão com a Internet. Naturalmente o cache precisa ser bem configurado, caso contrário os clientes vão começar a receber páginas desatualizadas.
O NAT é mais recomendado quando você quer apenas compartilhar a conexão, sem ter muita dor de cabeça. Existem várias formas de compartilhar a conexão via NAT. O Windows vem com o ICS que precisa ser apenas habilitado, várias distribuições Linux incluem assistentes bem fáceis de usar (no Mandrake por exemplo basta clicar no “assistente de compartilhamento de conexão” no Mandrake Control Center), no Kurumin (a partir da versão 1.2) basta chamar o como root o “compartilhar-ppp0” ou “compartilhar-eth0” e você pode ainda usar um micro antigo com o Coyote ou o Freesco.
Usando o NAT o servidor passa a apenas redirecionar todas as requisições dos clientes, enviando de volta as respostas. Os clientes acessam de forma transparente, como se estivessem diretamente conectados à Web.
Neste caso, a configuração dos clientes é muito mais simples, você precisa apenas configurar corretamente a rede, fornecendo o endereço IP e máscara de sub-rede (geralmente 255.255.255.0), o endereço do Default Gateway que no caso é o endereço do PC que está compartilhando a conexão, além dos endereços dos servidores DNS do seu provedor de acesso:
O termo NAT vem de “Network Adress Translating” que explica bem como a coisa funciona. Imagine que você tenha uma rede com dois micros, um possui duas placas de rede, uma para a Internet e outra para a rede local e está compartilhando a conexão via NAT, enquando o segundo está acessando através dele. O esquema da rede ficaria assim:
Quando você tenta acessar o endereço https://www.hardware.com.br no segundo PC, ele sabe que se trata de um nome de domínio e por isso envia a requisição para o servidor de DNS. Como o endereço configurado “200.134.54.1” no exemplo, não está dentro da rede local (192.168.0.0), o PC direciona o pedido para o Default Gateway, que nada mais é do que o PC que está compartilhando a conexão e que tem acesso direto à Internet.
Pois bem, o PC 1 recebe o recado e o envia para o DNS do provedor, que devolve o endereço IP do servidor do Guia do Hardware, que pode ser por exemplo “207.153.127.9”. Ao receber a resposta do servidor de DNS, o PC 1 envia a resposta para o PC 2.
Com o endereço IP do site em mãos, o PC 2 pode finalmente acessá-lo. Como novamente o endereço “207.153.127.9” não está dentro da rede local, a requisição vai de novo para o default gateway, que o envia para a Internet e devolve a resposta.
Isso não se aplica apenas ao navegador. Qualquer programa, seja um cliente de FTP, o leitor de e-mails, um programa de compartilhamento de arquivos qualquer, etc. vai fazer exatamente o mesmo caminho, não importa qual seja a porta utilizada.
A única limitação do compartilhamento via NAT é que o PC1 é apenas capaz de redirecionar conexões iniciadas pelo PC2 e outros micros da rede, mas não fazer o inverso, ou seja, direcionar conexões vindas da Internet.
Isso faz com que alguns programas, que abrem servidores e recebem conexões vindas da Internet funcionem com algumas limitações. É o caso do NetMeeting por exemplo. Você consegue iniciar conversações e falar normalmente, mas não consegue receber chamadas de outras pessoas, pois as conexões são barradas pelo PC1. Isto também se aplica a servidores Web, FTP, jogos multiplayer e alguns programas de compartilhamento.
Para poder receber conexões diretas nos PCs da rede interna você precisa configurar o servidor para redirecionar as portas desejadas. Assim, quando o PC1 receber uma conexão na porta 3456 por exemplo ele enviará o chamado para o PC2 e devolverá a resposta para o cliente remoto. Veja que continua existindo uma única porta 3456, a única diferença é que ela mudou de dono.
Se você estiver compartilhando através do Windows 2000/XP você pode compartilhar portas clicando sobre as propriedades da conexão de internet compartilhada e depois em Compartilhamento > Configuração > Serviços > Adicionar.
A limitação é que você não tem como direcionar todas as portas, apenas algumas portas específicar, uma a uma. Ou seja, você tem que primeiro descobrir qual é a porta usada pelo programa servidor e em seguida direcioná-la. Se você precisar usar o programa simultâneamente em vários micros é precisa configurá-lo de modo que cada micro use uma porta diferente. Não é possível direcionar a mesma porta simultâneamente para dois PCs da rede interna. Lembre-se, existe apenas uma porta, ela apenas muda de dono.
Se você estiver usando o Coyote pode direcionar as portas adicionando a linha:
/sbin/ipmasqadm autofw -A -r tcp 3456 3456 -h 192.168.0.2
… no arquivo de configuração do Firewall (consulte o tutorial) onde o “3456” é a porta a ser redirecionada e o “192.168.0.2” é o PC da rede local que receberá a porta. Esta opção pode ser usada também, no Freesco e outras distribuições Linux baseadas no Kernel 2.2 ou com Ipchains.
Outra possibilidade é redirecionar de uma vez todas as portas para um endereço da rede local. Assim o PC1 fica invisível na Internet e você cria uma zona demilitarizada, um endereço IP desprotegido, onde você pode rodar qualquer tipo de programa sem limitação. Neste caso você utilizaria duas linhas na configuração do Coyote, uma direcionando todas as portas TCP e outra direcionando todas as portas UDP:
/sbin/ipmasqadm autofw -A -r tcp 1 65535 -h 192.168.0.200
/sbin/ipmasqadm autofw -A -r udp 1 65535 -h 192.168.0.200
Neste exemplo todas as portas do PC1 estão sendo direcionadas para o endereço “192.168.0.200” da rede interna. Não é obrigatório que exista algum PC neste endereço. Você pode deixar o endereço vago e apenas mudar o endereço do PC2 quando precisar usar algum programa que precise aceitar conexões de fora.
O fato de acessar a Web através de uma conexão compartilhada, seja via proxy ou seja via NAT, adiciona um certo nível de proteção aos PCs da rede internet, pois (a menos que você redirecione as portas) eles não podem ser acessados diretamente a partir da Internet. Ou seja, você pode compartilhar arquivos e impressoras e rodar servidores diversos nos PCs da rede local sem medo de que eles fiquem disponíveis também na Internet.
O problema é que o compartilhamento protege apenas contra acessos diretos e não contra vírus e trojans que você possa vir a baixar. Por isso é importante manter ativado um firewall com filtro de conteúdo e, no caso dos clientes Windows, também um antivírus atualizado.
A beleza do NAT é que a configuração dos clientes é extremamente simples. Você pode instalar um servidor com o Coyote ou o Mandrake numa rede com 20 micros e configurar tudo em poucas horas, ao contrário do trabalhão que seria configurar um proxy com várias regras e restrições.
