Réseaux avancés : VPC, routage, InterLink et VPN

Pourquoi

À la fin du cours Le cloud : les fondamentaux, Signalements vivait dans un seul réseau privé, pn-signalements (172.16.20.0/22), où les instances, la base et la passerelle se voyaient toutes. C'était suffisant pour une application et une équipe. Ce ne l'est plus pour trois raisons.

L'application a grandi. Il y a maintenant un groupe d'instances qui s'agrandit les soirs d'orage, une base avec un réplica en lecture, un Redis, des fonctions qui traitent les photos. Une instance compromise dans ce réseau unique peut tenter de se connecter à tout le reste : à la base, au Redis, au bastion. Rien, au niveau du réseau, ne distingue un serveur d'application d'un poste d'administration.

Un client veut entrer. La métropole cliente fait tourner un système d'information géographique (SIG) sur un serveur de sa direction des services techniques, dans son propre réseau (192.168.50.0/24). Elle veut pousser chaque nuit le référentiel des voies et des équipements dans Signalements, et en tirer les signalements géolocalisés. Le service informatique de la métropole refuse que ces données passent en clair sur Internet, et refuse tout autant d'exposer son SIG publiquement. Il faut un lien chiffré entre son réseau et le nôtre.

L'audit le demande. Le contrat de la métropole exige de pouvoir dire, flux par flux, qui peut parler à qui. « Tout le monde peut tout joindre dans le réseau privé » n'est pas une réponse que l'on peut écrire dans un dossier de sécurité.

Sans les outils de cette leçon, on improvise : une IP publique sur la base « juste pour la nuit », une liste d'adresses autorisées que personne ne tient à jour, un VPN monté à la main que tout le monde a oublié. Cette leçon remplace ces bricolages par ce que Scaleway fournit.

Les concepts

Un VPC, plusieurs réseaux privés

Rappelons les deux niveaux vus au cours précédent : le VPC est un domaine de niveau 3, régional, et chaque réseau privé est un segment de niveau 2, régional lui aussi, à l'intérieur d'un VPC. Ce qui est nouveau ici, c'est d'en avoir plusieurs dans le même VPC, et de les relier par du routage plutôt que de tout mettre sur le même segment.

La documentation de Scaleway recommande explicitement ce découpage par fonction, au nom de la séparation des responsabilités : moins de trafic de diffusion sur chaque segment, une organisation lisible, un dépannage plus simple, et surtout un endroit où poser un filtre. Pour Signalements, le découpage retenu est le suivant :

Deux contraintes ont dicté ce tableau, et elles sont typiques :

• Le bloc d'un réseau privé ne se modifie pas après sa création. La documentation du VPC Peering le rappelle : en cas de chevauchement, il faut supprimer le réseau et le recréer. Le plan d'adressage se décide donc avant, avec de la marge, comme le montre la leçon Découper en sous-réseaux.
• Tous les produits ne suivent pas le routage VPC. Au 5 octobre 2026, la documentation liste six produits qui peuvent être rattachés à un réseau privé sans prendre en charge le routage VPC : Clusters for Apache Kafka, Clusters for Apache Spark, Cloud Essentials for OpenSearch, Data Warehouse for ClickHouse, Managed Databases for MongoDB, et Managed Database for Redis. Le Redis de Signalements ne serait pas joignable depuis un autre réseau privé que le sien : il doit donc vivre dans le même réseau que les instances qui l'utilisent. D'où sa place dans pn-signalements, et non dans pn-sig-donnees où on l'aurait spontanément rangé.

Le routeur virtuel et sa table de routes

Chaque VPC dont le routage est activé possède un routeur virtuel (vRouter), entièrement géré par Scaleway et non configurable directement. Il tient la table de routes du VPC et la synchronise sur chaque ressource au moment où elle rejoint un réseau privé. Une route se compose d'une destination (un préfixe), d'un saut suivant (next hop), d'une description et d'une portée (tout le VPC, ou certains réseaux privés).

Trois sortes de routes y apparaissent :

La règle de choix est celle de tout routeur, décrite dans la leçon Le routage : le préfixe le plus long l'emporte. Une route vers 172.16.8.0/22 passe avant la route par défaut.

Quatre comportements, documentés, ont des conséquences pratiques :

1. Le routage est activé par défaut sur tout VPC créé aujourd'hui, et il peut être activé sur un ancien VPC. Il ne peut pas être désactivé ensuite.
2. Dès qu'il est activé, tous les réseaux privés du VPC communiquent entre eux. Découper en trois réseaux ne cloisonne rien tant qu'aucun filtre n'est posé : c'est le rôle des Network ACL, plus bas.
3. Les routes personnalisées sont annoncées dans tout le VPC sur les VPC créés depuis le 1er juillet 2025 (ou mis à jour vers ce comportement). Avant, elles n'étaient annoncées que sur le réseau privé de la ressource désignée comme saut suivant. Une route vers un VPN monté sur une instance de pn-sig-admin est donc visible aussi depuis pn-signalements : si ce n'est pas souhaité, c'est encore une Network ACL qui le règle.
4. Les routes par défaut restent locales par défaut. Une passerelle publique n'annonce sa route 0.0.0.0/0 qu'aux réseaux privés auxquels elle est attachée. Chaque réseau privé peut choisir de recevoir aussi les routes par défaut annoncées ailleurs dans le VPC (option default-route-propagation-enabled). La documentation prévient que si une ressource reçoit plusieurs routes par défaut, celle qu'elle utilise dépend de son système ; sous Ubuntu, probablement la première reçue. Mieux vaut ne pas laisser ce choix au hasard.

