Esegui il deployment di una rete hub and spoke utilizzando un bilanciatore del carico come hop successivo

Questo tutorial descrive come utilizzare il peering di rete VPC per eseguire il deployment di un'architettura hub-and-spoke.

Questo tutorial è destinato agli ingegneri di rete cloud e ai professionisti delle operazioni che vogliono implementare un'architettura hub-and-spoke nel proprio Google Cloud ambiente utilizzando appliance centralizzate costituite da macchine virtuali Compute Engine. In questo tutorial, esegui il deployment di queste macchine virtuali come gateway NAT, ma puoi utilizzare lo stesso approccio per altre funzioni, come i firewall di nuova generazione. Questo tutorial presuppone che tu abbia familiarità con le reti VPC e Compute Engine.

Architettura

In questa architettura, un insieme di reti VPC spoke comunica con l'esterno tramite una rete VPC hub in cui il traffico viene instradato attraverso un pool centralizzato di appliance, in questo caso gateway NAT (Network Address Translation). Le route pertinenti vengono esportate dalla rete VPC hub nelle reti VPC spoke. I gateway NAT sono configurati come backend di un bilanciatore del carico interno con una nuova route predefinita, che ha un bilanciatore del carico di rete passthrough interno di Cloud Load Balancing come hop successivo.

Puoi ottenere lo stesso tipo di distribuzione del carico e alta affidabilità utilizzando più route con routing ECMP (Equal-cost multipath). Tuttavia, l'utilizzo del bilanciatore del carico di rete passthrough interno presenta i seguenti vantaggi:

  • Il traffico viene inoltrato solo alle istanze integre quando si utilizzano i controlli di integrità. Con ECMP, il traffico viene inoltrato a tutte le istanze attive a cui punta la route; l'utilizzo di un bilanciatore del carico di rete passthrough interno elimina la possibilità di route inutilizzate. Inoltre, non è necessario eseguire la pulizia delle route quando le istanze vengono terminate o riavviate.
  • Il failover è potenzialmente più veloce perché puoi ottimizzare i timer dei controlli di integrità. Se utilizzi gruppi di istanze gestite e il ripristino automatico, puoi ancora personalizzare i timer dei controlli di integrità, ma vengono utilizzati per ricreare l'istanza, non instradare il traffico.

Google offre anche Cloud NAT come servizio gestito, che fornisce alta affidabilità senza gestione e intervento da parte dell'utente. Tuttavia, Cloud NAT non è supportato in questo caso d'uso perché la configurazione NAT non viene importata in una rete con peering.

Il seguente diagramma mostra la topologia che crei in questo tutorial.

Architettura di una rete VPC hub con due reti VPC spoke.

La topologia è costituita da una rete VPC hub e due reti VPC spoke con peering con la rete VPC hub utilizzando il peering di rete VPC. La rete VPC hub ha due istanze di gateway NAT dietro un bilanciatore del carico di rete passthrough interno. Una route predefinita statica (0/0 NAT-GW-ILB) punta al bilanciatore del carico di rete passthrough interno come hop successivo. Questa route predefinita statica viene esportata tramite il peering di rete VPC utilizzando route personalizzate.

Obiettivi

  • Crea più reti VPC ed esegui il peering utilizzando un'architettura hub-and-spoke.
  • Crea e configura i gateway NAT nella rete VPC hub.
  • Configura il bilanciatore del carico di rete passthrough interno come hop successivo.
  • Verifica la connettività dalle reti VPC spoke a internet pubblico.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi Google Cloud utenti potrebbero avere diritto a una prova senza costi.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per saperne di più, consulta Esegui la pulizia.

Prima di iniziare

  1. Accedi al tuo Google Cloud account. Se non hai mai utilizzato Google Cloud, crea un account per valutare il rendimento dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei workload.

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Compute Engine API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the Compute Engine API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

    8.

  8. Nella Google Cloud console, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della Google Cloud console viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già incluso e installato e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

    9. In questo tutorial, esegui tutti i comandi da Cloud Shell.

Configurazione dell'ambiente

  1. In Cloud Shell, assicurati di lavorare nel Google Cloud progetto che hai creato o selezionato. Sostituisci project-id con il tuo Google Cloud progetto.

    gcloud config set project project-id

