Ce tutoriel explique comment utiliser l'appairage de réseaux VPC pour déployer une architecture hub-and-spoke.
Ce tutoriel s'adresse aux ingénieurs réseau cloud et aux professionnels des opérations qui souhaitent mettre en œuvre une architecture en étoile dans leur environnement Google Cloud à l'aide de serveurs centralisés constitués de machines virtuelles Compute Engine. Vous allez déployer ces machines virtuelles en tant que passerelles NAT, mais vous pouvez utiliser la même approche pour d'autres fonctions telles que les pare-feu nouvelle génération. Dans ce tutoriel, nous partons du principe que vous connaissez les réseaux VPC et Compute Engine.
Architecture
Dans cette architecture, un ensemble de réseaux VPC "spoke" communique avec l'extérieur via un réseau VPC "hub" dans lequel le trafic est acheminé via un pool centralisé de serveurs, dans ce cas des passerelles de traduction d'adresses réseau (NAT). Les routes concernées sont exportées depuis le réseau VPC hub vers les réseaux VPC spoke. Les passerelles NAT sont configurées comme backends d'un équilibreur de charge interne avec une nouvelle route par défaut, qui possède un équilibreur de charge réseau passthrough interne de Cloud Load Balancing comme saut suivant.
Vous pouvez obtenir le même type de répartition des charges et de haute disponibilité en utilisant plusieurs routes avec un routage multichemin à coût égal (ECMP, Equal Cost Multi-Path). Cependant, l'utilisation de l'équilibreur de charge réseau passthrough interne présente les avantages suivants :
- Le trafic n'est transféré vers des instances opérationnelles que lorsque vous utilisez des vérifications de l'état. Avec l'ECMP, le trafic est transféré vers toutes les instances actives vers lesquelles la route pointe. L'utilisation de l'équilibreur de charge réseau passthrough interne élimine la possibilité que des routes soient inutilisées. En outre, il n'est pas nécessaire de nettoyer les routes lorsque les instances sont arrêtées ou redémarrées.
- Il existe un basculement potentiellement plus rapide, car vous pouvez affiner les minuteurs de vérification de l'état. Si vous utilisez des groupes d'instances gérés et l'autoréparation, vous pouvez toujours personnaliser les minuteurs de vérification de l'état, mais ils sont utilisés pour recréer l'instance et non pour router le trafic.
Google propose également Cloud NAT en tant que service géré, ce qui offre une haute disponibilité sans intervention ni gestion des utilisateurs. Cependant, Cloud NAT n'est pas compatible dans ce cas d'utilisation, car la configuration NAT n'est pas importée dans un réseau appairé.
Le schéma suivant montre la topologie que vous créez dans ce tutoriel.
La topologie se compose d'un réseau VPC hub et de deux réseaux VPC spoke appairés au réseau VPC hub à l'aide de l'appairage de réseaux VPC. Le réseau VPC hub dispose de deux instances de passerelle NAT derrière un équilibreur de charge réseau passthrough interne.
Une route statique par défaut (0/0 NAT-GW-ILB
) pointe vers l'équilibreur de charge réseau passthrough interne en tant que saut suivant. Cette route statique par défaut est exportée via l'appairage de réseaux VPC à l'aide de routes personnalisées.
Objectifs
- Créer plusieurs réseaux VPC et les appairer à l'aide d'une architecture en étoile
- Créer et configurer des passerelles NAT dans le réseau VPC hub
- Configurer l'équilibreur de charge réseau passthrough interne comme saut suivant
- Vérifier la connectivité entre les réseaux VPC spoke et l'Internet public
Coûts
Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.
Avant de commencer
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Compute Engine API.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Compute Engine API.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Dans ce tutoriel, vous allez exécuter toutes les commandes dans Cloud Shell.
Configurer votre environnement
Dans Cloud Shell, assurez-vous que vous travaillez dans le projet Google Cloud que vous avez créé ou sélectionné. Remplacez
project-id
par votre projet Google Cloud.gcloud config set project project-id export PROJECT_ID=`gcloud config list --format="value(core.project)"`
Définissez la région et la zone de calcul par défaut.
gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-c export REGION=us-central1 export ZONE=us-central1-c
Dans ce tutoriel, la région est
us-central1
et la zone estus-central1-c
.
Créer les réseaux et sous-réseaux VPC
Dans Cloud Shell, créez le réseau et le sous-réseau VPC hub :
gcloud compute networks create hub-vpc --subnet-mode custom gcloud compute networks subnets create hub-subnet1 \ --network hub-vpc --range 10.0.0.0/24
Créez les réseaux VPC spoke, appelés
spoke1-vpc
etspoke2-vpc
, avec un sous-réseau chacun :gcloud compute networks create spoke1-vpc --subnet-mode custom gcloud compute networks create spoke2-vpc --subnet-mode custom gcloud compute networks subnets create spoke1-subnet1 \ --network spoke1-vpc --range 192.168.1.0/24 gcloud compute networks subnets create spoke2-subnet1 \ --network spoke2-vpc --range 192.168.2.0/24
Créez des règles de pare-feu dans le réseau VPC hub et les réseaux VPC spoke. Ces règles autorisent le trafic interne (TCP/80 et 443, UDP/53 et ICMP) à partir des plages RFC 1918 spécifiées :
gcloud compute firewall-rules create hub-vpc-web-ping-dns \ --network hub-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.1.0/24,192.168.2.0/24 gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \ --network spoke1-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.1.0/24 gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \ --network spoke2-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.2.0/24
Créez des règles de pare-feu dans le réseau VPC hub et les réseaux VPC spoke pour permettre à IAP pour SSH d'accéder à toutes vos machines virtuelles :
gcloud compute firewall-rules create hub-vpc-iap \ --network hub-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20 gcloud compute firewall-rules create spoke1-vpc-iap \ --network spoke1-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20 gcloud compute firewall-rules create spoke2-vpc-iap \ --network spoke2-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20
Ce tutoriel utilise Identity-Aware Proxy (IAP) pour SSH. Pour plus d'informations, consultez la section Connexion à des instances sans adresse IP externe.
Créez une règle de pare-feu pour autoriser les vérifications de l'état pour les groupes d'instances d'autoréparation dans le réseau VPC hub :
gcloud compute firewall-rules create hub-vpc-health-checks \ --network hub-vpc --allow tcp:443 --target-tags nat-gw \ --source-ranges 130.211.0.0/22,35.191.0.0/16
Créer les instances et les routes requises
Dans Cloud Shell, créez le modèle d'instance pour la passerelle NAT qui comporte un script de démarrage pour configurer la passerelle NAT :
gcloud compute instance-templates create \ hub-nat-gw-ilbnhop-template \ --network hub-vpc \ --subnet hub-subnet1 \ --machine-type n1-standard-2 --can-ip-forward \ --tags nat-gw --scopes default,compute-rw \ --metadata startup-script='#! /bin/bash apt-get update # Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf # Read VM network configuration: md_vm="http://metadata.google.internal/computeMetadata/v1/instance/" md_net="$md_vm/network-interfaces" nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google")" nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")" nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")" nic0_id="$(ip addr show | grep $nic0_addr | tail -c 5)" # Use a web server to pass the health check for this example. # In production, use a more complete test. sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl echo "Example web page to pass health check" | \ tee /var/www/html/index.html sudo systemctl restart apache2 # Enable IP masquerading iptables -t nat -A POSTROUTING -o $nic0_id -j MASQUERADE'
Ce tutoriel utilise
n1-standard-2
comme type d'instance, mais vous pouvez utiliser n'importe quel autre nombre ou n'importe quelle autre taille de passerelle. Veillez à prendre en compte des facteurs tels que la bande passante de sortie maximale par VM.Créez une vérification d'état HTTP :
gcloud compute health-checks create http nat-gw-ilbnhop-health-check \ --region us-central1 \ --port 80
Créez un groupe d'instances régional avec deux instances réparties dans une seule région :
gcloud compute instance-groups managed create \ hub-nat-gw-ilbnhop-mig \ --region us-central1 --size=2 \ --template=hub-nat-gw-ilbnhop-template \ --health-check nat-gw-ilbnhop-health-check \ --initial-delay 15
Dans ce didacticiel, le délai initial est de 15 secondes. Dans un déploiement en production, personnalisez ce paramètre en fonction de vos besoins. Ce tutoriel n'utilise pas les règles d'autoscaling.
Créez un service de backend et ajoutez le groupe d'instances :
gcloud compute backend-services create hub-nat-gw-ilbnhop-backend \ --load-balancing-scheme=internal \ --protocol=tcp \ --health-checks=nat-gw-ilbnhop-health-check gcloud compute backend-services add-backend \ hub-nat-gw-ilbnhop-backend \ --instance-group=hub-nat-gw-ilbnhop-mig \ --instance-group-region=us-central1
Créez une règle de transfert :
gcloud compute forwarding-rules create \ hub-nat-gw-ilbnhop \ --load-balancing-scheme=internal \ --network=hub-vpc \ --subnet=hub-subnet1 \ --address=10.0.0.10 \ --ip-protocol=TCP \ --ports=all \ --backend-service=hub-nat-gw-ilbnhop-backend \ --backend-service-region=us-central1 \ --service-label=hub-nat-gw-ilbnhop
Même si la règle de transfert est définie uniquement avec TCP, lorsque vous utilisez l'équilibreur de charge réseau passthrough interne comme saut suivant, la règle de transfert transfère la totalité du trafic vers tous les ports sur les VM de backend. L'équilibreur de charge réseau passthrough interne est un équilibreur de charge régional.
Créez une route avec la règle de transfert comme saut suivant :
gcloud compute routes create hub-nat-gw-ilbnhop \ --network=hub-vpc \ --destination-range=0.0.0.0/0 \ --next-hop-ilb=hub-nat-gw-ilbnhop \ --next-hop-ilb-region=us-central1 \ --priority=800
Vous pouvez spécifier des tags réseau pour que la route de saut suivant ne s'applique qu'aux instances clientes qui ont été configurées avec le tag, sans que les tags ne soient exportés ni importés via l'appairage de réseaux VPC.
Supprimez la route par défaut du VPC hub :
export hub_default_route=$(gcloud compute routes list \ --format="value(name)" --filter="network:hub-vpc AND \ nextHopGateway:default-internet-gateway" | head -n 1) gcloud compute routes delete $hub_default_route -q
Créez une nouvelle route balisée pour autoriser le trafic provenant uniquement des passerelles NAT :
gcloud compute routes create hub-default-tagged \ --network hub-vpc --destination-range 0.0.0.0/0 \ --next-hop-gateway default-internet-gateway \ --priority 700 --tags nat-gw
Supprimez les routes par défaut vers Internet depuis le VPC pour chaque spoke :
export spoke1_default_route=$(gcloud compute routes list \ --format="value(name)" --filter="network:spoke1-vpc AND \ nextHopGateway:default-internet-gateway") gcloud compute routes delete $spoke1_default_route -q export spoke2_default_route=$(gcloud compute routes list \ --format="value(name)" \ --filter="network:spoke2-vpc AND nextHopGateway:default-internet-gateway") gcloud compute routes delete $spoke2_default_route -q
En cas de conflit entre les routes locales et importées, les routes locales prévalent toujours. Pour plus d'informations, reportez-vous à la section Ordre de routage.
Créer des VM clientes :
gcloud compute instances create spoke1-client \ --subnet=spoke1-subnet1 --no-address \ --metadata startup-script='#! /bin/bash apt-get update apt-get install dnsutils -y' gcloud compute instances create spoke2-client \ --subnet=spoke2-subnet1 --no-address \ --metadata startup-script='#! /bin/bash apt-get update apt-get install dnsutils -y'
Créer les connexions d'appairage de réseaux VPC
L'appairage de réseaux VPC est bidirectionnel et doit donc être défini aux deux extrémités. Un réseau VPC peut être appairé à plusieurs réseaux VPC, mais des limites s'appliquent. Pour atteindre la route par défaut via un appairage de réseaux VPC, utilisez la fonctionnalité Importer et exporter des routes personnalisées via l'appairage de réseaux VPC.
Pour ce tutoriel, vous allez créer tous les réseaux VPC dans le même projet Google Cloud.
Dans Cloud Shell, créez les connexions VPC entre le réseau VPC hub et les réseaux VPC spoke avec l'option d'exportation de routage activée :
gcloud compute networks peerings create hub-to-spoke1 \ --network hub-vpc --peer-network spoke1-vpc \ --peer-project $PROJECT_ID \ --export-custom-routes gcloud compute networks peerings create hub-to-spoke2 \ --network hub-vpc --peer-network spoke2-vpc \ --peer-project $PROJECT_ID \ --export-custom-routes
Créez une connexion d'appairage de réseaux VPC du réseau VPC
spoke1
vers le réseau VPC hub avec l'option d'importation de routage activée :gcloud compute networks peerings create spoke1-to-hub \ --network spoke1-vpc --peer-network hub-vpc \ --peer-project $PROJECT_ID \ --import-custom-routes
Créez une connexion d'appairage de réseaux VPC du réseau VPC
spoke2
vers le réseau VPC hub avec l'option d'importation de routage activée :gcloud compute networks peerings create spoke2-to-hub \ --network spoke2-vpc --peer-network hub-vpc \ --peer-project $PROJECT_ID \ --import-custom-routes
Vérifier la propagation des routes et la connectivité
Dans Cloud Shell, vérifiez que les routes statiques ont été correctement créées dans le cadre des scripts de démarrage.
gcloud compute routes list --filter="network:hub-vpc"
Assurez-vous que les routes
hub-default-tagged
ethub-nat-gw-ilbanhop
sont présentes dans la sortie :NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-13a4b635b5eab48c hub-vpc 10.0.0.0/24 hub-vpc 1000 hub-default-tagged hub-vpc 0.0.0.0/0 default-internet-gateway 700 hub-nat-gw-ilbanhop hub-vpc 0.0.0.0/0 10.0.0.10 800 peering-route-3274f1257a9842a0 hub-vpc 192.168.2.0/24 hub-to-spoke2 1000 peering-route-798c5777f13094bc hub-vpc 192.168.1.0/24 hub-to-spoke1 1000
Vérifiez la table de routage
spoke1-vpc
pour vous assurer que la route par défaut a été correctement importée :gcloud compute routes list --filter="network:spoke1-vpc"
Assurez-vous qu'il existe une route commençant par
peering-route
avec0.0.0.0/0
comme valeurDEST_RANGE
dans la sortie :NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-75f6ea8f5fc54813 spoke1-vpc 192.168.1.0/24 spoke1-vpc 1000 peering-route-6c7f130b860bfd39 spoke1-vpc 10.0.0.0/24 spoke1-to-hub 1000 peering-route-9d44d362f98afbd8 spoke1-vpc 0.0.0.0/0 spoke1-to-hub 800
Connectez-vous à l'un des clients à l'aide de SSH via IAP :
gcloud compute ssh spoke1-client --tunnel-through-iap
Vérifiez la connectivité en testant le DNS public de Google via la passerelle NAT :
sudo hping3 -S -p 80 -c 3 dns.google
Étant donné que l'équilibreur de charge réseau passthrough interne prend en charge TCP et UDP, vous ne pouvez pas vérifier la connectivité Internet en utilisant un ping ICMP. Vous devez donc utiliser un outil tel que hping3.
Le résultat ressemble à ce qui suit :
HPING dns.google (eth0 8.8.4.4): S set, 40 headers + 0 data bytes len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=0 win=65535 rtt=4.6 ms len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=1 win=65535 rtt=4.4 ms len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=2 win=65535 rtt=4.3 ms --- dns.google hping statistic --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 4.3/4.4/4.6 ms
Vérifiez l'adresse IP publique que vous utilisez pour communiquer avec Internet :
curl ifconfig.co
Le résultat affiche une adresse IP publique de l'une des instances de passerelle NAT. Si vous exécutez à nouveau la commande, la sortie peut afficher une adresse IP publique différente, car les connexions sont réparties à l'aide de l'affinité de session d'équilibrage de charge interne configurée (par défaut, adresse IP client, protocole et port).
L'appairage de réseaux VPC n'est pas transitif. Il n'y a donc pas de connectivité entre les réseaux VPC spoke via l'appairage de réseaux VPC.
Informations spécifiques à un environnement de production
La configuration que vous créez dans ce tutoriel fournit deux passerelles NAT dans une même région. Cependant, l'équilibrage de charge ECMP n'est pas parfait et un flux individuel n'est pas réparti sur des liens multiples, ce que vous souhaitez faire lorsque vous utilisez des appareils avec état tels que les pare-feu nouvelle génération.
Pour déployer cette configuration dans l'environnement de production, tenez compte des points suivants :
- Cette configuration est optimale pour les liens sortants éphémères ou sans état. Si la taille du pool de passerelles NAT change, les connexions TCP peuvent être rééquilibrées, ce qui risque d'entraîner la réinitialisation d'une connexion établie.
- Les nœuds ne sont pas mis à jour automatiquement. Par conséquent, si une installation Debian par défaut présente une faille de sécurité, vous devez mettre à jour l'image manuellement.
- Si vous disposez de VM dans plusieurs régions, vous devez configurer des passerelles NAT dans chaque région.
- La bande passante par passerelle peut varier selon le type de matériel. Veillez à prendre en compte des facteurs tels que la bande passante de sortie maximale par VM. En cas de défaillance d'une passerelle, le trafic est distribué aux autres passerelles. Comme les flux en cours d'exécution ne sont pas reprogrammés, le trafic n'est pas immédiatement réinitialisé lorsque la passerelle se reconnecte. Veillez par conséquent à prévoir une marge suffisante lors du dimensionnement.
- Pour être averti des résultats inattendus, utilisez Cloud Monitoring pour surveiller les groupes d'instances gérés et le trafic réseau.
Effectuer un nettoyage
Le moyen le plus simple d'éviter la facturation consiste à supprimer le projet Google Cloud que vous avez créé pour le tutoriel. Vous pouvez également supprimer les différentes ressources.
Supprimer le projet
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Supprimer les ressources individuelles
Si vous souhaitez conserver le projet Google Cloud, vous pouvez supprimer les ressources que vous avez créées pour ce tutoriel.
Supprimez les connexions d'appairage de réseaux VPC :
gcloud compute networks peerings delete spoke2-to-hub \ --network spoke2-vpc -q gcloud compute networks peerings delete spoke1-to-hub \ --network spoke1-vpc -q gcloud compute networks peerings delete hub-to-spoke1 \ --network hub-vpc -q gcloud compute networks peerings delete hub-to-spoke2 \ --network hub-vpc -q
Supprimez les instances, les ressources de l'équilibreur de charge, les modèles et les routes :
gcloud compute instances delete spoke1-client \ --zone=us-central1-c -q gcloud compute instances delete spoke2-client \ --zone=us-central1-c -q gcloud compute routes delete hub-nat-gw-ilbnhop -q gcloud compute forwarding-rules delete hub-nat-gw-ilbnhop -q gcloud compute backend-services delete -q hub-nat-gw-ilbnhop-backend -q gcloud compute instance-groups managed delete hub-nat-gw-ilbnhop-mig \ --region us-central1 -q gcloud compute health-checks delete nat-gw-ilbnhop-health-check -q gcloud compute instance-templates delete hub-nat-gw-ilbnhop-template -q gcloud compute routes delete hub-default-tagged -q
Supprimez les règles de pare-feu, les sous-réseaux et les réseaux VPC :
gcloud compute firewall-rules delete spoke2-vpc-iap -q gcloud compute firewall-rules delete spoke2-vpc-web-ping-dns -q gcloud compute firewall-rules delete spoke1-vpc-iap -q gcloud compute firewall-rules delete spoke1-vpc-web-ping-dns -q gcloud compute firewall-rules delete hub-vpc-iap -q gcloud compute firewall-rules delete hub-vpc-web-ping-dns -q gcloud compute firewall-rules delete hub-vpc-health-checks -q gcloud compute networks subnets delete spoke1-subnet1 \ --region us-central1 -q gcloud compute networks subnets delete spoke2-subnet1 \ --region us-central1 -q gcloud compute networks subnets delete hub-subnet1 \ --region us-central1 -q gcloud compute networks delete spoke1-vpc -q gcloud compute networks delete spoke2-vpc -q gcloud compute networks delete hub-vpc -q
Étapes suivantes
- Découvrez les bonnes pratiques et architectures de référence pour la conception de VPC.
- Consultez la documentation sur l'appairage de réseaux VPC et les équilibreurs de charge réseau passthrough internes en tant que sauts suivants.
- Documentez-vous sur les configurations spéciales pour les instances de VM.