Les routes personnalisées servent à envoyer un trafic vers un équipement que vous gérez : une instance pare-feu par laquelle tout doit passer, un VPN monté à la main, une appliance. La destination 0.0.0.0/0 est permise : elle est alors traitée comme une route par défaut, avec la même portée locale. Une limite documentée : le routage VPC ne prend pas en charge les adresses IP virtuelles.

Les Network ACL en profondeur

Le cours précédent les a présentées en une phrase. Les voici en détail, parce que ce sont elles qui transforment trois réseaux privés en trois zones de confiance.

Une Network ACL est une liste de règles attachée au VPC, qui filtre le trafic quand il entre dans un réseau privé ou en sort pour aller vers un autre réseau du même VPC. Ses propriétés, toutes documentées :

• Sans état. Contrairement aux groupes de sécurité que vous créez vous-même, elle ne suit pas les connexions. Si vous autorisez pn-signalements à joindre le port 5432 de pn-sig-donnees, la réponse de PostgreSQL, qui part du port 5432 vers un port éphémère du client, doit être autorisée par une seconde règle. L'exemple de la documentation autorise les ports 32768-65535 en retour ; c'est une plage qui englobe celle que Linux utilise par défaut (32768-60999, voir la leçon UDP et les ports).
• Ordonnée. Les règles sont lues de haut en bas, la première qui correspond s'applique (accepter ou jeter), et l'évaluation s'arrête là.
• Une règle par défaut obligatoire, accept ou drop, pour tout ce qui ne correspond à aucune règle. La bonne pratique, que la documentation recommande aussi, est drop par défaut et uniquement des règles accept au-dessus.
• Deux listes séparées, une pour IPv4 et une pour IPv6. Une règle IPv4 ne dit rien du trafic IPv6 : si vos réseaux ont un bloc IPv6 (ce qui est le cas par défaut), pensez à la seconde liste.
• 255 règles au plus par famille et par VPC.
• Elle ne filtre ni le trafic à l'intérieur d'un même réseau privé, ni le trafic avec Internet. Le premier relève du pare-feu de l'hôte, le second des groupes de sécurité et de leurs équivalents.
• Elle ne peut pas bloquer le DNS et le DHCP de Scaleway, ni le service de métadonnées des instances.

Une Network ACL trace des frontières grossières entre zones ; elle ne remplace pas le pare-feu de chaque machine.

Plusieurs passerelles publiques

Une passerelle publique est zonale : si la zone fr-par-1 tombe, les instances de fr-par-2 qui sortaient par elle perdent leur accès à Internet, et donc leurs mises à jour et leurs appels aux API externes. Le cours précédent a mentionné la réponse : attacher plusieurs passerelles, dans plusieurs zones, au même réseau privé.

Avec le routage VPC, on peut aussi faire recevoir aux autres réseaux les routes par défaut de tout le VPC, ce qui simplifie mais concentre la sortie sur des équipements zonaux. Pour Signalements :

• deux passerelles sur pn-signalements, une en fr-par-1, une en fr-par-2 ;
• pn-sig-donnees sans sortie vers Internet : la base managée n'en a pas besoin, et un réseau de données sans route par défaut, c'est un chemin d'exfiltration en moins ;
• pn-sig-admin qui opte pour les routes par défaut du VPC, parce que l'instance d'administration a besoin de ses mises à jour mais pas d'une passerelle à elle.

Relier un autre réseau : quatre outils

Pour relier le réseau de la métropole au VPC, ou un VPC à un autre, Scaleway propose au 5 octobre 2026 quatre approches, avec leurs équivalents chez les autres fournisseurs :

Quelques précisions, toutes tirées de la documentation :

• Site-to-Site VPN ne sait pas relier deux VPC Scaleway entre eux : l'ASN de la passerelle client doit être différent de celui de Scaleway, 12876. C'est le rôle de VPC Peering.
• InterLink est hébergée (via un opérateur partenaire, de 100 Mbit/s à 25 Gbit/s garantis) ou auto-hébergée (sur votre propre connexion physique). Elle s'attache à un seul VPC (deux InterLink pour la redondance) et porte deux sessions BGP, une par famille d'adresses.
• VPC Peering relie deux VPC de la même région, du même projet ou non, de la même organisation ou non. Il faut un connecteur de chaque côté, créé par quelqu'un qui gère chacun des deux VPC (le consentement est mutuel), aucun chevauchement de blocs entre les réseaux des deux VPC, et des routes personnalisées de part et d'autre. La transitivité (A joint C à travers B) est possible jusqu'à quatre VPC chaînés, si elle a été activée à la création du VPC intermédiaire.

