Mostrando postagens com marcador IPv6. Mostrar todas as postagens
Mostrando postagens com marcador IPv6. Mostrar todas as postagens

sexta-feira, 9 de fevereiro de 2018

Webcast Prático de IPv6 na Comunidade de Suporte Cisco

Olá Pessoal,

A convite da Cisco, nessa semana (07/fev) ministrei um webcast prático sobre configuração do IPv6 em roteadores Cisco. O evento foi transmitido ao vivo para os membros da comunidade de suporte, parceiros oficiais e funcionários da Cisco. 


Na agenda do evento foram abordados os seguintes conteúdos:


  • Autoconfiguração SLAAC do IPv6
  • Sub-Redes IPv6 em Links Ponto-a-Ponto
  • Roteamento IPv6
  • Comandos de Troubleshoot do IPv6
  • Laboratório Prático


No link abaixo vocês podem acessar a página do evento na Comunidade de Suporte Cisco e em breve a gravação do webcast será disponibilizada para todos. 


Para aqueles interessados em estudar mais detalhes sobre IPv6, recomendo a leitura do meu livro intitulado "IPv6 - O Novo Protocolo da Internet" que está disponível em formatos impresso e digital nas principais livrarias e lojas eletrônicas do Brasil. Para mais informações, basta acessar a página da editora:


Samuel.

terça-feira, 7 de junho de 2016

Boas Práticas de Filtragem BGP em IPv4 e IPv6

Olá Pessoal,

Este artigo tem por objetivo chamar a atenção para algumas recomendações e exemplos de boas práticas de filtragem de prefixos no BGP que são de grande interesse para aqueles responsáveis por um AS e que queiram impedir o recebimento de rotas inesperadas que sequer deveriam existir na Internet, mas que podem aparecer em decorrência de erros de configuração ou mesmo de ataques. A topologia abaixo é bastante simples, mas suficiente para exemplificar as configurações deste artigo.

Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv4 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| 0.0.0.0      /08 | Rede Zero     | 6890 |
| 10.0.0.0     /08 | Privado       | 1918 |
| 100.64.0.0   /10 | CGNAT         | 6598 |
| 127.0.0.0    /08 | Loopback      | 6890 |
| 169.254.0.0  /16 | Link Local    | 3927 |
| 172.16.0.0   /12 | Privado       | 1918 |
| 192.0.0.0    /24 | IETF          | 6890 |
| 192.0.2.0    /24 | Documentação  | 5737 |
| 192.168.0.0  /16 | Privado       | 1918 |
| 198.18.0.0   /15 | Benchmark     | 2544 |
| 198.51.100.0 /24 | Documentação  | 5737 |
| 203.0.113.0  /24 | Documentação  | 5737 |
| 224.0.0.0    /04 | Multicast     | 5771 |
| 240.0.0.0    /04 | Classe E      | 1700 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. É comum utilizar prefix-list para esse fim pela flexibilidade de informar não apenas os prefixos exatos, mas também uma faixa de prefixos que sejam menores ou igual (le) do que determinado valor de referência. A última regra permite o recebimento de qualquer prefixo menor do que /24 (0.0.0.0/0 le 24), uma prática recomenda porque impede o recebimento de anúncios fragmentados que sejam maiores do que /24. Depois de criar a lista em R1, é necessário aplicá-la na entrada da vizinhança BGP com R4.

!-- Criação do Filtro via Prefix-List
R1(config)# ip prefix-list FILTRO-ENTRADA deny   0.0.0.0/8       le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   10.0.0.0/8      le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   100.64.0.0/10   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   127.0.0.0/8     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   169.254.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   172.16.0.0/12   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.0.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.2.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.168.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.18.0.0/15   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.51.100.0/24 le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   203.0.113.0/24  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   224.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   240.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA permit 0.0.0.0/0       le 24

!-- Aplicação do Filtro no Vizinho eBGP
R1(config)# router bgp 100
R1(config-router)# neighbor 203.0.113.2 remote-as 200
R1(config-router)# neighbor 203.0.113.2 prefix-list FILTRO-ENTRADA in
R1(config-router)# end
R1# clear bgp all 200 soft

