Dans l'univers du cloud computing, la gestion réseau est essentielle au bon fonctionnement de vos applications et services.
Photo de Ar_TH sur Shutterstock
Introduction
Dans l'univers du cloud computing, la gestion réseau est essentielle au bon fonctionnement de vos applications et services. L'un de ses aspects fondamentaux consiste à attribuer des adresses IP (Internet Protocol) aux différentes ressources de votre environnement cloud. Ces adresses IP servent d'identifiants numériques à vos ressources cloud et leur permettent de communiquer entre elles ainsi qu'avec Internet.
Lors de la conception d'un réseau, qu'il s'agisse d'un environnement on-premises traditionnel ou d'une plateforme cloud comme Google Cloud Platform (GCP), on rencontre les notions de plages d'adresses IP qui se chevauchent (overlapping) et de plages qui ne se chevauchent pas (non-overlapping).
Les plages d'adresses IP qui se chevauchent désignent deux plages ou plus partageant des adresses IP communes, créant ainsi un recouvrement.
Les plages d'adresses IP non chevauchantes forment un ensemble dans lequel chaque adresse est unique et n'entre pas en conflit avec celles d'une autre plage.
Chaque réseau Virtual Private Cloud (VPC) sur GCP se compose d'un ou plusieurs sous-réseaux, dont les plages d'adresses IP peuvent ou non chevaucher celles d'autres VPC. Il est essentiel d'utiliser une plage IP non chevauchante pour vos sous-réseaux, car l'accès réseau privé n'est pas autorisé par défaut entre sous-réseaux qui se chevauchent.
Dans mon précédent article, j'expliquais comment utiliser Private Service Connect (PSC) pour accéder de manière privée à des services hébergés dans des réseaux VPC dont les plages IP se chevauchent.
GCP a récemment introduit Private NAT en version Preview, afin de faciliter la communication privée entre réseaux qui se chevauchent. Dans cet article, nous allons voir comment configurer le NAT Inter-VPC pour accéder de façon privée à des services hébergés dans différents réseaux VPC, qu'ils contiennent des plages IP qui se chevauchent ou non.
Qu'est-ce que le NAT Inter-VPC ?
Sur GCP, le VPC peering n'est pas autorisé entre réseaux qui se chevauchent, car il ne permet pas de partager des sous-réseaux spécifiques entre VPC. Le NAT Inter-VPC est une offre de passerelle Private NAT qui permet aux ressources d'un VPC situées dans des sous-réseaux qui se chevauchent de communiquer avec des ressources situées dans des sous-réseaux non chevauchants au sein d'un autre VPC, même si d'autres sous-réseaux se chevauchent, grâce à une configuration NAT de type=PRIVATE.
Il s'appuie sur Network Connectivity Center, un système unifié, global et simplifié de gestion de la connectivité réseau. Conçu pour réunir les différentes capacités réseau de Google Cloud au sein d'une interface unique, il facilite la connexion et la gestion de vos réseaux cloud et on-premises.
Network Connectivity Center repose sur un modèle hub-and-spoke. Le hub constitue le point central de connectivité vers vos réseaux Virtual Private Cloud (VPC). On peut le voir comme un routeur virtuel qui agrège la connectivité provenant de différents spokes. Ces spokes peuvent être des VPN, des Interconnects, des routeurs tiers ou d'autres réseaux VPC.
Pour activer le NAT Inter-VPC entre vos réseaux VPC, vous devez configurer chaque réseau VPC comme VPC spoke d'un hub Network Connectivity Center. Les VPC spokes permettent de connecter plusieurs réseaux VPC et d'échanger des routes IPv4 spécifiques de sous-réseaux, ce qui n'est pas possible avec le VPC peering. Cela offre une connectivité IPv4 complète entre l'ensemble des workloads présents dans ces réseaux VPC.
Lors de la création d'un spoke, vous devez empêcher le partage des plages d'adresses IP qui se chevauchent avec les autres VPC spokes.
Limitations
En Preview, le NAT Inter-VPC présente actuellement les principales limitations suivantes.
Le NAT Inter-VPC avec prise en charge inter-projets n'est pas disponible en Preview.
Le logging du NAT Inter-VPC n'est pas disponible en Preview.
En Preview, vous devez utiliser exclusivement la CLI gcloud pour mettre à jour une passerelle Private NAT existante. Passer par la console Google Cloud risque d'aboutir à une configuration incorrecte.
Le NAT Inter-VPC ne prend en charge que les connexions TCP et UDP.
Le NAT Inter-VPC ne prend en charge la traduction d'adresses réseau (NAT) qu'entre VPC spokes Network Connectivity Center, et non avec des réseaux Virtual Private Cloud connectés via VPC Network Peering.
Une instance de machine virtuelle (VM) située dans un réseau VPC ne peut accéder qu'à des destinations situées dans un sous-réseau non chevauchant d'un réseau peeré, et non dans un sous-réseau qui se chevauche.
GCP est susceptible de lever certaines limitations avant le passage en GA. Consultez la documentation officielle pour suivre les mises à jour.
Architecture de référence
Dans cette configuration, vpc-a et vpc-b possèdent un sous-réseau dont les plages d'adresses IP se chevauchent. vpc-b dispose également d'un sous-réseau non chevauchant qui héberge un exemple d'application.
Une passerelle Private NAT sera déployée dans vpc-a pour permettre aux instances du sous-réseau qui se chevauche de se connecter à l'application hébergée dans le sous-réseau non chevauchant.
Nous allons créer aux étapes suivantes des instances de VM sans IP externes. Le forwarding TCP IAP permet d'établir un tunnel chiffré pour acheminer du trafic SSH, RDP et autre vers ces instances.
Vérifiez que les utilisateurs disposent du rôle roles/iap.tunnelResourceAccessor, nécessaire au forwarding TCP et aux tâches associées.
gcloud compute firewall-rules create vpc-a-iap \
--direction=INGRESS \
--priority=1000 \
--network=vpc-a \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20
gcloud compute firewall-rules create vpc-b-iap \
--direction=INGRESS \
--priority=1000 \
--network=vpc-b \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20
Étape 4 : créez une instance Cloud NAT pour l'accès Internet. Cette instance n'autorise pas la communication privée entre VPC, qui sera gérée séparément.
À ce stade, l'instance vpc-a-subnet-a-test dans vpc-a ne peut pas accéder au service hébergé dans l'instance vpc-b-subnet-b-test, faute de connectivité réseau, et il est impossible de mettre en place du VPC peering entre les réseaux à cause du sous-réseau qui se chevauche.
Configurer le hub et les VPC spokes dans Network Connectivity Center
Pour permettre la communication entre deux réseaux VPC dont les plages IP de sous-réseaux se chevauchent, vous devez configurer ces réseaux comme VPC spokes connectés au même hub Network Connectivity Center.
Étape 6 : créez un hub Network Connectivity Center.
Le NAT Inter-VPC nécessite un sous-réseau dédié dont la finalité est PRIVATE_NAT. La passerelle Private NAT s'appuie sur les plages d'adresses IP de ce sous-réseau pour effectuer le NAT. Ce sous-réseau ne doit chevaucher aucun sous-réseau existant des VPC spokes rattachés au même hub Network Connectivity Center et reste exclusivement réservé au Private NAT.
Étape 8 : créez un sous-réseau dédié au Private NAT. Il sera créé dans vpc-a, puisque celui-ci doit accéder au service hébergé dans vpc-b. Le Private NAT n'effectue le NAT que pour les requêtes sortantes.
Étape 10 : créez une règle NAT dans la passerelle Private NAT pour appliquer le NAT au trafic sortant du VPC spoke source vers tout VPC spoke pair rattaché au même hub Network Connectivity Center. Selon cette règle, la passerelle Private NAT attribue les adresses IP NAT issues du sous-réseau Private NAT pour effectuer la traduction.
Étape 12 : testez la connectivité entre les réseaux vpc-a et vpc-b.
La capture d'écran confirme que l'instance située dans vpc-a peut accéder au service hébergé dans le sous-réseau non chevauchant de vpc-b via le NAT Inter-VPC.
Le NAT Inter-VPC est un outil puissant qui simplifie la communication privée entre réseaux qui se chevauchent. Il garantit qu'une ressource peut dialoguer en privé avec d'autres ressources situées dans des sous-réseaux non chevauchants d'un autre VPC, même lorsqu'elle se trouve elle-même dans un sous-réseau qui en chevauche d'autres.
Utilisez Private Service Connect pour activer la communication privée entre sous-réseaux qui se chevauchent. J'espère que ce billet vous aura été utile. N'hésitez pas à me contacter pour toute question.
\n'sudo\ \
apt\ update
À ce stade, l'instance vpc-a-subnet-a-test dans vpc-a ne peut pas accéder au service hébergé dans l'instance vpc-b-subnet-b-test, faute de connectivité réseau, et il est impossible de mettre en place du VPC peering entre les réseaux à cause du sous-réseau qui se chevauche.
Configurer le hub et les VPC spokes dans Network Connectivity Center
Pour permettre la communication entre deux réseaux VPC dont les plages IP de sous-réseaux se chevauchent, vous devez configurer ces réseaux comme VPC spokes connectés au même hub Network Connectivity Center.
Étape 6 : créez un hub Network Connectivity Center.
Étape 7 : ajoutez les réseaux VPC comme spokes au hub. Veillez à exclure les réseaux qui se chevauchent de l'export.
VPC Spokes
Route échangée entre les VPC
Configurer le NAT Inter-VPC
Le NAT Inter-VPC nécessite un sous-réseau dédié dont la finalité est PRIVATE_NAT. La passerelle Private NAT s'appuie sur les plages d'adresses IP de ce sous-réseau pour effectuer le NAT. Ce sous-réseau ne doit chevaucher aucun sous-réseau existant des VPC spokes rattachés au même hub Network Connectivity Center et reste exclusivement réservé au Private NAT.
Étape 8 : créez un sous-réseau dédié au Private NAT. Il sera créé dans vpc-a, puisque celui-ci doit accéder au service hébergé dans vpc-b. Le Private NAT n'effectue le NAT que pour les requêtes sortantes.
Étape 9 : créez un Cloud Router et une passerelle Private NAT.
Étape 10 : créez une règle NAT dans la passerelle Private NAT pour appliquer le NAT au trafic sortant du VPC spoke source vers tout VPC spoke pair rattaché au même hub Network Connectivity Center. Selon cette règle, la passerelle Private NAT attribue les adresses IP NAT issues du sous-réseau Private NAT pour effectuer la traduction.
Étape 11 : créez une règle de pare-feu dans vpc-b pour autoriser les connexions provenant de la passerelle Private NAT.
Étape 12 : testez la connectivité entre les réseaux vpc-a et vpc-b.
La capture d'écran confirme que l'instance située dans vpc-a peut accéder au service hébergé dans le sous-réseau non chevauchant de vpc-b via le NAT Inter-VPC.
Le NAT Inter-VPC est un outil puissant qui simplifie la communication privée entre réseaux qui se chevauchent. Il garantit qu'une ressource peut dialoguer en privé avec d'autres ressources situées dans des sous-réseaux non chevauchants d'un autre VPC, même lorsqu'elle se trouve elle-même dans un sous-réseau qui en chevauche d'autres.
Utilisez Private Service Connect pour activer la communication privée entre sous-réseaux qui se chevauchent. J'espère que ce billet vous aura été utile. N'hésitez pas à me contacter pour toute question.
À ce stade, l'instance vpc-a-subnet-a-test dans vpc-a ne peut pas accéder au service hébergé dans l'instance vpc-b-subnet-b-test, faute de connectivité réseau, et il est impossible de mettre en place du VPC peering entre les réseaux à cause du sous-réseau qui se chevauche.
Configurer le hub et les VPC spokes dans Network Connectivity Center
Pour permettre la communication entre deux réseaux VPC dont les plages IP de sous-réseaux se chevauchent, vous devez configurer ces réseaux comme VPC spokes connectés au même hub Network Connectivity Center.
Étape 6 : créez un hub Network Connectivity Center.
Étape 7 : ajoutez les réseaux VPC comme spokes au hub. Veillez à exclure les réseaux qui se chevauchent de l'export.
VPC Spokes
Route échangée entre les VPC
Configurer le NAT Inter-VPC
Le NAT Inter-VPC nécessite un sous-réseau dédié dont la finalité est PRIVATE_NAT. La passerelle Private NAT s'appuie sur les plages d'adresses IP de ce sous-réseau pour effectuer le NAT. Ce sous-réseau ne doit chevaucher aucun sous-réseau existant des VPC spokes rattachés au même hub Network Connectivity Center et reste exclusivement réservé au Private NAT.
Étape 8 : créez un sous-réseau dédié au Private NAT. Il sera créé dans vpc-a, puisque celui-ci doit accéder au service hébergé dans vpc-b. Le Private NAT n'effectue le NAT que pour les requêtes sortantes.
Étape 9 : créez un Cloud Router et une passerelle Private NAT.
Étape 10 : créez une règle NAT dans la passerelle Private NAT pour appliquer le NAT au trafic sortant du VPC spoke source vers tout VPC spoke pair rattaché au même hub Network Connectivity Center. Selon cette règle, la passerelle Private NAT attribue les adresses IP NAT issues du sous-réseau Private NAT pour effectuer la traduction.
Étape 11 : créez une règle de pare-feu dans vpc-b pour autoriser les connexions provenant de la passerelle Private NAT.
Étape 12 : testez la connectivité entre les réseaux vpc-a et vpc-b.
La capture d'écran confirme que l'instance située dans vpc-a peut accéder au service hébergé dans le sous-réseau non chevauchant de vpc-b via le NAT Inter-VPC.
Le NAT Inter-VPC est un outil puissant qui simplifie la communication privée entre réseaux qui se chevauchent. Il garantit qu'une ressource peut dialoguer en privé avec d'autres ressources situées dans des sous-réseaux non chevauchants d'un autre VPC, même lorsqu'elle se trouve elle-même dans un sous-réseau qui en chevauche d'autres.
Utilisez Private Service Connect pour activer la communication privée entre sous-réseaux qui se chevauchent. J'espère que ce billet vous aura été utile. N'hésitez pas à me contacter pour toute question.
