Compartilhando a conexão, atualizado Tutoriais

Numa rede pequena ou média, com 10 a 50 micros, é possível usar um único servidor, de configuração razoável para todas estas funções. Em redes maiores, com 100 micros ou mais, isso passa a depender muito do nível de utilização do servidor.

Por exemplo, um simples Pentium 100, com 32 MB de RAM pode compartilhar um link de 1 ou 2 megabits com um número indefinido de clientes. O mesmo servidor pode compartilhar uma impressora e compartilhar arquivos (serviços mais pesados que simplesmente compartilhar a conexão), desde que estes serviços não sejam utilizados de forma intensiva. Porém, uma configuração modesta como esta já não é adequada para rodar um servidor proxy para uma rede de 50 micros por exemplo.

Uma máquina mais atual, um Sempron 2200+ com 512 MB de RAM e um HD de 7200 RPM já pode rodar o mesmo proxy para 100 ou 200 micros com folga. Adicione 1 GB de RAM e ele pode rodar também um servidor de arquivos para os mesmos 200 micros.

Configurando

Do ponto de vista da segurança e até mesmo da facilidade de configuração, é sempre recomendável usar um servidor com duas placas de rede, separando o tráfego proveniente da internet do tráfego da rede local.

Com duas placas separadas, fica mais fácil criar as regras de firewall adequadas para bloquear acessos provenientes da internet e ao mesmo tempo permitir o tráfego vindo da rede local.

Se você acessa via ADSL, é recomendável manter o modem configurado como bridge ao invés de configurá-lo como roteador, pois assim o servidor recebe todas as portas de entrada, permitindo que você acesse o servidor remotamente via SSH (muito útil para prestar suporte remoto em servidores instalados por você) ou rodar um servidor web ou FTP.

Embora acabe sendo mais trabalhoso, nada impede que você configure o modem como roteador e use o servidor para novamente compartilhar a conexão recebida do modem, acrescentando os demais serviços. Nestes casos você vai precisar configurar o modem para direcionar ao servidor as portas que devem ficar abertas para a internet, como a porta 22, usada pelo SSH (caso você pretenda administrar o servidor remotamente), por exemplo.

Comece configurando a rede local, usando uma das faixas de endereços IP reservadas a redes locais, como por exemplo 192.168.0.x, onde o servidor fica com o IP 192.168.0.1 e os micros da rede interna recebem endereço IP seqüenciais, de 192.168.0.2 em diante. Não se esqueça de colocar o endereço IP do servidor (192.168.0.1 no exemplo) como gateway padrão na configuração dos clientes. A configuração de gateway padrão no servidor fica em branco, pois o gateway padrão do servidor vai ser definido ao configurar a conexão com a internet.

Verifique se é possível dar ping nos PCs da rede interna (ex: ping 192.168.0.2) a partir do servidor. Se estiver usando Linux nas estações, experimente ativar o servidor SSH em uma das estações e tentar se conectar a ela a partir do servidor.

Da primeira vez que configurar a rede, use endereços IP estáticos para todas as estações, pois assim é mais fácil detectar problemas diversos. Depois de tudo funcionando, mude para configuração via DHCP se preferir. Se alguma das estações estiver inacessível, verifique se não existe um firewall ativo, verifique o cabo, troque a porta usada no hub, etc.

Com a rede local funcionando, o próximo passo é conectar à internet a partir do servidor. É preferível deixar para configurar a placa da internet depois da placa da rede local, pois isso evita alguns erros comuns. Por exemplo, se você conectar na internet e depois configurar a rede local, colocando um endereço qualquer no campo "default gateway", o gateway informado na configuração da rede local vai substituir o gateway do provedor (definido ao conectar na internet), fazendo com que a conexão deixe de funcionar.

Rode o comando "ifconfig" para verificar qual é a Interface ligada na internet. Lembre-se de que ao conectar via ADSL com autenticação ou acesso discado, a interface eth0 ou eth1 é substituída pela interface virtual ppp0.

