Configurer un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant (avec tags)

Ce tutoriel utilise un exemple pour vous montrer comment déployer un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant vers lequel les paquets sont transférés le long de la route menant à leur destination finale. Vous utilisez des tags réseau pour configurer les instances de client spécifiques auxquelles la route s'applique.

Dans ce guide, nous partons du principe que vous connaissez le fonctionnement d'un équilibreur de charge réseau interne à stratégie directe, ses composants associés, tels que les règles de pare-feu et les vérifications d'état, et comment les équilibreurs de charge réseau internes à stratégie directe sont utilisés en tant que sauts suivants pour transférer des paquets sur une route.

Avec l'équilibreur de charge réseau interne à stratégie directe en tant que fonctionnalité de saut suivant, vous pouvez intégrer des dispositifs tiers de manière évolutive et hautement disponible. Pour ce faire, vous devez configurer une route statique personnalisée et définir le saut suivant vers l'équilibreur de charge, qui distribue le trafic pour le préfixe de destination vers le pool d'appareils VM tiers vérifiés pour l'état. Lorsque vous sélectionnez vos sauts suivants, vous disposez de plusieurs options pour assurer la haute disponibilité de ces dispositifs tiers :

• Spécifiez une adresse IP en tant que prochain saut : utilisez l'adresse IP interne associée à la règle de transfert en tant que prochain saut. L'adresse IP virtuelle de cet équilibreur de charge peut être apprise sur plusieurs pairs sans avoir à exporter la route personnalisée via ses pairs.
• Utiliser des tags réseau :vous pouvez spécifier un tag réseau afin que l'équilibreur de charge réseau interne à stratégie directe en tant que route de saut suivant ne s'applique qu'aux instances clientes qui ont été configurées avec le tag. Cela vous permet de sélectionner les instances de client auxquelles vous souhaitez associer un équilibreur de charge réseau interne à stratégie directe en tant que route de saut suivant et l'ensemble d'appareils vers lesquels acheminer votre trafic. Vous n'avez pas besoin de répartir les différentes instances clientes dans des VPC distincts. Chacune d'elles pointe vers son équilibreur de charge réseau interne à stratégie directe préféré afin d'interfacer un ensemble d'appareils. Les routes avec tag ne sont pas exportées ni importées via l'appairage de réseaux VPC.
• Configurer plusieurs routes vers le même préfixe de destination : avec des tags, vous pouvez spécifier plusieurs routes vers la même destination avec des équilibreurs de charge internes différents comme sauts suivants. Bien que le protocole ECMP ne soit pas compatible (même préfixe de destination, mêmes tags, sauts suivants différents), vous pouvez utiliser des tags ou des priorités différents pour ces mêmes routes de destination.

Vue d'ensemble de la configuration

Les groupes d'instances gérés utilisant des VM avec une carte d'interface réseau unique sont définis dans différentes régions, les instances Linux étant configurées pour effectuer la traduction SNAT de tout le trafic sortant vers Internet (flux de trafic sortant Nord-Sud). Le basculement régional est déclenché manuellement. Ce tutoriel illustre également la connectivité Est-Ouest avec le hachage symétrique utilisant un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant.

Les étapes de cette section décrivent comment configurer les éléments suivants :

1. Exemples de réseaux VPC avec des sous-réseaux personnalisés
2. Des règles de pare-feu autorisant les connexions entrantes aux VM de backend
3. Groupes d'instances gérés de backend qui déploient des passerelles NAT
4. VM clientes pour tester les connexions
5. Les composants de l'équilibreur de charge réseau interne à stratégie directe suivants :
   • Vérification d'état du service de backend
   • Un service de backend interne
   • Règle de transfert interne et adresse IP pour l'interface de l'équilibreur de charge

L'architecture de cet exemple se présente comme suit :

Équilibreur de charge réseau interne à stratégie directe en tant que configuration de saut suivant (cliquez pour agrandir)

