VPC, VNet et sous-réseaux : créer votre réseau privé cloud

Un réseau privé virtuel est une plage d'adresses que vous réservez chez un fournisseur, et à l'intérieur de laquelle vos machines se parlent sans passer par Internet. Tout le reste, sous-réseaux, routes, pare-feu, se construit dedans. Cette page vous fait créer ce réseau, le découper, et comprendre la distinction public/privé qui est la source de malentendu la plus fréquente du sujet. Le lab se rejoue sans compte cloud ni carte bancaire.

Ce que vous allez apprendre

• Créer un réseau privé virtuel et le découper en sous-réseaux.
• Comprendre ce qui rend un sous-réseau « public », qui n'est pas ce que son nom laisse croire.
• Répartir vos sous-réseaux sur plusieurs zones sans y perdre en disponibilité.
• Nommer vos ressources pour vous y retrouver dans deux ans.
• Reconnaître l'erreur de chevauchement d'adresses, et la voir échouer en vrai.

Prérequis

La leçon précédente sur l'adressage et le routage. Pour le lab, une machine Linux et l'émulateur feint installé, ou un compte chez un fournisseur si vous préférez travailler en réel.

Le même objet, six noms

Tous les fournisseurs vendent la même chose sous un nom différent. C'est le premier obstacle quand on lit deux documentations en parallèle, et il se lève en une ligne.

Fournisseur	Le réseau privé	Le découpage interne
AWS	VPC	Subnet
Azure	VNet	Subnet
Google Cloud	VPC	Subnetwork
OUTSCALE	Net	Subnet
OVHcloud	Private Network	Subnet
Scaleway	VPC	Private Network

Glissez pour voir

Une différence de fond se cache derrière cette liste, et elle mérite d'être sue : chez AWS, OUTSCALE et Azure, le réseau est régional et le sous-réseau est attaché à une zone précise. Chez Google Cloud, le sous-réseau est lui-même régional et couvre toutes les zones. Cela change la façon de répartir les machines, comme on le verra plus bas.

Créer le réseau, et le dimensionner une bonne fois

Renuméroter un réseau en production est l'une des opérations les plus coûteuses de l'infrastructure cloud, et la décision se prend en trente secondes, souvent sans y penser. Certains fournisseurs permettent d'ajouter une plage secondaire à un réseau existant, ce qui offre une porte de sortie, mais aucun ne permet de changer les adresses déjà attribuées sans toucher aux machines, aux règles de filtrage, aux enregistrements DNS et aux interconnexions. Vérifiez ce que permet votre fournisseur, puis dimensionnez comme si ce n'était pas possible.

Pour un laboratoire ou un premier environnement, un /16 découpé en /24 est un bon point de départ. Ce dimensionnement ne coûte rien, les adresses privées étant gratuites, et il laisse 256 sous-réseaux là où vous en utiliserez une dizaine.

En entreprise, ce plan ne s'improvise pas

Le couple /16 plus /24 est un plan de départ, pas une architecture durable. Quatre situations le mettent en défaut, et elles sont fréquentes : l'espace d'adressage privé est déjà fragmenté par des années d'historique ; plusieurs clouds doivent s'interconnecter sans recouvrement, ce qui interdit que deux d'entre eux utilisent la même tranche ; Kubernetes consomme des plages importantes pour ses pods et ses services, en plus de celle des machines ; et une acquisition peut amener du jour au lendemain un réseau qui recouvre le vôtre.

Dès que l'un de ces cas s'applique, l'allocation ne se décide plus dans la console mais dans l'outil de gestion d'adressage de l'entreprise, en demandant une plage à l'équipe réseau. Le réflexe utile est simple : avant de créer un réseau cloud, demandez quelle tranche vous avez le droit d'utiliser.

Et surtout, tenez un plan d'adressage écrit, même sommaire, dès le deuxième réseau. Un simple tableau dans le dépôt d'infrastructure suffit.