Em seguida temos os comandos que compartilham a conexão. No Linux, o compartilhamento é feito usando o Iptables, o firewall integrado ao Kernel. Na verdade o Iptables é expandido através de módulos, por isso suas funções vão muito além das de um firewall tradicional. Para ativar o compartilhamento, são necessários apenas três comandos:

# modprobe iptable_nat
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Substitua o "eth0" pela placa da internet. Este comando simplesmente compartilha a conexão proveniente da placa da internet com todas as demais placas de rede espetadas no servidor, por isso não é necessário especificar a placa de rede local.

O primeiro comando ativa o "iptable_nat", o módulo do Iptables responsável por oferecer suporte ao roteamento de pacotes via NAT. O segundo ativa o "ip_forward", o módulo responsável pelo encaminhamento de pacotes, utilizado pelo módulo iptable_nat.

Finalmente, o terceiro cria uma regra de roteamento, que orienta o servidor a direcionar para a internet todos os pacotes recebidos dos clientes, que se destinarem a endereços que não façam parte da rede local (ou seja, qualquer coisa fora da faixa 192.168.0.x). A partir daí, o servidor passa a ser o gateway da rede.

Nem todas as distribuições instalam o Iptables por padrão. No Mandriva, por exemplo, ele é instalado ao marcar a categoria "firewall" durante a instalação. Para instalá-lo posteriormente, use o comando "urpmi iptables".

Em muitas distribuições com o Kernel 2.6 é necessário usar um quarto comando ao compartilhar uma conexão ADSL. Este comando ajusta os tamanhos dos pacotes recebidos do modem ao MTU usado na rede local.

# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m \
tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

