Failover de Servidores DHCP Redundantes no Linux

Olá Pessoal.

É muito comum a utilização de um servidor DHCP no ambiente da empresa para fins de configuração dinâmica dos endereços IP das estações da rede de maneira automática. Uma vez que a implementação de um servidor DHCP é uma tarefa relativamente simples, é comum que muitos administradores acabem por dar menor importância ao seu papel crucial em qualquer rede de médio ou grande porte. É fato que o serviço de configuração automática dos endereços é fundamental para a operação de uma rede, afinal sem endereço IP nenhum host sequer consegue ser membro efetivo da rede.

É por essa simplicidade de configuração que o serviço DHCP acaba recebendo menos atenção do administrador e muitas vezes, talvez na maioria, é implantado através de um único servidor. O problema dessa abordagem tradicional é que um único servidor DHCP acaba se tornando um potencial ponto de falha que pode trazer sérios prejuízos para qualquer rede. Caso o servidor venha a cair, as máquinas que já receberam suas configurações irão mantê-las somente até que o tempo limite de empréstimo seja atingido (lease), por isso muitos administradores contornam esse problema aumentando o tempo de empréstimo. Ocorre que essa estratégia não resolve o problema por completo, uma vez que  novas máquinas não conseguirão localizar um servidor DHCP na rede e, portanto, não serão capazes de configurar automaticamente seus endereços.

No contexto específico de ambientes que possuem servidores baseados no Linux Debian, o serviço ISC-DHCP oferece a capacidade de configuração do recurso de failover através da inserção de dois servidores DHCP redundantes. Para demonstrar o roteiro de instalação de ambos os servidores primário e secundário, tomaremos por base a topologia apresentada na figura abaixo.

1. Instalação do Serviço DHCP

A primeira etapa consiste na instalação do pacote isc-dhcp-server em ambos os servidores para que o Linux possa ser posteriormente configurado com o serviço DHCP na rede. Essa tarefa é simples e rápida através do APT (Debian):

root@LinuxServer:/# apt-get install isc-dhcp-server

2. Ativar Interfaces p/ Responder Requisições DHCP

A segunda etapa é informar em ambos os servidores em qual(is) interface(s) o serviço irá responder requisições dos clientes da rede, através da edição do arquivo "/etc/default/isc-dhcp-server".

#--- em /etc/default/isc-dhcp-server
(...) Conteúdo Omitido
#On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#Separate multiple interfaces with spaces, e.g. "eth0 eth1".

INTERFACES="eth0"

3. Configuração do Servidor DHCP Primário

Assim como a configuração tradicional de um servidor DHCP, a configuração do failover é relativamente simples. A principal diferença é que será adicionada uma nova declaração denominada "failover peer", onde definiremos a função do servidor (primário ou secundário) e as portas em que ambos os servidores parceiros irão conversar para sincronizar os empréstimos de endereços.

#--- em /etc/dhcp/dhcpd.conf

authoritative;

ddns-update-style none;
default-lease-time 3600;
max-lease-time 3600;

failover peer "NOME"

{

    primary;                     #define servidor como primário

    address 192.168.221.1;       #endereço do servidor local

    port 647;                    #porta do servidor local

    peer address 192.168.221.2;  #endereço do servidor parceiro

    peer port 647;               #porta do servidor parceiro

    max-response-delay 30;      
    max-unacked-updates 10;     

    load balance max seconds 3;

    mclt 1800;                  

    split 128;                  

} 

subnet 192.168.221.0 netmask 255.255.255.0

{

    option routers 192.168.221.254;

    option domain-name-servers 192.168.221.201, 208.67.222.222;
    option domain-name "nome.com.br";

    pool

    {

        failover peer "NOME";

        range 192.168.221.100 192.168.221.199;

    }

}

Os parâmetros mclt e split somente devem ser configurados no servidor primário. O parâmetro mclt (maximum client lead time) corresponde à extensão do tempo de lease concedido aos clientes no caso de falha do servidor responsável. O parâmetro split é uma métrica que define a proporção de balanceamento de carga entre os dois servidores, podendo variar de 0 (toda a carga no servidor secundário) até 255 (toda a carga no servidor primário), sendo que 128 equivale ao balanceamento simétrico (50/50).

4. Configuração do Servidor DHCP Secundário

A configuração do servidor secundário não é muito diferente da configuração anterior do servidor primário, exceto pelo fato de que informaremos o papel secundário e que algumas informações específicas previamente configuradas no servidor primário agora são omitidas.

#--- em /etc/dhcp/dhcpd.conf

authoritative;

ddns-update-style none;
default-lease-time 3600;
max-lease-time 3600;

failover peer "NOME"

{

    secondary;                   #define servidor como secundário

    address 192.168.221.2;       #endereço do servidor local

    port 647;                    #porta do servidor local

    peer address 192.168.221.1;  #endereço do servidor parceiro

    peer port 647;               #porta do servidor parceiro

    max-response-delay 30;

    max-unacked-updates 10;

    load balance max seconds 3;

} 

subnet 192.168.221.0 netmask 255.255.255.0