Lorsque vous suivez ce tutoriel, remplacez REGION_A et REGION_B par les régions que vous souhaitez utiliser pour cet exemple.

Créer les réseaux et sous-réseaux VPC

1. Créez un réseau VPC appelé hub-vpc.

   gcloud compute networks create hub-vpc --subnet-mode custom
   

2. Créez un sous-réseau dans hub-vpc, dans la région REGION_A.

   gcloud compute networks subnets create hub-subnet-a \
       --network hub-vpc \
       --range 10.0.0.0/24 \
       --region REGION_A
   

3. Créez un sous-réseau dans hub-vpc, dans la région region B.

   gcloud compute networks subnets create hub-subnet-b \
       --network hub-vpc \
       --range 10.0.1.0/24 \
       --region REGION_B
   

4. Créez un réseau VPC appelé spoke1-vpc.

   gcloud compute networks create spoke1-vpc --subnet-mode custom
   

5. Créez un sous-réseau dans spoke1-vpc.

   gcloud compute networks subnets create spoke1-subnet1 \
       --network spoke1-vpc \
       --range 192.168.0.0/24 \
       --region REGION_A
   

6. Créez un réseau VPC appelé spoke2-vpc.

   gcloud compute networks create spoke2-vpc --subnet-mode custom
   

7. Créez un sous-réseau dans spoke2-vpc.

   gcloud compute networks subnets create spoke2-subnet1 \
       --network spoke2-vpc \
       --range 192.168.1.0/24 \
       --region REGION_A
   

Configurer des règles de pare-feu

1. Configurez les règles de pare-feu suivantes pour permettre au trafic TCP, UDP et ICMP d'atteindre les instances des plages sources 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,10.0.1.0/24,192.168.0.0/24,192.168.1.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,10.0.1.0/24,192.168.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,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24
   

2. Créez une règle de pare-feu pour autoriser les vérificateurs d'état à accéder aux instances sur hub-vpc.

   gcloud compute firewall-rules create hub-vpc-health-checks \
       --network hub-vpc \
       --allow tcp:80 \
       --target-tags natgw \
       --source-ranges 130.211.0.0/22,35.191.0.0/16
   

3. Créez des règles de pare-feu pour autoriser l'accès SSH pour les instances sur tous les sous-réseaux. Si vous préférez utiliser Identity-Aware Proxy pour le transfert TCP (recommandé), suivez ces étapes pour activer SSH.

   gcloud compute firewall-rules create hub-vpc-allow-ssh \
       --network hub-vpc \
       --allow tcp:22
   

   gcloud compute firewall-rules create spoke1-vpc-allow-ssh \
       --network spoke1-vpc \
       --allow tcp:22
   

   gcloud compute firewall-rules create spoke2-vpc-allow-ssh \
       --network spoke2-vpc \
       --allow tcp:22
   

Configurer l'appairage de réseaux VPC

1. Créez un appairage de hub-vpc à spoke1-vpc.

   gcloud compute networks peerings create hub-to-spoke1 \
       --network hub-vpc \
       --peer-network spoke1-vpc \
       --peer-project PROJECT_ID \
       --export-custom-routes
       

2. Créez un appairage de spoke1-vpc à hub-vpc.

   gcloud compute networks peerings create spoke1-to-hub \
       --network spoke1-vpc \
       --peer-network hub-vpc \
       --peer-project PROJECT_ID \
       --import-custom-routes
   

3. Créez un appairage de hub-vpc à spoke2-vpc.

   gcloud compute networks peerings create hub-to-spoke2 \
       --network hub-vpc \
       --peer-network spoke2-vpc \
       --peer-project PROJECT_ID \
       --export-custom-routes
   

4. Créez un appairage de spoke2-vpc à hub-vpc.

   gcloud compute networks peerings create spoke2-to-hub \
       --network spoke2-vpc \
       --peer-network hub-vpc \
       --peer-project PROJECT_ID \
       --import-custom-routes
   

