Public Gateway Scaleway : sortir sans adresse publique, entrer par le bastion

Une Instance sans adresse publique ne peut ni sortir sur Internet ni être jointe, et c'est exactement ce qu'on veut : une machine qu'aucun scanner ne trouvera. Reste à lui donner un chemin de sortie pour ses mises à jour, et un chemin d'entrée pour vous. La passerelle publique fait les deux, par traduction d'adresses dans un sens et par bastion SSH dans l'autre. Cette leçon construit l'ensemble, prouve chaque affirmation depuis l'intérieur de la machine, et mesure ce qui se casse quand on retire le rattachement.

Ce que vous allez apprendre

• Créer une passerelle et la rattacher à un réseau privé, avec la traduction d'adresses.
• Prouver qu'une Instance sans adresse publique atteint Internet, et sous quelle identité.
• Publier un service interne sur un port public, sans lui donner d'adresse.
• Vous connecter par le bastion SSH, avec le bon utilisateur, ce qui n'est pas celui qu'on croit.
• Retrouver l'adresse privée d'une Instance, qui ne se cherche pas là où on la cherche.
• Supprimer dans l'ordre, en sachant ce que chaque dépendance refuse.

Pourquoi retirer l'adresse publique d'une machine ?

Parce qu'une adresse publique est une surface d'attaque permanente, et que la plupart des machines n'en ont aucun besoin. Un serveur applicatif derrière un équilibreur de charge, une base de données, un travailleur de file d'attente : aucun n'a de raison d'être joignable depuis Internet.

Ce qu'ils ont besoin de faire, en revanche, c'est sortir : télécharger des correctifs, appeler une API externe, envoyer des journaux. C'est là que la passerelle intervient.

Sans passerelle	Avec passerelle
soit une adresse publique, soit aucune sortie	sortie possible sans adresse publique
chaque machine exposée est une cible	une seule adresse publique, celle de la passerelle
accès SSH par adresse publique sur chaque machine	un bastion unique, avec les clés du Projet
chaque machine porte une facture d'adresse	une adresse pour tout le réseau privé

Glissez pour voir

Le raisonnement de sécurité est celui du point d'entrée unique. Vous ne supprimez pas le risque, vous le concentrez sur un composant que vous pouvez surveiller, restreindre par liste d'adresses autorisées, et dont vous maîtrisez la version.

Quel gabarit de passerelle choisir ?

Le gabarit se choisit sur la bande passante, et il se change ensuite. C'est l'une des rares décisions non irréversibles de ce chapitre.

Les valeurs se lisent dans l'API plutôt que dans une page :

scw vpc-gw gateway-type list zone=fr-par-1 -o json

Gabarit	Bande passante	Quand le choisir
VPC-GW-S	100 Mbit/s	quelques machines qui téléchargent des correctifs
VPC-GW-M	1 Gbit/s	trafic sortant applicatif régulier
VPC-GW-L	3 Gbit/s	plusieurs dizaines de machines actives
VPC-GW-XL	10 Gbit/s	sortie massive, sauvegardes vers l'extérieur

Glissez pour voir

Relevé le 10 septembre 2026 avec scw 2.62.0.

Toutes les zones n'ont pas de passerelle

L'aide de scw vpc-gw gateway create en 2.62.0 énumère fr-par-1, fr-par-2, it-mil-1, les trois zones d'Amsterdam et les trois de Varsovie, sans fr-par-3. Mais une liste d'aide ne prouve rien : c'est le refus de l'API qui tranche. Tentative faite le 10 septembre 2026 :

scw vpc-gw gateway create name=essai type=VPC-GW-S zone=fr-par-3

Unknown service

Le refus est net, et le catalogue public le confirme : pour fr-par-3, il ne contient que la référence d'adresse IP de passerelle, aucun gabarit. Une architecture qui prévoit une passerelle par zone à Paris se heurtera donc à la troisième.