É interessante aproveitar o assunto e fazer um paralelo com esse mesmo procedimento no contexto do protocolo IPv6. Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv6 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| ::          /0   | Default       |      |
| ::          /128 | Sem Endereço  | 4291 |
| ::1         /128 | Loopback      | 4291 |
| ::ffff:0:0  /96  | IPv4 Mapeado  | 4291 |
| 0100::      /64  | Descarte      | 6666 |
| 2000::      /3   | Global        | 3587 |
| 2001::      /32  | Teredo        | 4380 |
| 2001:10::   /28  | ORCHID        | 4843 |
| 2001:db8::  /32  | Documentação  | 3849 |
| 2002::      /16  | 6to4          | 3056 |
| fc00::      /7   | Unique Local  | 4193 |
| fe80::      /10  | Link-Local    | 4291 |
| ff00::      /8   | Multicast     | 4291 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA-v6 em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. Observem nos comandos abaixo que nem todas as redes reservadas da tabela acima aparecem explicitamente nas regras, já que a sequência de permissões e negações apresentada é suficiente para garantir a filtragem delas. Com base no filtro abaixo, somente são permitidos prefixos IPv6 iguais ou menores do que /48, uma boa prática para evitar o recebimento de prefixos fragmentados.

ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001:db8::/32  le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2001::/32
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001::/32      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2002::/16   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2002::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   3ffe::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2000::/3       le 48   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   ::/0           le 128

Caso o laboratório estivesse configurado com endereços IPv6, essa prefix-list poderia ser aplicada em um vizinho eBGP (2001:db8:cafe::40) através dos comandos abaixo. Uma diferença no contexto do IPv6 é que as políticas do BGP devem ser aplicadas no sub-modo de configuração da address-family IPv6. O leitor interessado na configuração de BGP através de IPv6 pode recorrer ao laboratório 34 do livro ou mesmo ao artigo intitulado "Peering IPv6 no Roteamento BGP".

!-- Exemplo de Aplicação do Filtro na Address Family IPv6
R1(config)# ipv6 unicast-routing
R1(config)# router bgp 100
R1(config-router)# neighbor 2001:DB8::2 remote-as 200
R1(config-router)# address-family ipv6 unicast
R1(config-router-af)# neighbor 2001:DB8::2 prefix-list FILTRO-ENTRADA-v6 in
R1(config-router-af)# neighbor 2001:DB8::2 activate

Há várias fontes de distribuição de filtros pradrões na Internet que tem por objetivo tornar a Internet um espaço mais seguro. Uma fonte interessante é do Team Cymru que atualiza sua relação de prefixos a cada 4 horas e que contempla, inclusive, aqueles prefixos alocados às  autoridades regionais da Internet (RIR) que ainda não foram atribuídos para nenhum AS. Vale à pena conferir o link abaixo...


Façam seus testes...

Samuel.

terça-feira, 2 de fevereiro de 2016

Rotas Locais de Host em Roteadores Cisco

Olá Pessoal,

É comum que muitos ainda não estejam familiarizados com as rotas locais de host (L), uma vez que a inserção desse tipo de rota na tabela de roteamento é relativamente nova, sendo automaticamente inserida a partir da versão 15 do IOS. De maneira bastante objetiva, uma rota local do tipo L nada mais é do que o próprio endereço IP configurado em uma determinada interface de rede diretamente conectada no roteador. A rota local aparece como um endereço /32 no IPv4 e um endereço /128 no IPv6, ou seja, equivale exatamente a um endereço IP, em contraste às demais rotas que equivalem a uma sub-rede.

Até a versão 12 do IOS, cada interface de rede configurada e ativada com um endereço IP qualquer implicava na inserção automática de uma rota diretamente conectada (do tipo C) equivalente ao prefixo da sub-rede na qual o endereço pertencia. Por exemplo, se a interface f0/1 fosse configurada com o endereço 203.0.113.1/30, isso implicaria na inserção automática de uma rota diretamente conectada (C) associada com a rede 203.0.113.0/30 através dessa interface f0/1, conforme pode ser observado na figura abaixo.


