Sortie Internet des VM sans IP publique #42

New issue

Open

opened 2026-08-20 20:33:59 +00:00 by nicolas.boufideline · 0 comments

nicolas.boufideline commented

2026-08-20 20:33:59 +00:00

Owner

Contexte

Dans le modèle #00, vrf-C ne dialogue qu'avec les RR et les RR ne dialoguent qu'avec les
hosts et les border routers. Une VM disposant d'une IP publique sort par le VNI public et sa
route par défaut vers les border routers.

Une VM sans IP publique n'a aucune sortie.

Besoin à qualifier

mises à jour système et dépôts de paquets ;
services partagés internes (DNS, NTP, journalisation, supervision, sauvegarde) ;
accès sortant applicatif éventuel.

Certains de ces besoins relèvent d'une VRF de service interne, d'autres d'un NAT sortant : à
distinguer avant de choisir un mécanisme unique.

Options

VRF de service partagée avec fuite de route contrôlée depuis chaque vrf-C.
NAT sortant sur les border routers ou sur des nœuds dédiés.
Gateway par VPC sur les border routers avec fuite de route ciblée.

Point d'attention majeur

Toute fuite de route entre VRF est exactement le mécanisme dont #02 établit qu'une erreur y
est silencieuse. Une VRF de service accessible depuis tous les VPC devient un point de
passage entre tenants si la fuite est bidirectionnelle ou mal filtrée.

Contraintes minimales à retenir quelle que soit l'option : fuite unidirectionnelle, filtrée
par prefix-list explicite, jamais par import vrf non filtré, et test négatif inter-VPC
étendu au chemin passant par la VRF de service.

À faire

Qualifier le besoin réel avec les équipes concernées.
Choisir le mécanisme et le documenter.
Étendre le test négatif de #02 au chemin de service.

## Contexte Dans le modèle #00, `vrf-C` ne dialogue qu'avec les RR et les RR ne dialoguent qu'avec les hosts et les border routers. Une VM disposant d'une IP publique sort par le VNI public et sa route par défaut vers les border routers. **Une VM sans IP publique n'a aucune sortie.** ## Besoin à qualifier - mises à jour système et dépôts de paquets ; - services partagés internes (DNS, NTP, journalisation, supervision, sauvegarde) ; - accès sortant applicatif éventuel. Certains de ces besoins relèvent d'une VRF de service interne, d'autres d'un NAT sortant : à distinguer avant de choisir un mécanisme unique. ## Options 1. **VRF de service partagée** avec fuite de route contrôlée depuis chaque `vrf-C`. 2. **NAT sortant** sur les border routers ou sur des nœuds dédiés. 3. **Gateway par VPC** sur les border routers avec fuite de route ciblée. ## Point d'attention majeur Toute fuite de route entre VRF est exactement le mécanisme dont #02 établit qu'une erreur y est **silencieuse**. Une VRF de service accessible depuis tous les VPC devient un point de passage entre tenants si la fuite est bidirectionnelle ou mal filtrée. Contraintes minimales à retenir quelle que soit l'option : fuite unidirectionnelle, filtrée par prefix-list explicite, jamais par `import vrf` non filtré, et test négatif inter-VPC étendu au chemin passant par la VRF de service. ## À faire - [ ] Qualifier le besoin réel avec les équipes concernées. - [ ] Choisir le mécanisme et le documenter. - [ ] Étendre le test négatif de #02 au chemin de service.

nicolas.boufideline added this to the 0.2.0 milestone

2026-08-20 20:34:37 +00:00

nicolas.boufideline added this to the Feature Gestion project

2026-08-20 20:34:40 +00:00

nicolas.boufideline added the

new feature

label

2026-08-20 20:34:44 +00:00