Bien dimensionner l’espace d’adressage d’un VPN site à site

Demandez quelle taille doit avoir le sous-réseau VPN et la réponse honnête est que la question peut contenir quatre sous-réseaux différents. Un VPN de site peut impliquer des points de terminaison de transport, des liens tunnel numérotés, les préfixes du réseau local protégé et, sur les passerelles gérées, un sous-réseau d’infrastructure réservé par le fournisseur. Un ou deux seulement existent dans une conception donnée. Les dimensionner à partir du nombre de postes du bureau, c’est ainsi qu’un plan finit avec un /24 qui ne satisfait personne.

Nommez les quatre rôles avant d’attribuer quoi que ce soit

Les points de terminaison de transport sont les adresses que deux passerelles utilisent pour se joindre à travers Internet ou un circuit privé, et leur nombre vient du modèle de passerelle et de redondance, non du réseau local. Les liens tunnel internes n’existent que là où la conception numérote une interface point à point, ce qu’une configuration IPsec basée sur des règles ne fait généralement pas. Les préfixes protégés sont les vrais réseaux de bureau ou de VPC qui doivent être routables, et le sous-réseau réservé par le fournisseur appartient au service géré.

Inventoriez ce qui existe déjà avant d’ajouter quoi que ce soit, car l’erreur coûteuse ici est de réutiliser un préfixe déjà routé ailleurs. Un tunnel oublié d’un projet pilote suffit à empoisonner un plan. Notez l’inventaire avec des dates, car le souvenir d’un lien décommissionné survit au lien lui-même.

ip -br addr show
ip route show | head -40

Ces deux commandes donnent la vue locale des réseaux connectés et des routes qui atteignent tout ce qui se trouve au-delà. Répétez l’inventaire sur chaque site, car un plan bâti sur la sortie d’un seul site entrera en collision avec celle du suivant. Recueillez les sorties avant d’attribuer le moindre bloc.

Comptez les liens et la topologie, pas les appareils

Une conception avec huit adjacences point à point consomme huit blocs, pas un. En /30, chaque bloc dépense quatre adresses pour relier deux hôtes, si bien que le plan porte trente-deux adresses pour seize extrémités utilisables, et c’est le chiffre que le budget doit tenir. Une plateforme prenant en charge les liens /31 en dépense la moitié, mais seulement si les deux extrémités et le service s’accordent sur ce modèle. Arrondissez le budget vers le haut plutôt que vers le bas, car réduire un bloc plus tard oblige à renuméroter des liens actifs.

Les contraintes du fournisseur l’emportent sur la pratique générale. Une plage interne documentée peut exiger /30 même là où /31 fonctionne sur vos routeurs, et une passerelle gérée peut imposer un masque précis pour son propre sous-réseau. Lisez l’exigence du service avant d’appliquer une règle empirique empruntée à une autre plateforme.

Un maillage multipoint change à nouveau le calcul : une adresse par passerelle, le maillage gérant l’accessibilité entre elles. Décidez quelle topologie la mise en œuvre utilise réellement avant de multiplier les sites par une taille de bloc.

La croissance mérite sa propre ligne dans le plan. Réserver une plage d’infrastructure cohérente est raisonnable, et noter quelles allocations plus petites s’y trouvent l’est aussi, afin que l’ingénieur suivant ne lise pas la réservation comme un seul domaine de diffusion.

Gardez le sous-réseau de passerelle hors du pool du réseau local

L’infrastructure d’une passerelle gérée n’est pas un pool de clients. Les adresses d’un sous-réseau de passerelle réservé hébergent les composants du service lui-même, et les télétravailleurs n’y puisent jamais. Dimensionner ce sous-réseau d’après le nombre d’utilisateurs est une erreur de catégorie qui soit gaspille une grande plage, soit affame la passerelle.

Il en va de même des plages tunnel des connexions VPN cloud, où le fournisseur alloue une petite plage interne par tunnel pour son propre usage. Cette plage n’est pas l’endroit où vivent vos serveurs d’agence, et elle ne vous appartient pas.

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

Lister les adresses extérieures confirme ce que le fournisseur a alloué et quel tunnel redondant est actuellement actif. C’est plus rapide que de lire un document de conception écrit avant l’existence de la connexion.

Consignez rôle, propriétaire et croissance pour chaque préfixe

Un plan qui survit au contact de l’exploitation indique, pour chaque préfixe, le rôle qu’il joue, qui attribue l’extrémité distante et la marge dont il dispose. Sans le champ propriétaire, deux équipes allouent le même /24 au même trimestre, et la collision n’apparaît qu’à la montée du tunnel.

Tenez ces plages à l’écart des préfixes domestiques et d’agence qui arrivent par d’autres tunnels, car le chevauchement d’espace est la raison habituelle pour laquelle une connexion site à site négocie correctement puis ne fait passer aucun trafic.

Attribuer des adresses de lien internes n’annonce pas les réseaux locaux situés derrière. Les routes ou sélecteurs de trafic, les chemins de retour et les règles d’accès sont des tâches distinctes, et le plan doit le dire au lieu de laisser entendre qu’une interface numérotée fait le routage à votre place.