Pour la métropole (quelques centaines de mégaoctets par nuit, un équipement déjà capable d'IPsec), le choix est Site-to-Site VPN.

Site-to-Site VPN : les pièces

Le service se compose de quatre objets, que la documentation présente dans cet ordre :

    flowchart LR
  subgraph SCW["VPC vpc-signalements (fr-par)"]
    PN["pn-signalements<br/>172.16.20.0/22"]
    VGW["Passerelle VPN<br/>vgw-signalements<br/>(ASN 12876)"]
    PN --- VGW
  end
  subgraph MET["Réseau de la métropole"]
    CGWD["Équipement IPsec<br/>de la métropole<br/>(ASN 65010)"]
    SIG["Serveur SIG<br/>192.168.50.0/24"]
    CGWD --- SIG
  end
  VGW <-->|"Connexion : tunnel IPsec<br/>+ session BGP<br/>(politique de routage)"| CGWD
  

• La passerelle VPN (VPN gateway) est l'extrémité du tunnel côté Scaleway. Elle est rattachée à un réseau privé, choisi à la création et non modifiable ensuite, reçoit une adresse privée dans ce réseau et une ou deux adresses publiques (IPv4, IPv6). Elle existe en plusieurs gabarits, qui diffèrent par la bande passante et le nombre maximal de connexions, et ne se change pas de gabarit après création.
• La passerelle client (customer gateway) est la représentation, chez Scaleway, de l'équipement de la métropole : son adresse publique et son numéro de système autonome (ASN).
• La politique de routage (routing policy) dit quels préfixes ont le droit de passer dans chaque sens. Par défaut, toutes les routes sont bloquées : sans politique, aucun trafic ne circule.
• La connexion (connection) réunit les trois : quelle passerelle VPN, quelle passerelle client, quels algorithmes, quelle politique, et qui initie le tunnel.

Le tunnel est protégé par IPsec : IKEv2 (RFC 7296) négocie l'authentification et les clés, ESP (RFC 4303) chiffre et authentifie les paquets. L'authentification se fait par clé prépartagée (PSK), générée par Scaleway à la création de la connexion et stockée dans Secret Manager (vous ne pouvez pas choisir la vôtre). La durée de vie des associations de sécurité est limitée à quatre heures pour IKEv2 et à une heure pour ESP ; le renouvellement est automatique.

Le routage est exclusivement dynamique, par BGP (RFC 4271) : pas de route statique. Les deux passerelles ouvrent une session BGP à travers le tunnel, sur un petit sous-réseau d'interconnexion privé fourni par Scaleway, et s'annoncent mutuellement leurs préfixes, filtrés par la politique de routage. La passerelle VPN apprend au plus 512 préfixes par connexion ; au-delà, la session BGP tombe. Si votre équipement n'a pas d'ASN public, la documentation recommande un ASN privé de la plage 64512 à 65534, celle que réserve la RFC 6996.

Le trafic ne circule qu'une fois la propagation des routes activée sur la connexion. C'est un second verrou, volontaire : on peut tout configurer, vérifier, puis ouvrir.

Les propositions de sécurité

Une proposition de sécurité fixe les algorithmes du tunnel : chiffrement, intégrité et groupe Diffie-Hellman pour IKEv2, chiffrement et intégrité (et groupe facultatif) pour ESP. La documentation de Scaleway recommande, pour du matériel récent :

Les algorithmes AEAD (AES-GCM, ChaCha20-Poly1305) chiffrent et authentifient en une seule opération : avec eux, pas d'algorithme d'intégrité séparé. Les modes AES-CBC restent proposés pour les équipements anciens, avec un HMAC, et la documentation les classe « à utiliser avec prudence ». La note technique de l'ANSSI sur IPsec va dans le même sens : privilégier IKEv2 et des algorithmes à jour, et ne garder les options anciennes que pour une compatibilité dûment justifiée.

Ce qu'il en coûte

Au 5 octobre 2026, la page de tarifs réseau de Scaleway affiche sept gabarits de passerelle VPN, de VGW-XXS (0,0808 € HT de l'heure, 59 € par mois) à VGW-XXL (1,0945 € HT de l'heure, 799 € par mois). S'y ajoutent l'adresse IPv4 publique de la passerelle, facturée à part, et le stockage de la clé prépartagée dans Secret Manager. La passerelle est facturée de sa création à sa suppression, qu'un tunnel soit établi ou non.

En pratique

Nous allons segmenter le VPC, poser une Network ACL, puis relier le site de la métropole. Les commandes ont été vérifiées avec l'aide de la CLI scw 2.62 et les structures du SDK Go ; la leçon ne montre aucune sortie. Les identifiants seront différents chez vous.

1. Vérifier le plan d'adressage

Avant de créer quoi que ce soit, la métropole et l'équipe Lyneko comparent leurs plages. Un chevauchement entre 192.168.50.0/24 et l'un des blocs du VPC rendrait le routage ambigu, et c'est le genre d'erreur qu'on ne découvre qu'au moment où rien ne passe. Le module ipaddress de Python fait le contrôle :

$ python3 - <<'EOF'
import ipaddress, itertools
reseaux = {
    "pn-signalements": "172.16.20.0/22",
    "pn-sig-donnees": "172.16.24.0/22",
    "pn-sig-admin": "172.16.28.0/22",
    "metropole-sig": "192.168.50.0/24",
}
for (a, x), (b, y) in itertools.combinations(reseaux.items(), 2):
    if ipaddress.ip_network(x).overlaps(ipaddress.ip_network(y)):
        print("CHEVAUCHEMENT", a, b)
print("contrôle terminé")
EOF

Le script n'affiche que contrôle terminé si aucune paire ne se chevauche. Demandez aussi à la métropole les autres plages de son réseau qui pourraient un jour avoir besoin du lien : il est beaucoup plus simple de les écarter maintenant.

2. Créer les réseaux privés et vérifier le routage

$ VPC_ID=$(scw vpc vpc list name=vpc-signalements region=fr-par -o json \
    | jq -r '.[] | select(.name == "vpc-signalements") | .id')
$ scw vpc vpc get "$VPC_ID" region=fr-par -o json \
    | jq '{routing_enabled, custom_routes_propagation_enabled}'

Les deux champs doivent valoir true : routage activé, et nouveau comportement de propagation des routes personnalisées. Si routing_enabled vaut false (VPC ancien), scw vpc route enable-routing l'active, sans retour possible.

$ PN_DONNEES=$(scw vpc private-network create name=pn-sig-donnees vpc-id="$VPC_ID" \
    subnets.0=172.16.24.0/22 region=fr-par -o json | jq -r .id)
$ PN_ADMIN=$(scw vpc private-network create name=pn-sig-admin vpc-id="$VPC_ID" \
    subnets.0=172.16.28.0/22 default-route-propagation-enabled=true \
    region=fr-par -o json | jq -r .id)

default-route-propagation-enabled=true sur pn-sig-admin lui fait recevoir les routes par défaut des passerelles attachées ailleurs dans le VPC ; pn-sig-donnees ne l'a pas, et n'aura donc aucune sortie vers Internet. Déplacez ensuite la base dans pn-sig-donnees (ajout d'un point d'accès privé sur le nouveau réseau, bascule de DATABASE_URL, puis retrait de l'ancien point d'accès : la même séquence que dans la leçon réseau du cours précédent), et regardez la table de routes :

$ scw vpc route list vpc-id="$VPC_ID" region=fr-par -o json \
    | jq -r '.[] | [.route.destination, .nexthop_resource_type, (.nexthop_name // "-")] | @tsv'

Vous devez y voir une route locale par réseau privé, en IPv4 et en IPv6, et une route par défaut par passerelle publique annonçant la route par défaut.

3. Écrire la Network ACL

Les flux nécessaires, et rien d'autre :

La quatrième ligne mérite une remarque : le trafic qui arrive par le tunnel VPN entre dans le VPC par la passerelle VPN, rattachée à pn-signalements. Pour la Network ACL, c'est un trafic interne à ce réseau privé, qu'elle ne filtre pas. La règle est donc utile seulement si le SIG veut joindre un autre réseau privé ; le vrai filtre du port 8000, pour le trafic de la métropole, est le pare-feu des instances et la politique de routage du VPN. On l'écrit quand même, pour documenter l'intention.

scw vpc rule set remplace toutes les règles d'une famille par celles que vous donnez :

$ scw vpc rule set vpc-id="$VPC_ID" is-ipv6=false default-policy=drop region=fr-par \
    rules.0.protocol=TCP rules.0.source=172.16.20.0/22 \
      rules.0.destination=172.16.24.0/22 rules.0.dst-port-low=5432 rules.0.dst-port-high=5432 \
      rules.0.action=accept rules.0.description="app vers base" \
    rules.1.protocol=TCP rules.1.source=172.16.28.0/22 \
      rules.1.destination=172.16.16.0/20 rules.1.dst-port-low=22 rules.1.dst-port-high=22 \
      rules.1.action=accept rules.1.description="admin SSH" \
    rules.2.protocol=TCP rules.2.source=172.16.28.0/22 \
      rules.2.destination=172.16.16.0/20 rules.2.dst-port-low=9100 rules.2.dst-port-high=9100 \
      rules.2.action=accept rules.2.description="admin supervision" \
    rules.3.protocol=TCP rules.3.source=192.168.50.0/24 \
      rules.3.destination=172.16.20.0/22 rules.3.dst-port-low=8000 rules.3.dst-port-high=8000 \
      rules.3.action=accept rules.3.description="SIG metropole vers API d'import" \
    rules.4.protocol=TCP rules.4.source=0.0.0.0/0 rules.4.destination=0.0.0.0/0 \
      rules.4.dst-port-low=32768 rules.4.dst-port-high=65535 \
      rules.4.action=accept rules.4.description="retours TCP" \
    rules.5.protocol=ICMP rules.5.source=0.0.0.0/0 rules.5.destination=0.0.0.0/0 \
      rules.5.action=accept rules.5.description="ICMP"

172.16.16.0/20 couvre les trois blocs /22 d'un coup (172.16.16.0 à 172.16.31.255, le bloc 172.16.16.0/22 restant libre) : c'est l'intérêt d'avoir choisi des blocs voisins. Notez que 172.16.20.0/20 serait invalide, car un préfixe /20 commence forcément sur un multiple de 16 dans le troisième octet ; python3 -c 'import ipaddress; ipaddress.ip_network("172.16.20.0/20")' le refuse. Vérifiez le résultat avec scw vpc rule get vpc-id="$VPC_ID" is-ipv6=false region=fr-par, puis testez : depuis une instance d'application, nc -vz <ip de sig-db> 5432 doit réussir ; depuis la même instance, nc -vz <ip de l'instance admin> 22 doit expirer (la règle n'autorise SSH que depuis pn-sig-admin).

Écrivez ensuite la liste IPv6 de la même façon (is-ipv6=true, avec les blocs IPv6 de vos réseaux), ou au minimum une liste vide avec default-policy=drop si aucun flux IPv6 n'est attendu entre réseaux.

Pour revenir en arrière en urgence :

$ scw vpc rule set vpc-id="$VPC_ID" is-ipv6=false default-policy=accept region=fr-par

4. Les passerelles : client et VPN

La métropole communique l'adresse publique de son équipement (198.51.100.20 dans cet exemple) et choisit un ASN privé, 65010 :

$ CGW_ID=$(scw s2s-vpn customer-gateway create name=cgw-metropole \
    ipv4-public=198.51.100.20 asn=65010 region=fr-par -o json | jq -r .id)
$ scw s2s-vpn vpn-gateway-type list region=fr-par -o json \
    | jq -r '.[] | [.name, .bandwidth, .allowed_connections, (.zones | join(","))] | @tsv'

La seconde commande liste les gabarits disponibles, avec leur bande passante (en bits par seconde), leur nombre maximal de connexions et leurs zones. Un VGW-XXS suffit pour un site et quelques centaines de mégaoctets par nuit ; prévoyez plus si d'autres métropoles suivent, puisque le gabarit ne se change pas.

Créez la passerelle VPN, rattachée à pn-signalements. La CLI attend l'identifiant IPAM d'une adresse publique déjà réservée (public-tunnel-config.single-ipv4-tunnel.ipam-id), et ni son aide ni la documentation consultée ne précisent le type d'adresse à réserver ; la console, elle, l'alloue pour vous. Créez donc la passerelle depuis la console (Network, Site-to-Site VPN, VPN gateways, en zone fr-par-1, gabarit VGW-XXS, réseau pn-signalements, nom vgw-signalements), puis reprenez la CLI :

$ VGW_ID=$(scw s2s-vpn vpn-gateway list region=fr-par -o json \
    | jq -r '.[] | select(.name == "vgw-signalements") | .id')
$ scw s2s-vpn vpn-gateway get "$VGW_ID" region=fr-par -o json \
    | jq '{status, gateway_type, zone, asn, public_config}'

Attendez le statut active. L'ASN affiché est celui de Scaleway.

5. La politique de routage

Elle autorise dans chaque sens uniquement les préfixes utiles :

$ POL_ID=$(scw s2s-vpn routing-policy create name=rp-metropole-v4 is-ipv6=false \
    prefix-filter-in.0=192.168.50.0/24 \
    prefix-filter-out.0=172.16.20.0/22 \
    region=fr-par -o json | jq -r .id)

• prefix-filter-in : ce que l'on accepte d'apprendre de la métropole. Seul son réseau SIG. Si son équipement annonce par erreur une route par défaut ou tout son plan d'adressage, ces annonces sont ignorées.
• prefix-filter-out : ce que l'on annonce à la métropole. Seul pn-signalements, où vit l'API. La base et le réseau d'administration ne sont pas annoncés : la métropole n'a aucun chemin vers eux, quelle que soit la configuration de son côté.

C'est la mesure de sécurité la plus forte de toute la leçon, et elle ne coûte qu'une ligne.

6. La connexion

$ scw s2s-vpn connection create name=cnx-metropole \
    vpn-gateway-id="$VGW_ID" customer-gateway-id="$CGW_ID" \
    initiation-policy=customer_gateway \
    ikev2-ciphers.0.encryption=aes256gcm ikev2-ciphers.0.dh-group=curve25519 \
    esp-ciphers.0.encryption=aes256gcm \
    bgp-config-ipv4.routing-policy-id="$POL_ID" \
    enable-route-propagation=false \
    region=fr-par -o json > .tmp/cnx-metropole.json
$ chmod 600 .tmp/cnx-metropole.json
$ CNX_ID=$(jq -r .connection.id .tmp/cnx-metropole.json)

• initiation-policy=customer_gateway : c'est l'équipement de la métropole qui ouvre le tunnel. L'autre valeur, vpn_gateway, fait initier par Scaleway ; choisissez selon ce que le pare-feu de la métropole accepte.
• Les algorithmes sont ceux de la recommandation standard de Scaleway. Ils doivent correspondre exactement à ceux configurés sur l'équipement de la métropole, sinon la négociation IKE échoue.
• enable-route-propagation=false : la connexion est créée verrouillée. On ouvrira à l'étape 8.

La réponse de création contient, en plus de la connexion, la clé prépartagée en clair (champ pre_shared_key, d'après le SDK) : c'est pourquoi elle part dans un fichier aux droits restreints, et non dans le terminal. La clé est aussi conservée dans Secret Manager, dont l'identifiant et la révision figurent dans la connexion :

$ jq -r '.connection | .secret_id, .secret_revision' .tmp/cnx-metropole.json

Pour la retrouver plus tard : scw secret version access <secret_id> revision=<révision> region=fr-par. Transmettez-la à la métropole par un canal distinct du reste de la configuration (pas dans le même courriel), puis supprimez le fichier local (shred -u .tmp/cnx-metropole.json). En cas de doute sur sa confidentialité, scw s2s-vpn connection renew-psk en génère une nouvelle.

7. Ce que la métropole configure

La documentation de Scaleway ne fournit pas de fichier de configuration par modèle d'équipement ; elle liste les informations à transmettre, que l'on rassemble ainsi :

$ scw s2s-vpn connection get "$CNX_ID" region=fr-par -o json \
    | jq '{ikev2_ciphers, esp_ciphers, initiation_policy, bgp_session_ipv4}'
$ scw s2s-vpn vpn-gateway get "$VGW_ID" region=fr-par -o json | jq '.public_config'

• l'adresse publique de la passerelle VPN ;
• la clé prépartagée ;
• l'ASN de Scaleway, 12876 ;
• les algorithmes IKEv2 et ESP ;
• le sous-réseau d'interconnexion BGP et les deux adresses de la session (champ bgp_session_ipv4) ;
• les préfixes : la métropole annonce 192.168.50.0/24 et doit accepter 172.16.20.0/22.

Côté métropole, le pare-feu doit laisser passer IKE (UDP 500) et IPsec avec traversée de NAT (UDP 4500) vers l'adresse de la passerelle VPN, ou ESP (protocole IP 50) si aucun NAT ne se trouve sur le chemin.

8. Ouvrir et vérifier

$ scw s2s-vpn connection enable-route-propagation "$CNX_ID" region=fr-par
$ scw s2s-vpn connection get "$CNX_ID" region=fr-par -o json \
    | jq '{status, tunnel_status, bgp_status_ipv4, route_propagation_enabled}'

Le SDK définit les valeurs possibles : tunnel_status vaut up ou down ; bgp_status_ipv4 vaut up, down ou disabled ; status (l'état global de la connexion) vaut active, limited_connectivity, down ou locked. La cible : tunnel up, BGP up, connexion active.

La route vers 192.168.50.0/24 apparaît alors dans la table du VPC, avec la passerelle VPN pour saut suivant :

$ scw vpc route list vpc-id="$VPC_ID" contains=192.168.50.0/24 region=fr-par -o json \
    | jq -r '.[] | [.route.destination, .nexthop_resource_type] | @tsv'

Depuis le serveur SIG, curl -v http://<IP privée d'une instance sig-app>:8000/sante doit répondre ; depuis une instance d'application, ping 192.168.50.10 doit répondre si le pare-feu de la métropole laisse passer ICMP.

9. Les noms privés vus depuis le site distant

Les instances du VPC résolvent sig-app-1.pn-signalements.internal grâce au résolveur géré, qui écoute sur 169.254.169.254 dans chaque réseau privé. Ce résolveur n'est pas joignable depuis la métropole : 169.254.0.0/16 est une plage de lien local (RFC 3927), que les routeurs ne transmettent pas, et la documentation de Scaleway ne décrit pas de résolution depuis un site distant. Deux options :

• donner à la métropole des adresses IP stables : celle du répartiteur interne, ou des adresses réservées dans IPAM ;
• installer, sur une petite instance de pn-signalements, un résolveur relais (Unbound, par exemple) qui transmet les requêtes en .internal au résolveur géré, et le déclarer comme serveur de transfert conditionnel dans le DNS de la métropole pour la seule zone internal.

La première suffit ici. Le résolveur géré limite d'ailleurs les requêtes à 50 par seconde et par ressource, ce qu'un relais pour tout un réseau d'entreprise atteindrait vite.

Sous le capot

Le routeur virtuel et le niveau 2. Un réseau privé Scaleway est un segment de niveau 2 qui s'étend sur toutes les zones d'une région ; le VPC ajoute par-dessus un routage de niveau 3. Quand une instance de pn-signalements envoie un paquet vers 172.16.24.10, elle consulte sa propre table de routage : la route vers 172.16.24.0/22, que le VPC synchronise sur chaque ressource au moment où elle rejoint un réseau privé, désigne le routeur virtuel. La trame part vers l'adresse MAC de ce routeur, qui consulte la table du VPC, passe le paquet à la Network ACL, et le remet sur le segment pn-sig-donnees.

Pourquoi « sans état » change tout. Un pare-feu à état (le groupe de sécurité, nftables avec ct state) garde une table des connexions et reconnaît une réponse comme appartenant à une connexion autorisée. Une Network ACL sans état ne garde rien : elle évalue chaque paquet isolément, d'après ses adresses, son protocole et ses ports. La réponse de PostgreSQL est, pour elle, un paquet TCP de 172.16.24.10:5432 vers 172.16.20.11:51234, qu'aucune règle « app vers base » ne couvre. Conséquence : la règle des ports éphémères accepte aussi un paquet qui n'est pas une réponse, pour peu qu'il vise un port élevé. Le pare-feu de l'hôte, à état, rattrape ce cas.

IPsec en deux temps. IKEv2 établit d'abord une association de sécurité « de contrôle » entre les deux passerelles : échange Diffie-Hellman (ici sur Curve25519), authentification par la clé prépartagée, puis négociation d'une ou plusieurs associations « filles » pour ESP. ESP encapsule ensuite chaque paquet IP, chiffré et authentifié (ici par AES-256-GCM), dans un nouveau paquet entre les deux adresses publiques. Les durées de vie courtes (une heure pour ESP) imposent des renouvellements de clés réguliers, avec un nouvel échange Diffie-Hellman qui garantit la confidentialité persistante : la compromission d'une clé ne permet pas de déchiffrer le trafic des périodes précédentes.

BGP dans le tunnel. Les deux passerelles sont voisines BGP (connexion TCP sur le port 179) à travers le tunnel. L'intérêt, même pour un seul site : si le tunnel tombe, la session tombe, la route vers 192.168.50.0/24 disparaît de la table du VPC, et les applications échouent immédiatement au lieu d'envoyer leurs paquets dans le vide. Avec deux tunnels, la route bascule seule.

Pièges courants

Croire que trois réseaux privés cloisonnent. Avec le routage activé, et il l'est par défaut, tous les réseaux d'un VPC se parlent. Sans Network ACL, le découpage n'est qu'une organisation, pas une protection.

Oublier les retours dans une Network ACL. Symptôme : nc -vz vers la base expire, alors que la règle « app vers base » est là. La réponse est jetée par la règle par défaut. Ajoutez la règle des ports éphémères, ou la règle inverse précise.

Oublier la liste IPv6. Les réseaux privés ont un bloc IPv6 par défaut. Une ACL IPv4 parfaite laisse tout passer en IPv6 si la liste IPv6 est restée vide avec une règle par défaut accept.

scw vpc rule set qui efface tout. La commande remplace la liste entière. Pour ajouter une règle, partez de scw vpc rule get ... -o json, modifiez, et réappliquez ; ou utilisez scw vpc rule edit, qui ouvre la liste dans un éditeur.

Mettre le Redis dans le réseau des données. Managed Redis ne prend pas en charge le routage VPC : depuis un autre réseau privé, il est injoignable, et l'erreur ressemble à un pare-feu. La liste des produits concernés est dans la documentation du VPC ; vérifiez-la avant de dessiner le schéma.

Choisir un bloc qui chevauche celui du client. Le cas classique : un VPC en 192.168.0.0/16 et un client dont le réseau de bureau est en 192.168.1.0/24. Les routes deviennent ambiguës, le VPC Peering refuse la connexion (état Conflict), et la seule correction est de recréer les réseaux privés.

Un tunnel « up » sans trafic. IPsec établi, BGP établi, et rien ne passe : la propagation des routes n'est pas activée, ou la politique de routage ne contient pas le bon préfixe (un /24 annoncé par la métropole alors que la politique attend un /23 n'est pas accepté s'il n'est pas couvert). Lisez la table de routes du VPC : si la route vers le site n'y est pas, le problème est dans BGP ou dans la politique, pas dans IPsec.

MTU. L'encapsulation ESP ajoute des en-têtes : si les petites requêtes passent et que les gros transferts se bloquent, pensez au trou noir de MTU de la leçon ICMP, ping, traceroute et la MTU.

Sécurité

• La politique de routage est le premier filtre. N'annoncez à un partenaire que les préfixes dont il a besoin ; n'acceptez de lui que les siens. Une métropole compromise ne doit pas pouvoir atteindre votre base, et elle ne le peut pas si pn-sig-donnees n'est jamais annoncé.
• La clé prépartagée est un secret de production. Elle ne s'affiche qu'à la création et dans Secret Manager ; ne la collez ni dans un ticket, ni dans un dépôt Git, ni dans le même message que l'adresse de la passerelle. Renouvelez-la (renew-psk) au départ d'une personne qui l'a connue, et coordonnez le changement avec le partenaire.
• Les algorithmes se choisissent et se revoient. AEAD et Curve25519 par défaut ; AES-CBC, modp2048 et l'intégrité SHA-256 seulement si l'équipement du partenaire ne sait pas mieux, avec une date de revue.
• Défense en profondeur. Politique de routage, Network ACL, pare-feu de l'hôte et authentification applicative sont quatre couches indépendantes. Le port 8000 ouvert à la métropole n'en reste pas moins une API qui exige un jeton.
• Tout est journalisé : VPC et Site-to-Site VPN sont intégrés à Audit Trail (leçon 15).
• Un réseau de données sans route par défaut ne peut pas exfiltrer vers Internet, même si un attaquant y prend pied. C'est une mesure gratuite.

En production

• La haute disponibilité du VPN. La documentation décrit des configurations à deux passerelles VPN dans deux zones, rattachées au même réseau privé, avec des connexions croisées vers deux équipements côté client. C'est la configuration à viser dès que le flux est critique ; pour la synchronisation nocturne d'un SIG, une passerelle et un tunnel IPv4, surveillés, suffisent, à condition que la métropole sache que le flux peut s'interrompre.
• Superviser les tunnels : tunnel_status et bgp_status_ipv4, relevés périodiquement et branchés sur une alerte (leçon 14).
• InterLink se justifie pour des flux continus, volumineux ou sensibles à la gigue (réplication, sauvegardes massives) ; sa mise en service demande un partenaire et un contrat, et se prévoit.
• Plusieurs clients : une politique de routage par client, et des préfixes clients qui ne se chevauchent pas entre eux.
• Le registre d'adressage (blocs du VPC, des clients, sous-réseaux d'interconnexion) se versionne et se relit avant toute création de réseau.
• Chez Lyneko, le cluster Kapsule lyneko-apps vit dans son propre VPC ; relier un jour un VPC client à ce cluster passerait par VPC Peering, avec les mêmes exigences : blocs disjoints, routes de part et d'autre, et filtres explicites.

Exercices

1. Lire une table de routes (niveau 200). La table d'un VPC contient : 172.16.20.0/22 (locale, pn-signalements), 172.16.24.0/22 (locale, pn-sig-donnees), 192.168.50.0/24 (passerelle VPN), 10.0.0.0/8 (route personnalisée vers une instance pare-feu de pn-sig-admin), 0.0.0.0/0 (passerelle publique de pn-signalements). Par où part un paquet émis depuis pn-signalements vers 192.168.50.7 ? vers 10.20.30.40 ? vers 192.168.51.1 ? vers 1.1.1.1 ? Et depuis pn-sig-donnees vers 1.1.1.1 ?

2. Une ACL sans état (niveau 300). Une équipe a posé une Network ACL avec default-policy=drop et une seule règle : TCP de 172.16.20.0/22 vers 172.16.24.0/22, port de destination 5432. L'application ne joint plus la base. Expliquez précisément ce qui se passe au niveau des paquets, puis proposez deux corrections, la plus large et la plus étroite.

3. Choisir l'outil (niveau 300). Pour chacun des besoins suivants, choisissez entre VPN sur instance, Site-to-Site VPN, InterLink et VPC Peering, et justifiez en une phrase : (a) relier le VPC de Signalements au VPC de l'équipe données de Lyneko, dans la même région ; (b) répliquer en continu une base de plusieurs téraoctets entre le centre de données d'un client et Scaleway ; (c) relier un cluster chez un autre fournisseur de cloud ; (d) donner un accès temporaire, pour deux semaines, à un prestataire qui doit migrer des données depuis un serveur sans équipement IPsec.

Récapitulatif

• Un VPC se découpe en réseaux privés par fonction ; leurs blocs ne se modifient pas après création et ne doivent chevaucher ni ceux des autres VPC ni ceux des clients.
• Le routeur virtuel tient une table de routes (locales, par défaut, personnalisées) ; le plus long préfixe l'emporte. Le routage est actif par défaut, irréversible, et fait communiquer tous les réseaux du VPC.
• Depuis le 1er juillet 2025, les routes personnalisées sont annoncées dans tout le VPC ; les routes par défaut restent locales, sauf si un réseau choisit de recevoir celles du VPC.
• Certains produits, dont Managed Redis, ne prennent pas en charge le routage VPC : ils restent dans le réseau de leurs clients.
• Les Network ACL sont sans état, ordonnées, séparées par famille d'adresses, avec une règle par défaut ; elles ne filtrent ni l'intérieur d'un réseau privé ni Internet.
• Pour sortir du VPC : VPN sur instance, Site-to-Site VPN (IPsec, BGP, disponibilité générale le 2 avril 2026), InterLink (lien dédié), VPC Peering (entre VPC Scaleway, disponibilité générale le 23 juin 2026).
• Site-to-Site VPN : passerelle VPN, passerelle client, politique de routage (tout est bloqué par défaut), connexion, puis propagation des routes ; routage par BGP uniquement, clé prépartagée générée et stockée dans Secret Manager.
• Le résolveur DNS privé (169.254.169.254) n'est pas joignable depuis un site distant.

Pour aller plus loin

• La page Understanding VPC routing de Scaleway, en particulier l'exemple d'ACL qui compense la portée élargie des routes personnalisées.
• La page des propositions de sécurité de Site-to-Site VPN, qui classe chaque algorithme, et la note technique de l'ANSSI sur IPsec.
• Les configurations de haute disponibilité et multisites de Site-to-Site VPN, pour le jour où le flux devient critique.
• La RFC 4271 (BGP), chapitres 1 à 3, pour comprendre ce que se disent réellement deux voisins.
• La leçon suivante, Observer avec Cockpit, où les métriques du VPC et de la passerelle VPN deviennent des tableaux de bord et des alertes.