OUTSCALE, Internet Service, NAT, EIP et bastion

Une fois le Net créé avec ses Subnets (cf. Réseau, design Net + Subnets), il faut connecter ce réseau à l'extérieur, Internet, datacenter on-premise, ou autres comptes, et organiser les accès humains vers les ressources internes. Cette page couvre les trois passerelles principales d'un Net OUTSCALE (Internet Service, NAT Service, EIP) et le pattern bastion pour l'accès humain SSH. Page tagguée pour les piliers Well-Architected Security (entrée / sortie maîtrisées) et Reliability (architecture de réseau résiliente).

Ce que vous allez apprendre

Le rôle de l'Internet Service (équivalent IGW AWS), ouvrir un Net vers Internet en bidirectionnel.
Le rôle du NAT Service : laisser sortir le tier privé sans l'exposer.
Les EIP (External / Public IP), IP publiques transférables entre ressources.
Le pattern bastion : point d'entrée unique pour les accès SSH humains.
Les Route Tables : comment associer chaque Subnet à la bonne passerelle.
Créer la chaîne complète IGW + NAT + EIP via oapi-cli.

Prérequis

Avoir lu Réseau, design Net + Subnets, un Net avec au moins un Subnet public et un Subnet privé est nécessaire.
Avoir lu Réseau, Security Groups, les SG s'appliquent en complément des routes.
oapi-cli configuré (cf. Outils CLI).

Internet Service, la passerelle d'entrée et de sortie

L'Internet Service (IGW, équivalent Internet Gateway AWS) est une passerelle bidirectionnelle entre un Net et Internet. Une fois attachée, elle permet :

Aux ressources d'un Subnet public d'être joignables depuis Internet (avec une EIP).
Aux ressources d'un Subnet public d'initier des connexions sortantes vers Internet.

Une seule Internet Service peut être attachée à un Net donné. Sans Internet Service, le Net est totalement isolé d'Internet.

Pour qu'un Subnet soit considéré comme « public », sa Route Table doit contenir une route 0.0.0.0/0 → Internet Service. C'est la route qui rend le Subnet effectivement public, pas une propriété du Subnet lui-même.

NAT Service, sortir sans s'exposer

Le NAT Service (NAT Gateway) permet aux ressources d'un Subnet privé d'initier des connexions sortantes vers Internet (pour télécharger des paquets, appeler une API tierce) sans recevoir de connexions entrantes depuis l'extérieur.

C'est le mécanisme qui matérialise la frontière entre les tiers public et privé : les VMs du tier privé peuvent récupérer des mises à jour, mais restent invisibles depuis Internet. Sur le fond, le NAT Service applique le même principe que le NAT sous Linux (traduction de l'adresse source), proposé ici sous forme de service managé.

Caractéristiques

Quatre contraintes structurent le placement d'un NAT Service, et elles se déduisent toutes de la même chose : c'est une ressource régionale rattachée à un Subnet, pas un service global du Net. Retenez surtout les deux dernières, ce sont celles qui se paient plus tard : oublier la Route Table côté privé donne un tier privé sans aucune sortie, et oublier la duplication par sous-région crée un point de défaillance unique dont personne ne se souvient le jour de la panne.

Le NAT Service vit dans un Subnet public (il a besoin d'accéder à Internet via l'Internet Service).
Il consomme une EIP dédiée (que vous allouez et fournissez à la création).
Les Subnets privés routent leur trafic Internet vers le NAT Service via leur Route Table : 0.0.0.0/0 → NAT Service.
Un NAT Service est lié à une sous-région : pour la haute disponibilité, prévoir un NAT par sous-région.

Coût et facturation

Le NAT Service est facturé à l'usage (heure d'existence + données traitées). Pour un projet en production, c'est un poste de coût visible : à anticiper dans le budget.

EIP, les IP publiques transférables

Une EIP (External Public IP) est une adresse IP publique que vous allouez à votre compte, puis que vous attachez à une ressource (VM, NIC, NAT Service). L'EIP reste votre propriété tant que vous la conservez allouée, vous pouvez la détacher d'une ressource et la rattacher à une autre, sans changer l'adresse IP visible depuis Internet.