Ocorre que a partir do IOS 15, a configuração de uma interface implica na inserção da rota diretamente conectada (C) associada ao prefixo da sub-rede e também de outra rota local (L) associada com o próprio endereço IP configurado na interface, ambas com distância administrativa (AD) igual a 0. A diferença entre essas duas rotas é que as redes diretamente conectadas são redistribuídas entre protocolos de roteamento, enquanto que as rotas locais não são redistribuídas porque interessam apenas localmente. Por exemplo, se a interface g0/1 for configurada com o endereço 203.0.113.1/30, isso implicará na inserção automática de uma rota diretamente conectada (C) associada com a rede 203.0.113.0/30 através dessa interface g0/1, além de outra rota local (L) associada com o endereço de host 203.0.113.1/32 configurado na própria interface g0/1, conforme observado na figura abaixo.


No contexto específico do IPv6, diferente do IPv4, as rotas locais sempre existiram, algo que alguns já devem ter reparado há algum tempo. A propósito, cabe destacar que as tabelas de roteamento IPv6, independente de interfaces configuradas, automaticamente contém a rota local FF00::/8 para assegurar as funcionalidades de multicast.


Com as rotas locais fica mais fácil observar os endereços configurados nas interfaces do roteador através da própria tabela de roteamento, sem ter que utilizar outros comandos de visualização das configurações das interfaces. Na realidade, o objetivo técnico por trás da instalação automática das rotas locais nas tabelas de roteamento a partir do IOS 15 é otimizar o encaminhamento CEF de pacotes que sejam destinados a alguma das interfaces do próprio roteador. 

Façam seus testes...

Samuel.

segunda-feira, 18 de janeiro de 2016

Palestra na Campus Party Brasil (CPBR9)

Olá Pessoal,

Nos dias 26 a 31 de janeiro ocorrerá a nona edição da Campus Party Brasil (CPBR9), o maior evento do mundo em tecnologia, principalmente nas áreas de inovação, criatividade, ciência, empreendedorismo e entretenimento digital. Em 2016 o evento será realizado no Centro de Exposição Anhembi e, assim como nos anos anteriores, haverá um palco com temática Segurança & Redes sob curadoria do NIC.br.




Pelo terceiro ano consecutivo, a convite dos colegas do NIC.br, fui escalado para participar de uma palestra e para ministrar um workshop, ambos no dia 29/jan (sexta-feira), oportunidade em que falarei sobre certificações da Cisco. A palestra ocorrerá no período da manhã e será uma mesa redonda sobre certificações em conjunto com outros especialistas em roteadores. Cada palestrante terá 15 minutos para falar da importância da sua certificação no mercado de trabalho. Como fazer uma certificação e se preparar para os exames serão assuntos abordados na discussão. No período da tarde serão realizados workshops em espaço reservado com bancadas largas, pontos de rede e tomadas para 80 alunos, na sua maioria jovens curiosos. Abaixo trago alguns detalhes do workshop que irei ministrar:

Título: Roteamento Dinâmico e IPv6 no Currículo Cisco® CCNA® 

Descrição da Atividade:
Está interessado em começar seus estudos para ser aprovado no exame CCNA, uma das certificações mais reconhecidas da área de redes? Além disso, que tal aprender algumas práticas relacionadas ao "novo" protocolo IPv6? Pois bem, essa é a oportunidade de participar de um workshop que consiste na resolução de um dos laboratórios do livro "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes", de autoria do palestrante, com foco na configuração de roteamento IPv6 em roteadores Cisco. A propósito, alguns participantes do workshop serão premiados com um dos livros do autor! :-)

Link p/ Inscrição no Workshop: http://goo.gl/bY3dzF

Espero vocês campuseiros no evento!

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.

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.

quarta-feira, 10 de junho de 2015

Livro de Laboratórios IPv6 do NIC.br

Olá Pessoal,