Environnement	Plage réservée	Sous-réseaux prévus
Production	10.20.0.0/16	10.20.1.0/24 public, 10.20.2.0/24 applicatif, 10.20.3.0/24 données
Préproduction	10.30.0.0/16	même découpage, autre tranche
Interconnexion future	10.40.0.0/16	réservé, non utilisé

Glissez pour voir

La troisième ligne est celle qui vous sauvera. Réserver une tranche que vous n'utilisez pas ne coûte rien et garantit qu'un futur VPN ou une future interconnexion trouvera de la place sans chevaucher l'existant.

Le chevauchement, l'erreur qui ne se rattrape pas

Deux réseaux qui partagent une plage d'adresses ne peuvent jamais être interconnectés. Ni par appairage, ni par VPN, ni par lien privé. Le routage n'a aucun moyen de décider si 10.20.1.5 désigne la machine d'un côté ou celle de l'autre.

Il n'existe pas de correctif élégant : il faut renuméroter un des deux réseaux, donc recréer les sous-réseaux et redéployer les machines qui s'y trouvent. Sur une production, cela se planifie sur plusieurs semaines.

Le lab plus bas vous fait déclencher cette erreur volontairement, pour que vous reconnaissiez son message le jour où elle apparaîtra pour de vrai.

Public ou privé : ce n'est pas une case à cocher

Chez AWS et OUTSCALE, un sous-réseau n'est pas « public » par nature : il l'est parce que sa table de routage contient une route vers une passerelle Internet. C'est le point le plus mal compris de ce modèle, et il explique quantité de tickets du type « ma machine a une adresse publique mais ne répond pas ».

Ce modèle est très répandu, et il n'est pas universel. Azure attribue longtemps un accès sortant par défaut et raisonne par groupes de sécurité réseau ; Google Cloud place le routage au niveau du réseau plutôt que du sous-réseau, et une machine sans adresse externe sort par Cloud NAT. Retenez donc l'intention, qui est commune, plutôt que la mécanique : il faut toujours réunir une adresse joignable, un chemin et une autorisation, mais chaque cloud répartit ces trois éléments sur des objets différents.

Reformulé simplement, il y a trois conditions pour qu'une machine soit joignable depuis Internet, et il faut les trois :

1. une adresse publique attachée à la machine ;
2. une route vers une passerelle Internet dans la table du sous-réseau ;
3. une règle de pare-feu qui autorise le trafic entrant sur le port visé.

Enlevez la deuxième, et l'adresse publique ne sert à rien. Enlevez la troisième, et le paquet arrive jusqu'à la machine où il est jeté. Le vocabulaire courant appelle « sous-réseau public » celui qui remplit la deuxième condition, mais rien dans l'objet lui-même ne porte cette propriété.

La conséquence pratique est rassurante : un sous-réseau est privé par défaut. Vous ne l'exposez pas par accident, vous l'exposez en ajoutant une route. C'est l'inverse d'un pare-feu mal configuré, et c'est une bonne nouvelle pour qui débute.

Le découpage à trois étages, et pourquoi il tient

Le schéma qui revient partout, quel que soit le fournisseur :

• le sous-réseau public ne contient que ce qui doit être joignable : le répartiteur de charge, éventuellement un serveur de rebond. Deux ou trois machines, rarement plus ;
• le sous-réseau applicatif contient vos serveurs. Ils sortent vers Internet par une passerelle NAT pour leurs mises à jour, et personne ne les joint directement ;
• le sous-réseau de données contient les bases. Il ne sort pas du tout, et n'accepte que le trafic venu du sous-réseau applicatif.

L'intérêt n'est pas théorique. Le jour où une application est compromise, l'attaquant se trouve dans le sous-réseau applicatif, et il lui reste à franchir une frontière supplémentaire pour atteindre les données. Ce n'est pas une garantie, c'est du temps gagné, et le temps est exactement ce qui manque lors d'un incident.

Répartir sur plusieurs zones

