Resumo
Depois de muita teoria no post anterior envolvendo RA – Router Advertisement, agora é a hora da diversão. Vamos analisar alguns cenários envolvendo diversas opções do RA. Apenas lembrando, o setup que vamos utilizar é o mesmo do post sobre KEA e DHCPv6, com o seguinte layout:
Cenário 1 – Sem radvd. Sem RA
.No cenário 1 vamos desabilitar o radvd no DHCP Server, nos certificar que Server B esta configurado para obter um endereço IPv6 por DHCPv6, e reiniciar a interface. Para que vejamos o que esta acontecendo, vamos utilizar tcpdump no DHCP Server, e verificar endereçamento IPv6 em Server B
# Em DHCP Server
systemctl stop radvd
# Em Server B, arquivo /etc/netplan/default.yaml
vlans:
vlan10:
id: 10
link: eth1
dhcp4: false
dhcp6: true
# Vamos verificar os pacotes que chegam em DHCP Server
tcpdump -i vlan10 -n
# Aplicamos a configuração em Server B
netplan try
# Podemos ver no log do DHCP Server que houve uma requisição DHCPv6
# e uma resposta
09:37:03.791040 IP6 fe80::20c:29ff:fe44:d8a2.546 > ff02::1:2.547: dhcp6 solicit
09:37:03.791578 IP6 fe80::20c:29ff:fe62:110a.547 > fe80::20c:29ff:fe44:d8a2.546: dhcp6 advertise
# Verificando qual IPv6 foi obtido em Server B
ip address show vlan10
4: vlan10@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0c:29:44:d8:a2 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fe44:d8a2/64 scope link
valid_lft forever preferred_lft forever
#### SEM IPV6 ATRIBUÍDO ??? ###Temos aqui uma situação que merece ser bem analisada, pois a princípio temos um erro. Configuramos nosso servidor ISC-KEA corretamente para DHCPv6, configuramos no netplan que o host deve consultar um servidor DHCPv6 para obter seu endereço, então, o que pode ter dado errado?
Bom, nada deu errado. Vejam a observação, obtida direto da fonte:
man systemd.network # Trecho relevante abaixo:
Note that DHCPv6 will by default be triggered by Router Advertisements, if reception is enabled, regardless of this parameter. By explicitly enabling DHCPv6 support here, the DHCPv6 client
will be started in the mode specified by the WithoutRA= setting in the [DHCPv6] section, regardless of the presence of routers on the link, or what flags the routers pass.
Resumindo, por padrão, o host irá consultar um servidor DHCPv6 apenas quando receber RA. O texto afirma sim que é possível alterar o parâmetro “WithoutRA”, mas isso esta fora do nosso escopo. Eu considero uma falha na verdade essa informação não estar clara na documentação do netplan, e nem haver nenhuma opção no netplan para alterar o parâmetro “WithoutRA”.
Ahh, mas houve uma consulta DHCPv6 e uma resposta. Sim, houve, mas vamos ver do que se tratava essa consulta:
Bem, nosso Server B requisitou algumas informações, mas não seu endereço IPv6.
Como falei, essa situação é um pouco delicada, se você ainda acha que é um erro, vamos forçar a consulta DHCPv6 manualmente, e analisar o que acontece.
Cenário 2 – Forçar DHCPv6 com dhclient
Bem, este cenário será bem simples, forçaremos a aquisição de um endereço IPv6 usando a ferramenta dhclient, e então analisaremos.
# Confirma que não há endereço IPv6 na vlan10
ip addr show vlan10
# Forçe a aquisição de um endereço IPv6 com:
dhclient -6 vlan10
# Confirma que há endereço IPv6 na vlan10
ip addr show vlan10
inet6 fd00:1:1:cafe:face::1568/128 scope global dynamic
# Temos um endereço IPv6, e vamos pingar nosso gateway
PING fd00:1:1:cafe::1(fd00:1:1:cafe::1) 56 data bytes
# Opa, sem resposta???
# Abra um tcpdump
tcpdump -i vlan10 -n
# Nem um pacote saindo? O que esta acontecendo?
Temos uma situação interessante aqui, não temos comunicação, e o Server B nem mesmo tenta enviar qualquer pacote. Isso tem uma explicação, e agora é sobre prefixos de rede. Antes, preste atenção na saída do comando “ip addr show”, e veja que o endereço entregue pelo DHCPv6 é um /128, conforme falamos aqui, esse é um comportamento normal do DHCPv6, mas porque isso impede qualquer comunicação?
O endereço /128 significa que Server B conhece apenas essa rede, no caso conhece APENAS seu próprio endereço IPv6, e nada mais. Vamos recordar os fundamentos de rede, pois quando um host tenta enviar pacotes na rede local, ele usa protocolos de camada 2 para obter o MAC do dispositivo destino, e OK.
Quando o destina é para outra rede, ele busca o MAC do gateway padrão e manda o pacote para ele. Vamos ver sua tabela de roteamento:
ip -6 route show
fd00:1:1:cafe:face::1566 dev vlan10 proto kernel metric 256 expires 29842sec pref medium
fd00:1:1:cafe:face::1568 dev vlan10 proto kernel metric 256 expires 29887sec pref medium
fe80::/64 dev vlan10 proto kernel metric 256 pref medium
# Veja que Server B não conheço nada além dele próprioBem, isso explica porque não conseguimos comunicação nem mesmo com o gateway, e também explica porque o cenário 1 não tem um resultado errado. No protocolo IPv6 a configuração via DHCPv6 é 100% dependente de RA, e veremos isso nos próximos cenários.
Cenário 3 – RA com M-Flag
Agora vamos ativar nosso radvd com uma configuração mínima em DHCP Server, e também instalar uma ferramenta bem útil para analisarmos RA. Mas antes, vamos liberar o endereço IPv6 que obtemos e apagar as informações da lease que obtemos anteriormente.
# Liberando a lease em Server B
dhclient -r -6 vlan10
# Removendo o arquivo de leases em Server B
rm /var/lib/dhcp/dhclient6.leases
# Instale o radvdump em Server B
apt-get install radvdump
# Confirme que não temos endereço IPv6 na interface
ip addr show vlan10
# Em Server B, abra outro terminal e deixe o comando aberto
radvdump
# No DHCP Server, arquivo /etc/radvd.conf
interface vlan10
{
// Habilita o RA na interface
AdvSendAdvert on;
// M-Flag habilitada
AdvManagedFlag on;
// Prefix a anunciar
prefix fd00:1:1:cafe::/64 {
// A-Flag desabilitada
AdvAutonomous off;
};
};
# Inicie o serviço em DHCP Server
systemctl start radvd.service
# Em Server B, confirme que obteve IPv6
ip addr show vlan10
inet6 fd00:1:1:cafe:face::15d1/128 scope global dynamic noprefixroute
# Verifique a tabela de roteamento
ip -6 route show
fd00:1:1:cafe:face::15d1 dev vlan10 proto kernel metric 256 expires 28486sec pref medium
fd00:1:1:cafe::/64 dev vlan10 proto ra metric 100 expires 86347sec pref medium
fe80::/64 dev vlan10 proto kernel metric 256 pref medium
default via fe80::20c:29ff:fe62:110a dev vlan10 proto ra metric 100 expires 1747sec pref medium
# Teste a conectividade
ping fd00:1:1:cafe::1 -c 4
PING fd00:1:1:cafe::1(fd00:1:1:cafe::1) 56 data bytes
64 bytes from fd00:1:1:cafe::1: icmp_seq=1 ttl=64 time=0.258 ms
64 bytes from fd00:1:1:cafe::1: icmp_seq=2 ttl=64 time=0.280 ms
64 bytes from fd00:1:1:cafe::1: icmp_seq=3 ttl=64 time=0.453 ms
64 bytes from fd00:1:1:cafe::1: icmp_seq=4 ttl=64 time=0.374 msBem, funcionou! Mas isso era o esperado, veja que agora não precisamos usar dhclient, Server B foi buscar informação de endereçamento no DHCPv6 graças ao RA, que esta com a flag M (Managed) habilitada. Também temos rota para o /64 do prefixo do IPv6 que obtemos, e, temos uma rota default???
Mas como, se não indicamos isso em nosso RA. Por favor nele, vamos ver o que o nosso radvdump capturou? Abaixo captura de um RA pelo radvdump, com algumas explicações:
# radvd configuration generated by radvdump 2.19
# based on Router Advertisement from fe80::20c:29ff:fe62:110a
# received by interface vlan10
#
interface vlan10
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
// Nossa M-Flag habilitada
AdvManagedFlag on;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
// Uhmmm, a linha abaixo indica que DHCP Server pode
// ser usado como gateway padrão
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
// Preferência de DHCP Server como gateway padrão
AdvDefaultPreference medium;
AdvSourceLLAddress on;
// Nosso estimado prefix
prefix fd00:1:1:cafe::/64
{
AdvValidLifetime 86400;
AdvPreferredLifetime 14400;
AdvOnLink on;
// A-Flag desabilitada
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
}; # End of interface definition
Vejam que o RA seguiu o que definimos no radvd, e o gateway seguiu o padrão, por isto vemos a rota padrão na saída de “ip -6 route show”
Cenário 4 – A-FLAG + M-Flag habilitadas, sem rota padrão
Agora
# Para o radvd no DHCP Server
systemctl stop radvd.service
# Edite /etc/radvd.conf conforme abaixo:
interface vlan10
{
AdvSendAdvert on;
AdvManagedFlag on;
AdvDefaultLifetime 0;
prefix fd00:1:1:cafe::/64 {
AdvAutonomous on;
};
route 2000::/3 { };
};
# Liberando o IPv6 em Server B, deve ser com netplan
# pois o IPv6 não foi obtido com dhclient
netplan try
# Confirme que não temos rotas
ip -6 route show
# Confirme que não temos endereço IPv6 na interface
ip addr show vlan10
# Pare o radvdump, limpe a tela e rode radvdump novamente
clear
radvdump
# Confirmado que não temos endereço IPv6 nem rotas, e estamos
# com radvd preparado, vamos iniciar o radvd no DHCP Server
systemctl start radvd.service
# Em Server B, vamos confirmar endereços IPv6
ip addr show vlan10
inet6 fd00:1:1:cafe:face::15d1/128 scope global dynamic noprefixroute
inet6 fd00:1:1:cafe:20c:29ff:fe44:d8a2/64 scope global dynamic mngtmpaddr noprefixroute
# Em Server B, vamos confirmar as rotas
ip -6 route show
2000::/3 via fe80::20c:29ff:fe62:110a dev vlan10 proto ra metric 100 expires 1795sec pref medium
fd00:1:1:cafe::/64 dev vlan10 proto ra metric 100 expires 86395sec pref medium
# Teste de Conectividade
ping fd00:1:1:cafe::1
PING fd00:1:1:cafe::1(fd00:1:1:cafe::1) 56 data bytes
64 bytes from fd00:1:1:cafe::1: icmp_seq=1 ttl=64 time=0.420 ms
64 bytes from fd00:1:1:cafe::1: icmp_seq=2 ttl=64 time=0.348 ms
Olha! Não é que funciona?
Vejam que habilitamos a M-Flag e a A-Flag juntos, resultado? Server B possui um endereço IPv6 obtido do DHCPv6, e outro endereço IPv6 autoconfigurado (SLAAC) usando EUI-64
Como definimos 0 (zero) para AdvDefaultLifetime, basicamente desabilitamos a criação de uma rota padrão através de DHCP Server. Ainda, informamos uma rota para a rede 2000::/3 através de DHCP Server.
Conclusão
Poderíamos ter outros cenários, mas creio que o objetivo foi alcançando, que é verificamos a dependência do RA para o DHCPv6, e também brincar com algumas opções do radvd e, claro, nos familiarizar com o RA, fundamental para qualquer rede IPv6
Logo vamos montar redes IPv6 usando equipamentos Cisco, Extreme, Juniper e outros, e esse conhecimento será de grande valia.
Finalizando
Este foi o maior post até então, e olha que tentei ser o mais direto possível.
Não citei, mas outras formas de verificação estão disponíveis, como “journalctl -f” tanto no DHCP Server quanto em Server B, e mesmo a interface Web, o Stork, para verificação das leases.
E você, conseguiu acompanhar os exemplos? Ficou com alguma dúvida? Se tiver alguma dificuldade ou quiser saber sobre algum cenário que não cobrimos, pergunte nos comentários. Compartilhe!
Referências