La réciproque n'est pas vraie, et c'est le piège de méthode. Une zone absente de l'aide peut malgré tout fonctionner : la même journée, scw lb lb create type=LB-S zone=it-mil-1 a été acceptée alors que l'aide de cette commande ne liste pas Milan. Les listes de l'aide sont figées dans le binaire au moment de sa compilation ; le catalogue et l'API, eux, sont vivants. Retenez l'ordre : l'API tranche, le catalogue confirme, l'aide oriente. Méthode de vérification dans régions et zones.

Construire l'ensemble

1. Créez le réseau privé, s'il n'existe pas déjà.

   VPC=$(scw vpc vpc create name=demo-vpc region=fr-par -o json | jq -r .id)
   PN=$(scw vpc private-network create name=demo-pn vpc-id="$VPC" \
     region=fr-par -o json | jq -r .id)

2. Réservez une adresse publique pour la passerelle, puis créez-la avec le bastion activé.

   IPID=$(scw vpc-gw ip create zone=fr-par-1 -o json | jq -r .id)
   GW=$(scw vpc-gw gateway create name=demo-gw type=VPC-GW-S ip-id="$IPID" \
     enable-bastion=true bastion-port=61000 zone=fr-par-1 -o json | jq -r .id)
   scw vpc-gw gateway get "$GW" zone=fr-par-1 -o json

   La sortie doit afficher "status":"allocating", puis "running" après quelques dizaines de secondes. Le port du bastion se choisit entre 1024 et 59999, et 61000 est la valeur par défaut, choisie pour éviter les conflits.

3. Créez l'Instance sans aucune adresse publique, puis rattachez-la au réseau privé.

   SRV=$(scw instance server create name=demo-priv type=DEV1-S \
     image=ubuntu_noble zone=fr-par-1 ip=none -o json | jq -r .id)
   scw instance private-nic create server-id="$SRV" \
     private-network-id="$PN" zone=fr-par-1

   La sortie de création doit afficher "public_ip": null : c'est le point de départ de tout le reste.

4. Rattachez la passerelle au réseau privé, avec la traduction d'adresses et l'annonce de la route par défaut.

   GWNET=$(scw vpc-gw gateway-network create gateway-id="$GW" \
     private-network-id="$PN" enable-masquerade=true push-default-route=true \
     zone=fr-par-1 -o json | jq -r .id)
   scw vpc-gw gateway-network get "$GWNET" zone=fr-par-1 -o json

   La sortie doit afficher "masquerade_enabled":true puis, après quelques secondes, "status":"ready".

Où trouver l'adresse privée de l'Instance ?

Pas là où vous allez la chercher. C'est le premier piège du lab, et il fait perdre un temps déraisonnable parce que la commande ne renvoie aucune erreur : elle renvoie une liste vide.

L'adresse réservée par IPAM n'est pas attachée au serveur, elle est attachée à sa carte réseau privée. Un filtre sur l'identifiant du serveur ne trouve donc rien :

# Ne renvoie RIEN, sans erreur
scw ipam ip list resource-id="$SRV" region=fr-par

La bonne requête passe par le réseau privé, puis retient les adresses de type instance_private_nic :

scw ipam ip list private-network-id="$PN" region=fr-par -o json

Sur le lab du 10 septembre 2026, cette commande a renvoyé trois entrées, et c'est instructif :

Adresse	Type de ressource	Ce que c'est
172.16.0.2/22	instance_private_nic	votre Instance
172.16.0.3/22	vpc_gateway_network	la passerelle, qui prend aussi une adresse
une adresse en fdb2:…/64	instance_private_nic	l'IPv6 de la même carte

Glissez pour voir

Retenez la deuxième ligne : la passerelle consomme une adresse du réseau privé, et c'est celle qui deviendra la route par défaut de vos machines.

Prouver que la sortie fonctionne

Une passerelle qui « devrait » fonctionner ne prouve rien : il faut regarder depuis l'intérieur de la machine. Et pour y entrer sans adresse publique, on passe par le bastion.

L'utilisateur du bastion est `bastion`, pas `root`

C'est le second piège, et le message d'erreur n'aide pas :

root@203.0.113.30: Permission denied (publickey,keyboard-interactive).

On croit à un problème de clé, alors que c'est l'utilisateur du rebond qui est faux. La forme correcte, celle de la documentation officielle, est :

