La Fibre
Télécom => Réseau => IPv6 => Discussion démarrée par: darkmoon le 19 mars 2019 à 11:34:32
-
Salut à tous,
Je partage le fruit de ma recherche au cas ou cela interesserait quelqu'un d'autre un jour (on ne sait jamais).
Je voulais régler moi même les ipv6 de mes serveurs (Debian 9 & Windows 10) derrière ma livebox.
Malgré le fait que je forçais les ip manuellement, je me retrouvais quand même avec une ip générée automatiquement par Windows (et par linux aussi d'ailleurs). Du coup, impossible de régler correctement le firewall de la livebox car il se sert des ips que la livebox a elle même générée.
Sous Windows 10:
Il faut d'abord trouver l'interface concernée.
netsh int ipv6 show int
Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 75 4294967295 connected Loopback Pseudo-Interface 1
9 25 4082 connected Ethernet 2
Puis exécuter les commandes suivantes (avec X le numéro de l'interface) :
netsh interface ipv6 set interface X routerdiscovery=disabled
netsh interface ipv6 set privacy state=disable store=persistent
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
Sous Linux :
editer le fichier /etc/sysctl.conf et rajouter (remplacer eth0 par votre interface si nécessaire):
net.ipv6.conf.eth0.accept_ra=0
Et voilà, on peut maintenant régler le pare-feu et avoir l'ip qu'on veut.
-
Et en cas de changement de préfixe tu fais quoi ? ;D
-
Faudra le changer manuellement.
Je ne fais que palier aux problèmes de la livebox qui sont :
- pas de réglage DCHP pour l'ipv6 (comme pour l'ipv4 par exemple pour assigner une ip spécifique à une adresse mac),
- le pare-feu choisi toujours d'ipv6 qui a été configuré par la livebox.
-
C'est pas forcèment aussi simple sous Linux, si le fichier de configuration a des lignes IPv6 avec "pre-up" on peut se retrouver dans de rares cas avec l'IPv6 SLAAC alors qu'on à mis les lignes suivantes dans /etc/sysctl.conf :
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_dad = 0
net.ipv6.conf.ens18.autoconf = 0
net.ipv6.conf.ens18.accept_ra = 0
net.ipv6.conf.ens18.accept_dad = 0
Cf Ubuntu serveur utilise l'IPv6 HS du RA à la place de /etc/network/interfaces (https://lafibre.info/serveur-linux/perte-ipv6/)
Le pb arrive quand l'IPv6 est configurée avant la prise en compte de /etc/sysctl.conf lors du boot.
Un reboot sur 15 était problématique chez moi.
Depuis que l’auto-configuration SLAAC est correcte (car où le routeur était pas correctement configuré) je n'ai plus de problème et ce sont bien les IP que j'ai mis dans /etc/network/interfaces qui sont utilisées.
-
Effectivement je n'ai pas de pre-up dans mon /etc/network/interfaces.
Mais on peut également faire ça effectivement :
pre-up /sbin/sysctl -w net.ipv6.conf.eth0.autoconf=0
pre-up /sbin/sysctl -w net.ipv6.conf.eth0.accept_ra=0
-
Bon, sinon, sous Linux, pour maitriser les 64 derniers bits de l'adresse tout en continuant de faire du SLAAC (et donc ne rien casser quand le préfixe change), il faut utiliser "ip token set" ;)
-
y'a beaucoup de confusion entre autoconf et accept_ra aussi.
autoconf = ne pas s'auto configurer d'adresse automatiquement (= SLAAC)
accept_ra = accepter les 'router advertisement' (RA) ce qui permet d'avoir le prefix pour autoconf et surtout la gateway.
Il y a de plus de plus de cas ou il faut accept_ra=1 que l'on veuille autoconf ou pas. car les RA sont le seul moyen d'obtenir la gateway.
Donc l'important pour ne pas avoir SLAAC c'est autoconf a 0 , pas accept_ra a 0...
la reco c'est comme @zoc indique, c'est d'utiliser SLAAC et le token.
-
Merci pour les explications (c'est pas mon métier, et tant que noob vous m'êtes d'une grande aide !).
Effectivement avec accept_ra=1 et un pre-up qui va bien c'est bien plus propre !
Dans /etc/network/interfaces
iface enp0s3 inet6 auto
pre-up /sbin/ip token set ::bad:c0de dev enp0s3
ce qui donne
root@Freeze:[~] > ip addr show dev enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:90:tt:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.0.12/24 brd 192.168.0.255 scope global dynamic enp0s3
valid_lft 86118sec preferred_lft 86118sec
inet6 2a01:cxxx:yyyy:zzzz::bad:c0de/64 scope global dynamic mngtmpaddr
valid_lft 1792sec preferred_lft 592sec
Finalement, c'est plus propre que sous Windows ou alors il y a le même principe et je n'ai pas encore trouvé.
-
Pourquoi ne pas utiliser l'adresse "privacy stable" ? (RFC 7217)
Elle est faite précisèment pour ça, être stable dans le temps sur un réseau donné, sans divulguer l'adresse matérielle.
C.a.d que sur Windows tu as juste à désactiver les adresses temporaires (rotation toutes les 24h):
netsh interface ipv6 set privacy state=disable store=persistent
Par contre tu laisses le randomizeidentifiers activé.
Il génère une adresse publique fixe dans le temps sur un réseau donné. Ex: Si tu déplace ton pc au boulot, il se créera là-bas une autre adresse bien sûr, mais quand tu le ramèneras à la maison il retrouvera l'adresse créée précédemment (c'est du pseudo-random en fait).
Le pare-feu s'y retrouve.
Source : https://www.bortzmeyer.org/7217.html (https://www.bortzmeyer.org/7217.html)
-
Oui mais si tu veux un suffixe spécifique, tu ne peux pas sous windows. Dommage qu'il n'y ai pas d'équivalent les fonctions linux sont pratiques pour ça.
-
Oui mais si tu veux un suffixe spécifique, tu ne peux pas sous windows. Dommage qu'il n'y ai pas d'équivalent les fonctions linux sont pratiques pour ça.
C'est pas la différence majeure entre Linux et Windows que tu pointes là ? :D
Quand il s'agit de traiter ou faire transiter de l'information, Windows est la ramasse. Point final. Faut juste l'accepter hein