Cas d'usage typiques

Le point commun de ces quatre situations est la stabilité de l'adresse face à un cycle de vie plus court : la VM est recréée, l'IP reste. C'est ce découplage qui rend possibles un enregistrement DNS durable et des règles de filtrage écrites une fois pour toutes. À l'inverse, si une ressource n'a besoin d'aucune adresse stable, elle n'a pas besoin d'EIP.

Frontaux web dans un Subnet public, chaque frontal porte une EIP qui ne change pas même si la VM est recréée.
NAT Service : l'EIP du NAT est l'IP que voient les services tiers contactés depuis le tier privé.
Bastion : EIP fixe pour pouvoir restreindre les Security Groups SSH des VMs internes à cette IP précise.
DNS : pointer un enregistrement A sur une EIP qui survit au redéploiement de la VM derrière.

EIP non utilisée = EIP facturée

Une EIP allouée mais non attachée à une ressource active est facturée. Discipline : libérer (DeletePublicIp) toute EIP qui ne sert plus immédiatement.

Le pattern bastion, un point d'entrée unique

Le bastion (ou « jump host ») est une VM dédiée placée dans un Subnet public, dont le seul rôle est de servir de point d'entrée SSH vers les VMs internes (tier privé et tier data). L'utilisateur se connecte d'abord au bastion, puis rebondit en SSH vers la VM cible.

Pourquoi le pattern bastion

Le bastion n'apporte aucune fonctionnalité nouvelle : il déplace le problème de l'exposition SSH d'un ensemble de machines vers une seule. Tout son intérêt tient dans ce rapport de un contre N. Lisez le tableau dans cet ordre : les deux premières lignes justifient l'existence du pattern, les trois suivantes décrivent ce qu'il rend possible ensuite. Le revers, à assumer, est qu'un bastion mal durci devient le point de compromission unique de toute l'infrastructure.

Avantage	Détail
Point d'entrée unique	Aucune VM interne n'est joignable depuis Internet, seul le bastion l'est.
Audit centralisé	Toutes les connexions humaines passent par un seul nœud, qui peut tracer qui se connecte quand vers quoi.
Surface d'attaque réduite	Une seule VM à durcir au maximum (kernel à jour, fail2ban, no password, MFA SSH).
EIP fixe	L'IP publique du bastion ne change pas, facile à autoriser dans les Security Groups internes.
Cohabitation propre avec EIM	Les comptes utilisateurs sur le bastion peuvent être liés à un IdP (LDAP, SSSD, etc.) pour le cycle de vie.

Architecture type

Ce schéma se lit de haut en bas pour l'entrée du trafic. Le point à retenir est l'absence d'EIP sur la VM applicative : elle n'est joignable que depuis le Subnet public, par le bastion, jamais depuis Internet.

Internet
   │
   ▼
[ Internet Service ]
   │
   ▼
Subnet public (eu-west-2a)        Subnet privé (eu-west-2a)
   │                                  │
   ▼                                  ▼
[ Bastion + EIP ]  ── SSH 22 ──▶ [ VM applicative ]
                  (SG-to-SG)         (sans EIP)

Le Security Group du bastion autorise SSH (port 22) uniquement depuis l'IP du bureau ou d'un VPN. Le Security Group des VMs internes autorise SSH uniquement depuis le SG du bastion (pattern SG-to-SG, cf. Security Groups).

Bastion vs alternatives modernes

Le bastion classique reste un pattern éprouvé. Pour les organisations qui veulent aller plus loin :

SSH agent forwarding ou ProxyJump d'OpenSSH évitent de stocker la clé privée sur le bastion.
Tailscale, Cloudflare Access ou solutions ZTNA équivalentes peuvent remplacer le bastion par un mesh d'accès. Ces solutions dépassent le périmètre du parcours mais sont à connaître.
Session Manager-like : OUTSCALE n'expose pas de service Session Manager natif équivalent à AWS SSM ; un outil tiers couvre ce besoin si nécessaire.

