Comment dimensionner l’espace d’adressage d’un VPN multisite

La taille du sous-réseau VPN n’a pas de réponse tant que vous ne nommez pas les adresses que vous comptez. Dans une conception, ce sont les deux extrémités d’une liaison tunnel numérotée, dans une autre, c’est le LAN du bureau derrière un tunnel basé sur des politiques, et dans une troisième, c’est l’infrastructure réservée d’une passerelle gérée. Trois objets, trois budgets, et la plupart des erreurs de dimensionnement viennent du fait de remplir une colonne avec le nombre d’une autre.

Quatre rôles, quatre questions différentes

Le transport externe est l’adresse à laquelle un pair se connecte, sa taille suit donc votre adressage public ou celui du fournisseur, jamais le nombre d’appareils derrière. Les liaisons tunnel internes n’existent que dans les conceptions qui numérotent une interface virtuelle, et là le nombre suit les adjacences de la topologie. Les préfixes de LAN protégé suivent les réseaux réels et leur plan de croissance. L’infrastructure réservée par le fournisseur suit ce que documente le service géré.

Seul le troisième de ces objets a un rapport avec le nombre d’ordinateurs portables au bureau. Cette seule confusion explique la plupart des discussions.

Écrivez les quatre rôles en colonnes séparées avant d’ouvrir une calculatrice. Chacun reçoit son allocation, son propriétaire et son hypothèse de croissance, et aucun n’hérite de la taille d’un autre. Quand une conception n’a pas de liaison interne numérotée, cette colonne est vide plutôt que petite, et une colonne vide est un fait qui mérite d’être consigné pour le prochain relecteur.

Compter les blocs : ce que coûte vraiment un /30

Une liaison point à point a besoin de deux adresses et consomme un bloc dont la taille dépend de la plateforme. Un /30 contient quatre adresses, dont deux sont généralement utilisables, donc douze liaisons consomment quarante-huit adresses dans le plan tout en offrant vingt-quatre extrémités. Un /31 contient deux adresses et les deux sont utilisables, ce qui divise l’arithmétique par deux, mais seulement là où les deux extrémités l’acceptent.

RFC 3021 définit le modèle à deux adresses, et la prise en charge est une propriété des extrémités et du service, non des bonnes intentions. Une API de fournisseur peut imposer sa propre exigence de masque sur une option de tunnel interne, et un RFC général n’annule pas une contrainte documentée. Vérifiez ce que votre plateforme déclare avant de résumer le budget, car la différence entre quarante-huit et vingt-quatre adresses décide si le plan tient dans la plage réservée. Faites l’arithmétique plutôt que de lui faire confiance à la fin d’une longue journée.

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

Ne multipliez qu’une fois la topologie arrêtée. Douze liaisons séparées et une superposition multipoint à douze participants produisent des totaux très différents à partir du même nombre de sites.

Le sous-réseau de la passerelle gérée n’est pas un pool de clients

Un service géré réserve souvent un sous-réseau pour sa propre infrastructure de passerelle, et ce sous-réseau est consommé par le service plutôt que remis aux clients. Il a une taille documentée, parfois un nom documenté, et aucun rapport avec le nombre d’utilisateurs qui se connectent. Le traiter comme le pool d’adresses des machines distantes produit une conception qui s’épuise dès le premier matin chargé.

Lisez l’exigence du fournisseur comme un coût fixe, comme vous traiteriez une unité de rack. Elle ne fait pas partie du budget du préfixe protégé.

La même lecture s’applique aux noms. Un sous-réseau dont l’objet documenté est l’infrastructure de passerelle est une infrastructure par convention dans ce service, et le renommer pour l’adapter à votre propre schéma casse le déploiement au lieu d’améliorer le schéma. Gardez les noms et les tailles du fournisseur, et dépensez votre propre schéma de numérotation sur les parties que vous contrôlez.

Documentez le plan pour qu’il survive au deuxième site

Un plan qui vit dans la tête d’un seul ingénieur échoue au premier chevauchement entre un préfixe de bureau et la plage par défaut d’un routeur domestique. Publiez les allocations avec leurs propriétaires et indiquez quelle extrémité de chaque liaison attribue quelle adresse. Les routes ou les sélecteurs doivent encore être annoncés, car numéroter une liaison interne ne publie pas un LAN à lui seul.

Consignez l’hypothèse de croissance derrière chaque bloc, car c’est la partie qu’aucun lecteur ultérieur ne peut reconstruire à partir des seules adresses.

Testez ensuite le plan avec les cas gênants : un site qui arrive avec un préfixe que vous utilisez déjà, une liaison dont l’extrémité distante est gérée par quelqu’un d’autre, et une région dont l’exigence de fournisseur diffère de la première que vous avez documentée. Si l’un de ces cas force une refonte, ce que vous aviez était un schéma et non une politique. Un plan qui leur survit est assez court pour tenir dans le dépôt à côté de la configuration du tunnel, et c’est exactement là que la personne suivante le cherchera.