Une zone de disponibilité peut tomber ; c'est la raison d'être des autres. Répartir coûte souvent zéro euro de plus en infrastructure, et change tout en cas de panne.

La règle est simple chez AWS, Azure et OUTSCALE : un sous-réseau vit dans une seule zone. Pour couvrir trois zones, il faut donc trois sous-réseaux, avec trois plages distinctes.

Zone	Sous-réseau public	Sous-réseau applicatif
Zone A	10.20.1.0/24	10.20.11.0/24
Zone B	10.20.2.0/24	10.20.12.0/24
Zone C	10.20.3.0/24	10.20.13.0/24

Glissez pour voir

Chez Google Cloud, le sous-réseau étant régional, un seul suffit pour couvrir les trois zones : vous placez simplement les machines dans des zones différentes. C'est plus simple, et c'est une vraie différence d'architecture, pas un détail de vocabulaire.

Ce que la répartition sur trois zones coûte vraiment

L'infrastructure réseau ne coûte rien de plus, mais deux postes apparaissent et surprennent en fin de mois.

• Le trafic entre zones est facturé chez plusieurs fournisseurs, souvent autour de 0,01 €/Go dans chaque sens. Une application bavarde entre son serveur en zone A et sa base en zone B paie ce trajet en permanence. Gardez les échanges intensifs dans une même zone, et répartissez ce qui doit survivre.
• La passerelle NAT est facturée par zone. Le schéma résilient en demande une par zone, donc trois lignes de facture au lieu d'une.

La bonne pratique n'est pas de renoncer à la répartition, c'est de la réserver à ce qui doit survivre à une panne, et de mesurer le trafic inter-zones plutôt que de le découvrir.

Nommer, pour se retrouver dans deux ans

Une convention de nommage est une décision de cinq minutes qui vous fait gagner des heures à chaque incident. Sans elle, une console affiche quarante ressources aux noms inventés au fil de l'eau, et personne n'ose rien supprimer.

Une convention qui a fait ses preuves tient en quatre champs : <environnement>-<rôle>-<zone>-<numéro>, ce qui donne prod-app-a-01 ou preprod-db-b-02. L'ordre compte : en commençant par l'environnement, le tri alphabétique regroupe naturellement ce qui va ensemble.

Ajoutez-y des étiquettes, ces couples clé-valeur que tous les fournisseurs proposent. Trois suffisent pour commencer, et elles répondent aux trois questions qu'on se pose devant une ressource inconnue.

Étiquette	Répond à	Exemple
environnement	Puis-je y toucher sans risque ?	production
equipe	Qui appelle-t-on ?	paiement
projet	Qui paie ?	refonte-caisse

Glissez pour voir

La troisième est celle qui transforme une facture illisible en tableau de répartition par projet. Sans elle, la question « combien nous coûte la refonte » n'a pas de réponse.

Lab : créer un réseau sans compte cloud

Ce lab se joue sur l'émulateur feint, qui sert les API en local. Aucune ressource n'est créée chez un fournisseur, aucune facture n'est émise, et vous pouvez tout casser sans conséquence.

1. Démarrer l'émulateur

   feint serve

   Laissez ce terminal ouvert et travaillez dans un second.

2. Configurer le client officiel

   eval "$(feint env scaleway)"

   Cette commande exporte l'adresse de l'émulateur et des identifiants factices dans votre terminal. Le CLI scw officiel n'y voit que du feu.

3. Créer le réseau privé virtuel

   scw vpc vpc create name=lab-reseau

   ID                              b1269474-d962-4a37-b252-2f3ef9565a93
   Name                            lab-reseau
   OrganizationID                  99999999-9999-4999-8999-999999999999
   ProjectID                       11111111-1111-1111-1111-111111111111
   Region                          fr-par
   IsDefault                       false

   Notez l'identifiant, la commande suivante en a besoin.

