Planifiez les plages d’adresses VPN privées avant que les sites n’entrent en collision

Deux sites qui utilisent tous deux 192.168.1.0/24 peuvent chacun atteindre internet et pourtant ne pas s’atteindre. La passerelle ne signale aucune erreur ; elle installe une seule route pour ce préfixe et envoie chaque paquet au pair qui l’a revendiqué le premier. Rien dans la poignée de main, la liste de chiffrement ou la métrique de l’interface ne dit quel pair est fautif. La planification d’adresses est la partie de la conception qui règle cela avant que quiconque se connecte.

Inventoriez chaque espace qui doit être joignable

Notez les plages qui doivent être routées, pas seulement celles que vous configurez. Cela comprend les LAN des sites, les pools de clients VPN, les sous-réseaux cloud, les réseaux de gestion et hors bande, les segments de laboratoire et les réseaux depuis lesquels les utilisateurs se connectent habituellement chez eux. Un routeur grand public livré en 192.168.1.0/24 n’est pas hypothétique, et le même préfixe apparaît dans les hôtels et les centres de conférence. L’inventaire est un tableau de préfixe, propriétaire et objectif, et c’est le seul artefact qui empêche la même plage d’être attribuée deux fois.

Ajoutez les préfixes que vous prévoyez dans l’année à venir, car un plan qui ne couvre qu’aujourd’hui échoue au premier nouveau site. Marquez chaque ligne avec qui peut la modifier, pas seulement qui la possède.

C’est la réutilisation qui rend la chose difficile : l’espace privé est fini et chaque organisation considère 10.0.0.0/8 comme le sien. Un plan ne peut pas promettre qu’aucun LAN invité futur ne tombera sur l’un de vos préfixes, donc la conception doit dire ce qui se passe quand cela arrive. Deux règles font l’essentiel du travail. Placez les pools de clients dans un bloc contigu que vous pouvez résumer, et n’attribuez jamais une plage qu’une autre équipe route déjà. Tout le reste est un registre que quelqu’un tient à jour.

Pourquoi un chevauchement défait la table de routage

Une route est un préfixe plus un prochain saut, et le transfert choisit le préfixe correspondant le plus long. Quand deux pairs revendiquent tous deux 192.168.1.0/24, la table n’en garde qu’une entrée, donc le trafic des deux sites sort par le même tunnel. Le second site n’est pas mal configuré ; il est injoignable parce que le premier répond pour les mêmes adresses. Aucune métrique ne peut les séparer, car la correspondance se produit avant que les métriques soient consultées.

La panne est asymétrique et facile à mal lire. Les hôtes du site A joignent la passerelle et certains services, tandis que ceux du site B ne répondent à rien, et le journal montre un tunnel sain dans les deux sens. Ce schéma est une collision d’adresses et non une panne d’authentification ou de pare-feu, et le confirmer demande un vidage de table comparé à l’inventaire.

Dimensionnez délibérément le pool de clients et les plages des sites

Un pool de clients VPN est une plage que la passerelle distribue une adresse à la fois, sa taille plafonne donc la concurrence. Un /24 contient 254 adresses utilisables, ce qui est généreux pour une petite équipe et serré pour une agence qui exécute des conteneurs ; un /22 ne coûte rien de plus dans l’espace privé et supprime la discussion. Gardez le pool contigu et à l’écart de chaque LAN de site, pour que la route résumée vers les clients n’avale jamais un site. Réservez la plage même quand le pool est vide, car une plage non écrite est celle que le prochain ingénieur attribuera.

Les sites reçoivent des plages dimensionnées pour les hôtes attendus plus la croissance, alignées sur une frontière qui se résume proprement. Des écarts délibérés entre attributions ne coûtent rien et achètent de la place pour agréger plus tard.

Vérifiez ensuite la direction que les gens oublient : le chemin de retour. Chaque routeur de site a besoin d’une route vers le pool de clients, et le concentrateur a besoin d’une route vers chaque préfixe de site qu’il sert. Une table de préfixes bien tenue sans chemin de retour vers le pool reste une conception cassée, et le symptôme est une connexion unidirectionnelle qui ne répond à rien. Gardez les deux directions dans la même table et révisez-la chaque fois qu’un site est ajouté.

La traduction et la renumérotation résolvent des problèmes différents

Quand un chevauchement existe déjà, il y a deux options honnêtes et une malhonnête. La renumérotation supprime la collision définitivement et coûte une fenêtre de maintenance plus chaque adresse codée en dur que vous avez oubliée. La traduction d’adresses mappe la plage privée d’un côté dans une autre plage au bord du tunnel, ce qui laisse les deux sites intacts mais ajoute de l’état, casse les protocoles qui embarquent des adresses et rend les journaux plus difficiles à lire. L’option malhonnête est une route d’hôte vers un seul serveur, qui passe un test et échoue à tout le reste.

Choisissez selon le contrôle et la durée de vie. Un site que vous possédez et pouvez planifier relève de la renumérotation ; un réseau partenaire que vous ne pouvez pas toucher, utilisé pour une seule application, est candidat à la traduction avec une correspondance documentée. Écrivez cette correspondance, car une traduction qui n’existe que dans un fichier de configuration disparaît à l’instant où le fichier est remplacé.

Testez depuis le côté distant avant de déployer

Testez depuis un réseau qui n’héberge pas la passerelle, car le LAN de la passerelle masque la plupart des erreurs de routage. Connectez un client derrière un routeur domestique ordinaire, puis joignez un service sur chaque site et un à l’intérieur du pool de clients. Testez aussi la direction inverse, d’un hôte de site vers le client, car les chemins de retour échouent indépendamment. Un test qui ne fait que pinguer la passerelle prouve que le tunnel est monté et rien de plus.

Gardez les plages, les propriétaires et les correspondances de traduction dans un registre partagé unique que le site suivant lit avant d’attribuer quoi que ce soit. Révisez-le quand un site est ajouté, et traitez une plage non documentée comme un défaut plutôt qu’une surprise.

Le registre est le livrable. Un plan qui vit dans la mémoire de trois personnes échoue la première fois que l’une d’elles est en congé, et un chevauchement trouvé en production coûte plus que la table ne l’aurait fait.