Les Route Tables, relier le tout

Les Route Tables (tables de routage) déterminent où va le trafic sortant d'un Subnet, en fonction de l'adresse de destination. Chaque Subnet est associé à une seule Route Table ; cette Route Table contient des routes au format « destination → cible ».

Routes typiques

La règle de sélection est celle du préfixe le plus spécifique : entre la route locale du CIDR du Net et la route 0.0.0.0/0, c'est toujours la première qui gagne pour le trafic interne. C'est pourquoi ajouter une route par défaut ne casse jamais la communication entre Subnets d'un même Net.

Une nuance sur la dernière ligne : les routes vers une Virtual Gateway ne se créent pas avec CreateRoute, qui n'accepte comme cibles que GatewayId, NatServiceId, NetPeeringId, NicId et VmId. Elles sont installées par propagation, avec l'appel UpdateRoutePropagation.

Destination	Cible	Effet
`<CIDR du Net>`	local	Trafic interne au Net (créée automatiquement, non modifiable)
`0.0.0.0/0`	Internet Service	Subnet public : trafic Internet bidirectionnel
`0.0.0.0/0`	NAT Service	Subnet privé : sortie via NAT, pas d'entrée
(aucune route Internet)	aucune	Subnet data : pas d'accès Internet du tout
`<CIDR autre Net>`	Net Peering	Routage vers un Net peeré
`<CIDR datacenter>`	Virtual Gateway	Routage VPN site-à-site (par propagation)

Une Route Table par tier

Bonne pratique : créer une Route Table dédiée par tier (rt-public, rt-private, rt-data) et associer chaque Subnet à la bonne table. Cela rend les flux explicites et auditables : un audit de sécurité peut lire les routes par tier sans se perdre dans une seule Route Table monolithique.

Créer la chaîne complète via `oapi-cli`

Voici l'enchaînement minimal pour rendre un Subnet public vraiment public et un Subnet privé capable de sortir.

1. Créer et attacher l'Internet Service

L'opération se fait en deux appels parce que la passerelle existe d'abord sans rattachement : CreateInternetService n'accepte aucun paramètre obligatoire, LinkInternetService exige ensuite InternetServiceId et NetId. Notez l'identifiant retourné, tous les appels suivants s'y réfèrent, et un ReadInternetServices reste la seule façon de le retrouver si vous le perdez.

# Créer l'Internet Service (pas de paramètre obligatoire)
oapi-cli CreateInternetService
# La réponse contient InternetServiceId (ex: "igw-12345678")

# Attacher au Net
oapi-cli LinkInternetService \
  --InternetServiceId "igw-12345678" \
  --NetId "vpc-12345678"

2. Allouer une EIP pour le NAT Service

L'EIP se réserve avant le NAT Service, qui l'exige à sa création et ne sait pas en allouer une lui-même. À partir de cet appel, la facturation court : une EIP allouée coûte, qu'elle soit attachée ou non. Si la suite de la procédure échoue, pensez à la libérer avec DeletePublicIp plutôt que de la laisser traîner.

# Allouer une EIP (pas de paramètre obligatoire - Outscale en attribue une)
oapi-cli CreatePublicIp
# La réponse contient PublicIpId (ex: "eipalloc-aabbccdd") et l'IP elle-même

3. Créer le NAT Service dans le Subnet public

Le SubnetId passé ici doit désigner un Subnet public, c'est-à-dire un Subnet dont la Route Table pointe déjà vers l'Internet Service créé à l'étape 1. Un NAT Service placé dans un Subnet privé est créé sans erreur mais ne route rien : il n'a lui-même aucun chemin vers Internet. C'est l'erreur la plus fréquente sur cette chaîne, et elle ne se manifeste qu'au premier apt update lancé depuis une VM du tier privé.

oapi-cli CreateNatService \
  --PublicIpId "eipalloc-aabbccdd" \
  --SubnetId "subnet-public-a-id"
