Bonjour à tous,

RED venant de me passer en IPv6, je commence à voir comment le déployer sur mon LAN. Et à moins d'un soucis de compréhension du fonctionnement de l'IPv6, j'avoue être un peu perdu sur comment gérer les DNS avec mes périphériques.

J'ai un routeur pfsense qui remplace ma box. La récupération de l'IPv4 et du préfixe IPv6 fonctionne sans soucis.

Pour l'instant j'ai un LAN en 192.168.1.0/21, réparti en 192.168.1.X = mes serveurs et autres périphériques réseaux (switch , AP), et 192.168.2.X = mes périphériques utilisateurs (téléphone, tablette, ordinateurs portables) (c'est le reste d'une tentative de séparation en 2 VLAN, qui apportait plus de problème pour aucun gain pratique). Tous le monde est réglé en bail fixe depuis les réglages DHCP de pfsense.

Mon DHCP distribue par défaut une adresse DNS v4 qui pointe vers un container AdguardHome, et les machines en 192.168.1.X voient eux leur DHCP pointer vers le DNS pfsense (DHCP DNS override, pour chaque client). Tout fonctionne bien.

Pour faire en sorte que tout le monde sur 192.168.2.X passe bien par AdguardHome seulement, j'ai une règle sur mon firewall qui bloque tout trafic sortant sur les ports 53 et 853 pour le réseau 192.168.2.0/24.

Là où je bloque, c'est sur la réplication de ce fonctionnement pour l'IPv6 :
- sur mon LAN, tout le monde s'adresse automatiquement sur le /64 récupéré depuis le routeur. Je peux utiliser un DHCPv6 pour attribuer aussi une IP plus reconnaissable (pas si facile en pratique ...), mais ce n'est pas forcément (même jamais ?) celle là qui est utilisée pour interroger le DNS ou sortir sur internet ;
- du coup, comment segmenter mon réseau en 2 sous parties comme je l'ai fait en IPv4 ? Suis-je obligé de passer par un VLAN, qui pose du coup d'autres soucis ?
- comment interdire à certains périphériques, dont je ne connais pas l'IP auto-attribuée, d'accéder à un DNS autre que celui que je veux ? Ne connaissant pas leur IP, je ne vois pas comment créer une règle de filtrage sur mon firewall ...
- et plus généralement, sur mon DNS AdguardHome, je ne peux plus identifier les clients qui s'y connectent par une IP changeante. Du coup, je ne peux pas non plus activer des règles "par client" (listes de filtrage différentes, par exemple, entre le téléphone de ma fille et le mien), puisqu'ils ne sont plus identifiables par une IP unique (seule possibilité sur AdguardHome pour identifier un client je crois) ?

Peut être suis-je complètement à côté de la plaque, mais j'avoue ne pas comprendre un truc là ...
Votre expertise est la bienvenue 

EDIT : une précision : pfsense diffuse les RA en mode "Assisted" (Will advertise this router with configuration through a DHCPv6 server and/or stateless autoconfig).

Deja la meilleur facon d'aborder IPv6 est surtout de ne pas chercher a reproduire ou pire a répliquer/transposer ce qu'on fait en IPv4...

C'est ce que j'ai lu partout et ce que je m'efforce de faire. Ici je ne cherche pas (je crois !) à reproduire méthodologiquement ce que je fais en IPv4, mais plutôt fonctionnellement : comment bloquer en IPv6 spécifiquement l'accès à certaines machines à certains services (DNS ici) alors que leur IP change. Mais peut être la question est-elle mal posée ?

DNS n'est pas forcement besoin de 'parler' IPv6 pour faire des résolution IPv6. Tant que tes appareils ont de l'IPv4 autant ne faire du DNS qu'en IPv4: ca ne sert a rien "de doubler" ta configuration de filtrage DNS avec IPv4 et IPv6 c'est double boulot, double gestion, etc.

Ca je l'ai compris il n'y a pas si longtemps. Mais il y a autre chose que j'ai du mal à saisir. Entre le DNS fourni par DHCPv4 et le DNS récupéré par RA/DHCPv6, lequel est utilisé par le client ? Je pose la question en particulier car je constate un comportement bizarre du client dhcp par défaut sur debian, qui a l'air d'osciller entre les 2, avec un fichier /etc/resolv.conf qui commence avec seulement l'IPv6 du DNS, puis qui change pour l'IPv4 seule au renouvellement du bail.

Il faut que dans la config RA tu annonce l'IPv6 link-local du serveur DNS comme ca les machines du réseau feront leur résolution DNS en IPv6 en utilisant leur link-local et pas leur IPv6 public. Du coup on peut les filtrer au niveau du serveur DNS.

Ça c'est l'info clé ! Je ne connaissais pas ce mécanisme, car en effet je maitrise alors l'identification du client.