export PROJECT_ID=`gcloud config list --format="value(core.project)"`

  2. Imposta la regione e la zona di computing predefinite.

    gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-c
export REGION=us-central1
export ZONE=us-central1-c

    In questo tutorial, la regione è us-central1 e la zona è us-central1-c.

Creazione delle reti VPC e delle subnet

  1. In Cloud Shell, crea la rete VPC hub e la subnet:

    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. Crea le reti VPC spoke, denominate spoke1-vpc e spoke2-vpc, con una subnet ciascuna:

    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. Crea regole firewall nella rete VPC hub e nelle reti VPC spoke. Queste regole consentono il traffico interno (TCP/80 e 443, UDP/53 e ICMP) dagli intervalli RFC 1918 specificati:

    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. Crea regole firewall nella rete VPC hub e nelle reti VPC spoke VPC per consentire a IAP for SSH di accedere a tutte le tue macchine virtuali:

    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

    Questo tutorial utilizza Identity-Aware Proxy (IAP) per SSH. Per saperne di più, consulta Connessione a istanze che non hanno indirizzi IP esterni.

  5. Crea una regola firewall per consentire i controlli di integrità per i gruppi di istanze di ripristino automatico nella rete 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

Creazione delle istanze e delle route richieste

  1. In Cloud Shell, crea il modello di istanza per il gateway NAT con uno script di avvio che configura il gateway 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'

    Questo tutorial utilizza n1-standard-2 come tipo di istanza, ma puoi utilizzare qualsiasi altro numero o dimensione di gateway che preferisci. Assicurati di considerare fattori come la larghezza di banda in uscita massima per VM.

  2. Crea un controllo di integrità HTTP:

    gcloud compute health-checks create http nat-gw-ilbnhop-health-check \
    --region us-central1 \
    --port 80

  3. Crea un gruppo di istanze regionale con due istanze distribuite su una singola regione:

    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

    In questo tutorial, il ritardo iniziale è impostato su 15 secondi. In un deployment di produzione, personalizza questa impostazione in base ai tuoi requisiti. Questo tutorial non utilizza policy di scalabilità automatica.

  4. Crea un servizio di backend e aggiungi il gruppo di istanze:

    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. Crea una regola di forwarding:

    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

    Anche se la regola di forwarding è definita solo con TCP, quando utilizzi il bilanciatore del carico di rete passthrough interno come hop successivo, la regola di forwarding inoltra tutto il traffico a tutte le porte delle VM di backend. Il bilanciatore del carico di rete passthrough interno è un bilanciatore del carico regionale.

  6. Crea una nuova route con la regola di forwarding come hop successivo:

    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

    Puoi specificare i tag di rete in modo che la route dell'hop successivo si applichi solo alle istanze client configurate con il tag, ma i tag non vengono esportati o importati tramite il peering di rete VPC.

  7. Elimina la route predefinita dal 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. Crea una nuova route con tag per consentire il traffico solo dai gateway 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. Elimina le route predefinite a internet dal VPC di ogni 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

    In caso di conflitto tra route locali e importate, quelle locali hanno sempre la precedenza. Per saperne di più, consulta Ordine di routing.

  10. Crea VM client:

    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'

Creazione delle connessioni di peering di rete VPC

Il peering di rete VPC è bidirezionale e pertanto deve essere definito su entrambe le estremità. Una rete VPC può eseguire il peering con più reti VPC, ma si applicano dei limiti. Per raggiungere la route predefinita tramite il peering di rete VPC, utilizza la funzionalità importazione ed esportazione di route personalizzate tramite il peering di rete VPC.

Per questo tutorial, crei tutte le reti VPC nello stesso Google Cloud progetto.

  1. In Cloud Shell, crea le connessioni VPC dalla rete VPC hub alle reti VPC spoke con il flag di esportazione delle route abilitato:

    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. Crea una connessione di peering di rete VPC dalla rete VPC spoke1 alla rete VPC hub con il flag di importazione delle route abilitato:

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

  3. Crea una connessione di peering di rete VPC dalla rete VPC spoke2 alla rete VPC hub con il flag di importazione delle route abilitato:

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