A barra invertida ("\") faz com que o shell não interprete o caractere seguinte (no caso, a quebra de linha), permitindo quebrar o comando em duas linhas, sem causar um erro. Ele é um truque que permite incluir comandos longos demais para caberem na página, divididos em duas linhas ou mais. Na verdade, o comando forma uma única linha.

Adicione os comandos num dos scripts de inicialização do sistema, para que eles sejam executados automaticamente durante o boot.

No Debian e derivados, coloque-os no final do arquivo "/etc/init.d/bootmisc.shn".
No Fedora, Mandriva e outros derivados do Red Hat, use o arquivo "/etc/rc.d/rc.local".

Esta receita é genérica, deve funcionar em qualquer distribuição. Lembre-se de substituir o "ppp0" no comando por "eth0" caso o seu ADSL/Cabo utilize IP Fixo ou o endereço seja obtido via DHCP sem autenticação. O "ppp0" é usado em serviços onde é preciso autenticar via PPPoE ou PPTP.

Uma segunda opção, mais elegante porém mais complicada, é criar um serviço de sistema, que pode ser ativado e desativado.

Neste caso, crie o arquivo de texto "/etc/init.d/compartilhar". Dentro dele vão as linhas abaixo. Observe que, novamente, o comando para ajustar o MTU dos pacotes em conexões via ADSL forma uma única linha:

Este é um shell script que aceita três funções: start e stop, executando dentro de cada uma os comandos que compartilham e param o compartilhamento da conexão. Esta estrutura é similar à usada nos demais scripts de inicialização do sistema, como os do Apache, Samba, Squid e outros serviços.

Transforme-o em um arquivo executável, usando o comando:

# chmod +x /etc/init.d/compartilhar

A partir daí, você pode iniciar e parar o compartilhamento usando os comandos:

# /etc/init.d/compartilhar start
# /etc/init.d/compartilhar stop

Em muitas distribuições você pode usar o comando "service", que simplifica o comando. Neste caso, você poderia digitar apenas "service compartilhar start".

Para que a conexão seja ativada durante o boot, adicione o comando "/etc/init.d/compartilhar start" dentro do arquivo "/etc/init.d/bootmisc.sh" ou "/etc/rc.d/rc.local", de acordo com a distribuição usada.

Se preferir, você pode usar uma das ferramentas disponíveis nas distribuições. No Kurumin use o "Iniciar > Internet > Compartilhar Conexão e firewall > Compartilhar conexão via modem ou ADSL PPPoE". No Mandriva você pode usar o DrakGw, encontrado na seção "Rede e internet" do Mandriva Control Center.

Como configurar um servidor DHCP

Hoje em dia quase todas as redes utilizam algum tipo de servidor DHCP. Em geral, eles são ativados automaticamente ao compartilhar a conexão ou junto com algum outro serviço, de forma que você acaba não aprendendo muita coisa sobre a sua configuração.

De um modo geral, o trabalho de um servidor DHCP é bastante simples. Ele responde aos pacotes de broadcast das estações, enviando um pacote com um dos endereços IP disponíveis e os demais dados da rede. Os pacotes de broadcast são enviados para o último endereço da rede, como em 192.168.1.255 ou 255.255.255.255, e são recebidos por todos os micros da rede.

Periodicamente o servidor DHCP verifica se as estações ainda estão lá, exigindo uma renovação do "aluguel" do endereço IP (opção "lease time"). Isto permite que os endereços IP sejam gastos apenas com quem realmente estiver online, evitando que os endereços disponíveis se esgotem.

No Linux o serviço de DHCP é exercido pelo dhcp3-server, que nas distribuições baseadas no Debian pode ser instalado através do comando:

# apt-get install dhcp3-server

Os comandos "/etc/init.d/dhcp3-server start" e "/etc/init.d/dhcp3-server stop" gerenciam a atividade do serviço.

No Mandriva o pacote se chama "dhcpcd" e pode ser instalado através do urpmi. Uma vez instalado, use os comandos "service dhcpd start" e "service dhcpd stop".

O arquivo de configuração é o dhcpd.conf. No Debian, o caminho completo para ele é "/etc/dhcp3/dhcpd.conf" e no Mandriva e Fedora é apenas "/etc/dhcpd.conf".

Apesar dessas diferenças nos nomes, o que interessa mesmo é a configuração do arquivo e esta sim é igual, independentemente da distribuição.

Um arquivo de configuração básico contém o seguinte:

A opção "default-lease-time" controla o tempo de renovação dos endereços IP. O "600" indica que o servidor verifica a cada dez minutos se as estações ainda estão ativas.

Se você tiver mais endereços IP do que máquinas, os endereços IP das estações raramente vão precisar mudar. Mas, no caso de uma rede congestionada, o "max-lease-time" determina o tempo máximo que uma estação pode usar um determinado endereço IP. Isso foi planejado para ambientes onde haja escassez de endereços IP, como por exemplo num provedor de acesso, onde sempre existem mais clientes do que endereços IP disponíveis e se trabalha contando que nem todos vão ficar conectados simultaneamente.

Em condições normais, estas duas opções não são muito importantes. O que interessa mesmo é o bloco que vai abaixo, onde ficam as configurações da rede.

A opção "range" determina a faixa de endereços IP que será usada pelo servidor. Se você utiliza a faixa de endereços 192.168.0.1 até 192.168.0.254, por exemplo, pode reservar os endereços de 192.168.0.1 a 192.168.0.100 para estações configuradas com IP fixo e usar os demais para o DHCP, ou então reservar uma faixa específica para ele, de 192.168.0.100 a 192.168.0.201, por exemplo. O importante é usar faixas separadas para o DHCP e os micros configurados com IP fixo.

Na "option routers" vai o endereço do default gateway da rede, ou seja, o endereço do servidor que está compartilhando a conexão. Não é necessário que o mesmo micro que está compartilhando a conexão rode também o servidor DHCP. Pode ser, por exemplo, que na sua rede o gateway seja o próprio modem ADSL que está compartilhando a conexão e o DHCP seja um dos PCs.

A opção "option domain-name-servers" contém os servidores DNS que serão usados pelas estações. Ao usar dois ou mais endereços, eles devem ser separados por vírgula, sem espaços.

Em geral você vai usar os próprios endereços DNS do provedor, a menos que você configure um servidor DNS interno na sua rede, que pode ser instalado no próprio micro que está compartilhando a conexão e rodando o DHCP. Estes serviços quase não consomem recursos da máquina.

O servidor DNS mais usado no Linux é o Bind. No Kurumin ou Debian em geral, você mata o coelho com um "apt-get install bind". Este servidor DNS pode ser configurado para implementar um sistema de domínios e sub-domínios na sua rede, mas o uso mais comum é simplesmente fazer um "cache", onde o servidor DNS simplesmente repassa as requisições para um dos 13 root servers da internet e vai armazenando os endereços que já foram acessados.

Você pode substituir o arquivo de configuração padrão por este modelo, ou editá-lo conforme a necessidade. Ao fazer qualquer alteração no arquivo, você deve reiniciar o servidor DHCP usando o comando:

# /etc/init.d/dhcp3-server restart

DHCP com IP fixo

Mais uma opção interessante no servidor DHCP é a possibilidade de relacionar um determinado endereço IP com o endereço MAC de certo micro da rede. Isto faz com que ele sempre obtenha o mesmo endereço a partir do servidor DHCP, como se tivesse sido configurado para usar IP fixo.

Este recurso é usado em redes de terminais leves, para que o servidor "reconheça" os terminais e possa enviar a configuração adequada a cada um, mas pode ser usado em outras situações, como, por exemplo, em uma pequena rede, onde alguns micros compartilham impressoras e arquivos e por isso não podem ficar mudando de endereço IP a cada reboot.

Configurar o servidor DHCP para dar a eles sempre o mesmo IP pode ser mais prático que configurá-los para usar IP fixo manualmente, pois eles continuarão recebendo o mesmo IP mesmo que você reinstale o sistema (pois, apesar da mudança de sistema operacional, a placa de rede continuará a mesma). Veja o caso de quem usa live-CDs como o Kurumin, por exemplo.

Para usar este recurso, adicione uma seção como esta para cada host, no final do arquivo dhcpd.conf, depois de todas as linhas de configuração, mas antes de fechar a chave (}):