Recentemente a equipe IPv6.br do NIC.br lançou o livro intitulado "Laboratório de IPv6", pela Editora Novatec, mesma editora dos meus livros, que acaba de ser disponibilizado gratuitamente para download sob licença Creative Commons. Já conheço o conteúdo dos laboratórios práticos trazidos na obra há alguns anos, ainda da época em que estive envolvido com os colegas do NIC.br no curso EAD de IPv6 (como aluno e monitor). Na realidade, ainda antes disso o colega Moreiras (IPv6.br) já havia comentado comigo do seu interesse em publicar esse livro gratuitamente. Faço questão de reafirmar a qualidade técnica do material e aproveito para retransmitir abaixo a mensagem original da equipe IPv6.br sobre o lançamento da obra:




Caros,

Buscando preencher uma lacuna na formação do profissional de redes o NIC.br acaba de lançar o livro *Laboratório de IPv6: Aprenda na Prática Usando um Emulador de Redes*Publicado pela Novatec Editora, a versão impressa pode ser adquirida em http://novatec.com.br/livros/labipv6/ ou nas principais livrarias. Há também a versão digital que pode ser obtida gratuitamente em http://lab.ipv6.brEssa publicação contém roteiros de experimentos práticos, para serem realizados com o auxílio do emulador de redes CORE, que é um software livre e pode ser obtido gratuitamente no site do livro: http://lab.ipv6.br.

Há experimentos sobre: funcionalidades básicas do IPv6; autoconfiguração de endereços e DHCPv6; configuração de servidores DNS, HTTP, proxy e de arquivos; configuração de firewall e IPSEC; técnicas de transição 6in4, GRE, DS-LITE, NAT64 e 464XLAT; e roteamento OSPF e BGP. Não é um livro para ler apenas, você deve praticar para aprender!

A equipe do IPv6.br, que é a iniciativa do NIC.br para a disseminação do IPv6, foi quem preparou e aperfeiçoou esses experimentos. Eles são utilizados em cursos de formação com muito sucesso. Centenas de alunos e profissionais já seguiram esses mesmos roteiros, que comprovadamente ajudam a entender a forma como o IPv6 funciona, o que é diferente do protocolo antigo e o que não é, e como realizar configurações na prática em uma série de situações. Os experimentos proporcionam uma base prática muito boa e ajudarão muito no seu dia a dia!

Dúvidas e comentários podem ser enviados para ipv6@nic.br

[]s
Equipe IPv6.br


Para aqueles que têm interesse em se aprofundar nos conceitos do "novo" protocolo IPv6 e de várias das tecnologias abordadas nos laboratórios práticos deste livro, recomendo meu livro intitulado "IPv6 - O Novo Protocolo da Internet" como leitura complementar. O leitor pode encontrar mais informações sobre meu livro de IPv6 nos links abaixo:

http://labcisco.blogspot.com.br/2013/07/lancamento-do-livro-de-ipv6.html
http://labcisco.blogspot.com.br/2013/07/livro-oficial-de-certificacao-ipv6-no.html

Aproveito para registrar meus parabéns aos colegas da equipe IPv6.br. 

Samuel.

terça-feira, 6 de janeiro de 2015

Aspectos de Segurança do "Novo" Protocolo IPv6

Olá Pessoal.

O sexto capítulo do meu livro intitulado "IPv6 - O Novo Protocolo da Internet" é dedicado aos aspectos de segurança do protocolo IPv6. Logo no início desse capítulo explico ao leitor que existe uma "promessa folclórica" de que o IPv6 é um protocolo mais seguro do que o seu antecessor IPv4, porque ele foi projetado na década de 1990, período em que muitas deficiências e vulnerabilidades do IPv4 eram amplamente conhecidas pela comunidade técnica. Por ser mais recente, realmente o IPv6 teve a oportunidade de corrigir várias dessas vulnerabilidades, no entanto, eu diria que ainda é equivocado afirmar categoricamente que o IPv6 é mais seguro do que o IPv4. Eu prefiro pensar que o IPv6 tem potencial para ser mais seguro do que o IPv4.