{

    option routers 192.168.221.254;

    option domain-name-servers 192.168.221.201, 208.67.222.222;
    option domain-name "nome.com.br";

    pool

    {

        failover peer "NOME";

        range 192.168.221.100 192.168.221.199;

    }

}

Além dos servidores redundantes serem úteis para fins de disponibilidade ao eliminar o ponto único de falha na rede, outra vantagem é que eles fazem um trabalho cooperativo de balanceamento de carga na oferta dos leases para os clientes da rede, dividindo igualmente os empréstimos (se split = 128). Ambos os servidores irão armazenar o registro de todos os leases, além de logar o status dos servidores.

Obs.: É importante estar ciente de que antes da configuração dos servidores primário e secundário, espera-se que ambos estejam com os clocks devidamente sincronizados, uma vez que a referência de tempo é crucial para o serviço DHCP funcionar devidamente. Uma boa opção para manter os relógios dos servidores sincronizados é a implantação do serviço NTP na rede. O leitor encontra mais informações sobre esse assunto em outro artigo do blog, intitulado "A Hora Certa na Internet Brasileira".

Façam seus testes...

Samuel.

Servidores DHCP Redundantes em Dispositivos Cisco

Olá Pessoal.

Uma prática útil para prover redundância no serviço de configuração automática de endereços IP é a inserção de um servidor DHCP adicional na rede que possa garantir a disponibilidade do serviço mesmo em caso de queda do servidor principal, além de dividir a carga de trabalho.

Basicamente essa tarefa pode ser implementada de duas maneiras: (a) através da divisão manual dos escopos configurados nos dois servidores DHCP, de maneira que os endereços providos por um servidor não conflitem com os endereços providos pelo outro; (b) através do protocolo DHCP Failover que viabiliza a coordenação das ações de ambos os servidores, feature suportada pelo ISC-DHCP no Linux Debian e também a partir do Windows Server 2012.

O método manual é suportado em qualquer caixa ou Sistema Operacional por ser o mais simples e não envolver nenhum protocolo específico, no entanto não há uma coordenação das atividades dos dois servidores, de maneira que as tabelas de leases dos dois servidores são totalmente independentes, o que não permite gerenciamento centralizado dos leases ou manutenção das reservas em caso de queda de um dos servidores. Apesar dessas limitações, ainda assim trata-se de uma opção muito comum e funcional para assegurar a disponibilidade do serviço de configuração automática de IPs.

Pois bem, neste breve artigo trago um exemplo bastante simples de configuração de dois roteadores Cisco (poderiam ser switches). Na figura abaixo existem dois roteadores que fazem parte de um grupo HSRP e que respondem pelo IP Virtual 192.168.0.10 (gateway).  Na figura abaixo o leitor pode observar a configuração de ambos os roteadores como servidor DHCP.

Em cada roteador foi definido um escopo denominado ESCOPO para distribuição de endreços na rede 192.168.0.0/24. No roteador DHCP-SRV1 excluímos a faixa inicial dos primeiros dez endereços para fins de atribuição estática e toda a segunda metade dos endereços da rede (de 192.168.0.129 até 192.168.0.254), ou seja, ele irá distribuir endereços que variam de 192.168.0.11 até 192.168.0.128. No roteador DHCP-SRV2 fizemos o processo inverso, ou seja, excluímos toda a primeira metade dos endereços da rede (de 192.168.0.1 até 192.168.0.128). Ao fazer isso, eliminamos qualquer possibilidade de conflito na distribuição de endereços a partir dos dois servidores DHCP presentes na rede.

Obs.: Aqueles interessados na tecnologia HSRP podem recorrer ao Laboratório 26 da segunda edição do livro Laboratórios de Tecnologias Cisco em Infraestrutura de Redes, que traz um exemplo de configuração de Alta Disponibilidade em Cluster de Roteadores.

Façam seus testes...

Samuel.

Integração dos Servidores DNS e DHCP no Linux

Olá Pessoal.

Recentemente escrevi dois artigos relacionados abaixo descrevendo o processo de configuração de um servidor DNS no Linux Debian utilizando o Bind (pacote bind9) e também como configurar um servidor DHCP no Linux Debian utilizando o ISC DHCP Server (pacote isc-dhcp-server). Pois bem, o objetivo deste artigo é mostrar ao leitor como integrar esses dois serviços de maneira que a aplicação Bind (servidor DNS) possa se comunicar com a aplicação ISC-DHCP-Server (servidor DHCP) para que as máquinas endereçadas dinamicamente na rede sejam automaticamente atualizadas nas relações de zonas direta e reversa do serviço de nomes, ou seja, dispensando qualquer esforço (inviável) de configuração manual para manutenção da integridade dos registros. 

• Servidor DNS no Sistema Operacional Linux
• Configuração de Servidor DHCP: Cisco x Linux

Antes de praticar essa tarefa é recomendada a leitura dos dois artigos citados previamente, uma vez que o foco deste artigo é apenas as alterações necessárias nos arquivos de configuração dos serviços DNS e DHCP para implementar aquilo que chamamos de DNS dinâmico. A topologia abaixo apresenta a proposta de topologia para exemplificar o processo de configuração dos serviços de maneira integrada.

1. Alterações no Arquivo de Configuração do Serviço DNS (Bind)