# La réponse contient NatServiceId (ex: "nat-1122aabb")

4. Configurer les routes

CreateRoute exige RouteTableId, DestinationIpRange et une cible. Pour le tier public, la cible est l'Internet Service ; pour le tier privé, c'est le NAT Service.

# Route Internet sur la Route Table du tier public
oapi-cli CreateRoute \
  --RouteTableId "rtb-public-id" \
  --DestinationIpRange "0.0.0.0/0" \
  --GatewayId "igw-12345678"

# Route NAT sur la Route Table du tier privé
oapi-cli CreateRoute \
  --RouteTableId "rtb-private-id" \
  --DestinationIpRange "0.0.0.0/0" \
  --NatServiceId "nat-1122aabb"

5. Allouer une EIP pour le bastion et l'attacher

Cette seconde EIP est distincte de celle du NAT Service : une EIP ne s'attache qu'à une ressource à la fois. LinkPublicIp n'a aucun paramètre obligatoire au sens de l'API, mais en pratique il faut lui donner l'identifiant de l'EIP et une cible, VmId ou NicId. L'option --AllowRelink autorise le transfert d'une EIP déjà attachée ailleurs, utile lors d'une bascule, dangereuse en usage courant puisqu'elle coupe silencieusement l'accès à la ressource précédente.

# Allouer une seconde EIP pour le bastion
oapi-cli CreatePublicIp
# Récupérer PublicIpId (ex: "eipalloc-bastion01")

# Attacher l'EIP à la VM bastion (déjà créée)
oapi-cli LinkPublicIp \
  --PublicIpId "eipalloc-bastion01" \
  --VmId "i-bastionvm0"

Bonnes pratiques (par pilier Well-Architected)

1. Un NAT Service par sous-région, pilier Reliability

Pour la haute disponibilité, ne pas dépendre d'un unique NAT Service. Si la sous-région qui héberge le NAT tombe, toutes les sorties Internet du tier privé tombent avec. Discipline : un NAT Service par sous-région, avec une route 0.0.0.0/0 → NAT local dans la Route Table du Subnet privé de chaque sous-région.

2. EIP fixe sur le bastion, pilier Security

L'EIP du bastion doit être stable pour que les Security Groups internes puissent l'autoriser comme source unique. Si l'IP changeait à chaque redémarrage, il faudrait modifier les SG en permanence. Une EIP allouée et persistante évite cela.

3. Pas d'EIP sur les VMs du tier privé, pilier Security

Les VMs du tier privé n'ont jamais d'EIP. Leur sortie Internet passe par le NAT Service. Une EIP attachée par erreur les rend joignables directement depuis Internet, ce qui contredit la séparation par tier.

4. Route Table par tier, pilier Operational Excellence

Une Route Table dédiée par tier (rt-public, rt-private, rt-data) avec un nom explicite. Pas de partage de Route Table entre tiers, sinon une modification accidentelle peut affecter plusieurs tiers à la fois.

5. Bastion durci, pilier Security

Un bastion est une cible privilégiée pour les attaques. Discipline minimale :

MFA SSH ou clés matérielles uniquement (pas de mot de passe).
fail2ban ou équivalent pour bloquer les tentatives répétées.
Mises à jour automatiques des paquets de sécurité.
Audit logs centralisés (export OOS ou Syslog distant).
OS minimaliste : uniquement OpenSSH et les outils strictement nécessaires.

6. Libérer les EIP non utilisées, pilier Cost

Une EIP allouée mais non attachée est facturée. Audit régulier (ReadPublicIps) pour repérer celles qui traînent et les libérer.

7. Tier data sans Internet, pilier Security

Le tier data ne doit pas avoir de route Internet (ni IGW ni NAT). Les bases de données et stockages sensibles n'ont aucune raison d'initier de connexions sortantes externes, leur isolation matérialise la défense en profondeur.

Antipatterns à éviter