No entanto, não podemos ser passionais e ignorar o fato de que o IPv6 é um protocolo apenas recente operacionalmente, o que torna sua adoção ainda pouco representativa atualmente. Isso quer dizer que o IPv6, por ser "novo", traz consigo várias funcionalidades nebulosas em relação ao seu modo de operação e, à medida que sua adoção crescer nas empresas e na Internet, fatalmente surgirão novas modalidades de ataques e novas vulnerabilidades que sequer existiam no IPv4.

Do ponto de vista arquitetural, o IPv6 é realmente mais robusto do que o IPv4, afinal, não podemos esquecer que segurança não era um requisito de projeto na concepção do IPv4, ao contrário do processo de concepção do IPv6 em que segurança foi um dos critérios mais relevantes na escolha da proposta que daria origem ao chamado IPng, ou IP de próxima geração, que posteriormente foi denominado IPv6. Tanto é que o protocolo IPSec foi criado para o IPv6 e somente depois foi aproveitado para operar sobre o IPv4. 

Essa afirmação "folclórica" de que o IPv6 é um protocolo mais seguro vem do fato de ele possuir suporte nativo ao IPSec. Por isso, muitas pessoas pensam que todo o tráfego v6 sempre é criptografado automaticamente sem nenhuma intervenção ou configuração do administrador - o que NÃO é verdade! O fato de IPSec estar embutido nos dispositivos (suporte nativo) não quer dizer que a solução de segurança seja autoconfigurada. Ao contrário, as principais soluções de segurança, a exemplo de autenticação e criptografia, deverão ser manualmente configuradas pelo administrador, de maneira bastante similar ao que já é feito atualmente com o IPv4. 

No decorrer do livro essa discussão é aprofundada, oportunidade em que apresento um tópico delicado e muitas vezes polêmicos: o fim do NAT no IPv6! ;-) Além dessa discussão, no livro apresento ao leitor os principais ataques conhecidos, bem como os respectivos mecanismos de defesa recomendados para mitigar esses ataques. Os links abaixo direcionam vocês para outros artigos que escrevi no blog e que trazem vários exemplos de configurações de segurança para IPv6 em roteadores e também em sistemas operacionais:


Por fim, aproveito a oportunidade para compartilhar um vídeo recém produzido pelos colegas do NIC.br, em que essa discussão é abordada em apenas 10 minutos! Vale a pena conferir...

Samuel.

terça-feira, 4 de novembro de 2014

Diferenças na Fragmentação de Pacotes em IPv4 e IPv6

Olá Pessoal.

No meu livro intitulado "IPv6 - O Novo Protocolo da Internet", especificamente na sub-seção dedicada aos chamados cabeçalhos de extensão (figura), explico ao leitor que uma das diferenças entre o tradicional IPv4 e o "novo" IPv6 está no processo da fragmentação de pacotes. Essa discussão é uma boa oportunidade para compartilhar um excelente vídeo recém publicado pelo NIC.br que explica essa diferença de maneira bem ilustrada.


No IPv4, a funcionalidade de fragmentação dos pacotes era responsabilidade do próprio cabeçalho principal por meios dos campos: (i) Identificação, (ii) Flags e (iii) Fragmentação. Acontece que a fragmentação somente é necessária quando um pacote se torna maior do que o limite máximo permitido pela tecnologia em operação, o que é denominado MTU (Maximum Transmission Unit).

Um diferencial vantajoso do IPv6 é que a fragmentação não ocorre mais nos dispositivos intermediários (roteadores), mas somente na origem do tráfego. Quando um roteador determina que um pacote ultrapassou o MTU, ele retorna uma mensagem para a origem ficar ciente de que deve fragmentar os pacotes. A partir de então a origem faz uma fragmentação dos pacotes e utiliza o cabeçalho de extensão denominado Fragmentation para sinalizar o vínculo entre os pacotes fragmentados e, assim, o destinatário fica ciente do processo de fragmentação realizado pela origem que consegue recuperar o pacote original.  