Abaixo trago um exemplo de configuração do arquivo /etc/bind/named.conf, onde há destaques em amarelo nas alterações necessárias no servidor DNS. No diretório /etc/bind existe um arquivo denominado rndc.key que contém uma chave única que utilizaremos em ambos os serviços DNS e DHCP para fins de autenticação, permitindo a comunicação entre as aplicações.

#--- /etc/bind/named.conf.local

include "/etc/bind/rndc.key";

zone "nome.com.br"

{

type master;

file "/etc/bind/nome.com.br.forward";

allow-transfer { 192.168.221.202; };

allow-update   { key "rndc-key"; };

};

zone "221.168.192.in-addr.arpa"

{

type master;

file "/etc/bind/nome.com.br.reverse";

allow-transfer { 192.168.221.202; };

allow-update   { key "rndc-key"; };

};

Obs.: Uma observação muito importante é que, por padrão, o diretório /etc/bind pertence ao usuário root, mas é necessário que a aplicação Bind tenha acesso de escrita ao diretório para criar e atualizar os novos arquivos dinâmicos das zonas direta e reversa. Por isso é importante ajustar os provilégios de acesso ao diretório através do comando: chown bind:bind /etc/bind.

2. Alterações no Arquivo de Configuração do Serviço DHCP

Abaixo trago um exemplo de configuração do arquivo /etc/dhcp/dhcpd.conf, onde há destaques em amarelo nas alterações necessárias no servidor DHCP. Reparem que estamos referenciando a mesma chave (rndc-key) utilizada anteriormente na configuração do Bind. Se os serviços DNS e DHCP estiverem instalados na mesma máquina, é possível fazer referência direta ao arquivo através da instrução include apontando para o mesmo arquivo na máquina local. Outra opção é inserir o conteúdo da chave manualmente, como é feito no exemplo abaixo. Além disso, também informamos as zonas direta e reversa previamente configuradas no servidor DNS que responde pelo IP informado no parâmetro primary.

#--- /etc/dhcp/dhcpd.conf

ddns-updates on;

ddns-update-style interim;

update-static-leases on;

key "rndc-key"

{

algorithm hmac-md5;

secret "aqui_vem_sua_chave";

};

authority;

default-lease-time 600;

max-lease-time 7200;

log-facility local7;

zone nome.com.br

{

primary 192.168.221.201;

key "rndc-key";

}

zone 221.168.192.in-addr.arpa

{

primary 192.168.221.201;

key "rndc-key";

}

subnet 192.168.221.0 netmask 255.255.255.0

{

range 192.168.221.101 192.168.221.199;

option routers 192.168.221.254;

option domain-name "nome.com.br";

option domain-name-servers 192.168.221.201, 192.168.221.202;

}

Façam seus testes...

Samuel.

Configuração de Servidor DHCPv6 no Linux

Olá Pessoal,

Em outro artigo intitulado "Configuração de Servidor DHCP: Cisco x Linux" explico ao leitor como utilizar o serviço ISC-DHCP em distribuições Linux baseadas no Debian para configurar um servidor DHCP em redes IPv4. Neste artigo trago os passos necessários para fazer essa mesma configuração, mas agora no contexto de uma rede IPv6 (bem simples) apresentada na topologia abaixo. Uma primeira observação relevante é que o ISC-DHCP somente pode ser executado para IPv4 ou IPv6 isoladamente, ainda que seja possível executar dois daemons parametrizados para IPv4 e IPv6.

1. Instalação do Serviço DHCP

A primeira etapa consiste na instalação do pacote isc-dhcp-server para que o Linux possa ser posteriormente configurado como servidor DHCP na rede IPv6. Como de costume, essa tarefa é simples e rápida através do APT (Debian):

apt-get install isc-dhcp-server

2. Definir o DHCPv6 nas Interfaces

A segunda etapa é informar em qual(is) interface(s) o servidor irá responder requisições dos clientes da rede, através da edição do arquivo /etc/default/isc-dhcp-server. É também nesse arquivo que apontaremos para outro arquivo específico de configuração do serviço DHCPv6 e definiremos a opção -6 para ativar o serviço DHCP na modalidade IPv6.

# Defaults for isc-dhcp-server initscript

# sourced by /etc/init.d/isc-dhcp-server

#

# This is a POSIX shell fragment

#

# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).

DHCPD_CONF=/etc/dhcp/dhcpd6.conf

# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).

DHCPD_PID=/var/run/dhcpd6.pid

# Additional options to start dhcpd with.

OPTIONS="-6"

# On what interfaces should the DHCP server serve DHCP requests?

INTERFACES="eth1"

3. Configurar o Servidor DHCPv6

A etapa mais importante consiste na configuração do servidor DHCPv6 propriamente dito, tarefa que é realizada através da criação e edição do arquivo /etc/dhcp/dhcpd6.conf, seguindo o caminho informado previamente na etapa anterior. Cabe observar que para o escopo IPv6 ser válido, é necessário que a interface do servidor esteja configurada com um endereço válido na mesma rede dos demais endereços que serão distribuídos dinamicamente para os clientes. Para exemplificar definirei um intervalo com endereços que variam seu final de dddd::100 até dddd::199, apenas porque o quarteto "dddd" faz lembrar de DHCP e facilita a identificação dos endereços atribuídos dinamicamente. Também utilizarei os endereços IPv6 de DNS públicos da Google e o domínio "labcisco.com.br". 