Si tu as plusieurs segments LAN ou VLAN ce n'est plus possible d'utiliser les link-local car elles ne sont uniques que par segment. Du coup le mieux est d'utiliser des ULA (= unique local address) qui seront aussi stables par machine et d'avoir le trafic DNS avec.

Je ne comprends pas "les link-local ne sont uniques que par segment". Cela veut-il dire que 2 link-local identiques sont susceptibles de se retrouver sur 2 VLAN différents pour 2 machines différentes ?
Je comprends bien le rôle des ULA, mais comment alors les connaître pour chaque client (si tant est que ce soit nécessaire) ? Là sur mon mac, je vois 4 adresses v6 : 2 GUA autoconfigurées, 1 GUA récupérée par mon DHCPv6, et un link-local fe80::. Pas de traces de ULA (en fd:: si j'ai bon ?)

J'espère être clair ... désolé si ce n'est pas le cas !

Bonsoir, je vais te répondre juste sur cette dernière partie :

- tu récupères une link-local à partir du moment où IPv6 est activé sur le lien, celle-ci est configuré automatiquement (avec ton adresse MAC)
- Tu récupère une GUA en autoconfiguration (normalement avec ta MAC mais je crois que Windows se base sur un autre algo, c'est a confirmé). De cette GUA est construite une deuxième GUA dites "temporaire", elle sera utilisée pour le traffic sortant et changera toutes les X minutes. Cela évite de se faire "pister" par son IP publique
- Une GUA par DHCPv6 tu l'as compris

Si tu veux que tes machines récupère des ULA il te suffit d'annoncer un préfixe ULA par RA, les machines s'autoconfigureront alors une ULA en plus des autres IPs.
Tu peux passer par un site comme celui-ci par exemple pour essayer d'avoir un préfixe "unique"
https://www.ip-six.de/

Ah OK, je n'avais pas compris que c'était à moi de spécifier l'ULA et le sous-réseau associé. Je viens de l'ajouter dans le RA, et je récupère bien une adresse en fd:: Cette adresse est (a priori) aléatoire mais ne changera plus, c'est bien ça ?

Autre question : il y a des clients pour lesquels je ne peux pas facilement (ou pas du tout !) avoir leurs infos de connexions (par exemple, une enceinte audio wifi) en IPv6 (pour l'IPv4, je vois facilement les requêtes DHCP et l'adresse MAC associée). Du coup, comment récupérer leur ULA qui j'imagine, est tout aussi aléatoire ? Ne serait-ce que pour identifier le client dans les stats de mon DNS (mais là aussi j'ai peut être un "réflexe" v4 qui n'a plus lieu d'être en v6 ?)

Je ne comprends pas "les link-local ne sont uniques que par segment". Cela veut-il dire que 2 link-local identiques sont susceptibles de se retrouver sur 2 VLAN différents pour 2 machines différentes ?

oui autrement dit:
Les link-local ne servent que sur un lien (segment) donné. par exemple un LAN.
Les link-local ne sont pas routables entre 2 segments ou plus. Elles ne servent qu'au trafic sur le segment.

d'ailleurs tres souvent les link-local ont une notation spéciale avec a la fin, en plus ,il y a "%nom" ou "%id" pour indiquer l'interface (le nom ou l'index de l'interface) (fe80:a:b:c:d%4 par exemple).

Du coup, comment récupérer leur ULA qui j'imagine, est tout aussi aléatoire ? Ne serait-ce que pour identifier le client dans les stats de mon DNS (mais là aussi j'ai peut être un "réflexe" v4 qui n'a plus lieu d'être en v6 ?)

par default les ULA (comme les link-local) ne sont pas aléatoires mais construites avec l'@MAC (mécanisme EUI-64) du coup identifiables et stables. Seules les adresses GUA 'privacy' sont aléatoires, les GUA fixes ne pas aléatoires non plus.

Pour le préfix LUA tu n'es pas obligé d'utiliser le site mentionné par vocograme, tu peux utiliser n'importe quel préfix ULA (donc un truc simple et facile a mémoriser par exemple fd:0:0:1::/64 et fd:0:0:2::/64 si tu as 2 LANs/VLANs).

Par contre attention a la priorité d'utilisation, dans les OS c'est dans l'ordre:

IPv6 GUA
IPv4
IPv6 LUA

donc si une résolution DNS a les 2: IPv6 (lua) et IPv4, c'est IPv4 qui sera utilisé.
En gros dans les configurations dual stack, quand DNS a les 2 réponses (A et AAAA):
pour le trafic public, IPv6 (GUA) est prioritaire sur IPv4
pour le trafic privé c'est IPv4 qui est prioritaire sur IPv6 (LUA).

Bref ce n'est pas simple le dual stack