Samuel.

sexta-feira, 5 de setembro de 2014

CGNAT na Transição IPv6: Solução ou Vilão?

Olá Pessoal.

O Carrier Grade NAT (CGN) ou Large Scale NAT (LSN), definido na RFC 6264, é uma técnica de tradução de grande porte que vem sendo praticada por algumas operadoras de telecomunicações que não possuem mais endereços IPv4 disponíveis e, portanto, se encontram em situação crítica. Essa prática consiste em aplicar o NAT na própria rede da operadora, antes mesmo de chegar ao usuário, entregando para seu cliente um endereço privado, conforme ilustrado na figura abaixo.



Se o NAT (também chamado de NAT44), por si só, já é uma agressão aos princípios arquiteturais da Internet por quebrar o modelo fim-a-fim e tornar o funcionamento de algumas aplicações mais complexo, o CGN é ainda mais grave porque implica na prática daquilo que chamamos de NAT444 ou pejorativamente de "NAT do NAT".

Um primeiro problema do NAT444 é o uso de endereços privados 10/8, 172.16/12 e 192.168/16 da RFC1918, afinal, existe a possibilidade de haver conflito entre os planos de endereçamento utilizados nas redes internas dos clientes e das operadoras. Para "sanar" esse problema e evitar o conflito de endereços, a RFC6598 reserva o prefixo 100.64.0.0/10 como sendo uma faixa privada não roteável na Internet e de uso exclusivo das operadoras. 

Ao se quebrar o modelo fim-a-fim, perde-se a possibilidade de alcançabilidade "direta" entre os pontos (em layer-3), o que torna o gerenciamento e a configuração da rede mais complexa. No entanto, a empresa (ou usuário residencial) ainda tem autonomia para criar políticas de redirecionamento (port-forwarding) através da escrita de regras em seu roteador de borda, permitindo que seu único endereço público possa direcionar o usuário externo às suas aplicações internas que estão escondidas da Internet por obscuridade. 

Com o NAT444, essa autonomia deixa de existir, porque o endereço público que tem alcançabilidade na Internet é de posse da operadora apenas, não mais da empresa. Dessa forma, os administradores da rede vão depender da ação conjunta das operadoras para que as políticas de redirecionamento de tráfego sejam escritas nos próprios roteadores da operadora, o que traz consigo vários problemas para os clientes e também para as operadoras.

Essa prática literalmente acaba com a autonomia da empresa/usuário em criar suas políticas de redirecionamento, afinal, ela fica totalmente dependente da operadora para "auxiliar" nesse processo, o que compromete a flexibilidade, escalabilidade e segurança. Cabe destacar que essa técnica é ruim, inclusive para a operadora, afinal, "administrar" as políticas individuais dos seus clientes é oneroso.

Além disso, para aqueles que sempre defenderam o NAT como medida de segurança (o que ele nunca foi, já que NAT foi criado para economizar IPs), a segurança do ambiente fica comprometida. Com CGNAT a operadora conhece detalhadamente quais portas/serviços estão em execução nos servidores privados, ou seja, é o fim da obscuridade para aqueles que defendiam essa prática e o começo da "iluminação absoluta"!

Essa discussão é aprofundada no meu livro intitulado "IPv6 - O Novo Protocolo da Internet", por isso sugiro sua leitura para os interessados no assunto. Por fim trago mais um vídeo produzido pelo NIC.br, dessa vez apresentando o CGNAT.

Samuel.


quarta-feira, 3 de setembro de 2014

Bem-Vindo IPv6, "Adeus" IPv4...

Olá Pessoal.

No livro "IPv6 - O Novo Protocolo da Internet" explico ao leitor que a transição completa até chegarmos à Internet puramente IPv6 não acontecerá da noite para o dia e será um processo moroso em virtude da ampla disseminação do IPv4. Apesar de o IPv6 ser a evolução natural da Internet e mesmo as pessoas tendo noção da importância em adotá-lo para viabilizar o crescimento da Internet, é inegável que o grau de penetrabilidade do IPv4 no mercado acaba criando uma zona de conforto que, aliada à escassez de profissionais preparados para lidar com o IPv6 e ao custo de investimento na aquisição de novos equipamentos, implicam nessa morosidade no processo de transição.

