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:0::ffff:0001;
    } 

}

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.conf.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.

quinta-feira, 3 de setembro de 2015

Pontos de Troca de Tráfego na Internet do Brasil

Olá Pessoal.

Uma forma de promover o desenvolvimento da Internet em termos de conectividade e desempenho é através da implantação dos chamados Pontos de Troca de Tráfego (PTT), do inglês Internet eXchange Point (IXP). Por possuírem dezenas ou centenas de Sistemas Autônomos (membros) conectados, atualmente os PTTs têm um papel crítico no ecossistema da Internet. Os PTTs tiveram um papel muito importante na distribuição de tráfego durante a Copa do Mundo de 2014 e o esperado é que sejam importantes novamente durante os Jogos Olímpicos de 2016, uma vez que permitem uma melhor distribuição de tráfego nas proximidades do usuário final.

Origem dos PTTs na Internet

Desde 1987 até 1994 a operação do backbone da rede NSFNET era responsabilidade da National Science Foundation (NSF) que, a partir de 1992, deu início a um plano para transferir a operação do núcleo da Internet para o setor privado. Foi no contexto desse novo ecossistema comercial que surgiram três elementos importantes: (i) Network Service Providers (NSP), responsáveis pela operação do backbone; (ii) Network Access Points (NAP), para transportar tráfego entre os NSPs a partir de locais estratégicos nos EUA; e (iii) Routing Arbiter (RA), para coletar e propagar informações de roteamento nos NAPs (similar aos modernos Route Servers). A concepção dos PTTs nasceu ainda nessa época, uma vez que os NAPs foram criados para ser um ponto físico de conexão de vários NSPs. Ao longo dos anos os NAPs enfraqueceram porque eram mantidos por grandes operadoras que tinham interesses próprios, o que motivou a desconexão das demais operadoras. 

As grandes operadoras somente tinham interesse de se conectar diretamente (peering) com outras de mesmo nível, demonstrando pouco (ou nenhum) interesse no peering aberto com outras operadoras menores. Em 1999 a necessidade por circuitos ponto-a-ponto entre as grandes operadoras escalava linearmente e custava caro, além do fato de que algumas vezes as concessionários telefônicas levavam mais de um ano para entrar um circuito. Diante dessa situação as grandes operadoras perceberam que o estabelecimento de peering privado através de um PTT neutro era mais rápido e econômico, tornando esse modelo dominante na Internet atual. 

Como Funcionam os PTTs?

Por definição o PTT é uma infraestrutura compartilhada que é instalada em uma região para receber a conexão de Sistemas Autônomos (através de peering) com o objetivo principal de otimizar o desempenho da Internet ao manter a troca de tráfego mais localizada entre diferentes redes pertencentes a uma mesma região, diminuindo, assim, o número de saltos entre membros geograficamente próximos. 

Seu núcleo é bastante complexo em termos de quantidade de conexões porque hospeda centenas de membros, por isso requer equipamentos de alto desempenho capazes de processar altas taxas de pacotes por segundo (pps). Apesar dessa complexidade, sua arquitetura é simples de entender, uma vez que o o objetivo do PTT se resume a prover um ponto centralizado de conexão através de uma switching-fabric baseada em tecnologia Ethernet (camada 2), conforme observado na figura abaixo.




Uma vez fisicamente conectados no PTT, seus membros podem acordar em fazer o peering multilateral (aberto) com todos os demais membros ou o peering bilateral (privado) de natureza seletiva ou restritiva, sendo que as configurações para o anúncioe alcançabilidade de prefixos IP são realizadas por meio do protocolo BGP (RFC 4271), via sessão TCP na porta 179. Para minimizar a complexidade de configuração individual do peering entre todos os membros através de uma topologia full-mesh, são instalados elementros centrais denominados servidores de rotas (RS) na infraestrutura do PTT, de maneira que um Sistema Autônomo é capaz de trocar rotas com os demais membros através do estabelecimento de uma única sessão BGP com o RS (peering multilateral), conforme pode ser observado na figura acima.




PTTs na Internet do Brasil

O Brasil lidera a região da América Latina operando mais de metade de todos os PTTs do continente e segue um modelo de negócios interessante que pode insipirar outros países em desenvolvimento. No cenário nacional o projeto IX.br (também conhecido como PTTMetro) contempla todos os PTTs públicos em operação, sendo o PTT-SP o maior da América Latina com registros médios de troca de tráfego da ordem de 600 Gbps e picos de 800 Gbps. Atualmente o IX.br está entre os dez que mais trocam tráfego no mundo, sendo o quinto maior em número de participantes. A tabela abaixo traz uma síntese de alguns dos maiores PTTs públicos do mundo em que é possível observar o grau de relevância do IX.br.


Desde 2006 o Brasil saltou de apenas 4 PTTs para 25 em operação (vide mapa abaixo), com 16 novas localidades em estudo, especialmente nas regiões norte e centro-oeste que são mais carentes de conectividade. Segundo o NIC.br, atualmente há 45 candidatos interessados em hospedar os novos IXPs. O objetivo maior por trás do projeto de expansão do IX.br é melhorar o desempenho da Internet no país e atrair provedores de acesso e de conteúdo para essas áreas mais carentes de conectividade. 

Fonte: IX.br (http://ix.br)

O modelo de negócios do PTT pode ser de natureza privada (comum nos Estados Unidos) ou aberta (comum na Europa e no Brasil). Na maioria dos casos, inclusive no Brasil, o objetivo principal do PTT é prover um ambiente aberto e indiscriminatório de natureza pública para estimular a colaboração e melhorar a troca de tráfego, alavancando a qualidade da Internet na sua região de operação. 

Samuel.

Fonte: Samuel Henrique Bucke Brito, Mateus Augusto Silva Santos, Ramon dos Reis Fontes, Danny Alex Lachos Perez, Christian Esteve Rothenberg. "Anatomia do Ecossistema de Pontos de Troca de Trafego Publicos na Internet do Brasil"[Slides] In XXXIII Simposio Brasileiro de Redes de Computadores (SBRC). Vitoria, ES, Brazil. May 18-22, 2015.