Photo de Ar_TH sur Shutterstock
Introduction
Dans le vaste univers du cloud computing, la gestion réseau est essentielle au bon fonctionnement de vos applications et services. L'un de ses aspects fondamentaux concerne l'attribution d'adresses IP (Internet Protocol) aux différentes ressources de votre environnement cloud. Ces adresses IP servent d'identifiants numériques aux ressources cloud et leur permettent de communiquer entre elles ainsi qu'avec l'ensemble d'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 ou non.
Les plages IP qui se chevauchent apparaissent lorsque deux plages d'adresses IP ou plus partagent des adresses communes, se superposant ainsi les unes aux autres.
Les plages IP non chevauchantes regroupent quant à elles des adresses IP toutes uniques, qui n'entrent jamais en intersection avec celles d'une autre plage.
Sur GCP, chaque réseau Virtual Private Cloud (VPC) est composé d'un ou plusieurs sous-réseaux, dont les plages IP peuvent chevaucher ou non celles d'autres VPC. Il est essentiel d'utiliser une plage IP non chevauchante pour les sous-réseaux, car l'accès réseau privé n'est pas autorisé par défaut entre des sous-réseaux qui se chevauchent.
Dans mon précédent article, j'ai expliqué comment utiliser Private Service Connect (PSC) pour accéder en privé à des services dans des réseaux VPC dont les plages IP se chevauchent.
GCP a récemment lancé Private NAT en version Preview, dans le but de faciliter la communication privée entre des réseaux qui se chevauchent. Dans cet article, nous verrons comment configurer Inter-VPC NAT pour accéder en privé à des services exécutés dans différents réseaux VPC, qu'ils contiennent des plages IP chevauchantes ou non.
Qu'est-ce qu'**Inter-VPC NAT ?**
Sur GCP, le VPC peering n'est pas autorisé entre des réseaux qui se chevauchent, car il ne permet pas le partage de sous-réseaux spécifiques entre VPC. Inter-VPC NAT est une offre de passerelle Private NAT qui permet aux ressources d'un VPC situées dans des sous-réseaux chevauchants de communiquer avec celles de sous-réseaux non chevauchants d'un autre VPC, même si d'autres sous-réseaux se chevauchent, grâce à une configuration NAT de type=PRIVATE.
Elle fonctionne de pair avec Network Connectivity Center, un système de gestion unifié, global et simplifié de la connectivité réseau. Conçu pour rassembler les différentes capacités réseau de Google Cloud dans une seule interface, 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é de différents spokes. Ces spokes peuvent être des VPN, des Interconnects, des routeurs tiers ou d'autres réseaux VPC.
Pour activer Inter-VPC NAT entre des réseaux VPC, vous devez configurer chaque réseau VPC en tant que VPC spoke d'un hub Network Connectivity Center. Les VPC spokes permettent de connecter plusieurs réseaux VPC et d'échanger des routes de sous-réseaux IPv4 spécifiques, ce qui n'est pas possible avec le VPC peering. On obtient ainsi une connectivité IPv4 complète entre tous les workloads présents dans l'ensemble de ces réseaux VPC.
Lors de la création du spoke, vous devez empêcher le partage des plages IP qui se chevauchent avec les autres VPC spokes.
Limitations
Inter-VPC NAT présente actuellement les principales limitations suivantes en Preview.
- Inter-VPC NAT ne prend pas en charge l'Endpoint-Independent Mapping.
- Inter-VPC NAT avec prise en charge inter-projets n'est pas disponible en Preview.
- La prise en charge du logging pour Inter-VPC NAT n'est pas disponible en Preview.
- En Preview, vous devez utiliser uniquement la CLI gcloud pour mettre à jour une passerelle Private NAT existante. Le passage par la console Google Cloud pour mettre à jour une passerelle Private NAT existante peut entraîner une configuration incorrecte.
- Inter-VPC NAT ne prend en charge que les connexions TCP et UDP.
- Inter-VPC NAT prend en charge la traduction d'adresses réseau (NAT) uniquement entre VPC spokes Network Connectivity Center, et non avec des réseaux Virtual Private Cloud connectés via le VPC Network Peering.
- Une instance de machine virtuelle (VM) 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 peered, et non dans un sous-réseau qui se chevauche.
GCP pourrait lever certaines limitations avant la disponibilité générale (GA) du service. Consultez la documentation officielle pour 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 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 chevauchant de se connecter à l'application située dans le sous-réseau non chevauchant.
https://cloud.google.com/nat/docs/private-nat#pvt-nat-flow-example
Configurer le réseau et déployer l'application
Étape 1 : définissez les variables d'environnement nécessaires.
export PROJECT_ID="your-project-id" #ex: chimbu-playground
export VPC_A_SUBNET_REGION="us-east1"
export VPC_A_SUBNET_A_CIDR="192.168.1.0/24"
export VPC_B_SUBNET_REGION="us-west1"
export VPC_B_SUBNET_B_CIDR="192.168.2.0/24" #non-overlapping subnet between vpc-a and vpc-b
export VPC_B_SUBNET_C_CIDR="192.168.1.0/24" #overlapping subnet between vpc-a and vpc-b
export VPC_A_PRIVATE_NAT_GW_CIDR="10.1.2.0/29"
Étape 2 : créez les réseaux VPC et leurs sous-réseaux.
#Create vpc-a custom Network and subnet
gcloud beta compute networks create vpc-a \
--subnet-mode=custom
gcloud beta compute networks subnets create subnet-a \
--network="vpc-a" \
--role="ACTIVE" \
--purpose="PRIVATE" \
--range=$VPC_A_SUBNET_A_CIDR \
--region=$VPC_A_SUBNET_REGION
# Create vpc-b custom Network and subnets
gcloud beta compute networks create vpc-b \
--subnet-mode=custom
gcloud beta compute networks subnets create subnet-b \
--network="vpc-b" \
--role="ACTIVE" \
--purpose="PRIVATE" \
--range=$VPC_B_SUBNET_B_CIDR \
--region=$VPC_B_SUBNET_REGION
gcloud beta compute networks subnets create subnet-c \
--network="vpc-b" \
--role="ACTIVE" \
--purpose="PRIVATE" \
--range=$VPC_B_SUBNET_C_CIDR \
--region=$VPC_B_SUBNET_REGION
Étape 3 : créez des règles de pare-feu pour le TCP forwarding via Identity-Aware Proxy (IAP) afin d'activer l'accès SSH aux instances de VM.
Les étapes suivantes consistent à créer des instances de VM sans IP externe ; le TCP forwarding IAP permet d'établir un tunnel chiffré pour acheminer du trafic SSH, RDP ou autre vers ces instances.
Vérifiez que le rôle roles/iap.tunnelResourceAccessor est attribué aux utilisateurs pour qu'ils puissent réaliser le TCP forwarding et les 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 Cloud NAT n'autorise pas la communication privée entre VPC ; ce point sera traité séparément.
#vpc-a Cloud router and NAT
gcloud compute routers create vpc-a-internet-nat-router \
--network=vpc-a \
--region=$VPC_A_SUBNET_REGION
gcloud beta compute routers nats create vpc-a-internet-nat \
--router=vpc-a-internet-nat-router \
--nat-all-subnet-ip-ranges \
--region=$VPC_A_SUBNET_REGION \
--auto-allocate-nat-external-ips
#vpc-b Cloud router and NAT
gcloud compute routers create vpc-b-internet-nat-router \
--network=vpc-b \
--region=$VPC_B_SUBNET_REGION
gcloud beta compute routers nats create vpc-b-internet-nat \
--router=vpc-b-internet-nat-router \
--nat-all-subnet-ip-ranges \
--region=$VPC_B_SUBNET_REGION \
--auto-allocate-nat-external-ips
Cloud NAT pour l'accès Internet des instances Compute Engine du réseau
Étape 5 : créez des instances Compute Engine de test sans IP externe.
#Test instance in vpc-a network and subnet-a
gcloud compute instances create vpc-a-subnet-a-test \
--project=$PROJECT_ID \
--zone="us-east1-b" \
--machine-type=e2-medium \
--network-interface=stack-type=IPV4_ONLY,subnet=subnet-a,no-address \
--tags=http-server \
--create-disk=auto-delete=yes,boot=yes,device-name=vpc-a-subnet-a-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-east1-b/diskTypes/pd-balanced
#Test instance in vpc-b network and subnet-b, Also deployed nginx service.Cloud NAT to download the required ngninx packages.
gcloud compute instances create vpc-b-subnet-b-test \
--project=$PROJECT_ID \
--zone="us-west1-a" \
--machine-type=e2-medium \
--network-interface=stack-type=IPV4_ONLY,subnet=subnet-b,no-address \
--metadata=startup-script=\#/bin/sh$'\n'sudo\ \
apt\ update$'\n'sudo\ apt\ install\ nginx\ -y\ \
--tags=http-server \
--create-disk=auto-delete=yes,boot=yes,device-name=vpc-b-subnet-b-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-west1-a/diskTypes/pd-balanced
#Test instance deployed in vpc-b network and subnet-c
gcloud compute instances create vpc-b-subnet-c-test \
--project=$PROJECT_ID \
--zone="us-west1-a" \
--machine-type=e2-medium \
--network-interface=stack-type=IPV4_ONLY,subnet=subnet-c,no-address \
--tags=http-server \
--create-disk=auto-delete=yes,boot=yes,device-name=vpc-b-subnet-c-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-west1-a/diskTypes/pd-balanced
Instances Compute Engine
À ce stade, l'instance vpc-a-subnet-a-test dans vpc-a ne peut pas accéder au service exécuté sur l'instance vpc-b-subnet-b-test faute de connectivité réseau, et il est impossible d'établir un 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 VPC en tant que VPC spokes connectés au même hub Network Connectivity Center.
Étape 6 : créez un hub Network Connectivity Center.
gcloud network-connectivity hubs create private-nat-demo-vpc-hub
Étape 7 : ajoutez les réseaux VPC en tant que spokes du hub. Veillez à exclure les réseaux qui se chevauchent de l'export.
#Add vpc-a to the hub and exclue VPC_A_SUBNET_A_CIDR from export.
gcloud network-connectivity spokes linked-vpc-network create vpc-a \
--hub="https://www.googleapis.com/networkconnectivity/v1/projects/$PROJECT_ID/locations/global/hubs/private-nat-demo-vpc-hub" --global \
--vpc-network="https://www.googleapis.com/compute/v1/projects/$PROJECT_ID/global/networks/vpc-a" \
--exclude-export-ranges=$VPC_A_SUBNET_A_CIDR
#Add vpc-b to the hub and exclue VPC_B_SUBNET_C_CIDR from export.VPC_B_SUBNET_B_CIDR will be exported between the VPCs.
gcloud network-connectivity spokes linked-vpc-network create vpc-b \
--hub="https://www.googleapis.com/networkconnectivity/v1/projects/$PROJECT_ID/locations/global/hubs/private-nat-demo-vpc-hub" --global \
--vpc-network="https://www.googleapis.com/compute/v1/projects/$PROJECT_ID/global/networks/vpc-b" \
--exclude-export-ranges=$VPC_B_SUBNET_C_CIDR
VPC spokes
Route échangée entre les VPC
Configurer Inter-VPC NAT
Inter-VPC NAT requiert un sous-réseau dédié dont l'objectif (purpose) 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 il est exclusivement réservé au Private NAT.
Étape 8 : créez un sous-réseau pour le Private NAT. Il sera créé dans vpc-a, puisque c'est ce VPC qui doit accéder au service exécuté dans vpc-b. Le Private NAT n'effectue le NAT que pour les requêtes sortantes.
gcloud beta compute networks subnets create private-nat-gateway \
--network=vpc-a \
--region=$VPC_A_SUBNET_REGION \
--range=$VPC_A_PRIVATE_NAT_GW_CIDR \
--purpose=PRIVATE_NAT
Étape 9 : créez un Cloud Router et une passerelle Private NAT.
gcloud compute routers create vpc-a-private-nat-gw-router \
--network="vpc-a" \
--region=$VPC_A_SUBNET_REGION
gcloud beta compute routers nats create vpc-a-private-nat-gw \
--router=vpc-a-private-nat-gw-router \
--type=PRIVATE \
--nat-all-subnet-ip-ranges \
--region=$VPC_A_SUBNET_REGION
É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 n'importe lequel des VPC spokes peer rattachés à un hub Network Connectivity Center correspondant. En s'appuyant sur cette règle NAT, la passerelle Private NAT attribue des adresses IP NAT issues du sous-réseau Private NAT pour traiter le trafic.
gcloud beta compute routers nats rules create 1000 \
--router=vpc-a-private-nat-gw-router \
--nat=vpc-a-private-nat-gw \
--match='nexthop.hub == "//networkconnectivity.googleapis.com/projects/chimbuc-playground/locations/global/hubs/private-nat-demo-vpc-hub"' \
--source-nat-active-ranges=private-nat-gateway \
--region=$VPC_A_SUBNET_REGION
Passerelle Private NAT
Étape 11 : créez une règle de pare-feu dans vpc-b pour autoriser les connexions provenant de la passerelle Private NAT.
gcloud compute firewall-rules create vpc-b-allow-ingress-private-nat-gw \
--direction=INGRESS \
--priority=1000 \
--network=vpc-b \
--action=ALLOW \
--rules=tcp \
--source-ranges=$VPC_A_PRIVATE_NAT_GW_CIDR
Étape 12 : testez la connectivité entre les réseaux vpc-a et vpc-b.
La capture d'écran confirme que l'instance dans vpc-a accède bien au service exécuté dans le sous-réseau non chevauchant de vpc-b via Inter-VPC NAT.
Inter-VPC NAT est un outil puissant qui simplifie la communication privée entre des réseaux qui se chevauchent. Grâce à lui, vous pouvez garantir qu'une ressource communique en privé avec d'autres ressources situées dans des sous-réseaux non chevauchants d'un autre VPC, même si cette ressource se trouve dans un sous-réseau qui en chevauche d'autres.
Pour activer la communication privée entre des sous-réseaux qui se chevauchent, utilisez Private Service Connect. J'espère que cet article vous aura été utile. N'hésitez pas à me contacter si vous avez la moindre question.