ssh -J bastion@<adresse-publique-de-la-passerelle>:61000 root@<adresse-privee>

L'utilisateur bastion sert au saut, root sert à la destination. Une précision qui compte aussi : les clés SSH du Projet sont copiées sur le bastion au moment de son activation. Une clé ajoutée au Projet après coup n'y est pas, et il faut la réimporter.

Une fois connecté, deux commandes suffisent à tout prouver :

ip route | grep '^default'
curl -s https://ifconfig.me

La traduction d'adresses se prouve par une égalité, et il suffit de deux commandes pour l'obtenir. Relevé le 10 septembre 2026 avec scw 2.62.0, depuis une Instance jointe par le bastion : la première a renvoyé default via 172.16.0.3 dev ens6 proto dhcp, c'est-à-dire l'adresse privée de la passerelle, poussée automatiquement par l'annonce de route par défaut. La seconde a renvoyé 203.0.113.10, qui était exactement l'adresse publique de la passerelle réservée au début du lab. Ces deux valeurs suffisent : la machine ne porte aucune adresse publique, et pourtant Internet la voit sous celle de la passerelle, qui réécrit l'adresse source de chaque paquet sortant. Toutes les machines du même réseau privé partageront cette identité unique, avec une conséquence directe en exploitation. Quand un service tiers filtre par adresse source, une place de marché d'API ou un pare-feu partenaire, c'est l'adresse de la passerelle qu'il faut lui déclarer, jamais celle des Instances, qui n'existe que dans le réseau privé.

Le nom interne, plus pratique qu'une adresse

Les ressources d'un réseau privé portent un nom résolvable, ce qui évite de manipuler des adresses qui changent :

<nom-de-la-ressource>.<nom-du-reseau-prive>.internal

Vérifié sur le lab : la connexion par ce nom aboutit exactement comme par l'adresse. C'est la forme à préférer dans une configuration, parce qu'elle survit à la recréation d'une machine.

Comment publier un service interne sans lui donner d'adresse ?

Par une règle PAT, qui fait entrer le trafic là où la traduction d'adresses le faisait sortir. PAT signifie Port Address Translation : la passerelle écoute sur un de ses ports publics et renvoie tout ce qui y arrive vers un couple adresse privée et port interne. Le service reste sans adresse publique, mais devient joignable.

C'est la moitié du produit que les tutoriels oublient, alors qu'elle décide souvent du choix d'architecture.

1. Faites tourner un service sur l'Instance privée, ici un serveur web sur le port 8080.

   python3 -m http.server 8080 --directory /root

2. Publiez ce port sur un port public de la passerelle.

   RULE=$(scw vpc-gw pat-rule create gateway-id="$GW" public-port=18080 \
     private-ip=172.16.16.2 private-port=8080 protocol=tcp zone=fr-par-1 \
     -o json | jq -r .id)
   scw vpc-gw pat-rule list gateway-ids.0="$GW" zone=fr-par-1 -o json

   Le protocole accepte tcp, udp ou both. La sortie doit afficher la règle avec ses quatre valeurs, par exemple "public_port":18080 et "private_ip":"172.16.16.2".

3. Vérifiez depuis l'extérieur, sur votre poste et non depuis l'Instance.

   curl -s http://<adresse-publique-de-la-passerelle>:18080/

   La sortie doit afficher la page servie par l'Instance. Sur le lab du 10 septembre 2026, curl http://203.0.113.20:18080/ a renvoyé le contenu d'une machine qui n'avait aucune adresse publique.

Deux refus utiles, et un piège qui ne dit rien

Réutiliser un port public déjà pris donne un message clair :

Resource already exists

Viser une adresse privée qui n'appartient à aucun réseau rattaché donne un message dont le début induit en erreur :

scaleway-sdk-go: precondition failed: resource is still in use, Gateway has no
private network with address 10.99.99.99

Le préfixe « still in use » laisse croire à une dépendance à libérer, alors que c'est un simple refus de validation : la passerelle ne route pas vers cette adresse. Lisez toujours la fin du message, pas son début.