Créer des VM de passerelle NAT et des ressources d'équilibrage de charge dans la région A

Créez le backend du groupe d'instances géré dans REGION_A. Créez ensuite les ressources d'équilibrage de charge et les routes de prochain saut.

Créer un groupe d'instances géré

1. Créez un modèle d'instance pour déployer une passerelle NAT dans region A.

   gcloud compute instance-templates create hub-natgw-region-a-template \
       --network hub-vpc \
       --subnet hub-subnet-a \
       --region REGION_A \
       --machine-type n1-standard-2 \
       --can-ip-forward \
       --tags natgw \
       --metadata startup-script='#! /bin/bash
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
   # iptables configuration
   iptables -t nat -F
   sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
   iptables-save
   # Use a web server to pass the health check for this example.
   # You should use a more complete test in production.
   apt-get update
   apt-get install apache2 tcpdump -y
   a2ensite default-ssl
   a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html \
   systemctl restart apache2'
   

2. Créez le groupe d'instances dans REGION_A.

   gcloud compute instance-groups managed create hub-natgw-region-a-mig \
       --region REGION_A \
       --size=2 \
       --template=hub-natgw-region-a-template
   

Créer l'équilibreur de charge

Pour créer un équilibreur de charge dans REGION_A, procédez comme suit :

1. Créez une vérification d'état.

   gcloud compute health-checks create http natgw-ilbnhop-health-check \
       --port=80
   

2. Créez le service de backend :

   gcloud compute backend-services create hub-natgw-region-a-be \
       --load-balancing-scheme=internal \
       --protocol tcp \
       --region REGION_A\
       --health-checks=natgw-ilbnhop-health-check
   

3. Ajoutez le groupe d'instances géré en tant que backend.

   gcloud compute backend-services add-backend hub-natgw-region-a-be \
       --instance-group=hub-natgw-region-a-mig \
       --instance-group-region=REGION_A
   

4. Créez la règle de transfert.

   gcloud compute forwarding-rules create hub-natgw-region-a \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet-a \
       --address=10.0.0.10 \
       --ip-protocol=TCP \
       --ports=all \
       --allow-global-access \
       --backend-service=hub-natgw-region-a-be \
       --backend-service-region=REGION_A
   

Créer les routes de saut suivant

Créez les routes d'équilibreur de charge réseau interne à stratégie directe en tant que saut suivant avec le tag réseau prédéfini ilbanh-region-a.

gcloud compute routes create spoke1-natgw-region-a \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

gcloud compute routes create spoke2-natgw-region-a \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

Tester la connectivité

Créer des instances clientes pour tester la connectivité

1. Créez une instance de client de test dans spoke1-vpc.

   gcloud compute instances create spoke1-client \
       --subnet=spoke1-subnet1 --no-address --zone ZONE_A \
       --tags=ilbanh-region-a \
       --metadata startup-script='#! /bin/bash
   apt-get update
   apt-get install tcpdump -y'
   

2. Créez une instance de client de test dans spoke2-vpc.

   gcloud compute instances create spoke2-client \
       --subnet=spoke2-subnet1 --no-address --zone ZONE_A \
       --tags=ilbanh-region-a \
       --metadata startup-script='#! /bin/bash
   apt-get update
   apt-get install tcpdump -y'
   

Valider les flux de trafic Nord-Sud et Est-Ouest

1. Assurez-vous que les VM de la passerelle NAT sont en cours d'exécution et notez les adresses IP externes attribuées :

   gcloud compute instances list --filter="status:RUNNING AND name~natgw"
   