Verifica della propagazione delle route e della connettività

  1. In Cloud Shell, verifica che le route statiche siano state create correttamente come parte degli script di avvio.

    gcloud compute routes list --filter="network:hub-vpc"

    Assicurati che le route hub-default-tagged e hub-nat-gw-ilbanhop siano presenti nell'output:

    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. Verifica la tabella di routing spoke1-vpc per assicurarti che la route predefinita sia stata importata correttamente:

    gcloud compute routes list --filter="network:spoke1-vpc"

    Assicurati che nell'output sia presente una route che inizia con peering-route con 0.0.0.0/0 come valore DEST_RANGE:

    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. Connettiti a uno dei client utilizzando SSH tramite IAP:

    gcloud compute ssh spoke1-client --tunnel-through-iap

  4. Verifica la connettività testando il DNS pubblico di Google tramite il gateway NAT:

    sudo hping3 -S -p 80 -c 3 dns.google

    Poiché il bilanciatore del carico di rete passthrough interno supporta TCP e UDP, non puoi verificare la connettività internet utilizzando un ping basato su ICMP, quindi devi utilizzare uno strumento come hping3.

    L'output è simile al seguente:

    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. Verifica l'indirizzo IP pubblico che utilizzi per comunicare con internet:

    curl ifconfig.co

    L'output mostra un indirizzo IP pubblico di una delle istanze del gateway NAT. Se esegui di nuovo il comando, l'output potrebbe mostrare un indirizzo IP pubblico diverso perché le connessioni vengono distribuite utilizzando l'affinità sessione del bilanciamento del carico interno configurata affinità di sessione (per impostazione predefinita, IP client, protocollo e porta).

    Il peering di rete VPC non è transitivo, quindi non esiste connettività tra le reti VPC spoke tramite il peering di rete VPC.

Considerazioni per un ambiente di produzione

La configurazione che crei in questo tutorial fornisce due gateway NAT in una singola regione. Tuttavia, il bilanciamento del carico ECMP non è perfetto, e un singolo flusso non viene distribuito su link multipli, che è ciò che vuoi quando utilizzi dispositivi stateful come i firewall di nuova generazione.

Per eseguire il deployment di questa configurazione nell'ambiente di produzione, tieni presente i seguenti punti:

  • Questa configurazione è ideale per i link in uscita temporanei o non stateful. Se le dimensioni del pool di gateway NAT cambiano, le connessioni TCP potrebbero essere ribilanciate, il che potrebbe comportare la reimpostazione di una connessione stabilita.
  • I nodi non vengono aggiornati automaticamente, quindi se un'installazione Debian predefinita presenta una vulnerabilità di sicurezza, devi aggiornare l'immagine manualmente.
  • Se hai VM in più regioni, devi configurare i gateway NAT in ogni regione.
  • La larghezza di banda per gateway può variare in base al tipo di hardware. Assicurati di considerare fattori come la larghezza di banda in uscita massima per VM. Durante un errore del gateway, il traffico viene distribuito ai gateway rimanenti. Poiché i flussi in esecuzione non vengono riprogrammati, il traffico non si ristabilisce immediatamente quando il gateway torna online. Assicurati quindi di consentire un overhead sufficiente durante il dimensionamento.
  • Per ricevere una notifica di risultati imprevisti, utilizza Cloud Monitoring per monitorare i gruppi di istanze gestite e il traffico di rete.

Libera spazio

Il modo più semplice per eliminare la fatturazione è quello di eliminare il Google Cloud progetto che hai creato per il tutorial. In alternativa, puoi eliminare le singole risorse.

Elimina il progetto

  1. Nella Google Cloud console, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID progetto e fai clic su Chiudi per eliminare il progetto.

Elimina le singole risorse

Se vuoi conservare il Google Cloud progetto, puoi eliminare le risorse che hai creato per questo tutorial.

  1. Elimina le connessioni di peering di rete 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. Elimina le istanze, le risorse del bilanciatore del carico, i modelli e le route:

    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. Elimina le regole firewall, le subnet e le reti 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

Passaggi successivi