La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: patatorx le 14 mars 2023 à 19:01:26
-
Bonjour,
Abonné chez Free depuis mon déménagement, j’utilise une Freebox Delta ainsi que le Free Player et j’ai décidé de passer tout le réseau à la maison en IPv6-only. J’ai auparavant écrit un post ([IPv6] Dépasser le premier /61 chez Free (https://lafibre.info/ipv6/ipv6-depasser-le-premier-61-chez-free/msg984889/#msg984889)) pour voir comment récupérer le /60 de chez Free mais j’ai pour le moment abandonner l’idée, je pense entre autres rationnaliser mon réseau et utiliser quelques (peu je vous rassure) préfixes ULA. J’ai bien l’opportunité d’obtenir un /48 qu’un LIR veut bien m'octroyer cependant ce dernier n’a que de la connectivité 1Gbs à me proposer (par principe, cela m’embête de me brider et me priver de mon 10Gbs :D)
Mais voilà, j’avoue que dans mon périple j’avais complètement oublié qu’il fallait quand même que je laisse mon réseau accéder à IPv4 sur Internet. Après de multiples lectures, j’ai fini par vouloir mettre en oeuvre du NAT64 à la maison. N’ayant pas d’équipement de libre sous la main disposant de 2 interfaces réseau, j’ai décidé de reconvertir un routeur Linksys sous OpenWRT, découvrant que celui-ci avait une implémentation de transition IPv4/IPv6 (IPv4/IPv6 transition technologies (https://openwrt.org/docs/guide-user/network/ipv6_ipv4_transitioning#ipv4ipv6_transition_technologies)); OpenWRT propose plusieurs solution: 6rd, 6to4 et 6in4. A la lecture de l’article, et possédant une Full IP chez Free, il me semblerait naturel de me porter vers du 6rd, j’ai raison?
Ci-joint un rapide schéma de mon réseau cible
-
Salut,
Pour tout passer en IPv6 only, fais déjà l'inventaire de tes applications, car certaines ne fonctionnent pas sans IPv4... exemple chez moi : le client lourd Spotify (capture ci-dessous). Avant de déployer pour rien, tu peux déjà tester avec un NAT64 public qu'avait linké simon : https://v6tools.kasperd.dk/nat64handoff/service
D'autre part, que vient faire le 6rd ici ? C'est pour récupérer le /48 du LIR ? Car si l'idée est abandonné tu n'en a pas besoin. Et d'ailleurs il doit falloir mettre en place le protocole qui leur convient, tu ne peux pas choisir celui que tu veux.
EDIT : ok j'ai compris où tu voulais en venir : ce n'est pas le 6rd, 6to4, ou 6in4 qui fait le NAT64 (dans ce cas ça sert juste à apporter une connectivité IPv6 tunnelisée dans IPv4, y'a toujours une dualstack), mais un programme à part entière. En l’occurrence, tayga (http://www.litech.org/tayga/) ou jool (https://www.jool.mx/en/index.html) : https://github.com/cvmiller/nat64
-
Comme le dit @renaud07 tu vas etre limité sur certaines applications. Le NAT64 (couplé à du DNS64) va te permettre d'accéder aux ressources IPv4 qui ont un nom de domaine :
- Le DNS64 "transforme" un enregistrement DNS qui ne donne qu'une IPv4 avec une IPv6 "fabriqué"
- Cette IPv6 sera utilisé par le NAT64 pour t'envoyer vers la bonne IPv4.
Tu comprends donc bien que si la cible est une IPv4 et non un NDD cela ne marche pas.
Il existe des mécanismes au niveau de l'appareil (le NAT64 étant géré par ton routeur) pour "transformer" une IPv4, par exemple le 464XLAT qui est pas mal implémenté sur les smartphones. Par contre je ne connais pas de PC l'utilisant.
-
Il me semble que le 464XLAT est proposé par Windows 10 / 11, mais avec une limitation de taille : uniquement pour des connexions WAN IPv6 only et non pour des connexions LAN IPv6 only.
C'est dommage, car cela serait une solution pour des grandes entreprises qui retirent IPv4 de leur LAN.
-
Je vois que tu as un vlan "Game". Aux dernières nouvelles, les Playstation par exemple ne supportent pas l'ipv6-only (mais peut-être y a-t-il une astuce quelque part ?).
-
Au lieu de tout migrer d'un coup, tu peux aussi procéder par étapes:
1) déploie le NAT64 + DNS64
2) observe le traffic (tcpdump, ou autre) sur chaque VLAN : y a-t-il encore du traffic IPv4 quelques jours après la migration, ou est-ce que tout le traffic v4 passe par le NAT64 ?
3) sur les VLAN dont tout le traffic est IPv6, tu peux désactiver IPv4 (DHCPv4, je suppose) sans problème
4) sur les VLAN où tu observes du traffic IPv4, tu peux soit :
a) laisser IPv4 activé sans te poser plus de questions, quitte à revoir plus tard
b) observer les adresses sources/destinations et protocoles qui utilisent toujours IPv4 pour identifier les équipements et services qui en ont toujours besoin.
Si tu choisis 4b), tu pourras ensuite mettre les équipements et applications à jour et revoir leur configuration (certains logiciels vont un peu à contre-courant en préférant IPv4 parce que "IPv6 pose des problèmes", comprendre: bien souvent les devs ne s'y intéressent pas), et voir si ca améliore la situation.
En fonction de ce que tu as dans les VLAN camera et IOT, je ne serai pas surpris que ces deux VLAN aient besoin de conserver IPv4.
C'est une méthode un peu plus chronophage certes, mais qui permet d'éviter les interruptions de service.
Perso, j'ai désactivé IPv4 sur tous mes VLAN d'un coup et n'ai pas eu de soucis, mais je comprends qu'on soit moins tête brulée que moi :-) Je n'ai rien trouvé qui pose problème à part le VPN d'entreprise d'un client dont la configuration utilisait des IPv4 codées en dur. En remplacant cette IPv4 par son équivalent IPv6 dans 64:ff9b::/96 (donc NAT64), ca a fonctionné sans souci.
Ceci dit, je n'ai ni caméra, ni IOT Chinois, ni console de jeu... ca aide beaucoup.
-
Il me semble que le 464XLAT est proposé par Windows 10 / 11, mais avec une limitation de taille : uniquement pour des connexions WAN IPv6 only et non pour des connexions LAN IPv6 only.
C'est dommage, car cela serait une solution pour des grandes entreprises qui retirent IPv4 de leur LAN.
Il doit bien avoir un moyen de l'activer de force (probablement en éditant le "registre" windows)... c'est sur ma todo list, mais je n'ai pas assez de soucis pour le faire monter en priorité :)
-
Il faudrait tester en faisant croire au système qu'une interface filaire ou wifi est de type WWAN, mais reste à savoir ce qui détermine ça : identifiant PCI ? Une valeur dans le registre ? Autre ?
En fouillant le registre dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE- BFC1-08002bE10318} Je vois qu'il y a une valeur DWORD MediaType ce qui pourrait correspondre. J'ai essayé de mettre une autre valeur, mais ça n'a pas d'effet.
EDIT : Apparemment ça agit bien dessus mais pas comme on peut s'y attendre. En plus de MediaType, il y a aussi IfType et PhysicalMediaType. J'ai connecté mon smartphone en diag qui permet un accès au modem et d'avoir une connexion WWAN créée. Et si je change ces 3 valeurs sur l'interface LAN pour la faire passer en WWAN elle disparaît de la liste des interfaces dispo...
En filaire :
IfType : 6
MediaType : 0
PhysicalMediaType : 14
En WWAN :
IfType : 244
MediaType : 9
PhysicalMediaType : 8
Je crois qu'on ne peut qu'attendre la prise en charge officielle sur n'importe quelle interface malheureusement...
-
Belle épreuve, bravo :D
Seul NAT64 et DNS64 sont conçus pour cet usage, les autres cités sont pour du pur ISP.
Maintenant rien empêche de se monter un lab pour encapsuler du V4 via 6rd ou Map pour le fun, mais c'est une usine à gaz.
Pour info, tayga est remplacé par Tundra nat64. Jool est toujours maintenu.
Attention aux performances, s'assurer que l'implémentation de nat64 exploite bien dpdk, ou le faire avec un petit fortigate ou autre. L'air de rien l'effet peut vite se ressentir sur une visio typiquement.
-
Pour info, tayga est remplacé par Tundra nat64. Jool est toujours maintenu.
Ah je savais pas. Pourtant il est toujours dispo chez debian. J'allais justement poster un petit tuto rapide debian/tayga que je teste depuis tout à l'heure.
-
Tundra n'est pas une évolution de Tayga, c'est une implémentation différente basée sur les mêmes principes (userspace avec tun).
Tayga fonctionne à merveille même si il n'y a pas eu de release depuis des années. Il n'est pas multithread et n'est pas adapté pour faire du Gbit/s, certes, mais pour permettre à un LAN d'accéder à IPv4, c'est parfait. Config simple, rock solid, fait une chose et la fait bien.
-
Par rapport au débit, j'ai effectivement remarqué que c'était pas fameux... j'ai voulu copier un gros fichier et le transfert plafonnait à 200Mb/s. Du coup, la mention Fast — can saturate gigabit Ethernet on modest PC hardware est à revoir...
Un truc que je n'ai pas compris cependant, je suis obligé de mettre du NAT pour que ça fonctionne, alors que sur la page du projet il n'en est pas fait mention. C'est peut-être pour ça que le débit est pas très élevé ?
D'autre part, je ne comprend pas à quoi servent ces deux lignes :
# ip addr add 192.168.0.1 dev nat64 (replace with your router's IPv4 address)
# ip addr add 2001:db8:1::1 dev nat64 (replace with your router's IPv6 address)
C'est si tayga est sur le routeur ? Car dans mon cas c'est une machine séparée avec une seule interface (d'où le NAT nécessaire je suppose) Les ajouter ou non ne change rien.
-
D'autre part, je ne comprend pas à quoi servent ces deux lignes :
# ip addr add 192.168.0.1 dev nat64 (replace with your router's IPv4 address)
# ip addr add 2001:db8:1::1 dev nat64 (replace with your router's IPv6 address)
C'est si tayga est sur le routeur ? Car dans mon cas c'est une machine séparée avec une seule interface (d'où le NAT nécessaire je suppose) Les ajouter ou non ne change rien.
Oui, ces adresses sont à ajouter sur l'interface tun de tayga et ne sont utilisées que pour les erreurs ICMP (hop limit exceeded, packet too big, etc.). Ne pas les mettre peut potentiellement créer des soucis de PMTUd ou autres joyeusetés difficiles à diagnostiquer.
Sur ta machine séparée, tu as bien une interface tun (pour tayga) et une interface physique, non? Et cette machine fait du routage IP, et son unique interface physique est connectée à ton routeur ?
Un truc que je n'ai pas compris cependant, je suis obligé de mettre du NAT pour que ça fonctionne, alors que sur la page du projet il n'en est pas fait mention. C'est peut-être pour ça que le débit est pas très élevé ?
Tayga fait du SIIT (stateless IP and ICMP translation) : pour chaque adresse source IPv6 nécessitant d'accéder au monde IPv4, il attribue temporairement une adresse IPv4 dans 100.64.0.0/16. Il ne s'occupe pas des protocoles de plus haut niveau (TCP, UDP, ICMP, etc.) et ne fait pas de NAPT.
Si tu avais un pool d'IPv4 publiques important, tu n'aurais pas besoin de NAT : il te suffirait de lui indiquer d'utiliser une partie de ton pool d'IPv4 publiques à la place de 100.64.0.0/16.
Si par contre tu n'as qu'une IPv4 publique (ce qui est le cas la pluspart du temps), il faut rajouter une couche de NAPT pour natter les IP privées (100.64.0.0/16) avant de sortir vers internet.
-
Oui, ces adresses sont à ajouter sur l'interface tun de tayga et ne sont utilisées que pour les erreurs ICMP (hop limit exceeded, packet too big, etc.). Ne pas les mettre peut potentiellement créer des soucis de PMTUd ou autres joyeusetés difficiles à diagnostiquer.
Sur ta machine séparée, tu as bien une interface tun (pour tayga) et une interface physique, non? Et cette machine fait du routage IP, et son unique interface physique est connectée à ton routeur ?
C'est ça. Donc je suis censé mettre l'adresse v4/v6 de la machine à l'interface tun également ?
Tayga fait du SIIT (stateless IP and ICMP translation) : pour chaque adresse source IPv6 nécessitant d'accéder au monde IPv4, il attribue temporairement une adresse IPv4 dans 100.64.0.0/16. Il ne s'occupe pas des protocoles de plus haut niveau (TCP, UDP, ICMP, etc.) et ne fait pas de NAPT.
Si tu avais un pool d'IPv4 publiques important, tu n'aurais pas besoin de NAT : il te suffirait de lui indiquer d'utiliser une partie de ton pool d'IPv4 publiques à la place de 100.64.0.0/16.
Si par contre tu n'as qu'une IPv4 publique (ce qui est le cas la pluspart du temps), il faut rajouter une couche de NAPT pour natter les IP privées (100.64.0.0/16) avant de sortir vers internet.
Ah ok. J'y vois plus clair :) Donc là on se retrouve avec un NAT44, puisque ça fait (dans mon cas) 192.168.255.x (pool) > 192.168.1.164 (IP de la debian) > IP publique
Franchement, ça marche pas mal. Dommage que le débit ne suive pas pour les transferts locaux. Il faudrait que je trouve un moyen d'exclure certaines machines du mécanisme (ou tout passer en ipv6, mais un peu la flemme pour le moment), t'aurais pas une idée ?
-
Je crois avoir résolu mon problème de débit en annonçant une route sur les machines au lieu de passer par le routeur et paf j'ai le plein débit ou presque. Mais c'est utile sur Windows uniquement.
En effet, ce c*n continue d'envoyer les paquets au routeur même après avoir reçu un ICMP redirect. Avec Linux, tout part vers le NAT64, je n'ai aucun trafic SMB arrivant au routeur.
Mais bien qu'une infime partie passe par le routeur, ça monte à un petit Mpbs max (sur un fichier de 700 Mo copié, il n'y a que 5 Mo après avoir fait un tcpdump). Le reste allant bien au NAT64, ça suffit pour faire plonger le débit à 14-15 Mo/s alors qu'en direct j'ai ~30 Mo/s. Je ne comprends pas vraiment pourquoi ça fait ça... et comme par hasard mon routeur est relié en 100 Mbps (pont wifi) soit très proche du débit que j'obtiens.
Ça veut dire que le peu de paquets "utile" envoyés au routeur ne pouvant pas aller au delà de 100 Mpbs, me bride le transfert à cette vitesse même si ce n'est pas saturé ? Ou c'est simplement qu'il y a trop d'attente entre les paquets car le routeur d'après la capture ne répond pas au trafic SMB (logique) et windows bombarde de retransmission (je penche plutôt pour cette hypothèse).
Encore un truc bien codé ::)
-
C'est ça. Donc je suis censé mettre l'adresse v4/v6 de la machine à l'interface tun également ?
Alors, pas les mêmes que celles que tu as sur l'interface physique, mais oui. Tu peux les ajouter avec des maques /128 (v6) et /32 (v4) pour ne pas cramer un /64 pour rien et utiliser une adresse dans le /64 du LAN, si besoin. C'est vraiment juste pour générer des ICMP packet too big/destination unreachable, ca n'a pas vraiment d'importance si on ne peut pas les pinger.
Il faudrait que je trouve un moyen d'exclure certaines machines du mécanisme (ou tout passer en ipv6, mais un peu la flemme pour le moment), t'aurais pas une idée ?
J'ai bien une solution pour toi, mais je crois que t'as un peu la flemme pour le moment :-) Plus sérieusement, ca t'enlèverai pas mal de complexité.
Ceci dit, tu dois pouvoir éviter le NAT44 en filtrant sur l'adresse de destination avec iptables -A POSTROUTING -i tun0 -d ! ${LAN_SUBNET} -j MASQUERADE ou quelque chose comme ca.
-
Je crois avoir résolu mon problème de débit en annonçant une route sur les machines au lieu de passer par le routeur et paf j'ai le plein débit ou presque. Mais c'est utile sur Windows uniquement.
En effet, ce c*n continue d'envoyer les paquets au routeur même après avoir reçu un ICMP redirect. Avec Linux, tout part vers le NAT64, je n'ai aucun trafic SMB arrivant au routeur.
Mais bien qu'une infime partie passe par le routeur, ça monte à un petit Mpbs max (sur un fichier de 700 Mo copié, il n'y a que 5 Mo après avoir fait un tcpdump). Le reste allant bien au NAT64, ça suffit pour faire plonger le débit à 14-15 Mo/s alors qu'en direct j'ai ~30 Mo/s. Je ne comprends pas vraiment pourquoi ça fait ça... et comme par hasard mon routeur est relié en 100 Mbps (pont wifi) soit très proche du débit que j'obtiens.
Ça veut dire que le peu de paquets "utile" envoyés au routeur ne pouvant pas aller au delà de 100 Mpbs, me bride le transfert à cette vitesse même si ce n'est pas saturé ? Ou c'est simplement qu'il y a trop d'attente entre les paquets car le routeur d'après la capture ne répond pas au trafic SMB (logique) et windows bombarde de retransmission (je penche plutôt pour cette hypothèse).
Encore un truc bien codé ::)
Gigue et packet loss qui sautent dans tous les sens sur le lien wifi et paquets qui arrivent désordonnés à la destination ?
Comment fais tu pour annoncer une route sur les machines ? router advertisement route information option ? SI oui, qui l'envoie ? la machine qui fait NAT64 ou le routeur directement connecté à Internet ?
-
Alors, pas les mêmes que celles que tu as sur l'interface physique, mais oui. Tu peux les ajouter avec des maques /128 (v6) et /32 (v4) pour ne pas cramer un /64 pour rien et utiliser une adresse dans le /64 du LAN, si besoin. C'est vraiment juste pour générer des ICMP packet too big/destination unreachable, ca n'a pas vraiment d'importance si on ne peut pas les pinger.
Merci
J'ai bien une solution pour toi, mais je crois que t'as un peu la flemme pour le moment :-) Plus sérieusement, ca t'enlèverai pas mal de complexité.
C'est sûr.
Mais j'ai pensé après coup que ça ne règle pas mon problème pour toutes les apps qui refusent de marcher sans v4... (et ajouter du CLAT complexifie encore plus les choses) Sans compter que je bidouille du legacy souvent (2000/XP) et pour eux, pas d'ipv6 ou alors très limité. J'ai déniché une bidouille à base de netcat pour pourvoir faire des requêtes DNS ipv6, mais c'est un peu crade.
Ceci dit, tu dois pouvoir éviter le NAT44 en filtrant sur l'adresse de destination avec iptables -A POSTROUTING -i tun0 -d ! ${LAN_SUBNET} -j MASQUERADE ou quelque chose comme ca.
S'il n'y a plus de NAT, comment les paquets sont censés partir ? J'avoue que je ne comprends pas très bien ce que c'est censé faire.
Gigue et packet loss qui sautent dans tous les sens sur le lien wifi et paquets qui arrivent désordonnés à la destination ?
Possible. Après, c'est la faute à windows qui fait n'importe quoi... Il faudrait que je teste d'autres versions de 10 ou même 7 voir si c'est un bug de version ou vraiment un problème de la pile IP. Je ne suis pas chez moi pour le moment, ça attendra ce soir.
Comment fais tu pour annoncer une route sur les machines ? router advertisement route information option ? SI oui, qui l'envoie ? la machine qui fait NAT64 ou le routeur directement connecté à Internet ?
Exact, route information par le NAT64. Au début, je m’obstinais à annoncer le préfixe et évidemment ne fonctionnait pas du tout comme attendu ;D Si je veux le faire annoncer par mon routeur c'est possible ? Car je crois avoir lu que c'est odhcpd sur OWRT et pas radvd ? Car je n'ai pas trouvé de doc là dessus.
-
Non, tu ne pourras pas l'annoncer depuis ton routeur car seul l'émetteur du RA est considéré comme next hop (il n'y a d'ailleurs pas de champ next hop dans les route information options).
Si ton routeur tourne sous OpenWRT, ca ne serait pas plus simple d'installer tayga dessus ? C'est ce que je fais et ca marche nickel. Example de conf dans /etc/config/network :
#nat64 gateway
config interface 'nat64'
option proto 'tayga'
option prefix 64:ff9b::/96
option ipv4_addr 100.64.255.254
option dynamic_pool 100.64.0.0/16
Il faut ensuite ajuster les règles de firewall, si nécessaire. fw4 s'en charge peut-être tout seul mais je n'en sais rien, j'ai un ruleset nft maison.
-
Non, tu ne pourras pas l'annoncer depuis ton routeur car seul l'émetteur du RA est considéré comme next hop (il n'y a d'ailleurs pas de champ next hop dans les route information options).
Ah ok, on ne peut pas associer une link-local à une route. Tout ce qui est annoncé par le routeur prend automatiquement la sienne. À l'exception donc des routes statiques.
Et par rapport à windows, j'ai à priori trouvé ce qui ne va pas : les ICMP redirect sont bloqué par le pare-feu (alors que le paramétrage par défaut les active, vachement logique...) ! ::) J'aurais dû y penser vu que le ping est aussi bloqué par défaut... Il faut recréer une règle pour débloquer la situation (du moins sur windows 7, reste à tester 10 et 11). Sans compter qu'en dehors de ça il y a bien un bug qui ne met pas la table de routage à jour : https://community.spiceworks.com/topic/292861-icmp-redirects
Mais malheureusement, ça ne fonctionne que pendant quelques minutes au démarrage du système, le redirect est pris en compte une première fois et plus de trafic. Mais si j'attends entre 15 et 30 sec, le flot de paquets revient sur le routeur et celui-ci "abandonne" et n'envoie plus de redirect (mais le trafic passe toujours ce qui est curieux). Bref, un beau bordel.
Si ton routeur tourne sous OpenWRT, ca ne serait pas plus simple d'installer tayga dessus ? C'est ce que je fais et ca marche nickel. Example de conf dans /etc/config/network :
#nat64 gatewayà propos de
config interface 'nat64'
option proto 'tayga'
option prefix 64:ff9b::/96
option ipv4_addr 100.64.255.254
option dynamic_pool 100.64.0.0/16
Il faut ensuite ajuster les règles de firewall, si nécessaire. fw4 s'en charge peut-être tout seul mais je n'en sais rien, j'ai un ruleset nft maison.
J'avais essayé sur une VM, mais ça ne voulait pas fonctionner (je l'ai remplacé par jool, qui se configure quasiment tout seul), il doit sans doute me manquer des trucs, faut que je relise correctement la doc. Par contre sur debian, pas de problème ça fonctionne bien.
-
Tayga sur mon routeur c'est pas un bon plan finalement (du moins pour le moment), le débit va être pire vu que tout le trafic va devoir passer par mon pont wifi... Et sur les transferts de fichiers ça va ramer sévère. Donc tant que tous les points bloquants ne sont pas résolus pour passer en ipv6, vaut mieux que je le conserve en VM dédiée connectée en 1G et encore même là, la translation me fait perdre un peu.
Et concernant l'ICMP redirect, sur 10 et 11 ça fonctionne un peu mieux que sur 7, la consigne est enregistrée pour plusieurs minutes. Mais il faut toujours penser à l'ouvrir sur le pare-feu.