Quelques news mais rien de décisif...
[3615MaVie]
En fait, j'ai fait tellement d'essais...
La nuit dernière, c'étaient 3 sessions SSH simultanées pour faire les modifs et du tcpdump. Plus un wireshark sur une machine directement sur le LAN de la NB6v.
Il y a 2 semaines, j'ignorais vraiment tout d'IPv6... Et ma première install d'un Wireshark était... hier.
Un gros kiffage en cours...
[/3615MaVie]
Rappel: WAN = eth1, LAN = eth0
(Je vais tenté d'être didactique ici, ça aidera peut-être les débutants comme moi et vous permettra de me corriger sur mes erreurs)
Donc ce soir, j'ai dans /etc/sysctl.conf :
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.proxy_ndp=1
net.ipv6.conf.all.proxy_ndp=1
net.ipv6.conf.eth1.accept_ra=2Pas d'autoconf ici, ni via le CLI (dont les scripts veulent voir un Disable forwarding également sur l'interface), car je veux la main sur l'interface de mon WAN et surtout sur son subnet (pour contrer le radvd qui tourne sur le LAN de la NB6v). Donc ici, j'accepte les Router Advertisement (=2) car mon interface est un Host qui doit prendre de l'info de son routeur (la NB6v). Pour que mon hôte reste un routeur, on précise Forwarding à 1.
Enfin, les flags pour le NDP proxy sont là pour une raison évoquée plus loin.
À noter que certains flags ici ont déjà la bonne valeur par défaut mais Linux fait un peu ce qu'il veut et c'est bien peu documenté (ou complexe selon l'angle de vue), je suis donc ici en réglages explicites. En revanche, j'ai lu quelque part que ne pas céder à l'autoconfiguration désactivait d'autres petites choses, les redirects? À surveiller... Mais quand on lit parfois qu'il est bon d'avoir le firewall activé pour que certaines choses fonctionnent mieux... Une corde, s'il-vous-plait...
En fonction des infos de Kgersen, je souhaite être dans le subnet DMZisé de mon préfixe 2a02:dead:be:af01::/56, qui n'est pas broadcasté et qui se trouve sur :1::/64. Ayant des difficultés à lire le script publié (ben oui, autant être nul partout...), je pars donc sur ce qui suit :
ethernet eth1 {
address dhcp
description WAN
duplex auto
firewall {
in {
ipv6-name WAN6_IN
name WAN_IN
}
local {
ipv6-name WAN6_LOCAL
name WAN_LOCAL
}
}
ipv6 {
address {
eui64 2a02:dead:be:af01::/64
}
dup-addr-detect-transmits 1
}
speed auto
}
Avec eui64, l'adresse résultante est basée sur ma MAC address, toujours dans mon subnet.
J'ai également mis mon interface LAN, qui porte mon radvd, dans un subnet différent :
ethernet eth0 {
address 192.168.2.254/24
description LAN
duplex auto
ipv6 {
address {
eui64 2a02:dead:be:af02::/64
}
dup-addr-detect-transmits 1
router-advert {
cur-hop-limit 64
default-preference high
link-mtu 0
managed-flag false
max-interval 600
other-config-flag false
prefix ::/64 {
autonomous-flag true
on-link-flag true
valid-lifetime 2592000
}
reachable-time 0
retrans-timer 0
send-advert true
}
}
speed auto
}Ici, on est en autoconfiguration pour les clients LAN. RàS de ce coté-là, à priori.
À noter que j'avais mis un
set interfaces ethernet eth0 ipv6 router-advert radvd-options 'RDNSS 2620:0:ccc::2 2620:0:ccd::2 { };'Mais cela semble superflu, l'ERL semble faire son boulot avec :
name-server 208.67.222.222
name-server 208.67.220.220
name-server 2620:0:ccc::2
name-server 2620:0:ccd::2Donc ici, les NS/NA ICMP6 passent bien, dans les 2 sens, entre mon interface WAN et le LAN de la NB6v.
En partant de là, je crois que tout devrait bien se passer... Sauf que non...
ping6 ipv6.google.com montrent bien les requêtes et les responses ICMP6 sur l'interface WAN. Mais la même chose depuis un client LAN ne montrera que les requètes.
(Avec mon firewall ou pas. J'ai ICMP6 autorisé sur tout pour le moment)
Je n'ai pas la capture wireshark sur le LAN de la NB6v devant les yeux là (plus une grosse flemme), mais on y voit aussi les requêtes ICMP6 continuer à se diriger vers la sortie, ainsi que les réponses revenir mais avec un Destination unreachable doté pourtant d'une adresse comportant le bon prefix (2a02:dead:be:af02::/64).
Donc, en l'état, sur le lien de la NB6v/mon WAN, "personne" ne sait trouver mon LAN et donc mes clients.
Ma table de routage (modifiée) :
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: U 256 0 0 lo
2a02:dead:be:af00::/64 :: UAe 256 0 1 eth1
2a02:dead:be:af01::/64 :: U 256 0 0 eth1
2a02:dead:be:af02::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
::/0 fe80::_local-link_de_la_NB6v UGDAe 1024 2 0 eth1
::/0 :: !n -1 1 23150 lo
::1/128 :: Un 0 1 0 lo
2a02:dead:be:af01::/128 :: Un 0 1 0 lo
2a02:dead:be:af01:_MAC_eth1_/128 :: Un 0 1 4171 lo
2a02:dead:be:af02::/128 :: Un 0 1 0 lo
2a02:dead:be:af02:_MAC_eth0_/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::_MAC_eth0_/128 :: Un 0 1 1253 lo
fe80::_MAC_eth1_/128 :: Un 0 1 1730 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
::/0 :: !n -1 1 23150 loDonc pour revenir sur le NDP proxy, possible que ce soit une solution, envisageable si on peut éviter les saisies manuelles, d'autant que les produits Apple de mon réseau jouent de l'adresse Global temporaire... Il faudrait donc un ndppd (NDP Proxy Deamon), sauf que pour EdgeOS, y'a pas (celui de Goretsoft est down et le prometteur ndppd6 est à compiler sur MIPS, tester, etc. Je me refuse à aller si loin. Et "même si", c'est une solution "crade".
Pistes à creuser préférentiellement (pour moi) :
- Puisque ma config sur le WAN est essentiellement manuelle pour éviter le radvd de la NB6v et son subnet firewallé, il y a peut-être encore des flags à modifier dans sysctl.conf (les redirects).
- J'ai mis mon ERL en DMZ sur l'interface Web de la NB6v, les filtrages off... pour voir... car lu que celà pouvait aussi agir sur la config IPv6. Gros doutes... Car je ne vois aucune raison technique formelle pour justifier cette "conséquence" mais aller savoir comment SFR nous a programmé ça.
- Enfin, objectif ultime : mettre l'ERL sur l'ONT mais on est encore très loin de l'efficacité du remplacement de la Livebox (fantastique boulot, Martin!).
Incidents SFR