2. Vérifiez que l'équilibreur de charge est opérationnel et que les routes ont été créées comme prévu :

   gcloud compute backend-services get-health hub-natgw-region-a-be --region REGION_A
   

   backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/instanceGroups/hub-natgw-region-a-mig
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
       forwardingRuleIp: 10.0.0.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-b/instances/<INSTANCE_NAME>
       ipAddress: 10.0.0.5
       port: 80
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
       forwardingRuleIp: 10.0.0.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-f/instances/<INSTANCE_NAME>
       ipAddress: 10.0.0.6
       port: 80
     kind: compute#backendServiceGroupHealth
   

3. Vérifiez que les routes de l'équilibreur de charge réseau interne à stratégie directe en tant que saut suivant sont ajoutées aux VPC spoke avec la priorité attendue et ciblant l'adresse IP de l'équilibreur de charge réseau interne à stratégie directe :

   gcloud compute routes list --filter="name~natgw"
   

4. Accédez à la console Google Cloud et établissez des connexions SSH avec les VM de la passerelle NAT dans différents onglets.

5. Démarrez tcpdump dans chacune de ces sessions SSH à l'aide de la commande suivante :

   sudo tcpdump -n net 192.168.0.0/16
   

6. Accédez à la console Google Cloud et établissez une nouvelle connexion SSH avec la VM spoke1-client. Exécutez ensuite la commande suivante pour pinguer l'adresse IP interne de spoke2-client.

   ping SPOKE2_CLIENT_INTERNAL_IP
   

7. Basculez vers les fenêtres SSH de la passerelle NAT et vérifiez que vous pouvez voir les paquets ICMP comme suit :

   16:51:28.411260 IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1684, seq 492, length 64
   16:51:28.411676 IP 192.168.1.2 > 192.168.0.2: ICMP echo reply, id 1684, seq 492, length 64
   

   Vous devriez pouvoir pinguer la VM cliente, ce qui illustre les éléments suivants :

   • Le trafic Est-Ouest est activé via les passerelles NAT. Notez que l'appairage transitif n'est pas disponible entre les VPC spoke.
   • Le hachage symétrique est activé et fonctionne comme prévu, car les clients peuvent communiquer à l'aide de leurs adresses IP sources, sans nécessiter la traduction SNAT.
   • Tous les protocoles sont compatibles avec l'équilibreur de charge réseau interne à stratégie directe en tant que saut suivant.

8. Arrêtez les sorties tcpdump sur les VM de la passerelle NAT et observez les statistiques iptables :

   watch sudo iptables -t nat -nvL
   

9. Revenez à la VM spoke1-client et exécutez plusieurs fois la commande suivante. Le résultat affiche l'adresse IP source publique utilisée pour se connecter au site Web.

   curl ifconfig.io
   

   Les adresses IP des deux VM de la passerelle NAT doivent s'afficher en tant qu'adresses IP sources. Cela montre que l'équilibreur de charge réseau interne à stratégie directe distribue le trafic en fonction de l'affinité par défaut (hachage à cinq tuples).

10. Revenez à la VM de passerelle NAT pour vérifier que les compteurs de paquets ont augmenté.

    Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
      105 11442 MASQUERADE  all  --  *      *       0.0.0.0/0           !192.168.0.0/16
    
    Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    

Créer des VM de passerelle NAT et des ressources d'équilibrage de charge dans la région B

Créez le backend du groupe d'instances géré dans region B. Créez ensuite les ressources d'équilibrage de charge et les routes de prochain saut.

Créer un groupe d'instances géré

1. Créez un modèle d'instance pour déployer une passerelle NAT dans region B.

   gcloud compute instance-templates create hub-natgw-region-b-template \
       --network hub-vpc \
       --subnet hub-subnet-b --region REGION_B \
       --machine-type n1-standard-2 --can-ip-forward \
       --tags natgw \
       --metadata startup-script='#! /bin/bash
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
   # iptables configuration
   iptables -t nat -F
   sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
   iptables-save
   # Use a web server to pass the health check for this example.
   # You should use a more complete test in production.
   apt-get update
   apt-get install apache2 tcpdump -y
   a2ensite default-ssl
   a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html \
   systemctl restart apache2'
   