Pourquoi votre liste de règles PAT paraît vide

Parce que le filtre ne s'appelle pas comme on l'écrit spontanément. En version 2.62.0, scw vpc-gw pat-rule list attend gateway-ids.{index}, au pluriel et indexé, et non gateway-id :

scw vpc-gw pat-rule list gateway-ids.0="$GW" zone=fr-par-1 -o json

Avec la forme au singulier, le CLI répond unknown argument 'gateway-id' et sort en code 1. Jusque-là, rien de perdu. Le piège vient de -o json : dans ce mode, le message d'erreur part sur la sortie d'erreur au format JSON, la sortie standard reste vide, et l'objet renvoyé ressemble à ceci :

{"message":"unknown argument 'gateway-id'","error":{},"hint":"Valid arguments are: order-by, gateway-ids.{index}, private-ips.{index}, protocol, zone"}

Un script qui fusionne les deux flux avec 2>&1 puis lit la clé pat_rules n'y trouve rien et conclut zéro règle, alors que la règle existe et fonctionne. Le script du lab de cette page est tombé exactement dans ce trou, et il a fallu la commande curl réussie pour s'apercevoir que le décompte mentait. La discipline qui l'évite tient en une ligne : ne jamais fusionner la sortie d'erreur dans un flux qu'on parse, et toujours tester le code de retour.

Que se passe-t-il si on retire le rattachement ?

Tout se coupe, y compris le chemin du bastion, et c'est logique une fois qu'on y pense. Le rattachement est ce qui relie la passerelle au réseau privé : sans lui, elle ne sait plus router vers vos machines, ni dans un sens ni dans l'autre.

Mesuré sur le lab : après suppression du rattachement, une tentative de connexion par le bastion échoue avec

Connection timed out during banner exchange

La leçon opérationnelle est qu'on ne retire pas un rattachement pour « tester » sur une infrastructure en service : on perd du même coup l'accès d'administration aux machines concernées, et il faut recréer le rattachement pour les retrouver.

Limites, quotas et plafonds

Limite	Valeur	Source
Réseaux privés par passerelle	8	FAQ officielle
Passerelles par Organisation	50	FAQ officielle
Port du bastion	entre 1024 et 59999, défaut 61000	documentation du bastion
Bande passante selon le gabarit	100 Mbit/s à 10 Gbit/s	gateway-type list, relevé le 2026-09-10
Zones disposant de passerelles	9 zones, sans fr-par-3	gateway create zone=fr-par-3 renvoie Unknown service, 2026-09-10

Glissez pour voir

Le plafond de 8 réseaux privés par passerelle est celui qui structure une architecture. Au-delà, il faut plusieurs passerelles, donc plusieurs adresses publiques, ce qui casse l'avantage du point de sortie unique.

Ce qu'il faut savoir de l'historique du produit

Deux changements majeurs ont eu lieu et se retrouvent encore dans de vieux tutoriels. Les connaître évite de chercher des fonctions qui n'existent plus.

Le DHCP a quitté la passerelle le 12 juillet 2023 pour rejoindre les réseaux privés eux-mêmes. Les réservations statiques créées à l'époque ont été migrées, mais la configuration manuelle est dépréciée et absente de la version 2 de l'API.

La version 1 de l'API a été retirée le 3 novembre 2025, et toutes les passerelles restantes ont été automatiquement migrées en mode IPAM. Un script qui appelle encore la v1 ne fonctionne plus.

La passerelle sous l'angle Well-Architected

Security : combien de portes votre réseau a-t-il vraiment ?

La question clé : combien de machines de votre infrastructure sont joignables depuis Internet, et chacune a-t-elle une raison de l'être ?

La passerelle permet de ramener ce nombre à un. Encore faut-il utiliser la liste d'adresses autorisées du bastion, sans laquelle le point d'entrée unique reste ouvert au monde entier.

La discipline : aucune adresse publique par défaut sur les machines, et une liste d'adresses autorisées sur le bastion, restreinte aux réseaux depuis lesquels vous administrez réellement.

