Choisissez l'espace d'adresses VPN par allocation, non par obscurité

Un préfixe d'apparence inhabituelle semble une échappatoire au conflit d'adresses entre la maison et le bureau, et ce n'est généralement pas le cas. Chaque bloc du registre IPv4 des usages spéciaux a un propriétaire, un objectif et une raison d'exister, et en emprunter un parce qu'il paraît discret déplace la collision au lieu de la supprimer. Procédez comme une séquence : lisez l'allocation, inventoriez ce qui se chevauche déjà, et seulement ensuite décidez si vous renumérotez, traduisez ou générez un espace neuf. L'ordre compte, car la troisième étape dépend de ce que les deux premières ont trouvé.

Lisez l'allocation avant d'emprunter une plage

Le registre des usages spéciaux de l'IANA sépare les plages qui sont un espace privé réutilisable de celles qui servent un objectif technique précis. L'usage privé, l'espace d'adresses partagé, la référence et les blocs de documentation se ressemblent dans un tableur et se comportent tout autrement une fois routés.

Deux préfixes qui ne diffèrent que par le deuxième octet ne sont pas le même bloc : 198.18.0.0/15 porte la réservation de référence, tandis que 192.18.0.0/16 n'en porte rien de tel. Un numéro qui ressemble seulement à une plage réservée n'en hérite pas le sens. Cette confusion est assez courante pour justifier un second regard avant qu'elle n'atteigne une règle de pare-feu.

Les produits utilisent parfois délibérément une plage spéciale au sein d'une superposition coordonnée, et c'est leur conception, à documenter. Cela ne fait pas de la même plage un espace libre pour un LAN sans rapport. L'espace public n'est pas un refuge non plus : une route privée vers une adresse qui appartient à quelqu'un d'autre détourne le trafic destiné à sa destination légitime.

Inventoriez les chevauchements que vous avez déjà

Avant de choisir un préfixe, listez chaque réseau qui sera joignable depuis le tunnel. Les sites, les pools de clients, les VPC cloud et les liaisons partenaires comptent tous, et la liaison partenaire est celle qu'on oublie jusqu'à ce que la première tentative de connexion échoue.

ip -4 route show table all
ip -6 route show
ip -br addr
ip route get 192.168.1.10

Placez les résultats dans un seul tableau avec le propriétaire de chaque plage à côté. Une plage dont vous ne pouvez pas nommer le propriétaire est une plage que vous ne pourrez pas renuméroter plus tard, et l'inventaire est ce qui transforme un débat sur des préfixes « inhabituels » en décision sur des numéros précis. Il vous dit aussi si le conflit que vous cherchez à éviter est réel ou imaginaire.

Si le réseau domestique d'un télétravailleur utilise le même préfixe que le LAN du bureau, ce conflit est visible dans l'inventaire et peut être traité explicitement. Ce n'est pas la preuve qu'un bloc de référence serait un choix astucieux, et c'est ainsi que se crée la collision suivante.

Générez une ULA unique au lieu de copier un préfixe

IPv6 résout le problème de réutilisation par un mécanisme différent plutôt que par un numéro plus joli. La RFC 4193 définit des adresses locales uniques attribuées localement avec un identifiant global pseudo-aléatoire de 40-bit, ce qui vous donne un /48 pour un site très peu susceptible d'entrer en collision avec celui d'un autre. La probabilité est élevée, pas absolue, et un préfixe ULA n'offre toujours aucune joignabilité Internet.

openssl rand -hex 5

Dix chiffres hexadécimaux font quarante bits. Préfixez-les de fd et regroupez-les dans le /48 : une sortie 3f9c1a7b02 devient fd3f:9c1a:7b02::/48. Générez-en un par site et notez-le, au lieu de coller le même fd00::/48 commode dans chaque déploiement.

Confirmez ensuite que tout le chemin parle réellement IPv6. Les clients, la passerelle, les routes, le DNS privé et la politique de service doivent tous s'accorder, et attribuer un préfixe au tunnel ne fait pas qu'une application uniquement IPv4 l'utilise.

Planifiez le chevauchement que vous ne pouvez pas supprimer

Certains chevauchements sont permanents, généralement parce qu'un partenaire ne renumérotera pas et que vous ne pouvez pas l'y contraindre. C'est alors que vous choisissez délibérément un mécanisme pris en charge : renumérotation de votre côté, contexte de routage isolé ou traduction explicite à une frontière. Choisir délibérément signifie écrire lequel vous avez retenu et pourquoi les deux autres ont été écartés. Cette note est ce qu'une future revue de changement lira réellement.

La traduction doit préserver le chemin de retour, ce qui suppose d'enregistrer à la fois le préfixe d'origine et celui présenté et de les associer aux noms DNS privés qui y résolvent. Un alias mappé peut rendre une connexion non ambiguë ; il ne rend pas les adresses d'origine globalement uniques et ne survivra pas à un second partenaire chevauchant sans un second mappage.

Écrivez l'allocation avec son exception

Terminez par un document qui liste chaque préfixe, sa catégorie, son propriétaire et la raison du choix. Ajoutez les exceptions avec leur règle de traduction ou de renumérotation, et la date à laquelle quelqu'un les a approuvées. Conservez-le à côté des règles de pare-feu qui l'appliquent, plutôt que dans un wiki que personne n'ouvre pendant un incident. Le document est le livrable, pas son résumé.

Cet enregistrement est ce qui empêche l'ingénieur suivant de chercher un numéro d'apparence plus étrange, et c'est ainsi que ce problème est redécouvert tous les quelques années sous un nouveau nom. Il donne aussi à une revue de changement quelque chose de concret à approuver plutôt qu'une opinion sur les préfixes. Écrivez-le une fois, à la fin de l'allocation, tant que le raisonnement est encore devant vous.