Veja que a seção começa com o nome da máquina, "kurumin" no exemplo. Em seguida vão, entre chaves, o endereço MAC da placa de rede (que você pode verificar através do comando "ifconfig") e o endereço IP que a estação deve usar.

Um exemplo de arquivo completo, incluindo a configuração de IP fixo para duas máquinas seria:

Em situações normais, você nunca deve manter mais de um servidor DHCP ativo ao mesmo tempo, principalmente se ambos estiverem configurados para dar endereços dentro da mesma faixa. Caso contrário, começam a surgir problemas com micros configurados com o mesmo IP (cada um dado por um DHCP diferente) e assim por diante.

Mas, em algumas situações, uma configuração com dois servidores DHCP pode funcionar, naturalmente depois de bem testada.

O dhcp3-server usado no Linux é bastante rápido, por isso (desde que a configuração não seja muito complexa) costuma responder antes dos servidores DHCP usados nos servidores Windows e na maioria dos modems ADSL, o que pode ser usado a seu favor.

Imagine um caso comum: uma rede de 10 ou 20 micros, com um ADSL de 1 megabit, compartilhado pelo próprio modem. Para melhorar o desempenho da rede, você resolve implantar um servidor com o Squid configurado para trabalhar como um proxy transparente, além de um servidor DNS próprio e DHCP.

Como este "servidor" é na verdade o seu micro, que precisa ser desligado de vez em quando, você decide manter a rede da forma que está, com o modem compartilhando a conexão e o seu micro funcionando como um segundo gateway, dentro da rede local.

Você quer que a rede continue funcionando mesmo quando seu micro precisar ser desligado por um certo tempo, por isso mantém o servidor DHCP do modem ativo, junto com o servidor DHCP instalado no seu micro.

No seu caso o Bind é mais rápido que o DHCP do modem, por isso, enquanto ele está ligado, os micros da rede local são configurados para acessar através dele, passando pelo proxy transparente. Quando ele é desligado, o modem ADSL passa a responder as chamadas e os micros passam a ser configurados para acessar diretamente através dele (é preciso reconfigurar os clientes via DHCP para que eles obtenham a configuração a partir do modem e passem a utilizá-lo como gateway). A rede continua funcionando mesmo que seu micro seja desconectado definitivamente.

