IPv6 ULA dans un VPN : un adressage privé, pas une protection

Les adresses qui semblent privées ne le sont pas au sens où la plupart des gens l’entendent, et l’adressage local unique d’IPv6 en est le cas le plus clair. Un préfixe ULA donne à un VPN un plan interne stable pour les ressources situées derrière. Il ne chiffre rien, n’authentifie aucun pair et ne décide pas des services qu’un client peut atteindre. Traiter le préfixe comme un contrôle de sécurité est l’erreur que cet article veut supprimer.

Ce que le préfixe procure réellement

La RFC 4193 réserve fc00::/7 pour un usage local, le bit L distinguant l’espace attribué localement de la forme réservée. En pratique, cela signifie que ce que vous générez est fd00::/8. La spécification définit aussi comment l’ID global de 40 bits doit être dérivé, afin que des sites indépendants ne choisissent pas le même préfixe par accident. Cet espace est conçu pour rester hors de l’internet public, ce qui est une propriété de routage et non une protection.

Au sein d’un site, la disposition habituelle est un ID global /48 découpé en sous-réseaux : un pour les clients du tunnel, un pour le côté serveur, un pour chaque LAN distant. Cette structure est tout le bénéfice, et c’est un bénéfice d’adressage. Chaque paquet a toujours besoin d’une route et toujours besoin d’une politique qui l’autorise.

Confondre le préfixe avec un tunnel, c’est ainsi qu’une conception finit par documenter des adresses fd00 et supposer que le trafic entre elles est protégé. Il ne l’est pas, sauf si autre chose assure la protection.

Pourquoi copier le préfixe de l’exemple fait mal

Chaque tutoriel utilise un préfixe facile à retenir, et chaque lecteur qui le copie hérite du même risque de collision. Deux sites qui se connectent plus tard par un tunnel site à site avec des plages identiques produisent exactement l’ambiguïté connue des espaces privés IPv4 qui se chevauchent. Aucun des deux côtés n’est faux en soi, et le réseau combiné n’a aucun moyen de savoir quelle destination est visée.

Générer l’ID global selon le processus documenté prend une minute et supprime la question. Notez le préfixe, l’entrée de génération et la date à côté du plan d’adressage.

Le risque n’est pas théorique pour qui fusionne des réseaux après une acquisition ou relie deux laboratoires par un VPN. Il n’est pas non plus urgent pour un site unique, et c’est pourquoi il est repoussé jusqu’à ce que la fusion soit déjà planifiée.

Portée et accès sont deux questions distinctes

ULA n’est pas destiné à l’adressage internet ordinaire routé mondialement. Cela ne rend pas fiable chaque hôte qui l’utilise et ne rend pas ces hôtes inaccessibles depuis d’autres réseaux privés connectés. Les pare-feux et les autorisations applicatives décident toujours de ce qu’un pair peut utiliser, et le tunnel fournit toujours l’authentification avec laquelle il a été configuré.

Une sortie internet a besoin de sa propre conception de sortie IPv6. Attribuer une adresse ULA à un client ne crée pas d’accès à des destinations globales arbitraires, et on ne doit pas attendre d’un client qui en reçoit une qu’il navigue sur l’internet public à travers elle.

Deux sites avec des préfixes différents ont toujours besoin de routes de retour pour les plages de l’autre, et les deux pare-feux ont besoin de règles correspondantes. Rien de tout cela ne découle de la famille d’adresses. Ce qui en découle est un travail de documentation : un tableau des préfixes et des systèmes autorisés à répondre sur chacun.

Vérifiez le plan aux deux extrémités

Confirmez que le préfixe apparaît là où vous pensez qu’il apparaît, puis confirmez qu’une destination est réellement joignable à travers lui.

ip -6 address show
ip -6 route show
ping -6 -c 3 fd12:3456:789a:1::1

La liste des adresses montre quelle interface détient quel sous-réseau, et un client qui a reçu le mauvais le montre généralement ici. La liste des routes montre si le préfixe distant a un chemin par le tunnel au lieu d’être rejeté. Le test répond à la seule question qui compte : si un paquet fait l’aller-retour.

Répétez la vérification après une reconnexion, car un client qui conserve son adresse mais perd la route produit une connexion qui semble active et ne transmet rien. L’adresse est la partie facile, et la route est ce qui disparaît. Enregistrez les deux sorties à côté du nom du profil de connexion pour que la comparaison suivante parte de preuves.