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.

Caractéristiques

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

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

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

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 de la formation 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

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)	—	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

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

# 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

# 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

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

# 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

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.

Prochaines étapes

Calcul — instances TINA et sizing Choisir le bon type d'instance pour les VMs des trois tiers.

Réseau — design Net + Subnets L'architecture réseau dans laquelle s'inscrivent IGW, NAT et EIP.

Réseau — Security Groups Le filtrage applicatif qui complète la mécanique réseau.

Volet 4 — Services managés et alternatives EIP flottante haute dispo, OKS, LBU pour les architectures managées.