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

 

Freebox / Unifi UDM, DHCP & IPV6

De base l'UDM / UDM Pro en mode bridge sur une Freebox fonctionne en IPV4. Ca fait le job, mais parfois on peut avoir besoin d'un adressage en IPV6. J'ai lu pas mal de choses sur ce sujet, plus ou moins précises, notamment sur ce fil et sur ce site, j'ai eu quelques difficultés de mise en œuvre et je vais essayer de faire une synthèse simple.

La première chose à faire est de récupérer l'IPV6 du port WAN actif de l'UDM en s'y connectant en SSH avec la commande ip addr | grep "global dynamic" -B2 -A3 :

# ip addr | grep "global dynamic" -B2 -A3
3: eth9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 10000
    link/ether 74:ac:b9:14:2d:e2 brd ff:ff:ff:ff:ff:ff
    inet 86.66.125.69/24 scope global dynamic eth9
       valid_lft 602510sec preferred_lft 602510sec
    inet6 fe80::76ec:b9xx:fe15:2df2/64 scope link
       valid_lft forever preferred_lft forever

L'IPV6 de notre port WAN est donc : fe80::76ec:b9xx:fe15:2df2/64

On va ensuite sur la page de configuration de la Freebox, dans mon cas une Delta S connectée à l'UDM avec un câble SFP+ dans l'espoir (vain) d'obtenir les 8 Gbit/s promis en 10G EPON. Donc sur http://mafreebox.freebox.fr (Paramètres de la Freebox / Configuration IPV6) et on reporte cette adresse dans le second Next Hop (et pas le premier hein !) afin de déléguer un préfixe. Et on note le préfixe associé.

On configure le port WAN de l'UDM en client DHCPv6 avec une taille de délégation de 64 :

Maintenant on va aller configurer le LAN de l'UDM. On reporte le préfixe précédemment noté au niveau IPV6 Gateway/Subnet et si on souhaite activer le serveur DHCP on défini une IP de départ et une IP de fin. Je ne l'ai pas fait car je souhaitait utiliser le DHCP de mon contrôleur de domaine Windows (pourquoi faire simple... mais idée abandonnée.). Pensez à cocher l'option RA.

A partir de là en SSH sur l'UDM on doit pouvoir pinguer en IPV6 :

# ping6 www.ibm.com
PING www.ibm.com (2a02:26f0:2b00:383::1e89): 56 data bytes
64 bytes from 2a02:26f0:2b00:383::1e89: seq=0 ttl=52 time=11.222 ms
64 bytes from 2a02:26f0:2b00:383::1e89: seq=1 ttl=52 time=11.307 ms
64 bytes from 2a02:26f0:2b00:383::1e89: seq=2 ttl=52 time=11.511 ms

Si on a pas configuré le serveur DHCP, on peut également rapidement configurer un client Windows en statique :

PS C:\Users\Lionel.SUPTEL> ping www.google.com -6
Pinging www.google.com [2a00:1450:4007:819::2004] with 32 bytes of data:
Reply from 2a00:1450:4007:819::2004: time=11ms
Reply from 2a00:1450:4007:819::2004: time=11ms
Reply from 2a00:1450:4007:819::2004: time=11ms
Reply from 2a00:1450:4007:819::2004: time=12ms

DHCP et résilience

Il me reste à configurer le serveur DHCP v6 sous Windows Serveur. Enfin, là se pose une vrai question sur les avantages et inconvénients. Actuellement j'ai un serveur Windows (VM dans un ESXi) dans une infrastructure Active Directory répartie sur plusieurs sites. Donc ça se justifie, et c'est même obligatoire au niveau du DNS.

Par contre, imaginons que demain je ne soit plus là ou dans l'incapacité de maintenir tout ça (infra IP et IoT). Il faut que l'accès internet soit résilient et puisse se passer du host ESXi . Mon idée est donc de basculer le DHCP sur l'UDM, de faire pointer les deux premiers DNS vers des serveurs AD et les deux suivants vers des DNS publics.

Mais pour cela il faut que le DHCP de l'UDM fasse aussi bien que celui de Windows. Et là ce n'est pas gagné. La lacune principale est qu'il n'y a rient pour facilement lister les baux. Sérieux ! Un jour surement dans une nouvelle interface encore plus design. A faire du beau ils en oublient souvent le fonctionnel chez Ubiquiti.

Par contre sur le DHCP WIndows j'utilise l'option 121 (Classless Static Route Option, RFC3442) qui se configure très facilement sur Windows. Sur l'UDM c'est un peu plus compliqué (mais pas plus que sur OpenSense ou Mikrotik). Heureusement il y a ici un calculateur qui va nous permettre de créer la chaine hexa que l'on va va pouvoir entrer dans les options personnalisées dans un champ texte des paramètres DHCP de l'UDM. Pourquoi faire simple !

Bien sur il est impossible d'importer les réservations DHCP de Windows vers l'UDM. Il va donc falloir se les faire à la main en cliquant sur chaque objet. Dans cette interface on peut également figer l'AP utilisé.

Il est intéressant de noter la possibilité d'affecter une IP réservée en dehors de la plage déclarée dans le DHCP. Et ça c'est intéressant. Dans un premier temps je crée un DHCP sur l'UDM avec uniquement une IP disponible et je laisse le DHCP Windows actif qui continuera à affecter les baux. Je fige les IP sur l'UDM et quand c'est terminé je peux arrêter le DHCP Windows et élargir la plage sur l'UDM, et accessoirement faire marche arrière au besoin.

Par contre coté IPv6 il n'est pas possible à ce jour de figer les IP. Ca viendra, peut-être...

Sources