2. Créez le groupe d'instances dans region B.

   gcloud compute instance-groups managed create hub-natgw-region-b-mig \
       --region REGION_B \
       --size=2 \
       --template=hub-natgw-region-b-template
   

Créer l'équilibreur de charge

Pour créer un équilibreur de charge dans la région B, procédez comme suit :

1. Créez le service de backend :

   gcloud compute backend-services create hub-natgw-region-b-be \
       --load-balancing-scheme=internal \
       --protocol tcp \
       --region REGION_B\
       --health-checks=natgw-ilbnhop-health-check
   

2. Ajoutez le groupe d'instances géré en tant que backend.

   gcloud compute backend-services add-backend hub-natgw-region-b-be \
       --instance-group=hub-natgw-region-b-mig \
       --instance-group-region=REGION_B
   

3. Créez la règle de transfert.

   gcloud compute forwarding-rules create hub-natgw-region-b \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet-b \
       --address=10.0.1.10 \
       --ip-protocol=TCP \
       --ports=all \
       --allow-global-access \
       --backend-service=hub-natgw-region-b-be \
       --backend-service-region=REGION_B
   

Créer les routes de saut suivant

Créez les routes d'équilibreur de charge réseau interne à stratégie directe en tant que saut suivant avec le tag réseau prédéfini ilbanh-region-a.

gcloud compute routes create spoke1-natgw-region-b \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

gcloud compute routes create spoke2-natgw-region-b \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

Valider le basculement régional

1. Assurez-vous que les VM de la passerelle NAT sont en cours d'exécution et notez les adresses IP externes attribuées :

   gcloud compute instances list --filter="status:RUNNING AND name~natgw"
   

2. Vérifiez que l'équilibreur de charge est opérationnel et que les routes sont créées comme prévu :

   gcloud compute backend-services get-health hub-natgw-region-b-be --region REGION_B
   

   backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/instanceGroups/hub-natgw-region-b-mig
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
       forwardingRuleIp: 10.0.1.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-a/instances/<INSTANCE_NAME>
       ipAddress: 10.0.1.3
       port: 80
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
       forwardingRuleIp: 10.0.1.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-b/instances/<INSTANCE_NAME>
       ipAddress: 10.0.1.2
       port: 80
     kind: compute#backendServiceGroupHealth
   

3. Vérifiez que les routes de l'équilibreur de charge réseau interne à stratégie directe en tant que saut suivant sont ajoutées aux VPC spoke avec la priorité attendue et ciblant l'adresse IP de l'équilibreur de charge réseau interne à stratégie directe :

   gcloud compute routes list --filter="name~natgw"
   

4. Vous pouvez maintenant valider le basculement régional en supprimant les routes à priorité élevée et en notant ce qui se passe. Basculez vers la VM spoke1-client et exécutez la commande suivante pour envoyer une requête curl toutes les secondes. Cette commande indique également l'adresse IP externe utilisée :

   while true; do echo -n `date` && echo -n ' - ' && curl ifconfig.io --connect-timeout 1; done
   

   Seules les adresses IP externes attribuées aux passerelles NAT dans region A doivent s'afficher, car il s'agit de la route à priorité élevée. Laissez la commande curl s'exécuter, et basculez vers Cloud Shell pour supprimer la route vers l'équilibreur de charge réseau interne à stratégie directe dans region A afin de vérifier le résultat :

   gcloud -q compute routes delete spoke1-natgw-region-a
   

   Dans region B, les adresses IP externes attribuées aux VM de la passerelle NAT apparaissent, probablement avec un temps d'arrêt minimal, ce qui montre que le basculement régional a réussi.

Remarque : Une route n'est pas automatiquement supprimée même si tous les backends sont non opérationnels. Envisagez d'automatiser ce processus à l'aide des Fonctions Cloud Run.

