1. Introdução
Gerenciar endereços manualmente funciona em redes pequenas, mas se torna impraticável quando dezenas de dispositivos entram e saem o tempo todo. O DHCP oferece distribuição automática de endereços IPv4, definição de gateway, DNS e outros parâmetros fundamentais de conectividade. Além de reduzir erros humanos, ele centraliza o controle da rede e permite ajustes coordenados. Em IPv6, ele convive com mecanismos autônomos como SLAAC, criando um ambiente mais flexível — mas também mais propenso a erros se não houver clareza de papéis.
2. Arquitetura do DHCP
O fluxo básico do DHCPv4 segue o modelo DORA: o cliente envia um Discover, anunciando que precisa de um endereço; o servidor responde com um Offer contendo um IP disponível; o cliente confirma com um Request e, por fim, o servidor conclui com Ack. Esse processo renova-se periodicamente, o que mantém endereços confiáveis mesmo em redes dinâmicas.
No IPv6, o DHCPv6 não substitui outros mecanismos — ele complementa. O endereço base normalmente chega ao host por SLAAC, um mecanismo no qual o roteador anuncia um prefixo via RA (Router Advertisement) e o cliente monta o próprio endereço a partir dele. Isso torna a rede mais autônoma, mas não resolve tudo: o RA não entrega informações como DNS interno, domínio de busca ou opções específicas da rede. É aí que o DHCPv6 entra, fornecendo esses parâmetros adicionais.
Essa divisão de responsabilidades funciona bem quando planejada, mas vira um problema em ambientes mistos ou mal configurados. Um roteador pode anunciar que “SLAAC é suficiente”, enquanto o servidor DHCPv6 tenta fornecer DNS ao mesmo tempo. Alguns hosts seguem fielmente o RA e ignoram o DHCPv6; outros fazem o oposto. O resultado é uma rede com comportamentos imprevisíveis: máquinas que conseguem navegar, mas não resolvem nomes internos, ou servidores que falham esporadicamente porque perderam o DNS de referência. Entender como SLAAC e DHCPv6 se sobrepõem — e decidir quem faz o quê — é decisivo para evitar esses cenários difíceis de diagnosticar.
3. Configuração do servidor (isc-dhcp)
Um exemplo de configuração para a sub-rede 10.20.0.0/24, respeitando a topologia usada nos artigos anteriores:
subnet 10.20.0.0 netmask 255.255.255.0 {
range 10.20.0.50 10.20.0.200;
option routers 10.20.0.1;
option domain-name "empresa.lan";
option domain-name-servers 10.20.0.5;
}
Aqui, o servidor distribui endereços de .50 a .200, deixando a faixa inicial reservada para equipamentos fixos — roteadores, servidores e dispositivos críticos. O DNS interno assumido é 10.20.0.5, e o gateway padrão 10.20.0.1.
4. Reservas - como planejar e por que usar
Reservas mapeiam um endereço IP a um MAC específico, garantindo previsibilidade sem abrir mão da automação. Diferente de um IP estático configurado no próprio host, uma reserva mantém administração centralizada: se você alterar o DNS da rede, o host reservado também herda a mudança sem intervenção manual.
Um conjunto típico de reservas na sua topologia poderia ser:
host servidor_web {
hardware ethernet 00:11:22:33:44:55;
fixed-address 10.20.0.10;
}
host servidor_dns {
hardware ethernet aa:bb:cc:dd:ee:ff;
fixed-address 10.20.0.5;
}
host roteador_x {
hardware ethernet 66:77:88:99:aa:bb;
fixed-address 10.20.0.2;
}
Esses exemplos seguem a lógica da rede construída nos artigos anteriores: o servidor web em .10, o DNS interno em .5, o roteador X em .2. Manter as reservas organizadas e agrupadas por função evita confusões durante a manutenção e facilita depuração, especialmente quando múltiplos equipamentos usam bridges, VLANs ou múltiplas interfaces.
5. Testes práticos
O teste mais direto é acionar manualmente o cliente DHCP e observar o ciclo completo de negociação. Ao executar:
dhclient -v eth0
O host inicia o processo enviando um DHCP Discover em broadcast, anunciando: “estou aqui, alguém pode me oferecer um endereço?”. O servidor que estiver ativo na rede responde com um DHCP Offer, propondo um IP e parâmetros de rede. Em seguida, o cliente envia um Request confirmando qual oferta escolheu — mesmo que só exista uma — e o servidor fecha o ciclo com o Ack, oficializando a concessão.
A flag -v revela cada etapa desse diálogo, facilitando a identificação de conflitos, atrasos ou ofertas vindas do servidor errado.
Para enxergar o que acontece no lado do servidor, você pode acompanhar os logs em tempo real:
journalctl -u isc-dhcp-server -f
Aqui aparecem mensagens como “DHCPDISCOVER from XX:XX:XX…” ou “DHCPOFFER on 10.20.0.80 to XX:XX:XX…”, permitindo verificar se o servidor está respondendo, se está respeitando as reservas ou se há outro serviço indesejado competindo na rede. É um teste simples, mas que costuma resolver boa parte das dúvidas quando o DHCP parece “não pegar”.
6. Erros comuns e como reconhecê-los
Um dos problemas mais frequentes é ter dois servidores DHCP ativos na mesma rede, muitas vezes um roteador doméstico esquecido ou uma VM mal configurada. O sintoma clássico é clientes recebendo IPs inconsistentes ou gateways errados.
Outro erro recorrente ocorre quando SLAAC distribui um prefixo IPv6 automático enquanto o administrador espera que DHCPv6 forneça DNS. O host então recebe endereço via SLAAC, mas não recebe DNS via DHCPv6 e perde resolução interna.
Por fim, ranges mal definidos — como incluir o IP do gateway dentro do pool — geram conflitos que só aparecem após renovações.
7. Conclusão
DHCP é simples na superfície, mas seu impacto na estabilidade da rede é profundo. Ele centraliza a distribuição de parâmetros fundamentais, suporta reservas para equipamentos essenciais e convive com mecanismos automáticos do IPv6. Um ambiente previsível exige ranges bem planejados, reserva para hosts críticos e vigilância constante sobre quem está realmente anunciando leases na rede. Seguindo boas práticas desde o início, você evita conflitos difíceis de rastrear e ganha um ambiente coerente em todos os níveis — do roteamento ao DNS.
Top comments (0)