Apres IPv6 c'est aussi l'occasion de remettre en question les pratiques IPv4. Filtrer ou faire de la sécurité au niveau 3 du réseau (niveau adresses IP donc) ce n'est plus trop une solution d'avenir. Surtout avec DNS et son évolution vers DoH.

Je ne sais pas la raison de l'utilisation de ton AdguardHome mais c'est peut-être ca qu'il faut aussi remettre en question plutot que partir dans de la conf réseau complexe.

par default les ULA (comme les link-local) ne sont pas aléatoires mais construites avec l'@MAC (mécanisme EUI-64) du coup identifiables et stables. Seules les adresses GUA 'privacy' sont aléatoires, les GUA fixes ne pas aléatoires non plus.

Pour le préfix LUA tu n'es pas obligé d'utiliser le site mentionné par vocograme, tu peux utiliser n'importe quel préfix ULA (donc un truc simple et facile a
mémoriser par exemple fd:0:0:1::/64 et fd:0:0:2::/64 si tu as 2 LANs/VLANs).

OK, j'ai compris ... mais visiblement je constate que les trucs apple n'utilisent pas EUI-64 pour générer leurs addresses ULA, mais une autre méthode qui semble dépendre du préfixe. Mais j'imagine qu'une fois celui-là choisi, il n'y plus de soucis et leurs IPs ne changent plus.
Du coup, j'ai encore du mal à bien comprendre l'intérêt des ULA vis à vis des link-local. J'ai bien compris que les 2nde n'étaient pas routables (ce qui d'ailleurs va me poser des soucis si je les utilise pour des communication inter-VLAN), mais est-ce là leur seule différence d'usage ?

En pratique, je constate donc que certaines adresse ULA commencent à interroger mon DNS ... mais ces adresses ne sont pas générées avec EUI-64, impossibles d'en identifier le client à l'origine. Bon, là sur mon petit réseau @home on s'en fiche, mais comment on gère ça sur un réseau plus conséquent ? On se fiche de savoir qui est qui en fait ?

Par contre attention a la priorité d'utilisation, dans les OS c'est dans l'ordre:

IPv6 GUA
IPv4
IPv6 LUA

donc si une résolution DNS a les 2: IPv6 (lua) et IPv4, c'est IPv4 qui sera utilisé.
En gros dans les configurations dual stack, quand DNS a les 2 réponses (A et AAAA):
pour le trafic public, IPv6 (GUA) est prioritaire sur IPv4
pour le trafic privé c'est IPv4 qui est prioritaire sur IPv6 (LUA).

Bref ce n'est pas simple le dual stack

En effet J'avais bien vu cette "priorité" ici : https://lafibre.info/ipv6/macoswindows-ula-et-precedence/.

Apres IPv6 c'est aussi l'occasion de remettre en question les pratiques IPv4. Filtrer ou faire de la sécurité au niveau 3 du réseau (niveau adresses IP donc) ce n'est plus trop une solution d'avenir. Surtout avec DNS et son évolution vers DoH.

Je ne sais pas la raison de l'utilisation de ton AdguardHome mais c'est peut-être ca qu'il faut aussi remettre en question plutot que partir dans de la conf réseau complexe.

C'est ce que je commence à comprendre doucement. Ici, je cherche à :
- utiliser AdguardHome comme DNS avec un filtre parental pour les clients de mes enfants ;
- utiliser AdguardHome comme DNS sans filtre parental pour les autres clients ;
- utiliser le DNS de mon routeur pour mes serveurs (pas de risque de blocage non anticipé).
Cela me semble être un utilisation "naturelle" des DNS filtreurs installés en local, mais peut être leur fonctionnement n'est plus adapté à un réseau IPv6 alors. Et oui, quand on en sera à interroger les DNS sur le port 443 de manière courante, ça sera une autre histoire 

Cette philosophie n'est bien sur pas partagé par tout ceux dont le métier ou le business a toujours été de "complexifier la couche 3": ca va des fabricants et installateur/vendeurs de routeurs, firewall, vpn hardware, etc aux administrateurs réseaux et tous ceux qui font du "service" au niveau réseau...

Moi je suis content de lire tes arguments ... Il y a plus de 20 ans (je travaillais à l'époque dans le domaine du test de vulnérabilités réseau), j'expliquais que la "sécurité périmétrique" était insuffisante, et qu'il fallait une vraie "défense en profondeur".
La sécurité périmétrique part d'un postulat : les "méchants" sont à l'extérieur du réseau, les "gentils" sont à l'intérieur.
Depuis des années, on sait pourtant que c'est faux ; voir les exemples récents de "ransomware", qui s'appuient à un moment sur le fait que quelque chose est entré à l'intérieur ...
Je sais, on s'écarte du sujet - désolé.