Ces sept situations ont un point commun : aucune ne provoque d'erreur au moment où elle est créée. Le NAT unique fonctionne parfaitement jusqu'à la panne de sous-région, l'EIP oubliée n'apparaît que sur la facture, la Route Table partagée ne pose problème que le jour où quelqu'un la modifie. Traitez donc cette liste comme une checklist de revue, pas comme un guide de dépannage : les conséquences arrivent toujours après coup.

Antipattern	Conséquence	Discipline correcte
Bastion sans EIP fixe	Les SG internes doivent être modifiés en permanence	EIP allouée et persistante
EIP sur une VM du tier privé	VM exposée directement à Internet, contradiction avec la séparation par tier	Sortie via NAT, pas d'EIP
NAT Service unique pour tout le Net	Perte d'AZ = perte de toutes les sorties Internet du tier privé	Un NAT par sous-région
Route Table partagée entre tiers	Modification accidentelle multi-tier	Une Route Table dédiée par tier
Bastion permissif (mot de passe, pas de MFA)	Cible privilégiée d'attaques brute force	MFA SSH, durcissement, audit
EIP allouée mais oubliée	Coût mensuel pour rien	Audit régulier, libération
Tier data avec route Internet	Surface d'exfiltration	Pas de route Internet sur les Subnets data

Sous l'angle Well-Architected

Security, entrée et sortie maîtrisées

L'IGW, le NAT Service, les EIP et le bastion constituent ensemble la mécanique d'entrée et de sortie d'un Net. Bien conçus, ils matérialisent les frontières de sécurité :

Qui peut entrer ?, Internet Service ouvre une fenêtre vers le tier public uniquement, le bastion concentre les accès humains, les autres tiers sont fermés à Internet.
Qui peut sortir ?, NAT Service contrôlé pour le tier privé, pas de sortie Internet pour le tier data.
Qui peut atteindre quoi en interne ?, pattern SG-to-SG (cf. Security Groups) qui complète la mécanique réseau par un filtrage applicatif.

Reliability, architecture multi-AZ

La résilience d'un Net dépend de la réplication des passerelles sur plusieurs sous-régions :

Internet Service est unique par Net mais ce n'est pas un point de défaillance, il est managé par OUTSCALE en haute disponibilité par construction.
NAT Service doit être dupliqué par sous-région pour ne pas créer de SPOF, chaque Subnet privé route vers le NAT de sa sous-région.
EIP flottante (sujet du Volet 4, services managés et alternatives) permet de basculer une IP d'une VM à l'autre en cas de défaillance.

Operational Excellence, architecture lisible

Une nomenclature claire (rt-public-a, rt-private-b, nat-a, igw-monprojet, eip-bastion) et une discipline de Route Tables par tier transforment une architecture potentiellement complexe en quelque chose qui se relit facilement, audit après audit, incident après incident.

À retenir

L'Internet Service est la passerelle bidirectionnelle entre un Net et Internet ; un seul par Net, attaché via LinkInternetService.
Le NAT Service vit dans un Subnet public et permet la sortie sans exposition pour le tier privé ; un par sous-région pour la résilience.
Les EIP (Public IP) sont des IP publiques transférables entre ressources, à conserver allouées tant qu'elles servent.
Le pattern bastion centralise les accès SSH humains : EIP fixe, durcissement, MFA, audit.
Les Route Tables déterminent la cible du trafic d'un Subnet ; une Route Table par tier est la bonne discipline.
Le tier data n'a jamais de route Internet : pas d'IGW, pas de NAT.
EIP non attachée = EIP facturée : audit régulier et libération.
L'industrialisation IaC (Volet 3) est le bon endroit pour matérialiser cette chaîne.

Pour aller plus loin

Pilier Security : Le cadre qui fait du bastion, du NAT contrôlé et de l'EIP une posture d'exposition maîtrisée.
Pilier Reliability : Le rôle des EIP transférables dans une bascule multi-AZ, et les limites du procédé.
Chapitre 3, Bastion SSH durci : La mise en pratique complète, EIP fixe hors Terraform et durcissement sshd par Ansible.