Note que isto é tecnicamente errado e só funciona em redes pequenas, onde todos os micros são ligados ao mesmo hub ou switch. Quanto maior a rede, mais imprevisível se torna o comportamento dos servidores DHCP e mais importante torna-se manter apenas um ativo.

Compartilhar a conexão usando uma única placa de rede

Se você está usando um notebook ou barebone, com uma placa onboard e sem slots de expansão, existe a possibilidade de compartilhar a conexão usando uma única placa de rede, utilizando uma placa de rede virtual.

Normalmente, a topologia para compartilhar a conexão é ligar o modem ADSL/Cabo na placa eth0 do servidor, conectar a placa eth1 do mesmo servidor no hub/switch, juntamente com as demais estações.

Ao compartilhar usando uma única placa, todo mundo passa a ser conectado diretamente ao hub/switch, inclusive o modem. O servidor é configurado para ter duas placas de rede "lógicas", uma para se conectar na internet e outra para a rede local.

Uma dica é que os modems ADSL geralmente utilizam um cabo de rede cross-over, já que são feitos para serem conectados diretamente a um PC e não ao hub. Nestes casos, você precisa ligar o modem na porta uplink do hub. Isto normalmente não é necessário ao usar um switch, pois eles são capazes de detectar o cabo cruzado e corrigir o sinal via software.

O primeiro passo é se conectar normalmente à internet no servidor, usando as configurações de sempre. A partir do momento em que ele estiver acessando, crie o alias para a placa de rede "lógica" que o conectará aos micros da rede local, usando o comando:

# ifconfig eth0:1 192.168.0.1/24

Isto fará com que o servidor passe a se comportar como se tivesse duas placas de rede, uma ligada ao modem ADSL e outra ligada à rede local, respondendo no endereço 192.168.0.1 (você pode trocar por outro se preferir). O "/24" indica a configuração da máscara de sub-rede, equivale a digitar "255.255.255.0". Para que isso funcione no Debian e algumas distribuições derivadas dele, é preciso instalar o pacote "net-tools" (apt-get install net-tools).

Compartilhe a conexão da forma usual, configure os clientes da rede e eles já serão capazes de navegar.

Lembre-se de que um alias para a placa de rede não é o mesmo que uma placa de rede física espetada na placa-mãe. Por isso o utilitário para compartilhar a conexão que você usa na sua distribuição pode ter problemas para trabalhar desta forma. Se por acaso ele falhar, use os quatro comandos para compartilhar diretamente através do Iptables que já vimos.

Compartilhar a conexão usando uma única placa de rede relaxa um pouco a segurança da rede. Embora o modem ADSL fique conectado diretamente no hub, ninguém na internet será capaz de enxergar os micros da rede local, pois eles utilizarão uma faixa de IPs inválida, como 192.168.0.x ou 10.0.0.x. Você ainda pode adicionar um firewall "fecha tudo" no servidor, para que ele não responda a pings, feche todas as portas etc.

O problema é que com o modem ADSL ligado diretamente ao hub, alguém que consiga obter acesso à configuração do modem poderia ganhar acesso aos micros da rede local através dele. Os modems ADSL não são apenas dispositivos burros que fazem a conversão analógico/digital, eles possuem vários recursos para rotear pacotes, criar vários tipos de filtros e, em muitos casos, até túneis VPN.

As empresas de telefonia e provedores geralmente protegem as configurações do modem com uma senha para que o usuário não possa ficar brincando com elas, mas em geral usam a mesma senha em milhares de modems! Muitas vezes o modem vem aberto para aceitar conexões da web, protegido apenas pela senha, sem falar que por terem tantos recursos sempre existe a possibilidade de surgirem bugs diversos de segurança. Pense no modem como PC que nunca recebe atualizações de segurança.

Se alguém consegue obter acesso à configuração do modem, pode ganhar acesso aos micros da rede local que estarão conectados diretamente a ele. Este é o grande problema. Usando duas placas de rede ainda seria preciso passar pelo servidor de compartilhamento, que pode ser protegido com um bom firewall. Ao conectar o modem diretamente no hub, esta linha de proteção é perdida.

» Gostou do texto? Veja nossos livros impressos

... ou use a busca para localizar outros artigos relacionados: