quarta-feira, 23 de dezembro de 2015

Caros Leitores, Boas Festas

Olá Pessoal.

Estamos nos aproximando do final de mais um ano e agora é época de festas. Essa é uma mensagem de carinho que deixo para todos vocês leitores do blog que têm colaborado no processo de divulgação de todo o conteúdo que tenho produzido, a exemplo dos artigos técnicos, dos livros, cursos, vídeos, etc. Nesse ano de 2015 ultrapassamos a marca de 1.000.000 (um milhão) de acessos e em 2016 o blog certamente estará repleto de novos artigos!

Feliz Natal e Próspero Ano Novo!

Samuel.


domingo, 22 de novembro de 2015

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.

domingo, 8 de novembro de 2015

Nova Nomenclatura de Interfaces Previsíveis no Linux

Olá Pessoal

Recentemente, a partir da versão v197 do systemd/udev, o Linux passou a utilizar um novo mecanismo para nomenclatura das interfaces de redes, denominado Predictable Network Interface Names. O objetivo da nova nomenclatura foi solucionar problemas reais decorrentes da generalização dos nomes tradicionais que utilizavam o formato ethX (ethernet), wlanX (wireless), etc.

O problema da nomenclatura tradicional é que as interfaces de mesma natureza recebem seus nomes do kernel de maneira sequencial (no formato eth0, eth1, eth2, etc...) assim que elas são consultadas pelo driver. Ocorre que o mecanismo de comunicação entre o driver e a interface não é previsível, o que implica na possibilidade de alteração nos nomes das interfaces durante o processo de boot de máquinas que tenham múltiplas interfaces de rede em caso de atualização de hardware. Essa situação traz riscos de segurança em ambientes que tenham scripts de firewall que foram baseados nos nomes tradicionais.

Obs.: O leitor pode fazer um teste rápido para verificar essa situação usando um liveCD em máquina que tenha duas interfaces de rede. Repare que a indexação das interfaces ocorre de forma aleatória a cada boot. Em sistemas devidamente instalados os nomes permanecem persistentes depois de atribuídos pelo kernel até que haja alguma alteração de hardware que demande nova reindexação. 

O novo mecanismo de nomenclatura traz suporte nativo a diferentes políticas para nomeação das interfaces de rede, a destacar:

  1. Nomes Indexados via Firmware/BIOS On-Board
  2. Nomes Indexados via Firmware/BIOS PCI Express
  3. Nomes Indexados via Localização Física do Hardware
  4. Nomes Indexados via Endereço Físico (MAC)
  5. Nomes Clássicos Nativos do Kernel (Imprevisíveis)

Todas essas políticas são utilizadas em conjunto, de forma que a primeira política será adotada caso as informações do firmware on-board estejam disponíveis, seguida pela segunda política caso as informações do firmware PCI estejam disponíveis, seguida pela terceira política se disponível, seguida da quinta política caso contrário. A quarta política não é utilizada por padrão, a menos que seja explicitamente configurada pelo administrador. Por exemplo, possíveis nomes de interfaces baseados na primeira, segunda, terceira, quarta e quinta políticas, respectivamente, seriam: eno1, ens1, enp2s0, enx78e7d1ea46da e eth0


Apesar das políticas padrões, as configurações realizadas pelo administrador sempre têm precedência. Ou seja, se o administrador criar links para outras regras udev, por exemplo para utilizar seus próprios nomes personalizados ou mesmo os nomes tradicionais, o novo mecanismo de nomenclatura previsível não será adotado. A nova nomenclatura previsível pode ser desativada, fazendo com que o sistema volte a utilizar os nomes tradicionais, através da simples passagem de uma instrução ao kernel durante o processo de boot. Essa tarefa pode ser realizada adicionando a seguinte linha  no arquivo de configuração do GRUB que fica localizado em /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0

Obs.: Reparem que em distribuições desktop é provável que a opção "quiet splash" esteja presente para que o usuário, durante o processo de boot, não tenha contato direto com as várias informações de inicialização do sistema, sendo que, ao invés disso, o usuário visualiza na tela uma imagem de inicialização (splash). Se for esse o caso, basta adicionar o parâmetro net.ifnames na sequência, depois de um espaço e dentro das aspas.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash net.ifnames=0"

Para que as alterações no arquivo de configuração do GRUB tenham efeito a partir do próximo boot, é necessário digitar update-grub. Façam seus testes...

sexta-feira, 16 de outubro de 2015

TACACS+ na Autenticação Centralizada de Dispositivos Cisco

Olá Pessoal.

A autenticação de usuários em dispositivos Cisco pode ser realizada através de uma base local de usuários que fica distribuída em cada uma das caixas ou através de uma base centralizada na rede via servidor TACACS+ (Terminal Access Controller Access Control System Plus). O TACACS+ é um protocolo de segurança utilizado para controlar os usuários que tentam se autenticar em roteadores ou switches da Cisco (e de outros fabricantes). Ao acessar uma caixa da rede, o usuário é conectado previamente a um servidor centralizado para fins de identificação e autorização das credenciais. Se autorizado, então o servidor TACACS+ encaminha as informações de login para a caixa remota que solicitou a autenticação.

A solução comercial oficialmente recomendada pela Cisco que implementa as funcionalidades de um servidor TACACS+ é o Cisco Secure Access Control System (ACS). Uma alternativa gratuita e que pode ser instalada no Linux é a ferramenta TAC_Plus (pacote tacacs+ no Debian). Neste artigo irei detalhar os passos necessários para configurar um servidor TACACS+ no Linux Debian e também como configurar as caixas Cisco para que o processo de autenticação seja centralizado através da comunicação com o servidor. A topologia proposta é bastante simples e pode ser observada na figura abaixo, sendo que o laboratório pode ser reproduzido no GNS3 em conjunto com o VirtualBox.


A primeira etapa consiste na instalação do pacote tacacs+ para que o Linux Debian possa ser posteriormente configurado como servidor TACACS+ na rede. Essa tarefa é simples através do APT.

root@tacacs:/# apt-get install tacacs+

Depois de instalado o pacote tacacs+, o arquivo de configuração principal do servidor TACACS+ fica armazenado em /etc/tacacs+/tac_plus.conf. Nas configurações abaixo definiremos uma chave de verificação do servidor denominada "CHAVE" e criaremos dois perfis, sendo um com privilégio administrativo de nível 15 (grupo "admin") e outro com privilégio de execução de nível 7 (grupo "user"). Na sequência, criaremos o usuário "shbbrito" no grupo "admin" e definiremos sua senha que deve ser informada de maneira cifrada. 

###--- em /etc/tacacs+/tac_plus.conf

accounting file = /var/log/tac_plus.acct

key = "CHAVE"

group = "admin"
{
  default service = permit
service = exec
{
priv-lvl = 15
idletime = 10
timeout  = 60
}
}

group = "user"
{
default service = deny
service = exec
{
priv-lvl = 7
idletime = 10
timeout  = 30
}
}

user = "shbbrito"
{
name = "Samuel Henrique Bucke Brito"
member = "admin"
login = des "1oV3QcqhpSN2w"
}


Obs.: Para gerar a senha cifrada pode ser utilizado o aplicativo tac_pwd. Ao digitar tac_pwd no shell, será necessário informar a senha para que o aplicativo possa fazer a cifragem e trazer seu resultado na tela. Neste exemplo, utilizamos a senha "SENHA" que equivale a "1oV3QcqhpSN2w".

Feito isso o servidor TACACS+ já está devidamente configurado no Linux Debian.
Para inicializar o serviço, basta digitar:

root@tacacs:/# service tacacs_plus start
[ OK ] tacacs_plus.service: TACACS+ authentication daemon

Agora que o servidor TACACS+ está operacional na rede, as caixas Cisco (roteadores e switches) devem ser configuradas para fazer a autenticação via TACACS+. Essa configuração é rápida e os comandos necessários para fazê-lo são listados abaixo, com destaque em amarelo para as informações do IP do servidor e a respectiva key que configuramos anteriormente.

Roteador(config)# aaa new-model
Roteador(config)# aaa authentication login default group tacacs+ local
Roteador(config)# aaa authorization exec default group tacacs+ local
Roteador(config)# tacacs-server host 192.168.221.1
Roteador(config)# tacacs-server key CHAVE

Façam seus testes...

Samuel.

segunda-feira, 12 de outubro de 2015

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.

domingo, 4 de outubro de 2015

Anúncio de Servidores DNS em Roteadores Linux (RDNSS)

Olá Pessoal.

Vamos a uma dica rápida sobre a autoconfiguração SLAAC do IPv6...

Recentemente escrevi um artigo intitulado "Anúncio de Prefixos IPv6 em Roteadores Linux" explicando o processo de instalação do pacote RADVD no Linux para fazer o anúncio dos prefixos IPv6 para toda uma rede local (link) através da autoconfiguração de endereços denominada SLAAC. No Linux o RADVD permite o envio periódico das mensagens ICMPv6 Tipo 134 (RA) para todos os clientes através do endereço ff02::1 (multicast-all-nodes) com o anúncio dos prefixos configurados.

Ocorre que uma limitação bastante reconhecida da autoconfiguração SLAAC é que ela originalmente permitia apenas a autoconfiguração do prefixo da rede e do endereço de gateway (fe80 do roteador responsável pelos anúncios RA). De fato um recurso muito interessante, mas pouco útil na prática por não permitir a configuração de um ou mais endereços de servidores DNS para fazer a resolução de nomes no contexto da Internet. 

Essa limitação foi solucionada e revisada em 2010 com a publicação da RFC 6106, oportunidade em que o daemon RADVD do Linux passou a oferecer suporte à configuração de parâmetros adicionais que permitem anunciar também, além do prefixo e gateway, um ou mais servidores DNS para os clientes autoconfiguradores via SLAAC. A configuração em si é bastante simples, bastando adicionar a declaração de um bloco RDNSS (Recursive DNS Server) no arquivo de configuração /etc/radvd.conf, conforme observado na figura abaixo. Também pode ser declarado um bloco DNSSL (DNS Search List) para informar aos clientes o sufixo do domínio.


Agora sim a autoconfiguração SLAAC se torna mais atrativa no IPv6!
Façam seus testes...

Samuel. 

quarta-feira, 23 de setembro de 2015

Configuração de Registros IPv6 em Servidores DNS

Olá Pessoal.

No livro "IPv6 - O Novo Protocolo da Internet" explico ao leitor que uma particularidade do DNS é que, diferente do que acontece com outros serviços, não existe uma versão DNSv4 e outra DNSv6. O serviço DNS continua sendo o mesmo em execução nos servidores, o que muda na realidade é que existe uma nova classe de registros para IPv6 denominada AAAA (quad-A).

No IPv4 o mapeamento entre endereços v4 e nomes de domínio é realizado adicionando novas entradas A, procedimento detalhado em outro artigo intitulado "Servidor DNS no Sistema Operacional Linux". Ocorre que para endereços IPv6 essas entradas chamam AAAA, uma alusão ao fato de que os endereços v6 são quatro vezes mais extensos do que os endereços v4.

Este artigo tem por objetivo apresentar o processo de configuração de endereços IPv6 nas zonas direta e reversa de um servidor DNS baseado em Linux Debian rodando o Bind. As configurações estão baseadas na topologia abaixo, em que temos um servidor DNS primário (2001:db8:cafe::201) e outro secundário (2001:db8:cafe::202) responsáveis pelo domínio "nome.com.br" na rede 2001:db8:cafe:0::/64.




A primeira etapa consiste na instalação do pacote "bind9" para que o Linux possa ser posteriormente configurado como servidor primário DNS na rede. Essa tarefa é simples e rápida através do APT.

root@ns1:/# apt-get install bind9

Os arquivos de configuração ficam armazenados em "/etc/bind". No arquivo de configuração "/etc/bind/named.conf.local" são realizadas as primeiras configurações da zona direta de domínio (forward) e da zona reversa.

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

