IPv6 @ Scaleway...

Depuis plus de 20 ans tout le monde parle d'IPv6, mais dans la pratique ce n'est pas encore l'euphorie au niveau de l'adoption. En France, une fois n'es pas coutume, on est un peu en avance, Free en tête qui a passé tout son réseau fibre en IPv6. En fait du 4rd pleinement documenté dans le RFC 7600. Dans la pratique c'est du tunneling (donc 2 clients qui discutent en IPv4 le font par un tunnel direct au dessus de leur IPv6, ca ne passe par une passerelle).  Par contre à ce que j'ai pu lire la sortie IPv4 vers le reste du monde ce fait via des 'Border Relay 4rd' ou du NAT64+. Et là si ces équipement ne sont pas suffisamment dimensionnés ça peut créer un goulot d'étranglement.

Il y a quelques temps je me suis aperçu que l'un de nos serveurs hébergé chez Scaleway présentait en soirée une importance latence, voire des lags pour les clients Free, ce qui est un comble car Free et Scaleway font partie de la même boutique !

Il semble donc qu'il y ait un entonnoir au niveau de la passerelle de sortie vers l'IPv6. Je ne connais pas les détails de l'infrastructure Free, mais je me suis dit qu'en rendant mon serveur accessible en IPv6 je pourrais contourner le problème, et que de toutes façons il était temps que je passe ma part d'IPv6 !

Sauf que ce n'est pas si simple, d'une par je n'ai jamais pratiqué, et d'autre par la documentation fournie par Scaleway est obsolète.

Chez Scaleway j'ai deux types d'approche, des serveurs loués (Dédibox) et une infra avec les propres serveurs installés dans une baie louée (Dédirack). Mon serveur étant une VM sous Windows 2019 sur un serveur Dédibox je me suis basé sur la documentation officielle qui fait référence à la fourniture d'un DUID (sur la console Online) après avoir demandé un bloc IPv6 et passé le serveur en SLAAC. Au vu des captures d'écrans cette doc doit dater de l'époque Windows NT (siècle dernier), j'espère qu'ils vont  la mettre à jour, aussi je mets les copies d'écran de la version actuelle ici : 1 | 2 .

Cette documentation mets en avant l'utilisation du DUID en modifiant une clé de registre de Windows. Hors changer le DUID dans l'implémentation Windows est devenu impossible comme l’expliquent ces deux articles parmi tant d’autres 1 | 2.

Le DUID change maintenant à chaque reboot en se basant sur l'adresse MAC de l’interface. C'est maintenant le comportement normal et attendu. Cette doc n'a donc plus lieu d'être dans sa version actuelle !

En fait pour obtenir une IPv6 sous Windows il n'y a rien de plus à faire que d'activer le stack IPv6 de Windows par défaut (client DHCP) (après avoir demandé un bloc IPv6 /48). Et c'est tout, l'obtention de l'IPv6 se fait via le serveur DHCPv6 de l'infrastructure Scaleway (il est également possible de renseigner une adresse prise dans le bloc).

Alors, pourquoi toute cette galère depuis des mois ?

Je me suis obstiné sur l'utilisation du DUID que la documentation mets en avant ! Normal j'ai appris à lire. Et d’autres sites y font référence. Ensuite il se trouve que cette machine avait un firewall plutôt blindé, et comme elle n'utilisait pas d'IPv6 auparavant tous les entrées Core Networking IPv6 étaient désactivées, donc les échanges avec le DHCPv6 et RA ne pouvaient pas se faire correctement. Je les ai réactivés dès lors que j’ai compris que la première option était obsolète.

A aucun moment le support Scaleway n'a su me dire qu'il ne fallait pas poursuivre dans la voie du DUID, ce qui aurait évité une perte de temps de toutes parts ! Le ticket de support n’est surement pas remonté auprès des bonnes personne et la culture Windows pas très présente, et meme si je les comprends il est impossible aujourd'hui d'ignorer le monde Microsoft !

Par contre de base Windows génère une IPv6 aléatoire, ce qui peut être utile sur un client mais gênante sur un serveur, on désactive en PS:

  Set-NetIPv6Protocol -RandomizeIdentifiers Disabled

Ou :

  netsh interface ipv6 set global randomizeidentifiers=disabled store=active
  netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
  netsh interface ipv6 set privacy state=disabled store=active
  netsh interface ipv6 set privacy state=disabled store=persistent

On peut également désactiver l'utilisation d'une IPv6 temporaire :

  Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

Voilà, en espérant que Scaleway clarifie son article car si le passage de l'utilisation d'un DUID à du full DHCPv6 facilite largement la tâche, encore faut-il l'expliquer ! Je n'ai pas testé sous Linux, mais sous pfsense ou OPNsense la procédure est relativement identique.

Et dans un Dédirack ?

On aurait pu penser au vu de la console Online qui affiche sur une même pages les infos réseau de mon Dédirack (IPv4) et de mon bloc IPv6 /48 que ce bloc soit également utilisable dans la baie Dédirack. Mais non, après avoir lourdement insisté auprès du support j'ai enfin eu la réponse :

Pour faire de l'IPv6 dans un Dédirack (offre housing de Scaleway), il faut demander au support un bloc /48 et ensuite le gérer en statique à sa convenance. Ca ne s'invente pas.

Et ça fonctionne ? Et bien non, car il aura fallu plusieurs jours et plusieurs personnes pour que l'on s'aperçoive que quelqu'un ne sais pas faire de copié/collé chez eux (ou un farceur ?), et que dans le bloc /48 que l'on m'a fourni il y avait un C00D qu'il fallait lire C00C !

Et sur l'offre Elastic Metal ?

Je n'ai pas encore testé, mais j'y ai installé un serveur ESXi et je crois savoir que la procédure est encore différente.

Sources et liens

 

Ajouter un commentaire

Loading