###--- /etc/dhcp/dhcpd6.conf

ddns-update-style none;

default-lease-time 86400;

max-lease-time 86400;

authoritative;

subnet6 2001:db8:cafe::/64

{

    range6 2001:db8:cafe::dddd:100 2001:db8:cafe::dddd:199;

    option dhcp6.name-servers 2001:4860:4860::8888, 2001:4860:4860::8844;

    option dhcp6.domain-search "labcisco.com.br";

    # Reserva de Emprestimo (Opcional)

    host NOME

    {

        host-identifier option dhcp6.client-id 00:01:00:01:3a:ff:ba:e2:6b:b1:1f:01:23:45;

        fixed-address6 2001:db8:cafe::ffff:1;

    } 

}

Obs.: A configuração do endereço de gateway não é mais realizada através do servidor DHCP, mas por meio das mensagens Router Advertisement (ICMPv6 Tipo 134) enviadas pelos roteadores. O leitor encontra mais informações sobre a configuração do roteador em outro artigo intitulado "Anúncio de Prefixos IPv6 em Roteadores Linux". Ao utilizar um servidor DHCPv6 de natureza stateful na rede, é importante ativar as flags AdvManagedFlag e AdvOtherConfigFlag na configuração do arquivo /etc/radvd.conf, sendo que a flag AdvAutonomous pode ser desativada (off) para impedir a autoconfiguração de endereços (SLAAC).

4. Reserva de Empréstimo (Opcional) 

Opcionalmente o administrador da rede pode reservar/fixar o lease (empréstimo) de um endereço IPv6 específico para um determinado cliente, conforme destacado em azul na configuração anterior. No contexto do IPv4 essa ação era realizada através da associação de um IPv4 com o endereço físico (MAC) do cliente, mas no IPv6 essa associação mudou. Agora a reserva é feita através da associação do endereço IPv6 com o identificador único (DUID) do cliente DHCP que é um número grande de 14 bytes. Em clientes rodando o Linux é possível localizar o DUID no arquivo /var/lib/dhcpv6/dhcp6c_duid. Em clientes Windows é possível identificar o DUID através do comando "ipconfig /all". 

5. Manipulação do Serviço DHCPv6

Antes de iniciar o serviço para realizar a distribuição dinâmica de endereços IPv6 via DHCP é necessário criar o arquivo /var/lib/dhcp/dhcpd6.leases para armazenar os logs com os registros dos empréstimos realizados. 

root@DHCPv6-Server:/# touch /var/lib/dhcp/dhcpd6.leases

root@DHCPv6-Server:/# service isc-dhcp-server start

[ ok ] Starting ISC DHCP Server: dhcpd.

Obs.: Caso o leitor tenha interesse nos procedimentos de configuração de um servidor DHCPv6 em roteadores Cisco, recomendo a leitura do artigo "Servidores DHCPv6 em Redes IPv6". Aqueles interessados em se aprofundar no conhecimento do protocolo IPv6 como um todo, não podem deixar de ler meu livro intitulado "IPv6 - O Novo Protocolo da Internet".

Façam seus testes...

Samuel.

Configuração de Relay-Agent em Roteadores Linux

Olá Pessoal.

No processo de comunicação do DHCP, os clientes fazem a busca por um ou mais servidores através do envio de mensagems de broadcast (com o endereço de origem 0.0.0.0/32 ou ::0/128) para alcançar toda a rede local na procura por algum servidor DHCP. O "problema" em ambientes com múltiplas sub-redes que possuem um único servidor DHCP centralizado é que a propagação do tráfego de broadcast nas sub-redes cessa nos seus respectivos gateways (na interface de um roteador), uma vez que roteadores não têm permissão para propagar broadcast.

Em situações em que existem diferentes sub-redes atrás de um roteador e um único servidor centralizado para distribuir os endereços via DHCP, além de configurar o servidor com os múltiplos escopos que ele deverá distribuir, é também necessário configurar um relay-agent DHCP. O relay-agent é um serviço configurado manualmente que redireciona o tráfego de broadcast que chega em uma (ou mais) interface(s) para um host específico como tráfego unicast. 

A configuração do relay-agent em roteadores Cisco é muito simples e pode ser realizada através do comando "ip helper-address <IP-HOST>" na interface que irá receber broadcast. O leitor interessado nessa configuração em roteadores Cisco pode encontrar um exemplo em outro artigo intitulado "Configuração de Switches Multi-Layer (Layer-3)"

O relay-agent pode ser facilmente implementado em ambientes que possuem roteadores Linux. Especificamente em distribuições baseadas no Debian, para configurar o serviço Relay-Agent é necessário instalar o pacote "dhcp-helper":

root@LinuxRouter:/# apt-get install dhcp-helper

Feito isso, basta realizar as configurações através do arquivo "/etc/default/dhcp-helper". Por padrão, o serviço irá inicializar fazendo o relay do broadcast na interface eth0, por isso é necessário personalizar a configuração para reproduzir a necessidade do seu ambiente. Para exemplificar o conteúdo do arquivo de configuração, consideremos o cenário da figura abaixo que pode ser facilmente reproduzido através do VirtualBox:

#--- em /etc/default/dhcp-helper

#

# You will need at least "-s" or

# "-b" so that dhcp-helper know where

# to relay DHCP requests.

DHCPHELPER_OPTS="-s 172.19.0.1 -e eth0" 

A opção -s faz referência ao endereço do(s) servidor(es) em que o tráfego de broadcast será redirecionado como unicast. O administrador poderia utilizar a opção -b para indicar ao relay-agent que todo tráfego de broadcast deveria ser encaminhado para a interface conectada na rede em que existe o servidor DHCP, assim seria desnecessário informar um endereço específico. No entanto essa prática implicaria em mais broadcast na rede, por isso o ideal é utilizar a opção -s e informar o endereço específico do servidor. A opção -e é utilizada para excluir a escuta em alguma interface específica em que não é desejado o serviço de relay do tráfego broadcast, por exemplo na Internet ou em alguma sub-rede endereçada estaticamente. A opção -i especifica em qual(is) interface(is) haverá escuta do tráfego broadcast, destacando que a omissão dessa opção implica na escuta em todas as interfaces (exceto naquelas excluídas através da opção -e).

O serviço pode ser inicializado através do comando abaixo:

root@LinuxRouter:/# service dhcp-helper start

Starting DHCP relay agent: dhcp-helper.

Para informações mais detalhadas, consulte o manual do serviço via linha de comando:

root@LinuxRouter:/# man dhcp-helper

Esse é um recurso simples e bastante útil.

Abraço.

Samuel.

Configuração de Servidor DHCP: Cisco x Linux

Olá Pessoal.

O tradicional serviço DHCP (Dynamic Host Configuration Protocol) é definido na RFC 2131 e diz respeito à distribuição automática de endereços em uma rede TCP/IPv4 através de um servidor. É nesse servidor que o administrador irá criar um escopo definindo o intervalo de endereços que será distribuído para as máquinas, bem como outras configurações importantes: gateway da rede, servidores de resolução de nomes (DNS), opções, etc.

O servidor fica responsável por manter uma tabela com o registro dos clientes (MAC), seus respectivos endereços atribuídos (IP) e seu tempo de empréstimo (lease). Uma vez que o servidor mantém essa tabela com o "estado" dos clientes associando os endereços físicos das máquinas (MAC) com os endereços lógicos (IP) atribuídos, então dizemos que esse é um serviço de natureza stateful, ou seja, é mantido um registro de estado.

A sua configuração através de um roteador Cisco é bastante simples, bastando a entrada de alguns poucos comandos para fazê-lo. Vamos observar o cenário da figura abaixo em que temos uma rede 192.168.221.0/24, sendo que todas as máquinas estarão configuradas para obter o endereço dinamicamente e o roteador será responsável por executar o serviço DHCP. As configurações necessárias seriam as seguintes:

01. Router(config)# ip dhcp excluded-address 192.168.221.1 192.168.221.30

02. Router(config)# ip dhcp pool NOME-ESCOPO

03. Router(config-dhcp)# network 192.168.221.0 255.255.255.0

04. Router(config-dhcp)# default-router 192.168.221.1

05. Router(config-dhcp)# dns-server 192.168.221.2 208.67.222.222
06. Router(config-dhcp)# domain-name nome.com.br
07. Router(config-dhcp)# lease 1

Na primeira linha definimos quis endereços devem ser excluídos do escopo que será posteriormente criado, uma vez que esses endereços serão atribuídos estaticamente porque são reservados para os servidores. Na segunda linha foi dado um nome para o escopo que irá compreender os endereços da rede informada na terceira linha, sendo que nas linhas 4 e 5 são informados os endereços que as máquinas deverão utilizar como gateway e DNS. A linha 6 informa o nome de domínio que deve ser anexado como sufixo aos nomes. A linha 7 poderia ser omitida porque indica que a duração do empréstimo é de 1 dia (padrão). Pois bem, simples até aqui!

Agora vamos considerar que no cenário anterior o roteador não ficará responsável pela execução do serviço DHCP, sendo que um dos servidores está instalado com Linux Debian e deverá assumir essa função, ou seja, será um servidor DHCP que estará configurado na rede com o IP 192.168.221.5. A boa notícia é que esse procedimento no Linux também é bastante simples, então vamos à configuração:

1. Instalação do Serviço DHCP

A primeira etapa consiste na instalação do pacote "isc-dhcp-server" para que o Linux possa ser posteriormente configurado como servidor DHCP na rede. Essa tarefa é simples e rápida através do APT (Debian):

root@LinuxServer:/# apt-get install isc-dhcp-server

2. Ativar Interfaces p/ Responder Requisições DHCP

A segunda etapa é informar em qual(is) interface(s) o servidor irá responder requisições dos clientes da rede, através da edição do arquivo "/etc/default/isc-dhcp-server".

#--- em /etc/default/isc-dhcp-server
(...) Conteúdo Omitido
#On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#Separate multiple interfaces with spaces, e.g. "eth0 eth1".

INTERFACES="eth1"

3. Configurar o Servidor DHCP

