Déployer un réseau hub-and-spoke en utilisant un équilibreur de charge en tant que saut suivant

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.

Architecture d'un réseau VPC hub avec deux réseaux VPC spoke.

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. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

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

  1. 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.
  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the Compute Engine API.

    Enable the API

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  6. Make sure that billing is enabled for your Google Cloud project.

  7. Enable the Compute Engine API.

    Enable the API

  8. In the Google Cloud console, activate Cloud Shell.

    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.

  9. Dans ce tutoriel, vous allez exécuter toutes les commandes dans Cloud Shell.

Configurer votre environnement

  1. 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)"`
    
  2. 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 est us-central1-c.

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

  1. 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
    
  2. Créez les réseaux VPC spoke, appelés spoke1-vpc et spoke2-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
    
  3. 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
    
  4. 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.

  5. 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

  1. 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.

  2. Créez une vérification d'état HTTP :

    gcloud compute health-checks create http nat-gw-ilbnhop-health-check \
        --region us-central1 \
        --port 80
    
  3. 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.

  4. 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
    
  5. 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.

  6. 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.

  7. 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
    
  8. 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
    
  9. 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.

  10. 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.

  1. 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
    
  2. 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
    
  3. 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é

  1. 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 et hub-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
    
  2. 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 avec 0.0.0.0/0 comme valeur DEST_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
    
  3. Connectez-vous à l'un des clients à l'aide de SSH via IAP :

    gcloud compute ssh spoke1-client --tunnel-through-iap
    
  4. 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
    
  5. 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

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. 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.

  1. 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
    
  2. 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
    
  3. 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