Até que essa transição seja concretizada, o que pode levar alguns anos, provavelmente mais que uma década, teremos duas "ilhas" da Internet operando em paralelo, uma baseada em IPv4 e outra em IPv6. Para que o usuário não seja prejudicado em relação à sua percepção do conteúdo existente na Internet, será crucial a adoção de mecanismos de transição que viabilizem a comunicação entre essas duas ilhas, o que não é uma tarefa simples, porque, ao contrário do que muitos pensam, ambos os protocolos não são diretamente compatíveis entre si.

Às técnicas que viabilizam a interoperabilidade entre as "ilhas" IPv4 e IPv6 e que, portanto, mantêm a Internet como sendo uma só para os usuários, apesar da complexidade da coexistência entre os dois protocolos, damos o nome de mecanismos de transição. Existe uma grande diversidade de mecanismos para tornar possível a interoperabilidade IPv4-IPv6, no entanto, de maneira geral, todos eles podem ser classificados em três categorias: (1) pilha-dupla, (2) tunelamento e (3) tradução

Os curiosos que ainda não têm conexão IPv6 nativa disponibilizada pelos seus provedores, podem optar pelos serviços gratuitos de Tunnel Broker oferecidos por empresas provedoras de conectividade. Os dois principais serviços de tunnel broker são da Hurricane Electric e da SixXS. O único que possui ponto de presença (PoP) no Brasil é o SixXS, oferecido de maneira colaborativa por um conjunto de empresas e que tem ampla presença em todo o mundo. O PoP da SixXS no Brasil é responsabilidade da CTBC, uma empresa do grupo Algar Telecom, localizada em Uberlândia (MG). Esse PoP provê túneis com prefixos /64, que são gerados a partir do prefixo 2001:1291:200::/48 .




Essa discussão é aprofundada com grande nível de detalhamento no livro, inclusive com exemplos de configuração. O fato de existir essa diversidade de técnicas possíveis para auxiliar no processo de transição torna difícil para os profissionais da área a tarefa de optar por uma ou outra, até mesmo porque cada ambiente possui suas particularidades. Para finalizar, aproveito a oportunidade para compartilhar mais uma série de vídeos produzida pelo NIC.br que discorre sobre esse assunto. Por enquanto está disponível apenas a primeira parte, por isso estarei incorporando as demais partes nesse post à medida que forem disponibilizadas. 

Acompanhem...






sexta-feira, 22 de agosto de 2014

Conceitos Básicos de Roteamento Interno e Externo

Olá Pessoal.

Novamente estou divulgando um novo vídeo produzido pelo NIC.br, dessa vez explicando os princípios mais básicos relacionados às técnicas de roteamento que são tão importantes na comunicação entre redes, seja no contexto de uma organização (IGP) ou mesmo na Internet (EGP). 


Aproveito a oportunidade para lembrar de outros dois artigos publicados no blog onde explico ao leitor como configurar roteamento estático no Linux em redes baseadas no tradicional IPv4 e também no IPv6. Além dos laboratórios com os procedimentos de configuração, também há a gravação de uma palestra prática que ministrei na Campus Party, a convite dos amigos do NIC.br, onde faço a configuração de roteamento estático IPv6 no Linux.
 

No meu livro intitulado "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes" existem vários laboratórios práticos que explicam os procedimentos de configuração de roteamento estático em roteadores Cisco, além dos principais protocolos de roteamento dinâmico, a destacar: RIP, OSPF e EIGRP (IGPs) e BGP (EGP). Também existe outro artigo que escrevi para o Blog IPv6.br do NIC.br em que discorro um pouco sobre os principais conceitos de roteamento, inclusive trazendo duas videoaulas de configuração de roteamento IPv6 em dispositivos Cisco.


Enfim, são vários os materiais de estudo para os interessados! ;-)

Samuel.