La Fibre
Télécom => Réseau => IPv6 => Discussion démarrée par: Cryptage le 03 juin 2023 à 11:18:11
-
Hello les pros de l'IPv6,
Je fais appel à vous car ça fait 2 jours que je sèche sur un problème et je ne trouve pas... Je dois zapper quelque chose mais je ne vois pas quoi.
Le contexte :
- 1 Freebox Delta avec firewall IPv6 actif et délégation des 4 premiers préfixes vers les adresses fe80::1.
- Initialement j'avais 2 Ubiquiti ER-X configuré en VRRP avec en VIP fe80::1 et l'adresse 2a01...:xxxx::254 en GUA.
Tout fonctionnait parfaitement bien.
Comme ces boitiers ne sont quasi plus maintenus, je les remplace par VYOS.
J'ai pu porter assez facilement la configuration car elle est relativement similaire moyennant quelques différences.
J'arrive donc à obtenir de l'IPv6 sur les machines, via SLAAC.
Sauf que... il y a un preferred lifetime et un valid lifetime (ce qui n'est pas forcément illogique) et dès qu'ils expirent les adresses passent deprecated puis disparaissent des machines.
Quand les adresses sont actives, tout fonctionne parfaitement (ping vers le routeur, accès internet...).
Je n'arrive pas à comprendre pourquoi elles ne se renouvellent pas et c'est là que vous intervenez :).
A noter que sur les VYOS il n'y a pas de firewall actif pour la partie IPv6, tout ce qui est ICMPv6 passe sans souci.
Un des 2 est une VM Proxmox, le second est une machine physique (Fujitsu Futro S540).
Pour écarter un problème lié à Proxmox, j'ai fait le test en utilisant le second VYOS et le résultat est le même donc ça semble exclure un problème qui serait lié à la VM.
J'ai regardé côté switch et il n'y a pas de filtrage sur le multicast, l'IPv6, les RA...
Sur une des machines :
inet6 2a01:e0a:2d3:yyyy:b40b:bcff:yyyy:yyyy/64 scope global dynamic mngtmpaddr
valid_lft 890sec preferred_lft 290sec
Qui après l'expiration transite par :
inet6 2a01:e0a:2d3:yyyy:b40b:bcff:yyyy:yyyy/64 scope global deprecated dynamic mngtmpaddr
valid_lft 42sec preferred_lft 0sec
Et finalement disparaît puisque expirée.
ip -6 neigh :
fe80::8cf6:45ff:xxxx:xxxx dev enp6s18 lladdr 8e:f6:45:xx:xx:xx router REACHABLE
fe80::1 dev enp6s18 lladdr 8e:f6:45:xx:xx:xx router REACHABLE
Quelques traces tcpdump :
Régulièrement on voit les échanges NS/NA entre la machine et le routeur :
10:50:39.146158 enp6s18 In IP6 fe80::8cf6:45ff:xxxx:xxxx > fe80::b40b:bcff:yyyy:yyyy: ICMP6, neighbor solicitation, who has fe80::b40b:bcff:yyyy:yyyy, length 32
10:50:39.146193 enp6s18 Out IP6 fe80::b40b:bcff:yyyy:yyyy > fe80::8cf6:45ff:xxxx:xxxx: ICMP6, neighbor advertisement, tgt is fe80::b40b:bcff:yyyy:yyyy, length 24
Et quelques fois :
11:07:32.134262 enp6s18 Out IP6 fe80::b40b:bcff:yyyy:yyyy > fe80::1: ICMP6, neighbor solicitation, who has fe80::1, length 32
11:07:32.134601 enp6s18 In IP6 fe80::1 > fe80::b40b:bcff:yyyy:yyyy: ICMP6, neighbor advertisement, tgt is fe80::1, length 24
Ainsi que des RA depuis le routeur :
10:51:48.598075 enp6s18 M IP6 fe80::1 > ip6-allnodes: ICMP6, router advertisement, length 32
La config VYOS VRRP :
address 2a01:e0a:2d3:yyyy::254/64 {
}
address fe80::1/64 {
}
advertise-interval 1
authentication {
password xxxxxxxx
type plaintext-password
}
interface eth2
preempt-delay 60
priority 2
vrid 11
Router-advert :
interface eth2 {
prefix 2a01:e0a:2d3:yyyy::/64 {
decrement-lifetime
deprecate-prefix
}
source-address fe80::1
}
La config RADVD que lui a généré :
interface eth2 {
IgnoreIfMissing on;
AdvDefaultPreference medium;
MaxRtrAdvInterval 600;
AdvReachableTime 0;
AdvIntervalOpt on;
AdvSendAdvert on;
AdvOtherConfigFlag off;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvRASrcAddress {
fe80::1;
};
prefix 2a01:e0a:2d3:xxxx::/64 {
AdvAutonomous on;
AdvValidLifetime 900;
AdvOnLink on;
AdvPreferredLifetime 300;
DeprecatePrefix on;
DecrementLifetimes on;
};
};
Le debug RADVD, il n'y a que ceci régulièrement :
[Jun 03 11:11:03] radvd (169792): eth2 recvmsg len=64
[Jun 03 11:11:03] radvd (169792): eth2 received a packet
[Jun 03 11:11:03] radvd (169792): eth2 received RA from: fe80::1 (myself)
[Jun 03 11:11:03] radvd (169792): processed RA on eth2
[Jun 03 11:11:03] radvd (169792): polling for 479.662 second(s), next iface is eth2
J'ai déjà tenté avec ou sans source-address, en modifiant les lifetime, sans les decrement-lifetime / deprecate-prefix (sachant que j'en ai besoin pour expirer les adresses quand ça bascule sur la liaison 4G qui elle n'a pas d'IPv6), en modifiant les min interval / max interval... mais le résultat est toujours le même : ça passe deprecated puis disparaît.
Je pourrais envisager de mettre un preferred / valid lifetime sans expiration mais ça me semble être du bricolage.
Des idées ?
Merci :)
-
Précision supplémentaire : quand les GUA disparaissent des machines, les ULA fe80::1 et celle du routeur restent joignables.
-
> 10:51:48.598075 enp6s18 M IP6 fe80::1 > ip6-allnodes: ICMP6, router advertisement, length 32
Ca me semble peu de bytes pour un RA avec un préfixe. Peux-tu refaire une capture avec -v pour qu'on voit ce qu'ils contiennent ? En recois-tu régulièrement ? A quel interval ? Normalement, les timers valid et preferred devraient se ré-armer à chaque réception de RA par les machines.
Tes valeurs AdvValidLifetime et AdvPreferredLifetime sont très courtes. Vu que le préfixe délégué est fixe chez free, tu pourrais soit mettre largement plus grand (x10 ou x100, par exemple) soit, en effet, mettre 0 pour avoir des valeurs infinies (solution que j'aime moins personnellement).
-
Merci du retour ;)
Les RA sont de 64 quand ça fonctionne.
J'ai testé de mettre en infini et ça fonctionne parfaitement, même si c'est bof...
Les valeurs sont courtes car je les ai abaissées pour faire les tests.
Même avec des valeurs plus longues le problème était le même (il y avait 24h initialement).
Les RA sont visibles dans l'analyse tcpdump toutes les 15 secondes mais le compteur ne se réarme jamais.
C'est d'ailleurs assez dingue, ça suit le temps restant sur les machines.
Ensuite les RA passent à 32 en effet avec plus aucune information.
J'avais regardé une capture détaillée et on voyait le router lifetime, le reachable time, le retrans timer, le prefix info...
J'en suis à me demander si le bug ne serait pas du côté VYOS qui ne réarmerait pas et donc forcément les machines non plus...
-
Est-ce que les lifetimes visibles dans tcpdump (contenus dans les RA) diminuent également progressivement ?
J'ai l'impression que VyOS considère les délégations (les /64 routés depuis la freebox) comme temporaires... et qu'une fois que ces délégations expirent dans VyOS, les préfixes ne sont plus annoncés dans les RA, ce qui expliquerait pourquoi la taille des RA passe de 64 bytes à 32.
Si tu retires les options decrement-lifetime et deprecate-prefix de la conf réseau "router advert", est-ce que ca change quelque chose ? Ces options n'ont pas vraiment de sens si la conf réseau est statique (ce qui est le cas ici).
-
peut-etre l'anti "denial-of-service" du AdvValidLifetime. il faut être supérieur a 2 heures ou que les routeurs soit authentifiés par SEcure Neighbor Discovery(SEND). (voir rfc4862 5.5.3/e) sinon c'est ignoré.
pour "AdvPreferredLifetime" tu peux mettre un truc court c'est meme reco dans ton cas.
-
Merci pour vos réponses :D.
Est-ce que les lifetimes visibles dans tcpdump (contenus dans les RA) diminuent également progressivement ?
J'ai l'impression que VyOS considère les délégations (les /64 routés depuis la freebox) comme temporaires... et qu'une fois que ces délégations expirent dans VyOS, les préfixes ne sont plus annoncés dans les RA, ce qui expliquerait pourquoi la taille des RA passe de 64 bytes à 32.
Si tu retires les options decrement-lifetime et deprecate-prefix de la conf réseau "router advert", est-ce que ca change quelque chose ? Ces options n'ont pas vraiment de sens si la conf réseau est statique (ce qui est le cas ici).
Absolument, on voit le temps diminuer dans les RA du tcpdump.
Retirer les options ne change strictement rien. Et j'en ai forcément besoin quand je perds la liaison fibre et que ça bascule sur la 4G qui n'a pas d'IPv6.
peut-etre l'anti "denial-of-service" du AdvValidLifetime. il faut être supérieur a 2 heures ou que les routeurs soit authentifiés par SEcure Neighbor Discovery(SEND). (voir rfc4862 5.5.3/e) sinon c'est ignoré.
pour "AdvPreferredLifetime" tu peux mettre un truc court c'est meme reco dans ton cas.
Initialement c'était > à 2h mais j'ai fait le test par acquis de conscience et ça ne change rien :(.