Operational Excellence : que se passe-t-il si la passerelle tombe ?

La question clé : vos machines perdent-elles seulement leur sortie, ou aussi votre accès d'administration ?

Les deux, comme le lab le montre. Une passerelle est donc un point de défaillance unique pour l'exploitation, et pas seulement pour le trafic sortant.

La discipline : savoir à l'avance comment reprendre la main sans elle, par la console série de l'Instance par exemple, et documenter cette procédure avant d'en avoir besoin.

Cost Optimization : payez-vous une passerelle par habitude ?

La question clé : vos machines ont-elles réellement besoin de sortir sur Internet, ou seulement d'atteindre des services du même fournisseur ?

Une passerelle se facture à l'heure, plus le trafic traité. Pour joindre un stockage objet ou une base managée du même fournisseur, un chemin privé évite souvent ce détour et son coût.

La discipline : distinguer ce qui doit sortir sur Internet de ce qui reste chez le fournisseur, et ne router par la passerelle que le premier.

Pièges courants

Toutes ces situations ont été rencontrées en lab le 10 septembre 2026 avec scw 2.62.0.

Symptôme	Cause	Solution
scw ipam ip list resource-id=<serveur> renvoie une liste vide, sans erreur	l'adresse appartient à la carte réseau, pas au serveur	filtrer par private-network-id et retenir le type instance_private_nic
Permission denied (publickey,keyboard-interactive) sur le bastion	l'utilisateur du rebond est bastion, pas root	ssh -J bastion@<passerelle>:61000 root@<privée>
Host key verification failed. sur le rebond	les options SSH ne se propagent pas au saut avec -J	passer par un ProxyCommand explicite qui porte les mêmes options
Connection timed out during banner exchange	le rattachement au réseau privé a été retiré	recréer le rattachement, il porte aussi le chemin du bastion
Unknown service à la création d'une passerelle	la zone visée n'héberge pas le produit, fr-par-3 par exemple	choisir fr-par-1 ou fr-par-2, et vérifier au catalogue public plutôt que dans l'aide
resource is still in use, Private Network must be empty to be deleted	des ressources sont encore rattachées au réseau privé	détacher les machines et la passerelle d'abord
Une clé SSH récente ne fonctionne pas sur le bastion	les clés sont copiées à l'activation du bastion	réimporter les clés depuis la console
unknown argument 'gateway-id' sur pat-rule list	le filtre est gateway-ids.{index}, au pluriel et indexé	pat-rule list gateway-ids.0="$GW"
pat-rule list annonce zéro règle alors qu'elle fonctionne	avec -o json, l'erreur part sur la sortie d'erreur et un 2>&1 la fait passer pour une liste vide	ne pas fusionner les flux, et tester le code de retour
Resource already exists à la création d'une règle PAT	le port public est déjà attribué à une autre règle	choisir un autre port public, ou supprimer la règle existante

Glissez pour voir

Antipatterns à éviter

Antipattern	Conséquence	Discipline
Donner une adresse publique à chaque machine « pour simplifier »	autant de surfaces d'attaque que de machines, et autant de lignes de facture	aucune adresse publique par défaut, une passerelle pour la sortie
Activer le bastion sans liste d'adresses autorisées	le point d'entrée unique est ouvert au monde	restreindre aux réseaux d'administration réels
Retirer un rattachement pour tester en production	perte simultanée de la sortie et de l'accès d'administration	tester sur un réseau privé dédié
Router tout le trafic par la passerelle	on paie le traitement d'un trafic qui aurait pu rester interne	distinguer sortie Internet et accès aux services du fournisseur
Coder les adresses privées en dur	elles changent à la recréation d'une machine	utiliser le nom interne en .internal
Publier un service applicatif par une règle PAT	aucune répartition, aucune terminaison TLS, aucun contrôle d'état du service	réserver PAT à l'administration ponctuelle, et passer par un équilibreur pour du trafic applicatif

Glissez pour voir

Nettoyer

L'ordre compte, et les deux dépendances ne se comportent pas pareil.

