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 ?

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.

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  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).

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 :

Code: [Sélectionner]

#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.