Effectuer un nettoyage des ressources

1. Supprimez les routes de l'équilibreur de charge réseau interne à stratégie directe en tant que saut suivant:

   gcloud -q compute routes delete spoke1-natgw-region-b
   
   gcloud -q compute routes delete spoke2-natgw-region-a
   
   gcloud -q compute routes delete spoke2-natgw-region-b
   

2. Supprimez les ressources et les backends de l'équilibreur de charge réseau interne à stratégie directe :

   gcloud -q compute forwarding-rules delete hub-natgw-region-a \
     --region REGION_A
   
   gcloud -q compute backend-services delete hub-natgw-region-a-be \
     --region REGION_A
   
   gcloud -q compute instance-groups managed delete hub-natgw-region-a-mig \
     --region REGION_A
   
   gcloud -q compute instance-templates delete hub-natgw-region-a-template
   
   gcloud -q compute forwarding-rules delete hub-natgw-region-b \
     --region REGION_B
   
   gcloud -q compute backend-services delete hub-natgw-region-b-be \
     --region REGION_B
   
   gcloud -q compute instance-groups managed delete hub-natgw-region-b-mig \
     --region REGION_B
   
   gcloud -q compute instance-templates delete hub-natgw-region-b-template
   
   gcloud -q compute health-checks delete natgw-ilbnhop-health-check
   

3. Supprimez les VM clientes :

   gcloud -q compute instances delete spoke1-client \
     --zone=ZONE_A
   
   gcloud -q compute instances delete spoke2-client \
     --zone=ZONE_A
   

4. Supprimez les appairages de réseaux VPC, les règles de pare-feu, les sous-réseaux et les VPC :

   gcloud -q compute networks peerings delete spoke2-to-hub \
     --network spoke2-vpc
   
   gcloud -q compute networks peerings delete spoke1-to-hub \
     --network spoke1-vpc
   
   gcloud -q compute networks peerings delete hub-to-spoke1 \
     --network hub-vpc
   
   gcloud -q compute networks peerings delete hub-to-spoke2 \
     --network hub-vpc
   
   gcloud -q compute firewall-rules delete spoke2-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete spoke1-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete hub-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete hub-vpc-health-checks
   
   gcloud -q compute firewall-rules delete hub-vpc-allow-ssh
   
   gcloud -q compute firewall-rules delete spoke1-vpc-allow-ssh
   
   gcloud -q compute firewall-rules delete spoke2-vpc-allow-ssh
   
   gcloud -q compute networks subnets delete spoke1-subnet1 \
     --region REGION_A
   
   gcloud -q compute networks subnets delete spoke2-subnet1 \
     --region REGION_A
   
   gcloud -q compute networks subnets delete hub-subnet-a \
     --region REGION_A
   
   gcloud -q compute networks subnets delete hub-subnet-b \
     --region REGION_B
   
   gcloud -q compute networks delete spoke1-vpc
   
   gcloud -q compute networks delete spoke2-vpc
   
   gcloud -q compute networks delete hub-vpc
   

Étapes suivantes

• Pour plus d'informations sur le basculement, consultez la page Concepts de basculement pour les équilibreurs de charge réseau internes à stratégie directe.
• Pour plus d'informations sur la configuration de la journalisation et de la surveillance pour l'équilibreur de charge réseau à stratégie directe interne, consultez la page Journalisation et surveillance de l'équilibreur de charge réseau interne à stratégie directe.
• Pour en savoir plus sur l'accès aux équilibreurs de charge réseau internes à stratégie directe à partir des réseaux pairs connectés à votre réseau VPC, consultez la page Équilibreurs de charge réseau internes à stratégie directe.
• Pour plus d'informations sur la résolution des problèmes liés à votre équilibreur de charge réseau à stratégie interne, consultez la page Résoudre les problèmes liés aux équilibreurs de charge réseau internes à stratégie directe.