A etapa mais importante consiste na configuração do servidor DHCP propriamente dito, tarefa que é realizada através da edição do arquivo "/etc/dhcp/dhcpd.conf".

#--- em /etc/dhcp/dhcpd.conf
ddns-update-style none;
default-lease-time 86400;
max-lease-time 604800;
authoritative;

subnet 192.168.221.100 netmask 255.255.255.0
{
  range 192.168.221.31 192.168.221.199;
  option routers 192.168.221.1;
  option domain-name-servers 192.168.221.2, 208.67.222.222;
  option domain-name "nome.com.br";
}

Obs.: Os tempos são configurados em segundos, ou seja, um empréstimo de 86400s equivale a 1 dia. O tempo padrão do empréstimo será o valor do default-lease-time, no entanto as interfaces podem solicitar um determinado tempo do empréstimo que não pode ultrapassar o valor de max-lease-time (604800s = 1 semana).

4. Reserva de Empréstimo (Opcional)

Opcionalmente, o administrador da rede pode reservar/fixar o lease (empréstimo) de um endereço IP específico para um determinado cliente através da associação com o seu endereço físico (MAC).

#--- em /etc/dhcp/dhcpd.conf
host NOME
{
  hardware ethernet 00:00:00:00:00:0a;
  fixed-address 192.168.221.37;
}

5. Manipulação do Serviço DHCP

Por fim, depois de configurado o servidor, basta iniciar o serviço para realizar a distribuição dinâmica de endereços via DHCP. O comando abaixo pode ser inserido no arquivo "/etc/rc.local" para que o serviço DHCP seja iniciado automaticamente em caso de boot do servidor.

root@LinuxServer:/# service isc-dhcp-server start
[ ok ] Starting ISC DHCP Server: dhcpd.

6. Visualização de Endereços Concedidos (Lease)

O administrador da rede pode visualizar a relação de todos os endereços concedidos pelo servidor DHCP, listando o conteúdo do arquivo "/var/lib/dhcp/dhcpd.leases".

root@LinuxServer:/# cat /var/lib/dhcp/dhcpd.leases
(...) Saída Omitida

Para obter informações detalhadas, consulte o manual via linha de comando:

root@LinuxServer:/# man dhcpd.conf

Abraço.

Samuel.

Delegação de Prefixos IPv6 em Roteadores Cisco

Olá Pessoal.

Em outros artigos que escrevi aqui no blog, mostrei ao leitor como configurar o DHCPv6 nas modalidades stateless e stateful. O DHCPv6 ainda possui um novo recurso bastante útil para provedores (ISPs) denominado Delegação de Prefixos (Prefix Delegation), comumente referenciado como DHCPv6-PD.

A idéia básica por trás desse recurso é que o roteador PE (Provider Edge) de um ISP pode entregar uma rede /64 ou mesmo um bloco /56 (com 256 sub-redes /64) para o roteador CE (Customer Edge) de seus clientes. Na realidade é possível entregar qualquer bloco menor a partir de um prefixo principal porque o roteador "quebra" o prefixo principal. Nesse contexto cabe destacar as recomendações do NIC.br de que empresas recebam um prefixo /48 (65.536 sub-redes /64) e usuários residenciais um prefixo /56 (256 sub-redes /64). Para exemplificar o processo de configuração do DHCPv6-PD utilizaremos o cenário abaixo.

Observem que o ISP detém o bloco 2001:DB8:CAFE::/48 e será configurado com o DHCPv6-PD para gerar sub-prefixos /56 para seus clientes. A interface f0/0 do roteador CE (cliente do ISP) está conectada na interface f0/0 do roteador ISP-PE. Na sequência iremos configurar o roteador CE do cliente para receber o prefixo via DHCPv6 e, posteriormente, esse prefixo /56 será utilizado para gerar novos prefixos /64 nas interfaces f1/0 e f2/0 que estão diretamente conectadas nas sub-redes locais.

Então vamos às configurações necessárias para configurar o roteador ISP-PE:

01. ISP-PE(config)# ipv6 local pool CLIENTE 2001:db8:cafe::/48 56

02. ISP-PE(config)# ipv6 dhcp pool ISP

03. ISP-PE(config-dhcp)# prefix-delegation pool CLIENTE lifetime infinite infinite

04. ISP-PE(config-dhcp)# exit

05. ISP-PE(config)# int f0/0

06. ISP-PE(config-if)# ipv6 address 2001:db8:cafe::1/64

07. ISP-PE(config-if)# ipv6 dhcp server ISP

08. ISP-PE(config-if)# no shut

09. ISP-PE(config-if)# end

10. ISP-PE# show ipv6 local pool

Na primeira linha criamos um pool local (denominado CLIENTE) informando o bloco principal /48 do provedor que deverá ser "quebrado" em prefixos /56. Na segunda linha estamos configurando o serviço DHCP configurado para fazer a delegação de prefixos, seguindo a lógica do pool local criado anteriormente. Por fim, na sétima linha ativamos a interface f0/0 para prover o serviço DHCP.