zone "nome.com.br"
{
type master;
file "/etc/bind/nome.com.br.forward";
allow-transfer { 2001:db8:cafe::202; };
};


zone "0.0.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa"
{
type master;
file "/etc/bind/nome.com.br.reverse.ipv6";
allow-transfer { 2001:db8:cafe::202; };
};

Para o exemplo da topologia apresentada neste artigo, a configuração do arquivo da zona direta deve ficar da seguinte maneira:

;--- /etc/bind/nome.com.br.forward
; BIND - Zona Direta (nome.com.br)
;---
$TTL    604800
@       IN      SOA     ns1.nome.com.br. root.nome.com.br. (
                        2014051801       ; Serial
                            604800       ; Refresh
                             86400       ; Retry
                           2419200       ; Expire
                            604800 )     ; Negative Cache TTL
;
@       IN     NS       ns1.nome.com.br.
@       IN NS ns2.nome.com.br.
;
host1   IN     AAAA     2001:db8:cafe::37
ns1 IN AAAA     2001:db8:cafe::201
ns2 IN AAAA 2001:db8:cafe::202
gateway IN AAAA     2001:db8:cafe::254

Outra observação importante diz respeito à entrada do endereço IPv6 reverso, aquele que faz a resolução inversa de endereços em nomes. O endereço reverso não pode ser abreviado, cada caractere é separado por ponto, ele é totalmente escrito de trás para frente e seu domínio raíz é ip6.arpa (RFC 3596). Por exemplo, veja nas configurações que a versão reversa do prefixo 2001:db8:cafe:0::/64 é 0.0.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa, enquanto que o mapeamento reverso (PTR) do host 2001:db8:cafe:0::1 na zona reversa do prefixo anterior seria:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0     IN     PTR     host.nome.com.br.

Obs.: Nesse sentido, de fato a configuração de DNS para endereços IPv6 ficou mais complicada, não porque seja diferente do processo de configuração de endereços IPv4, mas só porque os endereços são mais complexos.

A configuração do arquivo de zona reversa ficaria da seguinte maneira:

;--- /etc/bind/nome.com.br.reverse.ipv6
; BIND - Zona Reversa IPv6 (nome.com.br)
;---
$TTL 604800
@ IN SOA ns1.nome.com.br. root.nome.com.br. (
2015091802 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@  IN   NS   ns1.nome.com.br.
@  IN   NS   ns2.nome.com.br.
;
7.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR   host1.nome.com.br.
1.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR   ns1.nome.com.br.
2.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR   ns2.nome.com.br.
4.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR   gateway.nome.com.br.

Antes de tentar inicializar o serviço é importante fazer uma verificação de erros de sintaxe nos arquivos de configuração através das ferramentas named-checkconf e named-checkzone. Se algum erro for indicado, verifique novamente os arquivos.

root@ns1:/# named-checkconf /etc/bind/named.conf.local
root@ns1:/# named-checkzone nome.com.br /etc/bind/nome.com.br.forward
root@ns1:/# named-checkzone 0.0.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa /etc/bind/nome.com.br.reverse.ipv6

Por fim, depois de configurado o servidor, basta iniciar o serviço para validar todas as configurações realizadas. A partir de agora os clintes da rede já podem utilizar o servidor de nomes interno, algo ainda mais importante no contexto do IPv6 em que os endereços são mais complexos. 

root@ns1:/# service bind9 start
ok ] Starting domain name service...: bind9.

No servidor secundário basta configurar o arquivo named.conf.local da maneira abaixo que os arquivos das zonas direta e reversa serão transferidos automaticamente a partir do servidor primário:

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

zone "nome.com.br"
{
type slave;
file "/etc/bind/nome.com.br.forward";
masters { 2001:db8:cafe::201; };
};


zone "0.0.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa"
{
type slave;
file "/etc/bind/nome.com.br.reverse.ipv6";
masters { 2001:db8:cafe::201; };
};

Façam seus testes...

Samuel.

sexta-feira, 18 de setembro de 2015

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. 




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.

quarta-feira, 9 de setembro de 2015

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.