Configurando um servidor Linux doméstico,

fácil
Introdução

PRÓXIMO: COMPARTILHANDO A CONEXÃO

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 nohttp://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.
» Leia mais sobre a configuração de Servidores Linux
PRÓXIMO: COMPARTILHA
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.
PRÓXIMO: ADICIONANDO UM PROXY TRANSPARENTE

Adicionando um proxy transparente

PRÓXIMO: ADICIONANDO UM SERVIDOR DHCP

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.
» Leia mais sobre a configuração de Servidores Linux