A figura abaixo traz a saída do comando "show ipv6 local pool", onde o leitor pode observar que o prefixo 2001:DB8:CAFE::/48 está configurado para gerar até 256 sub-prefixos /56 e que, até esse momento, nenhum sub-prefixo está sendo utilizado pelo(s) cliente(s). 

Agora vamos às configurações do roteador CE do cliente:

01. CE(config)# int f0/0

02. CE(config-if)# ipv6 enable

03. CE(config-if)# ipv6 address autoconfig default

04. CE(config-if)# ipv6 dhcp client pd FROM-ISP

05. CE(config-if)# no shut

06. CE(config-if)# end

07. CE# show ipv6 dhcp interface

A figura abaixo traz a saída do comando "show ipv6 dhcp interface", onde o leitor pode observar os blocos ativos que o roteador CE está recebendo do seu ISP, sendo que, a partir dessa informação, é possível utilizar o prefixo /56 recebido para quebrá-lo em sub-prefixos /64 nas interfaces f1/0 e f2/0.

Pois bem, vamos às configurações finais no roteador CE do cliente:

08. CE(config)# int f1/0

09. CE(config-if)# ipv6 enable

10. CE(config-if)# ipv6 address FROM-ISP ::1:0:0:0:1/64

11. CE(config-if)# no shut

12. CE(config-if)# int f2/0

13. CE(config-if)# ipv6 enable

14. CE(config-if)# ipv6 address FROM-ISP ::2:0:0:0:1/64

15. CE(config-if)# no shut

16. CE(config-if)# end

17. CE# show ipv6 int brief

Observem nos destaques em amarelo (linhas 10 e 14) que, a partir do prefixo FROM-ISP (2001:DB8:CAFE:0::/56), estamos criando duas sub-redes /64 fazendo referência explícita ao quarto quarteto do endereço IPv6. É por isso que na configuração enxergamos 5 quartetos... A figura abaixo traz a saída do comando "show ipv6 int brief", onde o leitor pode observar os endereços configurados nas interfaces f1/0 e f2/0.

Por fim é interessante observar novamente o prefixo delegado no roteador ISP-PE, afinal agora um prefixo /56 (gerado a partir do original /48) já está em uso, restando 255. Também vale mencionar que o roteador ISP-PE automaticamente cria uma rota 2001:db8:cafe::/56 associada às as sub-redes do cliente, conforme ilustrado na figura abaixo:

Esse recurso de DHCPv6-PD é, de fato, MUITO útil para provedores.

Abraço.

Samuel.

Servidores DHCPv6 em Redes IPv6

Olá Pessoal.

Muito se fala da visível diferença que existe nos endereços IPv4 (32 Bits) e IPv6 (128 Bits), o que permite uma quantidade de endereços de ordem astronômica com o "novo" protocolo - 340 undecilhões de endereços possíveis! Porém, pouco se fala das VÁRIAS outras diferenças que existem entre os protocolos. O IPv6 é um protocolo novo e que, portanto, possui muitas particularidades bem diferentes do seu antecessor - o tradicional IPv4.

Por exemplo, quando pensamos na questão da atribuição dos endereços, o "novo" IPv6 permite que essa configuração seja realizada de diversas maneiras, tais como:

• Autoconfiguração Stateless (SLAAC)

• Configuração Estática

• Configuração Estática EUI-64

• DHCPv6 Stateful

• DHCPv6 Stateless

Seria necessário um artigo para cada uma dessas técnicas, então esse artigo será focado apenas nas principais diferenças entre o DHCPv6 nas modalidades: (i) Stateful e (ii) Stateless. Aproveitarei a oportunidade para mostrar as diferenças na configuração de um serviço DHCP em roteadores Cisco para ambientes IPv4 e IPv6.

No IPv4 o tradicional serviço de DHCP (Dynamic Host Configuration Protocol) é definido na RFC 2131 e diz respeito à distribuição automática de endereços em uma rede TCP/IPv4 através de um servidor reponsável por executar uma instância de um serviço DHCP. É nesse servidor em que o administrador irá criar um escopo definindo o intervalo de endereços que será distribuído para as máquinas, bem como outras configurações importantes: gateway da rede, servidores de resolução de nomes (DNS), opções, etc.

Nesse caso cabe ao servidor manter uma tabela com o registro dos clientes, seus respectivos endereços atribuídos e seu tempo de empréstimo (lease). Uma vez que o servidor é responsável por manter essa tabela com o "estado" dos clientes associando os endereços físicos das máquinas (MAC) com os endereços lógicos atribuídos (IP), então dizemos que esse é um serviço de natureza stateful, ou seja, é mantido um registro de informações.

A sua configuração através de um roteador Cisco é bastante simples, bastando a entrada de alguns poucos comandos para fazê-lo. Vamos observar o cenário da figura abaixo em que temos uma rede 192.168.221.0 /24, sendo que todas as máquinas estarão configuradas para obter o endereço dinamicamente e o roteador será responsável por executar o serviço DHCP. As configurações necessárias seriam as seguintes:

01. Router(config)# ip dhcp excluded-address 192.168.221.1 192.168.221.30

02. Router(config)# ip dhcp pool NOME-ESCOPO

03. Router(config-dhcp)# network 192.168.221.0 255.255.255.0

04. Router(config-dhcp)# default-router 192.168.221.1