4. Créer deux sous-réseaux avec des plages distinctes

   scw vpc private-network create name=lab-public vpc-id=<ID_DU_VPC> subnets.0=10.20.1.0/24
   scw vpc private-network create name=lab-prive  vpc-id=<ID_DU_VPC> subnets.0=10.20.2.0/24

5. Provoquer volontairement l'erreur de chevauchement

   scw vpc private-network create name=lab-doublon vpc-id=<ID_DU_VPC> subnets.0=10.20.1.0/24

   Invalid arguments 'subnets'
   
   Details:
   - 'subnets' does not respect constraints
   
   Hint:
   Subnet 10.20.1.0/24 overlaps 10.20.1.0/24

   Voilà le message. Il est explicite ici parce que le conflit est interne au même réseau ; entre deux réseaux distincts que l'on cherche à interconnecter, l'erreur arrive beaucoup plus tard et beaucoup moins clairement.

6. Relire ce que vous avez construit

   scw vpc private-network list

   lab-public     10.20.1.0/24, fdba:fde8:9c04:f111::/64
   lab-prive      10.20.2.0/24, fdba:fde8:9c04:20a4::/64

L'IPv6 que vous n'avez pas demandé

Regardez la dernière sortie : chaque sous-réseau porte une plage IPv6 en plus de l'IPv4, alors que vous n'avez rien demandé. Scaleway attribue un préfixe /64 d'office, et il n'est pas seul à le faire.

Ce n'est pas anodin. Une machine peut être joignable en IPv6 alors que vos règles de pare-feu n'ont été écrites que pour IPv4 : le filtrage porte sur des adresses, et vos règles ignorent la moitié de la surface exposée. La leçon consacrée à IPv6 revient sur ce point, qui est un classique des audits.

Cette double surface explique pourquoi la manipulation qui suit reste un exercice d'API. Créer un découpage et lire les messages d'erreur enseigne le vocabulaire et les contraintes du fournisseur ; cela ne remplace pas l'observation du trafic réel, et il vaut mieux savoir précisément ce que l'exercice démontre avant d'en tirer des conclusions.

Ce que ce lab prouve, et ce qu'il ne prouve pas

Il prouve que vous savez enchaîner les appels d'API et que vous reconnaîtrez le message de chevauchement. Il ne prouve rien sur le trafic réel : sans runtime, aucun paquet ne circule, et une règle de pare-feu écrite ici ne filtre rien du tout.

C'est la limite honnête de tout émulateur, détaillée dans ce que feint prouve et ne prouve pas. Le plan de contrôle se teste en local ; le chemin réseau se teste sur une infrastructure réelle.

À retenir

• Le réseau privé virtuel, c'est le même objet partout, sous six noms différents. Retenez l'objet, pas le nom.
• La plage du réseau ne se change plus après création. Prévoyez un /16, découpez en /24, et réservez une tranche pour l'avenir.
• Deux réseaux qui se chevauchent ne seront jamais interconnectables. C'est l'erreur qui impose une renumérotation.
• Chez AWS et OUTSCALE, un sous-réseau est public par sa route, pas par une case à cocher. Ailleurs les primitives diffèrent, mais les trois conditions restent : adresse joignable, chemin, autorisation.
• Un sous-réseau vit dans une zone chez AWS, Azure et OUTSCALE ; il est régional chez Google Cloud.
• Le trafic entre zones est facturé et la passerelle NAT est facturée par zone : répartissez ce qui doit survivre, pas tout.
• Nommez et étiquetez dès la première ressource, sinon la facture restera illisible.

Prochaines étapes

Tables de routage et passerelles Rendre un sous-réseau public, et comprendre ce qui se passe vraiment.

Sécurité réseau : groupes et listes de contrôle La troisième condition, celle du filtrage.

Régions, zones et disponibilité Choisir où placer vos ressources, et ce que la répartition change.

Le coût du transfert sortant Chiffrer le trafic entre zones et vers Internet avant de concevoir.

×

📖 Voir la documentation →