1. Supprimez les règles PAT, puis les Instances avec leurs volumes et leurs adresses.

   scw vpc-gw pat-rule delete "$RULE" zone=fr-par-1
   scw instance server terminate "$SRV" zone=fr-par-1 \
     with-block=true with-ip=true

2. Supprimez le rattachement, puis la passerelle et son adresse.

   scw vpc-gw gateway-network delete "$GWNET" zone=fr-par-1
   scw vpc-gw gateway delete "$GW" zone=fr-par-1
   scw vpc-gw ip delete "$IPID" zone=fr-par-1

3. Supprimez le réseau privé, puis le VPC.

   scw vpc private-network delete "$PN" region=fr-par
   scw vpc vpc delete "$VPC" region=fr-par

4. Vérifiez le retour à zéro sur les cinq familles concernées.

   scw instance server list zone=fr-par-1 -o json
   scw vpc-gw gateway list zone=fr-par-1 -o json
   scw vpc-gw ip list zone=fr-par-1 -o json
   scw vpc private-network list region=fr-par -o json
   scw vpc vpc list region=fr-par -o json

   Les cinq sorties doivent être des listes vides.

Le réseau privé refuse, la passerelle accepte

Les deux dépendances ne sont pas symétriques, et c'est mesuré. Le réseau privé refuse d'être supprimé tant qu'il porte des ressources :

resource is still in use, Private Network must be empty to be deleted

La passerelle, elle, se supprime même rattachée, sans avertissement. Le rattachement disparaît avec elle. Ne comptez donc pas sur un refus pour vous protéger d'une suppression prématurée : c'est à votre script d'imposer l'ordre.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• L'adresse publique se facture à part de la passerelle : au catalogue public du 10 septembre 2026, VPC Public Gateway IP vaut 0,005 € par heure en fr-par-1, en plus des 0,026 € du gabarit VPC-GW-S.
• L'adresse privée d'une Instance appartient à sa carte réseau, pas au serveur : ipam ip list resource-id=<serveur> renvoie une liste vide sans erreur.
• La passerelle consomme une adresse du réseau privé, et c'est celle qui devient la route par défaut de vos machines.
• L'utilisateur du rebond SSH est bastion, pas root, et les clés du Projet sont copiées sur le bastion à son activation seulement. Les deux erreurs donnent le même Permission denied (publickey,keyboard-interactive), qui fait chercher du mauvais côté.
• La traduction d'adresses se prouve en une commande : depuis l'Instance, l'adresse vue par Internet est celle de la passerelle.
• Une règle PAT fait l'inverse : pat-rule create public-port=18080 private-ip=… private-port=8080 rend joignable un service qui n'a pas d'adresse publique.
• Le filtre de pat-rule list est gateway-ids.0=, et avec -o json une erreur part sur la sortie d'erreur : un 2>&1 la transforme en liste vide silencieuse.
• Retirer le rattachement coupe aussi le bastion, donc l'accès d'administration, pas seulement la sortie Internet.
• Le réseau privé refuse d'être supprimé tant qu'il porte des ressources, alors que la passerelle, elle, accepte de disparaître même rattachée.
• fr-par-3 n'héberge pas de passerelle : la création y renvoie Unknown service. À l'inverse, une zone absente de l'aide du CLI peut fonctionner, l'aide étant figée dans le binaire.

Pour aller plus loin

• IAM : donner le droit minimal à une CI, et le prouver : restreindre à une politique limitée le droit de créer une passerelle, donc d'ouvrir une porte sur Internet.
• Infrastructure as Code : qui fait quoi : passerelle, rattachement et cartes réseau se déclarent, ce qui évite de reconstruire cet enchaînement à la main.

Ressources externes

• Documentation Public Gateway : les concepts, les gabarits et la configuration.
• Utiliser le bastion SSH : la commande de connexion officielle, la liste d'adresses autorisées et la réimportation des clés.
• Comprendre la version 2 de l'API : ce qui a changé depuis le retrait de la v1 et la migration en mode IPAM.
• Gérer le routage dans un VPC : la portée de l'annonce de route par défaut, qui décide de ce qui sort par la passerelle.

×

📖 Voir la documentation →