05. Router(config-dhcp)# dns-server 192.168.221.2

Na primeira linha definimos quais endereços devem ser excluídos do escopo que será posteriormente criado, uma vez que esses endereços serão atribuídos estaticamente porque são reservados para os servidores. Na segunda linha foi dado um nome para o escopo que irá compreender os endereços da rede informada na terceira linha, sendo que nas linhas 4 e 5 são informados os endereços que as máquinas deverão utilizar como gateway e DNS. Pois bem, até aqui bem simples! 

Acontece que quando pensamos em IPv6 as coisas mudam bastante. Primeiro porque nativamente as redes IPv6 têm suporte ao processo de autoconfiguração stateless em que as próprias máquinas são capazes de formar seu endereço através de duas etapas: (i) a máquina determina seu identificador de host (sufixo) a partir do endereço físico da interface (MAC) e (ii) a máquina determina seu identificador de rede (prefixo) através de anúncios emitidos pelo roteador através de um protocolo de descoberta de vizinhança (NDP). Em um próximo artigo escreverei detalhadamente sobre o processo de autoconfiguração dos enredeços IPv6...

Por conta disso, via de regra, um servidor DHCP seria algo dispensável em redes IPv6 e agora o roteador da infraestrutura se torna um elemento ainda mais importante. Apesar disso, o DHCPv6 é definido na RFC 3315 e pode existir em duas modalidades: (i) stateful e (ii) stateless. 

A modalidade stateless é aquela em que o servidor não mantém um registro dos endereços atribuídos aos clientes porque agora as máquinas irão formar automaticamente seu endereço a partir do endereço físico da interface de rede (MAC) e através dos anúncios dos prefixos dos roteadores. Nessa modalidade cabe ao servidor DHCPv6 informar apenas os endereços complementares, tais como: DNS e/ou Opções. Vale destacar que a funcionalidade stateless é muito útil para informar automaticamente os servidores DNS da rede, afinal em IPv6 o serviço DNS é fundamental para amenizar a "complexidade" do endereço de 128 bits.

Estamos falando de uma versão bastante simplificada do DHCP que não consome muitos recursos do "servidor" e que utiliza como base o processo de autoconfiguração! Para exemplificar como seria a configuração desse serviço, vamos observar o cenário da figura abaixo que é apenas uma reprodução da figura anterior num ambiente TCP/IPv6 em que temos a rede 2001:DB8:CAFE::/64.

O processo de configuração do DHCPv6 Stateless consiste em criar e configurar o "escopo" (linhas de 1 a 3), destacando que é importante ativar o serviço DHCPv6 na interface conectada à LAN que receberá os endereços dinâmicos (linha 7) e informar aos hosts que as informações complementares devem ser aprendidas pelo serviço DHCPv6 (linha 8), através da ativação da flag O (other-config-flag).

01. Router(config)# ipv6 dhcp pool NOME-ESCOPO
02. Router(config-dhcp)# dns-server 2001:DB8:CAFE::2
03. Router(config-dhcp)# domain-name labcisco.com.br
03. Router(config-dhcp)# exit
04. Router(config)# int f0/0
05. Router(config-if)# ipv6 enable
06. Router(config-if)# ipv6 address 2001:DB8:CAFE::1/64
07. Router(config-if)# ipv6 dhcp server NOME-ESCOPO
08. Router(config-if)# ipv6 nd other-config-flag
09. Router(config-if)# end

Embora não seja recomendado pela Cisco e nem todos os roteadores suportem, ainda existe uma versão stateful do DHCPv6 para aqueles que precisam manter o registro dos endereços dinamicamente atribuídos e que querem determinar o escopo explicitamente. Normalmente essa modalidade será empregada em servidores Linux e Windows Server. O processo de configuração do DHCPv6 Stateful no roteador ficaria:

01. Router(config)# ipv6 dhcp pool NOME-ESCOPO
02. Router(config-dhcp)# address prefix 2001:DB8:CAFE::/64 lifetime 1800 60
03. Router(config-dhcp)# dns-server 2001:DB8:CAFE::2
04. Router(config-dhcp)# exit
05. Router(config)# int f0/0
06. Router(config-if)# ipv6 enable
07. Router(config-if)# ipv6 address 2001:DB8:CAFE::1/64
08. Router(config-if)# ipv6 dhcp server NOME-ESCOPO
09. Router(config-if)# ipv6 nd managed-config-flag
10. Router(config-if)# exit

Reparem que agora tivemos que configurar na interface (linha 9) uma opção que instrui os clientes a receber todas as configurações de endereço via DHCPv6 (stateful), procedimento feito através da ativação da flag M (managed-config-flag). Além disso, na linha 2 o prefixo é explicitamente configurado.

Por fim, o segiunte comando poderia ser utilizado para fins de verificação:

Router# show ipv6 dhcp pool

Esse artigo mostra que as diferenças entre os protocolos IPv4 e IPv6 estão muito além do formato do endereço utilizado. O IPv6 é um protocolo que possui muitas particularidades que não existiam no seu antecessor, motivo pelo qual precisamos disseminar suas funcionalidades e qualificar mais profissionais preparados para lidar com o novo protocolo.

Abraço.

Samuel.