Início
Introdução
Quando as conexões de banda larga começaram a se tornar populares, por volta de 2000, compartilhar a conexão se tornou uma dúvida comum, já que compartilhar uma conexão ininterrupta faz muito mais sentido do que compartilhar a conexão via modem. No começo, era muito comum serem usados PCs com o Windows 98 ou 2000, compartilhando a conexão através do ICS, ou micros antigos rodando mini-distribuições Linux especializadas na tarefa, como o antigo Coyote.
Hoje em dia, compartilhar a conexão deixou de ser um problema, já que praticamente qualquer modem ADSL pode ser configurado como roteador, sem falar dos pontos de acesso com funções de roteador e da enorme variedade de servidores domésticos que temos no mercado.
Vamos então a um tutorial rápido de como compartilhar a conexão no Linux, usando um PC com duas placas de rede, aproveitando para incluir também alguns recursos adicionais no servidor, instalando também um proxy transparente e um servidor DHCP. Este mesmo servidor pode ser configurado também como um servidor de arquivos e impressoras para a rede, assumindo também o papel de NAS.
Os passos a seguir podem ser usados em praticamente qualquer distribuição, de forma que você pode usar a que tiver mais familiaridade. Também não é necessário reservar um PC só para compartilhar a conexão: você pode perfeitamente usar seu próprio micro, ou outro que fique ligado continuamente.
Se você não se importar em fazer a configuração via linha de comando, você pode utilizar um PC antigo, instalando a versão server do Ubuntu. Ela está disponível no http://www.ubuntu.com/getubuntu/downloadmirrors, juntamente com a versão principal, mas é um pouco menor, com cerca de 500 MB.
Ao contrário da versão desktop, que carrega o ambiente gráfico por padrão e precisa de um PC com pelo menos 256 MB de memória RAM para rodar, a versão server usa um instalador simples, em modo texto (o mesmo usado nas primeiras versões), e pode ser instalada mesmo em micros com apenas 32 MB de memória RAM:
Esta versão instala apenas os pacotes básicos, sem o ambiente gráfico, por isso o boot depois da instalação é feito em modo texto. Logue-se usando a conta criada durante a instalação e use o comando "sudo passwd" para definir a senha de root. A partir daí você pode se logar diretamente como root, como em outras distribuições:
$ sudo passwd
Inicialmente, o Ubuntu server vem apenas com o vi instalado, que não é um editor de texto particularmente amigável, mas, depois de fazer a configuração inicial da rede (editando o arquivo "/etc/network/interfaces"), você pode instalar outro editor mais amigável, como o mcedit (que faz parte do pacote "mc"), o "joe" ou o "nano". Não importa muito qual editor resolva usar, o importante é que você se sinta confortável com pelo menos um deles.
Um exemplo de arquivo "/etc/network/interfaces" configurado é:
# /etc/network/interfaces
auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
O arquivo é dividido em duas partes. A linha "auto ..." lista as interfaces que devem ser ativadas automaticamente e as demais contém a configuração de cada uma. Para configurar uma nova placa de rede, você adicionaria a configuração relacionada a ela no final do arquivo e a adicionaria na linha "auto", como em "auto lo eth0 eth1". Se, por outro lado, você quiser desativar uma interface, precisa apenas removê-la da linha auto, não é preciso remover as demais linhas.
A interface "lo" é a interface de loopback, usada para a comunicação local entre diversos aplicativos e componentes do sistema, por isso nunca deve ser desativada. Embora o uso da interface de loopback pareça ser uma exclusividade do Linux, ela é usada também no Windows; a única diferença é que no Windows ela não aparece na configuração.
Em seguida temos a configuração de cada interface, que vai em uma seção separada. No caso da interface lo é usada uma única linha, "iface lo inet loopback", usada em qualquer instalação, seguida pelas demais interfaces.
Como você pode ver, as últimas 5 linhas na configuração da placa eth0 especificam o IP utilizado pelo PC e o restante da configuração da rede, com exceção dos endereços dos servidores DNS, que vão no arquivo "/etc/resolv.conf".
Se você quisesse que a interface fosse configurada via DHCP, poderia substituir as 6 linhas referentes a ela por:
iface eth0 inet dhcp
Ao configurar um servidor com duas placas de rede, onde a eth0 está ligada à rede local e a eth1 ao cable modem (obtendo o endereço via DHCP), por exemplo, o arquivo ficaria:
# /etc/network/interfaces
auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
iface eth1 inet dhcp
Veja que nesse caso a configuração da interface eth0 não inclui o gateway, pois é a eth1 que será usada para acessar a web.
Depois de editar o arquivo, você pode aplicar as alterações reiniciando o serviço relacionado a ele:
# /etc/init.d/networking restart
Um problema comum que afeta versões do Debian, Ubuntu e distribuições baseadas neles é as interfaces mudarem de endereço a cada reset em micros com duas ou mais interfaces de rede. A placa eth0 passa então a ser a ath1 e assim por diante, o pode ser uma grande dor de cabeça ao configurar um servidor para compartilhar a conexão, já que se as duas interfaces mudam de posição, nada funciona.
A solução para o problema é um pequeno utilitário chamado "ifrename", que permite fixar os devices utilizados para as placas. Utilizá-lo é bem simples. Comece instalando o pacote via apt-get:
# apt-get install ifrename
Crie o arquivo "/etc/iftab" e, dentro dele, relacione o device de cada interface com o endereço MAC correspondente, seguindo o modelo abaixo:
#/etc/iftab
eth0 mac 00:11:D8:76:59:2E
eth1 mac 00:E0:7D:9B:F8:01
Em caso de dúvida, use o comando "ifconfig -a" para ver a configuração atual das placas e o endereço MAC de cada uma. Uma vez criado, o arquivo é verificado a cada boot e a configuração se torna persistente, resolvendo o problema. Este bug das interfaces itinerantes afeta apenas algumas distribuições, por isso você não precisa se preocupar com ele até que perceba que está usando uma das afetadas.
O Ubuntu server vem com o servidor SSH instalado por padrão, de forma que depois de configurar a rede, você pode fazer todo o resto da configuração confortavelmente a partir do seu micro. Uma dica é que ao utilizar o joe, o nano ou o vi (o mcedit não suporta o uso do clipboard), você pode usar o botão central do mouse para colar texto dentro do terminal, o que é muito útil quando você tem um modelo de configuração pronto pra usar.
Compartilhando a conexão
Depois de configuradas as duas interfaces de rede, ativar o compartilhamento da conexão é bastante simples. No Linux o trabalho é feito pelo iptables, o firewall padrão do sistema, que incorpora a função de compartilhamento através do módulo "iptable_nat". Para ativar o compartilhamento, precisamos apenas carregar o módulo, ativar o roteamento de pacotes e em seguida executar o comando que ativa o compartilhamento propriamente dito. Explicando assim pode parecer difícil, mas na prática isso é feito usando apenas 3 comandos:
# modprobe iptable_nat
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
O "eth0" no terceiro comando indica a placa onde está a conexão com a Internet. Não se esqueça de indicar a interface apropriada ao executar o comando (na dúvida você pode checar a configuração da rede usando o ifconfig). Se você acessa via ADSL, usando o pppoeconf ou o adsl-setup (com o modem configurado como bridge) será criada a interface "ppp0".
A partir daí, todas as requisições recebidas na interface de rede local serão mascaradas e roteadas usando a interface especificada e as respostas serão devolvidas aos PCs da rede local.
É possível compartilhar qualquer tipo de conexão, incluindo conexões discadas, wireless, conexões via celular e assim por diante. O servidor simplesmente passa a rotear os pacotes dos demais micros da rede, transmitindo todas as requisições através da conexão que possui. Você precisa apenas configurar os demais PCs da rede para o utilizarem como gateway.
Nem todas as distribuições instalam o executável do 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".
Os três comandos devem ser colocados em algum dos arquivos de inicialização do sistema para que passem a ser executados automaticamente durante o boot. No caso do Ubuntu e outras distribuições derivadas do Debian, você pode utilizar o arquivo "/etc/rc.local". No Fedora, Mandriva e outras distribuições derivadas do Red Hat, use o arquivo "/etc/rc.d/rc.local".
Você pode aproveitar para proteger o servidor usando um firewall simples, que bloqueie as portas de entrada, deixando passar apenas pacotes de respostas e conexões em portas indicadas manualmente. Com isso, o firewall garante um bom nível de proteção, com um mínimo de efeitos colaterais.
Para isso, utilizaremos o próprio iptables, complementando os três comandos anteriores. Estes comandos podem ser incluídos no arquivo /etc/rc.local ou /etc/rc.d/rc.local, logo abaixo dos comandos para compartilhar a conexão:
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
O primeiro comando faz com que o seu servidor deixe de responder a pings. Muitos ataques casuais começam com uma varredura de diversas faixas de endereços de conexões domésticas, enviando um ping para todas as máquinas. Responder ao ping indica não apenas que a máquina está online, mas também que provavelmente ela está com o firewall desativado, o que estimula o atacante a continuar o ataque, lançando um portscan e iniciando o ataque propriamente dito. Deixando de responder aos pings, o volume de ataques ao servidor cai bastante.
Os dois comandos seguintes protegem contra IP spoofing (uma técnica usada em diversos tipos de ataques, onde o atacante envia pacotes usando um endereço IP falseado como remetente, tentando assim obter acesso a PCs da rede interna) e contra pacotes inválidos, que são comumente utilizados em ataques DoS e ataques de buffer overflow.
As três últimas linhas autorizam pacotes provenientes da interface de loopback (lo), juntamente com pacotes provenientes da rede local e descartam novas conexões na interface de Internet, deixando passar apenas pacotes de resposta. Não se esqueça de substituir o "eth1" pela interface de rede local correta, caso contrário você vai acabar fazendo o oposto, ou seja, bloqueando as conexões dos PCs da rede local e deixando passar as provenientes da Internet :).
Se você quiser abrir portas específicas adicione a regra "iptables -A INPUT -p tcp --dport 22 -j ACCEPT" (onde o "22" é a porta e o "tcp" é o protocolo) antes da regra que bloqueia as conexões. Você pode repetir a regra caso necessário, abrindo assim todas as portas desejadas.
No final, incluindo os comandos para compartilhar a conexão e regras para abrir as portas 22 (SSH) e 6881 (bittorrent), os comandos a adicionar no script de inicialização seriam:
#!/bin/sh
# Compartilha a conexão
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Bloqueia pings e protege contra IP spoofing e pacotes inválidos
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state --state INVALID -j DROP
# Abre para a interface de loopback e para a interface de rede local
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
# Abre para as portas especificadas
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 6881 -j ACCEPT
# Bloqueia as demais conexões, deixando passar apenas pacotes de resposta
iptables -A INPUT -p tcp --syn -j DROP
Você pode também criar um filtro simples de conteúdo indicando manualmente endereços que devem ser bloqueados, usando o comando "iptables -A FORWARD -d dominio.com -j DROP". Isso faz com que o servidor se recurse a encaminhar pacotes destinados aos endereços citados, impedindo que eles sejam acessados a partir dos micros da rede local. Você só precisa adicionar uma regra para cada domínio a ser bloqueado no seu script de firewall, como em:
iptables -A FORWARD -d orkut.com -j DROP
iptables -A FORWARD -d msn.com -j DROP
iptables -A FORWARD -d myspace.com -j DROP
Usada dessa forma, a regra bloqueia o acesso aos domínios especificados usando qualquer protocolo. Ou seja, se você adicionar uma regra bloqueando um tracker bittorrent, por exemplo, os clientes bittorrent rodando nas máquinas da rede não conseguirão se conectar a ele para fazerem download dos arquivos. Praticamente qualquer programa que precise se conectar a um servidor central, com um endereço fixo, pode ser bloqueado usando esta regra, desde que você saiba indicar o endereço correto.
A limitação é que esta regra se aplica apenas ao servidor relacionado ao domínio, por isso ela não bloqueia subdomínios hospedados em servidores diferentes. Por exemplo, você pode bloquear o domínio "uol.com.br", mas isso não bloqueará o "tvuol.uol.com.br", que é hospedado em um servidor separado. Em casos como este, a única solução é bloquear ambos.
Outra dica é que, ao compartilhar uma conexão discada ou uma conexão via celular (que também é uma forma de conexão discada, já que você precisa usar o kppp ou o gnome-ppp), você pode fazer com que o sistema execute o script de compartilhamento ao efetuar a conexão usando a aba "Executar" nas propriedades da conexão.
Adapte o script de compartilhamento para compartilhar a interface ppp0 e coloque o comando que executa o script no campo "Ao conectar":
Com isso o compartilhamento é automaticamente ativado ao conectar. A principal observação é que para usar o script de compartilhamento dessa forma você deve abrir o kppp como root, ou modificar o script de forma que ele use o sudo em todos o comandos que precisarem ser executados como root, de forma que ele possa ser executado usando seu login de usuário.
Adicionando um proxy transparente
Os servidores proxy são a forma mais antiga de compartilhar a conexão entre vários micros. Diferente de um servidor configurado para compartilhar a conexão via NAT, que simplesmente roteia pacotes da rede local para a Internet e da Internet para a rede local, mascarando os endereços, um servidor proxy oferece um acesso mais limitado, intermediando a conexão, vasculhando o conteúdo dos pacotes e permitindo apenas o acesso a portas específicas. A grande desvantagem é que todos os micros da rede precisam ser configurados manualmente para utilizarem o proxy.
Usar um servidor proxy permite logar os acessos, impor restrições diversas, baseadas em horários, endereços e outras condições, limitar o uso de banda e assim por diante, o que faz com que eles sejam bastante populares em redes empresariais, onde a redução no uso da banda e o possível aumento na produtividade compensam o trabalho necessário.
Em uma rede doméstica, você pode configurar o servidor proxy para trabalhar em modo transparente, onde ele passa a fazer seu trabalho de forma invisível, sem que você precise configurar os micros da rede para utilizarem-no. O proxy complementa então o compartilhamento via NAT, cacheando os arquivos e as páginas acessadas.
O servidor passa então a armazenar atualizações do Windows Update, downloads diversos, páginas e imagens, pacotes instalados através do apt-get e tudo mais que for acessado via http. Com isso, muita coisa passará a ser acessada a partir do cache do servidor proxy, reduzindo o uso de banda e agilizando o acesso.
A principal limitação é que o proxy transparente irá cachear apenas o tráfego http, através da porta 80. Não é possível usar um proxy transparente para FTP e SSL, a menos que você configure os programas em cada PC manualmente para utilizarem o proxy. No Firefox por exemplo, a configuração de proxy vai dentro do menu "Editar > Preferências", em "Rede > Configurações > Configuração manual de proxy":
Marcando a opção "Usar este proxy para todos os protocolos" você faz com que todo o tráfego passe pelo proxy e seja armazenado no cache, incluindo os arquivos baixados via FTP e https. O problema é que você precisaria fazer essa configuração em todos os micros da rede, o que anula a principal vantagem de usar um proxy transparente, que é a possibilidade de ter ganhos na velocidade de acesso sem precisar fazer modificações nos PCs da rede.
De qualquer forma, a configuração que utilizaremos atende tanto aos PCs configurados para acessar a web diretamente quanto aos PCs configurados manualmente para usar o proxy, de forma que a configuração dos clientes fica a seu critério.
O primeiro passo é configurar o servidor Linux com duas placas de rede para compartilhar a conexão, como vimos nos tópicos anteriores. O proxy transparente é apenas um add-on, que complementa o compartilhamento da conexão via NAT.
Com tudo funcionando, o próximo passo é instalar o Squid, o que é feito através da instalação do pacote "squid" usando o gerenciador de pacotes, como em:
# apt-get install squid
ou:
# yum install squid
A configuração do Squid é feita através de um único arquivo, o "/etc/squid/squid.conf". O arquivo de exemplo, instalado junto com o pacote é assustadoramente grande, com mais de 3000 linhas, incluindo comentários sobre todas as opções disponíveis. Ele é uma boa leitura se você quiser se aprofundar na configuração do Squid, mas se você quer apenas ver seu proxy transparente funcionando, é mais fácil renomear o arquivo e começar com um arquivo de configuração vazio:
# mv /etc/squid/squid.conf /etc/squid/squid.conf.modelo
# touch /etc/squid/squid.conf
Abra o arquivo /etc/squid/squid.conf em branco que foi criado e copie o modelo de configuração abaixo. As opções em negrito são as opções que você precisa alterar:
# /etc/squid/squid.conf
http_port 3128 transparent
visible_hostname gdh
cache_mem 64 MB
maximum_object_size_in_memory 128 KB
maximum_object_size 512 MB
cache_dir ufs /var/spool/squid 4096 16 256
cache_access_log /var/log/squid/access.log
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 21 280 443 488 563 591 777 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all
A primeira linha indica a porta utilizada pelo Squid (3128) e que ele deve operar em modo transparente (transparent). A segunda indica o nome do servidor (gdh), que você deve substituir pelo nome do seu.
As quatro linhas seguintes indicam a configuração do cache. O Squid trabalha com dois caches distintos, um cache mais rápido, feito na memória RAM, e outro mais lento (porém maior) feito usando espaço do HD.
O "cache_mem 64 MB" indica o tamanho do cache na memória RAM (é recomendável que você utilize no máximo 1/3 da memória total instalada), enquanto o "4096" na linha cache_dir ufs /var/spool/squid 4096 16 256" indica o tamanho do cache que será feito no HD, em megabytes.
A linha "acl redelocal src 192.168.1.0/24" indica a faixa de endereços e a máscara utilizada na sua rede local (o /24 equivale à mascara 255.255.255.0). Combinada com as regras "http_access allow redelocal" e "http_access deny all" ela faz com que apenas micros da rede local possam utilizar o proxy, afastando qualquer possibilidade de que ele fique aberto para a Internet, independentemente da configuração do firewall.
A linha maximum_object_size 512 MB indica o tamanho máximo de arquivo que será armazenado no cache (arquivos maiores do que isso serão ignorados), o que evita que arquivos muito grandes, (como imagens ISO) que você vai baixar apenas uma vez, desperdicem espaço no cache.
Depois de terminar, reinicie o Squid para que a configuração entre em vigor:
# /etc/init.d/squid restart
Com isso, a configuração do servidor proxy está pronta, mas falta um passo igualmente importante, que é ativar a regra de firewall que faz com que os acessos destinados à porta 80, provenientes da rede local sejam encaminhados para o Squid. Sem isso, as requisições continuam sendo roteadas diretamente, sem passarem pelo proxy:
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
Note que o "eth1" no comando especifica a interface de rede local, que deve ser alterada de acordo com a sua configuração. Este comando deve ser colocado no script de inicialização (juntamente com os comandos para compartilhar a conexão) para que seja executado automaticamente durante o boot.
Depois de ativar a regra de firewall, você pode testar o proxy navegando em algum dos micros da rede local (que use o servidor como gateway) e verificar o conteúdo do arquivo "/var/log/squid/access.log" no servidor. Conforme as requisições passam pelo proxy, o arquivo é alimentado com um grande volume de informações sobre as conexões realizadas, como em:
1201780615.239 1337 192.168.1.10 TCP_MISS/302 884 GET http://192.168.112.2o7.net/b/ss/mxmacromedia/1/F.3-XELvs - DIRECT/216.52.17.136 text/plain
1201780615.753 248 192.168.1.10 TCP_MISS/200 1526 GET http://wwwimages.adobe.com/www.adobe.com/lib/com.adobe/template/gnav/google.gif - DIRECT/204.245.162.8 image/gif
1201780647.918 29013 192.168.1.10 TCP_MISS/200 3036521 GET http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz - DIRECT/72.246.38.70 application/x-gzip
Pela presença das entradas no arquivo você percebe que os acessos estão realmente passando pelo proxy.
Uma última observação é que esta configuração vale para as versões recentes do Squid, do 2.6 em diante. Em versões antigas do Squid eram usadas 4 linhas adicionais no final do arquivo, no lugar do parâmetro "transparent" na primeira linha:
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
A menos que você esteja usando o Debian Sarge, ou outra distribuição antiga, é improvável que esteja usando uma versão do Squid anterior à 2.6. De qualquer forma, fica a observação. A maior parte dos tutoriais disponíveis na web são anteriores à mudança e por isso ensinam a usar esta configuração antiga, que não funciona mais nas versões atuais. Em caso de dúvida, você pode checar a versão do Squid instalada usando o comando "squid -v".
Adicionando um servidor DHCP
Complementando o compartilhamento da conexão, você pode configurar também um servidor DHCP, especificando a configuração que deve ser fornecida aos PCs da rede. É importante enfatizar que você deve manter apenas um servidor DHCP ativo na rede, de forma que se você já está usando o servidor DHCP do modem ou do roteador wireless, você deve primeiro desativá-lo, antes de ativar o DHCP no servidor.
Com dois servidores DHCP na rede, ambos irão responder às requisições e as máquinas vão simplesmente usar a configuração que receberem primeiro. Mesmo que ambos os servidores DHCP estejam configurados para fornecer a configuração correta, você poderá ter problemas com máquinas recebendo endereços repetidos (um servidor DHCP não tem como saber quais foram os endereços fornecidos pelo outro) e assim por diante. Confie em mim, manter um único servidor DHCP ativo vai tornar sua vida bem mais simples.
Para instalar o servidor DHCP, instale o pacote "dhcp3-server" usando o gerenciador de pacotes, como em:
# apt-get install dhcp3-server
No Fedora o pacote se chama "dhcp" e no Mandriva se chama "dhcpd". Você pode instalá-lo usando (respectivamente) os comandos:
# yum install dhcp
# urpmi dhcpd
Nas distribuições derivadas do Debian o arquivo de configuração é o "/etc/dhcp3/dhcpd.conf" e no Fedora e Mandriva é o "/etc/dhcpd.conf". Apesar disso, em ambos os casos a configuração é a mesma.
Você pode usar o modelo de configuração abaixo. Assim como no caso do Squid, as opções em negrito são as que você deve alterar de acordo com a configuração da sua rede:
# dhcpd.conf
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.250;
option routers 192.168.1.1;
option domain-name-servers 208.67.222.222,208.67.220.220;
option broadcast-address 192.168.1.255;
}
A opção "default-lease-time" controla o tempo de renovação dos endereços IP. O servidor DHCP checa periodicamente se a estação ainda está ativa e, ao perceber que ela foi desligada ou desconectada da rede, libera o endereço para uso de outro micro, evitando que os endereços disponíveis se esgotem. O "default-lease-time" indica o intervalo entre as checagens e o "max-lease-time" determina o tempo máximo antes de liberar o endereço. Em condições normais, essas 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. No exemplo, configurei o DHCP para fornecer os endereços de 192.168.1.100 a 192.168.1.250, de forma a ficar com os demais endereços livres para o uso em estações com IP fixo, mas você poderia reservar toda a faixa de endereços da rede para o DHCP (deixando de fora apenas o endereço do gateway), como em "range 192.168.1.2 192.168.1.254;".
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, enquanto a opção "option domain-name-servers" contém os dois servidores DNS que serão usados pelas estações, separados por vírgula.
O endereço de broadcast é sempre o último endereço da rede, como em "192.168.1.255" ou "10.255.255.255". Ele simplesmente acompanha a faixa de endereços e a máscara utilizada.
Depois de terminada a configuração, reinicie o servidor DHCP para que ela entre em vigor:
# /etc/init.d/dhcp3-server restart
(no Debian e derivados) ou:
# service dhcp restart
(no Fedora e Mandriva)
Ao configurar um servidor com duas placas de rede no Ubuntu ou outra distribuição derivada do Debian, abra o arquivo "/etc/default/dhcp3-server" e indique qual é a placa da rede local, como em:
INTERFACES="eth0"
Isso faz com que o servidor forneça endereços apenas para micros ligados à interface indicada e não mais em qualquer uma das interfaces. Isso evita que ele responda a conexões provenientes da Internet.
Se você quiser também que o servidor atue como um servidor DNS, instale também o pacote "bind", como em:
# apt-get install bind
Ao contrário do DHCP, ele não precisa de configuração, pois vem de fábrica configurado para trabalhar como um servidor DNS de cache, que simplesmente repassa as requisições para um dos 13 root servers da Internet e faz um cache das respostas.
Como vimos no capítulo 2, um servidor DNS local será geralmente mais lento, mas é interessante ter um para testar problemas de conectividade. Afinal, se você consegue navegar usando seu DNS local, mas não navega usando o DNS do provedor, significa que a conexão está funcionando e o problema é apenas no DNS.
fonte : http://www.hardware.com.br/tutoriais/servidor-linux-domestico/
Quando as conexões de banda larga começaram a se tornar populares, por volta de 2000, compartilhar a conexão se tornou uma dúvida comum, já que compartilhar uma conexão ininterrupta faz muito mais sentido do que compartilhar a conexão via modem. No começo, era muito comum serem usados PCs com o Windows 98 ou 2000, compartilhando a conexão através do ICS, ou micros antigos rodando mini-distribuições Linux especializadas na tarefa, como o antigo Coyote.
Hoje em dia, compartilhar a conexão deixou de ser um problema, já que praticamente qualquer modem ADSL pode ser configurado como roteador, sem falar dos pontos de acesso com funções de roteador e da enorme variedade de servidores domésticos que temos no mercado.
Vamos então a um tutorial rápido de como compartilhar a conexão no Linux, usando um PC com duas placas de rede, aproveitando para incluir também alguns recursos adicionais no servidor, instalando também um proxy transparente e um servidor DHCP. Este mesmo servidor pode ser configurado também como um servidor de arquivos e impressoras para a rede, assumindo também o papel de NAS.
Os passos a seguir podem ser usados em praticamente qualquer distribuição, de forma que você pode usar a que tiver mais familiaridade. Também não é necessário reservar um PC só para compartilhar a conexão: você pode perfeitamente usar seu próprio micro, ou outro que fique ligado continuamente.
Se você não se importar em fazer a configuração via linha de comando, você pode utilizar um PC antigo, instalando a versão server do Ubuntu. Ela está disponível no http://www.ubuntu.com/getubuntu/downloadmirrors, juntamente com a versão principal, mas é um pouco menor, com cerca de 500 MB.
Ao contrário da versão desktop, que carrega o ambiente gráfico por padrão e precisa de um PC com pelo menos 256 MB de memória RAM para rodar, a versão server usa um instalador simples, em modo texto (o mesmo usado nas primeiras versões), e pode ser instalada mesmo em micros com apenas 32 MB de memória RAM:
Esta versão instala apenas os pacotes básicos, sem o ambiente gráfico, por isso o boot depois da instalação é feito em modo texto. Logue-se usando a conta criada durante a instalação e use o comando "sudo passwd" para definir a senha de root. A partir daí você pode se logar diretamente como root, como em outras distribuições:
$ sudo passwd
Inicialmente, o Ubuntu server vem apenas com o vi instalado, que não é um editor de texto particularmente amigável, mas, depois de fazer a configuração inicial da rede (editando o arquivo "/etc/network/interfaces"), você pode instalar outro editor mais amigável, como o mcedit (que faz parte do pacote "mc"), o "joe" ou o "nano". Não importa muito qual editor resolva usar, o importante é que você se sinta confortável com pelo menos um deles.
Um exemplo de arquivo "/etc/network/interfaces" configurado é:
# /etc/network/interfaces
auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
O arquivo é dividido em duas partes. A linha "auto ..." lista as interfaces que devem ser ativadas automaticamente e as demais contém a configuração de cada uma. Para configurar uma nova placa de rede, você adicionaria a configuração relacionada a ela no final do arquivo e a adicionaria na linha "auto", como em "auto lo eth0 eth1". Se, por outro lado, você quiser desativar uma interface, precisa apenas removê-la da linha auto, não é preciso remover as demais linhas.
A interface "lo" é a interface de loopback, usada para a comunicação local entre diversos aplicativos e componentes do sistema, por isso nunca deve ser desativada. Embora o uso da interface de loopback pareça ser uma exclusividade do Linux, ela é usada também no Windows; a única diferença é que no Windows ela não aparece na configuração.
Em seguida temos a configuração de cada interface, que vai em uma seção separada. No caso da interface lo é usada uma única linha, "iface lo inet loopback", usada em qualquer instalação, seguida pelas demais interfaces.
Como você pode ver, as últimas 5 linhas na configuração da placa eth0 especificam o IP utilizado pelo PC e o restante da configuração da rede, com exceção dos endereços dos servidores DNS, que vão no arquivo "/etc/resolv.conf".
Se você quisesse que a interface fosse configurada via DHCP, poderia substituir as 6 linhas referentes a ela por:
iface eth0 inet dhcp
Ao configurar um servidor com duas placas de rede, onde a eth0 está ligada à rede local e a eth1 ao cable modem (obtendo o endereço via DHCP), por exemplo, o arquivo ficaria:
# /etc/network/interfaces
auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
iface eth1 inet dhcp
Veja que nesse caso a configuração da interface eth0 não inclui o gateway, pois é a eth1 que será usada para acessar a web.
Depois de editar o arquivo, você pode aplicar as alterações reiniciando o serviço relacionado a ele:
# /etc/init.d/networking restart
Um problema comum que afeta versões do Debian, Ubuntu e distribuições baseadas neles é as interfaces mudarem de endereço a cada reset em micros com duas ou mais interfaces de rede. A placa eth0 passa então a ser a ath1 e assim por diante, o pode ser uma grande dor de cabeça ao configurar um servidor para compartilhar a conexão, já que se as duas interfaces mudam de posição, nada funciona.
A solução para o problema é um pequeno utilitário chamado "ifrename", que permite fixar os devices utilizados para as placas. Utilizá-lo é bem simples. Comece instalando o pacote via apt-get:
# apt-get install ifrename
Crie o arquivo "/etc/iftab" e, dentro dele, relacione o device de cada interface com o endereço MAC correspondente, seguindo o modelo abaixo:
#/etc/iftab
eth0 mac 00:11:D8:76:59:2E
eth1 mac 00:E0:7D:9B:F8:01
Em caso de dúvida, use o comando "ifconfig -a" para ver a configuração atual das placas e o endereço MAC de cada uma. Uma vez criado, o arquivo é verificado a cada boot e a configuração se torna persistente, resolvendo o problema. Este bug das interfaces itinerantes afeta apenas algumas distribuições, por isso você não precisa se preocupar com ele até que perceba que está usando uma das afetadas.
O Ubuntu server vem com o servidor SSH instalado por padrão, de forma que depois de configurar a rede, você pode fazer todo o resto da configuração confortavelmente a partir do seu micro. Uma dica é que ao utilizar o joe, o nano ou o vi (o mcedit não suporta o uso do clipboard), você pode usar o botão central do mouse para colar texto dentro do terminal, o que é muito útil quando você tem um modelo de configuração pronto pra usar.
Compartilhando a conexão
Depois de configuradas as duas interfaces de rede, ativar o compartilhamento da conexão é bastante simples. No Linux o trabalho é feito pelo iptables, o firewall padrão do sistema, que incorpora a função de compartilhamento através do módulo "iptable_nat". Para ativar o compartilhamento, precisamos apenas carregar o módulo, ativar o roteamento de pacotes e em seguida executar o comando que ativa o compartilhamento propriamente dito. Explicando assim pode parecer difícil, mas na prática isso é feito usando apenas 3 comandos:
# modprobe iptable_nat
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
O "eth0" no terceiro comando indica a placa onde está a conexão com a Internet. Não se esqueça de indicar a interface apropriada ao executar o comando (na dúvida você pode checar a configuração da rede usando o ifconfig). Se você acessa via ADSL, usando o pppoeconf ou o adsl-setup (com o modem configurado como bridge) será criada a interface "ppp0".
A partir daí, todas as requisições recebidas na interface de rede local serão mascaradas e roteadas usando a interface especificada e as respostas serão devolvidas aos PCs da rede local.
É possível compartilhar qualquer tipo de conexão, incluindo conexões discadas, wireless, conexões via celular e assim por diante. O servidor simplesmente passa a rotear os pacotes dos demais micros da rede, transmitindo todas as requisições através da conexão que possui. Você precisa apenas configurar os demais PCs da rede para o utilizarem como gateway.
Nem todas as distribuições instalam o executável do 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".
Os três comandos devem ser colocados em algum dos arquivos de inicialização do sistema para que passem a ser executados automaticamente durante o boot. No caso do Ubuntu e outras distribuições derivadas do Debian, você pode utilizar o arquivo "/etc/rc.local". No Fedora, Mandriva e outras distribuições derivadas do Red Hat, use o arquivo "/etc/rc.d/rc.local".
Você pode aproveitar para proteger o servidor usando um firewall simples, que bloqueie as portas de entrada, deixando passar apenas pacotes de respostas e conexões em portas indicadas manualmente. Com isso, o firewall garante um bom nível de proteção, com um mínimo de efeitos colaterais.
Para isso, utilizaremos o próprio iptables, complementando os três comandos anteriores. Estes comandos podem ser incluídos no arquivo /etc/rc.local ou /etc/rc.d/rc.local, logo abaixo dos comandos para compartilhar a conexão:
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
O primeiro comando faz com que o seu servidor deixe de responder a pings. Muitos ataques casuais começam com uma varredura de diversas faixas de endereços de conexões domésticas, enviando um ping para todas as máquinas. Responder ao ping indica não apenas que a máquina está online, mas também que provavelmente ela está com o firewall desativado, o que estimula o atacante a continuar o ataque, lançando um portscan e iniciando o ataque propriamente dito. Deixando de responder aos pings, o volume de ataques ao servidor cai bastante.
Os dois comandos seguintes protegem contra IP spoofing (uma técnica usada em diversos tipos de ataques, onde o atacante envia pacotes usando um endereço IP falseado como remetente, tentando assim obter acesso a PCs da rede interna) e contra pacotes inválidos, que são comumente utilizados em ataques DoS e ataques de buffer overflow.
As três últimas linhas autorizam pacotes provenientes da interface de loopback (lo), juntamente com pacotes provenientes da rede local e descartam novas conexões na interface de Internet, deixando passar apenas pacotes de resposta. Não se esqueça de substituir o "eth1" pela interface de rede local correta, caso contrário você vai acabar fazendo o oposto, ou seja, bloqueando as conexões dos PCs da rede local e deixando passar as provenientes da Internet :).
Se você quiser abrir portas específicas adicione a regra "iptables -A INPUT -p tcp --dport 22 -j ACCEPT" (onde o "22" é a porta e o "tcp" é o protocolo) antes da regra que bloqueia as conexões. Você pode repetir a regra caso necessário, abrindo assim todas as portas desejadas.
No final, incluindo os comandos para compartilhar a conexão e regras para abrir as portas 22 (SSH) e 6881 (bittorrent), os comandos a adicionar no script de inicialização seriam:
#!/bin/sh
# Compartilha a conexão
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Bloqueia pings e protege contra IP spoofing e pacotes inválidos
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state --state INVALID -j DROP
# Abre para a interface de loopback e para a interface de rede local
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
# Abre para as portas especificadas
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 6881 -j ACCEPT
# Bloqueia as demais conexões, deixando passar apenas pacotes de resposta
iptables -A INPUT -p tcp --syn -j DROP
Você pode também criar um filtro simples de conteúdo indicando manualmente endereços que devem ser bloqueados, usando o comando "iptables -A FORWARD -d dominio.com -j DROP". Isso faz com que o servidor se recurse a encaminhar pacotes destinados aos endereços citados, impedindo que eles sejam acessados a partir dos micros da rede local. Você só precisa adicionar uma regra para cada domínio a ser bloqueado no seu script de firewall, como em:
iptables -A FORWARD -d orkut.com -j DROP
iptables -A FORWARD -d msn.com -j DROP
iptables -A FORWARD -d myspace.com -j DROP
Usada dessa forma, a regra bloqueia o acesso aos domínios especificados usando qualquer protocolo. Ou seja, se você adicionar uma regra bloqueando um tracker bittorrent, por exemplo, os clientes bittorrent rodando nas máquinas da rede não conseguirão se conectar a ele para fazerem download dos arquivos. Praticamente qualquer programa que precise se conectar a um servidor central, com um endereço fixo, pode ser bloqueado usando esta regra, desde que você saiba indicar o endereço correto.
A limitação é que esta regra se aplica apenas ao servidor relacionado ao domínio, por isso ela não bloqueia subdomínios hospedados em servidores diferentes. Por exemplo, você pode bloquear o domínio "uol.com.br", mas isso não bloqueará o "tvuol.uol.com.br", que é hospedado em um servidor separado. Em casos como este, a única solução é bloquear ambos.
Outra dica é que, ao compartilhar uma conexão discada ou uma conexão via celular (que também é uma forma de conexão discada, já que você precisa usar o kppp ou o gnome-ppp), você pode fazer com que o sistema execute o script de compartilhamento ao efetuar a conexão usando a aba "Executar" nas propriedades da conexão.
Adapte o script de compartilhamento para compartilhar a interface ppp0 e coloque o comando que executa o script no campo "Ao conectar":
Com isso o compartilhamento é automaticamente ativado ao conectar. A principal observação é que para usar o script de compartilhamento dessa forma você deve abrir o kppp como root, ou modificar o script de forma que ele use o sudo em todos o comandos que precisarem ser executados como root, de forma que ele possa ser executado usando seu login de usuário.
Adicionando um proxy transparente
Os servidores proxy são a forma mais antiga de compartilhar a conexão entre vários micros. Diferente de um servidor configurado para compartilhar a conexão via NAT, que simplesmente roteia pacotes da rede local para a Internet e da Internet para a rede local, mascarando os endereços, um servidor proxy oferece um acesso mais limitado, intermediando a conexão, vasculhando o conteúdo dos pacotes e permitindo apenas o acesso a portas específicas. A grande desvantagem é que todos os micros da rede precisam ser configurados manualmente para utilizarem o proxy.
Usar um servidor proxy permite logar os acessos, impor restrições diversas, baseadas em horários, endereços e outras condições, limitar o uso de banda e assim por diante, o que faz com que eles sejam bastante populares em redes empresariais, onde a redução no uso da banda e o possível aumento na produtividade compensam o trabalho necessário.
Em uma rede doméstica, você pode configurar o servidor proxy para trabalhar em modo transparente, onde ele passa a fazer seu trabalho de forma invisível, sem que você precise configurar os micros da rede para utilizarem-no. O proxy complementa então o compartilhamento via NAT, cacheando os arquivos e as páginas acessadas.
O servidor passa então a armazenar atualizações do Windows Update, downloads diversos, páginas e imagens, pacotes instalados através do apt-get e tudo mais que for acessado via http. Com isso, muita coisa passará a ser acessada a partir do cache do servidor proxy, reduzindo o uso de banda e agilizando o acesso.
A principal limitação é que o proxy transparente irá cachear apenas o tráfego http, através da porta 80. Não é possível usar um proxy transparente para FTP e SSL, a menos que você configure os programas em cada PC manualmente para utilizarem o proxy. No Firefox por exemplo, a configuração de proxy vai dentro do menu "Editar > Preferências", em "Rede > Configurações > Configuração manual de proxy":
Marcando a opção "Usar este proxy para todos os protocolos" você faz com que todo o tráfego passe pelo proxy e seja armazenado no cache, incluindo os arquivos baixados via FTP e https. O problema é que você precisaria fazer essa configuração em todos os micros da rede, o que anula a principal vantagem de usar um proxy transparente, que é a possibilidade de ter ganhos na velocidade de acesso sem precisar fazer modificações nos PCs da rede.
De qualquer forma, a configuração que utilizaremos atende tanto aos PCs configurados para acessar a web diretamente quanto aos PCs configurados manualmente para usar o proxy, de forma que a configuração dos clientes fica a seu critério.
O primeiro passo é configurar o servidor Linux com duas placas de rede para compartilhar a conexão, como vimos nos tópicos anteriores. O proxy transparente é apenas um add-on, que complementa o compartilhamento da conexão via NAT.
Com tudo funcionando, o próximo passo é instalar o Squid, o que é feito através da instalação do pacote "squid" usando o gerenciador de pacotes, como em:
# apt-get install squid
ou:
# yum install squid
A configuração do Squid é feita através de um único arquivo, o "/etc/squid/squid.conf". O arquivo de exemplo, instalado junto com o pacote é assustadoramente grande, com mais de 3000 linhas, incluindo comentários sobre todas as opções disponíveis. Ele é uma boa leitura se você quiser se aprofundar na configuração do Squid, mas se você quer apenas ver seu proxy transparente funcionando, é mais fácil renomear o arquivo e começar com um arquivo de configuração vazio:
# mv /etc/squid/squid.conf /etc/squid/squid.conf.modelo
# touch /etc/squid/squid.conf
Abra o arquivo /etc/squid/squid.conf em branco que foi criado e copie o modelo de configuração abaixo. As opções em negrito são as opções que você precisa alterar:
# /etc/squid/squid.conf
http_port 3128 transparent
visible_hostname gdh
cache_mem 64 MB
maximum_object_size_in_memory 128 KB
maximum_object_size 512 MB
cache_dir ufs /var/spool/squid 4096 16 256
cache_access_log /var/log/squid/access.log
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 21 280 443 488 563 591 777 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all
A primeira linha indica a porta utilizada pelo Squid (3128) e que ele deve operar em modo transparente (transparent). A segunda indica o nome do servidor (gdh), que você deve substituir pelo nome do seu.
As quatro linhas seguintes indicam a configuração do cache. O Squid trabalha com dois caches distintos, um cache mais rápido, feito na memória RAM, e outro mais lento (porém maior) feito usando espaço do HD.
O "cache_mem 64 MB" indica o tamanho do cache na memória RAM (é recomendável que você utilize no máximo 1/3 da memória total instalada), enquanto o "4096" na linha cache_dir ufs /var/spool/squid 4096 16 256" indica o tamanho do cache que será feito no HD, em megabytes.
A linha "acl redelocal src 192.168.1.0/24" indica a faixa de endereços e a máscara utilizada na sua rede local (o /24 equivale à mascara 255.255.255.0). Combinada com as regras "http_access allow redelocal" e "http_access deny all" ela faz com que apenas micros da rede local possam utilizar o proxy, afastando qualquer possibilidade de que ele fique aberto para a Internet, independentemente da configuração do firewall.
A linha maximum_object_size 512 MB indica o tamanho máximo de arquivo que será armazenado no cache (arquivos maiores do que isso serão ignorados), o que evita que arquivos muito grandes, (como imagens ISO) que você vai baixar apenas uma vez, desperdicem espaço no cache.
Depois de terminar, reinicie o Squid para que a configuração entre em vigor:
# /etc/init.d/squid restart
Com isso, a configuração do servidor proxy está pronta, mas falta um passo igualmente importante, que é ativar a regra de firewall que faz com que os acessos destinados à porta 80, provenientes da rede local sejam encaminhados para o Squid. Sem isso, as requisições continuam sendo roteadas diretamente, sem passarem pelo proxy:
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
Note que o "eth1" no comando especifica a interface de rede local, que deve ser alterada de acordo com a sua configuração. Este comando deve ser colocado no script de inicialização (juntamente com os comandos para compartilhar a conexão) para que seja executado automaticamente durante o boot.
Depois de ativar a regra de firewall, você pode testar o proxy navegando em algum dos micros da rede local (que use o servidor como gateway) e verificar o conteúdo do arquivo "/var/log/squid/access.log" no servidor. Conforme as requisições passam pelo proxy, o arquivo é alimentado com um grande volume de informações sobre as conexões realizadas, como em:
1201780615.239 1337 192.168.1.10 TCP_MISS/302 884 GET http://192.168.112.2o7.net/b/ss/mxmacromedia/1/F.3-XELvs - DIRECT/216.52.17.136 text/plain
1201780615.753 248 192.168.1.10 TCP_MISS/200 1526 GET http://wwwimages.adobe.com/www.adobe.com/lib/com.adobe/template/gnav/google.gif - DIRECT/204.245.162.8 image/gif
1201780647.918 29013 192.168.1.10 TCP_MISS/200 3036521 GET http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz - DIRECT/72.246.38.70 application/x-gzip
Pela presença das entradas no arquivo você percebe que os acessos estão realmente passando pelo proxy.
Uma última observação é que esta configuração vale para as versões recentes do Squid, do 2.6 em diante. Em versões antigas do Squid eram usadas 4 linhas adicionais no final do arquivo, no lugar do parâmetro "transparent" na primeira linha:
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
A menos que você esteja usando o Debian Sarge, ou outra distribuição antiga, é improvável que esteja usando uma versão do Squid anterior à 2.6. De qualquer forma, fica a observação. A maior parte dos tutoriais disponíveis na web são anteriores à mudança e por isso ensinam a usar esta configuração antiga, que não funciona mais nas versões atuais. Em caso de dúvida, você pode checar a versão do Squid instalada usando o comando "squid -v".
Adicionando um servidor DHCP
Complementando o compartilhamento da conexão, você pode configurar também um servidor DHCP, especificando a configuração que deve ser fornecida aos PCs da rede. É importante enfatizar que você deve manter apenas um servidor DHCP ativo na rede, de forma que se você já está usando o servidor DHCP do modem ou do roteador wireless, você deve primeiro desativá-lo, antes de ativar o DHCP no servidor.
Com dois servidores DHCP na rede, ambos irão responder às requisições e as máquinas vão simplesmente usar a configuração que receberem primeiro. Mesmo que ambos os servidores DHCP estejam configurados para fornecer a configuração correta, você poderá ter problemas com máquinas recebendo endereços repetidos (um servidor DHCP não tem como saber quais foram os endereços fornecidos pelo outro) e assim por diante. Confie em mim, manter um único servidor DHCP ativo vai tornar sua vida bem mais simples.
Para instalar o servidor DHCP, instale o pacote "dhcp3-server" usando o gerenciador de pacotes, como em:
# apt-get install dhcp3-server
No Fedora o pacote se chama "dhcp" e no Mandriva se chama "dhcpd". Você pode instalá-lo usando (respectivamente) os comandos:
# yum install dhcp
# urpmi dhcpd
Nas distribuições derivadas do Debian o arquivo de configuração é o "/etc/dhcp3/dhcpd.conf" e no Fedora e Mandriva é o "/etc/dhcpd.conf". Apesar disso, em ambos os casos a configuração é a mesma.
Você pode usar o modelo de configuração abaixo. Assim como no caso do Squid, as opções em negrito são as que você deve alterar de acordo com a configuração da sua rede:
# dhcpd.conf
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.250;
option routers 192.168.1.1;
option domain-name-servers 208.67.222.222,208.67.220.220;
option broadcast-address 192.168.1.255;
}
A opção "default-lease-time" controla o tempo de renovação dos endereços IP. O servidor DHCP checa periodicamente se a estação ainda está ativa e, ao perceber que ela foi desligada ou desconectada da rede, libera o endereço para uso de outro micro, evitando que os endereços disponíveis se esgotem. O "default-lease-time" indica o intervalo entre as checagens e o "max-lease-time" determina o tempo máximo antes de liberar o endereço. Em condições normais, essas 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. No exemplo, configurei o DHCP para fornecer os endereços de 192.168.1.100 a 192.168.1.250, de forma a ficar com os demais endereços livres para o uso em estações com IP fixo, mas você poderia reservar toda a faixa de endereços da rede para o DHCP (deixando de fora apenas o endereço do gateway), como em "range 192.168.1.2 192.168.1.254;".
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, enquanto a opção "option domain-name-servers" contém os dois servidores DNS que serão usados pelas estações, separados por vírgula.
O endereço de broadcast é sempre o último endereço da rede, como em "192.168.1.255" ou "10.255.255.255". Ele simplesmente acompanha a faixa de endereços e a máscara utilizada.
Depois de terminada a configuração, reinicie o servidor DHCP para que ela entre em vigor:
# /etc/init.d/dhcp3-server restart
(no Debian e derivados) ou:
# service dhcp restart
(no Fedora e Mandriva)
Ao configurar um servidor com duas placas de rede no Ubuntu ou outra distribuição derivada do Debian, abra o arquivo "/etc/default/dhcp3-server" e indique qual é a placa da rede local, como em:
INTERFACES="eth0"
Isso faz com que o servidor forneça endereços apenas para micros ligados à interface indicada e não mais em qualquer uma das interfaces. Isso evita que ele responda a conexões provenientes da Internet.
Se você quiser também que o servidor atue como um servidor DNS, instale também o pacote "bind", como em:
# apt-get install bind
Ao contrário do DHCP, ele não precisa de configuração, pois vem de fábrica configurado para trabalhar como um servidor DNS de cache, que simplesmente repassa as requisições para um dos 13 root servers da Internet e faz um cache das respostas.
Como vimos no capítulo 2, um servidor DNS local será geralmente mais lento, mas é interessante ter um para testar problemas de conectividade. Afinal, se você consegue navegar usando seu DNS local, mas não navega usando o DNS do provedor, significa que a conexão está funcionando e o problema é apenas no DNS.
fonte : http://www.hardware.com.br/tutoriais/servidor-linux-domestico/
