Subnet

Le reti Virtual Private Cloud (VPC) sono risorse globali. Ogni rete VPC è composta da uno o più intervalli di indirizzi IP chiamati subnet. Le subnet sono risorse regionali a cui sono associati intervalli di indirizzi IP.

In Google Cloud, i termini subnet e subnet sono sinonimi. Vengono utilizzati in modo intercambiabile nella console Google Cloud, nei comandi di Google Cloud CLI e nella documentazione delle API.

Reti e subnet

Una rete deve avere almeno una subnet per poter essere utilizzata. Le reti VPC in modalità automatica creano automaticamente delle subnet in ogni regione. Le reti VPC in modalità personalizzata iniziano senza subnet e offrono il controllo completo sulla creazione delle subnet. Puoi creare più di una subnet per regione. Per informazioni sulle differenze tra le reti VPC in modalità automatica e personalizzata, consulta i tipi di reti VPC.

Quando crei una risorsa in Google Cloud, scegli una rete e una subnet. Per risorse diverse dai modelli di istanza, seleziona anche una zona o una regione. La selezione di una zona seleziona in modo implicito la relativa regione padre. Poiché le subnet sono oggetti a livello di regione, la regione selezionata per una risorsa determina le subnet che può utilizzare:

• Quando crei un'istanza, selezioni una zona per l'istanza. Se non selezioni una rete per la VM, viene utilizzata la rete VPC predefinita, che ha una subnet in ogni regione. Se selezioni una rete per la VM, devi selezionarne una che contiene una subnet nella regione padre della zona selezionata.

• Quando crei un gruppo di istanze gestite, selezioni una zona o una regione, a seconda del tipo di gruppo e di un modello di istanza. Il modello di istanza definisce la rete VPC da utilizzare. Di conseguenza, quando crei un gruppo di istanze gestite, devi selezionare un modello di istanza con una configurazione appropriata. Il modello deve specificare una rete VPC con subnet nella zona o regione selezionata. Le reti VPC in modalità automatica hanno sempre una subnet in ogni regione.

• Il processo di creazione di un cluster di container Kubernetes prevede la selezione di una zona o di una regione (a seconda del tipo di cluster), una rete e una subnet. Devi selezionare una subnet disponibile nella zona o regione selezionata.

Tipi di subnet

Le reti VPC supportano i seguenti tipi di subnet:

• Subnet solo IPv4 (stack singolo), con intervalli di subnet solo IPv4

• Subnet IPv4 e IPv6 (stack doppio), con intervalli di subnet IPv4 e IPv6

Una singola rete VPC può contenere qualsiasi combinazione di questi tipi di subnet.

Quando crei una subnet, specifichi il tipo di stack da utilizzare. Puoi anche aggiornare una subnet solo IPv4 esistente per configurarla come subnet a doppio stack.

Le subnet a doppio stack sono supportate solo sulle reti VPC in modalità personalizzata. Le subnet a doppio stack non sono supportate sulle reti VPC in modalità automatica o sulle reti legacy.

Nota: se vuoi creare reti dual stack in una rete VPC in modalità automatica, devi prima convertire la rete in modalità automatica in modalità personalizzata.

Quando crei un intervallo di subnet IPv4, fornisci le seguenti informazioni:

Impostazione subnet	Valori validi	Dettagli
Intervallo IPv4	Un intervallo valido scelto da te	Obbligatorio
Intervallo IPv4 secondario	Un intervallo valido scelto da te	Facoltativo

Quando crei un intervallo di subnet IPv6, fornisci le seguenti informazioni:

Impostazione subnet	Valori validi	Dettagli
Tipo di accesso IPv6	Interno Esterno	Un intervallo di indirizzi IPv6 /64 viene assegnato automaticamente alla subnet. Gli intervalli IPv6 interni vengono assegnati dall'intervallo interno della rete VPC, che utilizza indirizzi locali univoci (ULA) Gli intervalli IPv6 esterni utilizzano indirizzi unicast globali (GUA)

Scopi delle subnet

Le subnet possono essere utilizzate per diversi scopi:

• Subnet regolari: è il tipo di subnet predefinito. Le subnet regolari vengono create dagli utenti o create automaticamente in reti in modalità automatica per essere utilizzate con le istanze VM. Le subnet regolari hanno lo scopo PRIVATE nell'interfaccia a riga di comando o nell'API gcloud. Lo scopo è Nessuno nella console Google Cloud.
• Subnet Private Service Connect: una subnet da utilizzare per pubblicare un servizio gestito mediante Private Service Connect.
• Subnet solo proxy: una subnet solo proxy da utilizzare con bilanciatori del carico basati su Envoy a livello di regione.
• Subnet Private NAT: una subnet riservata all'utilizzo come intervallo di origine per Private NAT. Questa subnet è impostata su --purpose=PRIVATE_NAT.

Nella maggior parte dei casi, non è possibile modificare lo scopo di una subnet dopo averla creata. Per saperne di più, consulta il riferimento ai comandi gcloud compute networks subnets update.

Intervalli di subnet IPv4

Ogni subnet ha un intervallo di indirizzi IPv4 principali. Gli indirizzi interni principali per le seguenti risorse provengono dall'intervallo principale della subnet: istanze VM, bilanciatori del carico interni e forwarding del protocollo interno. Facoltativamente, puoi aggiungere intervalli di indirizzi IP secondari a una subnet, utilizzati solo dagli intervalli IP alias. Tuttavia, puoi configurare intervalli IP alias per le istanze dall'intervallo principale o secondario di una subnet.

Ogni intervallo IPv4 principale o secondario per tutte le subnet in una rete VPC deve essere un blocco CIDR valido univoco. Consulta i limiti per rete per il numero di intervalli di indirizzi IP secondari che puoi definire.

Le subnet IPv4 non devono necessariamente formare un blocco CIDR contiguo predefinito, ma puoi farlo se vuoi. Ad esempio, le reti VPC in modalità automatica creano subnet che rientrano in un intervallo IP predefinito.

Per ulteriori informazioni, vedi Utilizzare le subnet.

Intervalli IPv4 validi

Gli intervalli di indirizzi IPv4 primari e secondari di una subnet sono indirizzi IPv4 interni a livello di regione. La tabella seguente descrive intervalli validi.

Intervallo	Descrizione
Intervalli di indirizzi IPv4 privati
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16	Indirizzi IP privati RFC 1918 Per informazioni sull'utilizzo di 172.17.0.0/16, consulta Considerazioni aggiuntive.
100.64.0.0/10	Spazio di indirizzi condiviso RFC 6598
192.0.0.0/24	Assegnazioni del protocollo IETF RFC 6890
192.0.2.0/24 (TEST-NET-1) 198.51.100.0/24 (TEST-NET-2) 203.0.113.0/24 (TEST-NET-3)	Documentazione RFC 5737
192.88.99.0/24	Inoltro da IPv6 a IPv4 (deprecato) RFC 7526
198.18.0.0/15	Test dei benchmark RFC 2544
240.0.0.0/4	Riservato per un uso futuro (Classe E) come indicato in RFC 5735 e RFC 1112. Alcuni sistemi operativi non supportano l'utilizzo di questo intervallo, perciò verifica che il sistema operativo lo supporti prima di creare subnet che utilizzano questo intervallo.
Intervalli di indirizzi IP pubblici utilizzati privatamente
Indirizzi IPv4 pubblici utilizzati privatamente	Indirizzi IPv4 pubblici utilizzati privatamente: Sono indirizzi IPv4 che normalmente sono instradabili su internet, ma che vengono utilizzati privatamente in una rete VPC Non può appartenere a un intervallo di subnet vietato Quando utilizzi questi indirizzi come intervalli di subnet, Google Cloud non annuncia queste route a internet e non instrada il traffico da internet verso loro. Se hai importato indirizzi IP pubblici in Google utilizzando la funzionalità Bring your own IP (BYOIP), gli intervalli BYOIP e gli intervalli di indirizzi IP pubblici utilizzati privatamente nella stessa rete VPC non devono sovrapporsi. Per il peering di rete VPC, le route di subnet per gli indirizzi IP pubblici non vengono scambiate automaticamente. Le route di subnet vengono esportate automaticamente per impostazione predefinita, ma le reti peer devono essere configurate esplicitamente in modo da importarle per poterle utilizzare.

Gli intervalli di subnet IPv4 hanno i seguenti vincoli:

• Gli intervalli di subnet non possono corrispondere, essere più ristretti o più ampi di un intervallo limitato. Ad esempio, 169.0.0.0/8 non è un intervallo di subnet valido perché si sovrappone all'intervallo locale rispetto al collegamento 169.254.0.0/16 (RFC 3927), che è un intervallo limitato.

• Gli intervalli di subnet non possono coprire un intervallo RFC (descritto nella tabella precedente) e un intervallo di indirizzi IP pubblici utilizzati privatamente. Ad esempio, 172.0.0.0/10 non è un intervallo di subnet valido perché include sia l'intervallo di indirizzi IP privati 172.16.0.0/12 sia gli indirizzi IP pubblici.

• Un intervallo di subnet non può coprire più intervalli RFC. Ad esempio, 192.0.0.0/8 non è un intervallo di subnet valido perché include sia 192.168.0.0/16 (da RFC 1918) sia 192.0.0.0/24 (da RFC 6890). Tuttavia, puoi creare due subnet con intervalli principali diversi, uno con 192.168.0.0/16 e l'altro con 192.0.0.0/24. In alternativa, puoi utilizzare entrambi questi intervalli sulla stessa subnet se ne imposti uno secondario.

Intervalli di subnet IPv4 vietati

Gli intervalli di subnet vietati includono gli indirizzi IP pubblici di Google e gli intervalli RFC prenotati comunemente, come descritto nella seguente tabella. Questi intervalli non possono essere utilizzati per gli intervalli di subnet.

Intervallo	Descrizione
Indirizzi IP pubblici per le API e i servizi Google, inclusi i netblock Google Cloud.	Puoi trovare questi indirizzi IP all'indirizzo https://gstatic.com/ipranges/goog.txt.
199.36.153.4/30 e 199.36.153.8/30	Indirizzi IP virtuali privati specifici dell'accesso Google
0.0.0.0/8	Rete (locale) attuale RFC 1122
127.0.0.0/8	Host locale RFC 1122
169.254.0.0/16	RFC 3927 locale rispetto al collegamento
224.0.0.0/4	Multicast (Classe D) RFC 5771
255.255.255.255/32	Indirizzo di destinazione di trasmissione limitato RFC 8190 e RFC 919

Indirizzi inutilizzabili negli intervalli di subnet IPv4

Google Cloud utilizza i primi due e gli ultimi due indirizzi IPv4 in ogni intervallo di indirizzi IPv4 principali della subnet per ospitare la subnet. Google Cloud consente di utilizzare tutti gli indirizzi negli intervalli IPv4 secondari.

Indirizzo IPv4 inutilizzabile	Descrizione	Esempio
Indirizzo di rete	Primo indirizzo nell'intervallo IPv4 principale	10.1.2.0 nell'intervallo 10.1.2.0/24
Indirizzo gateway predefinito	Secondo indirizzo nell'intervallo IPv4 principale	10.1.2.1 nell'intervallo 10.1.2.0/24
Penultimo indirizzo	Secondo e ultimo indirizzo nell'intervallo IPv4 principale Questo intervallo è riservato da Google Cloud per un potenziale uso futuro.	10.1.2.254 nell'intervallo 10.1.2.0/24
Indirizzo di trasmissione	Ultimo indirizzo nell'intervallo IPv4 principale	10.1.2.255 nell'intervallo 10.1.2.0/24

Nota: la rete di networking software-defined di Google Cloud prenota un indirizzo IP del gateway virtuale per gli intervalli IP principali di ogni subnet in una rete VPC. Tuttavia, i gateway virtuali non rispondono al traffico ICMP o diminuiscono le intestazioni TTL degli IP.

Gli intervalli IP secondari delle subnet non hanno un indirizzo IP del gateway virtuale riservato. Di conseguenza, un gateway predefinito non risponde a ping e non viene visualizzato quando esegui traceroute da un'istanza VM.

Gli strumenti che inviano un ping all'indirizzo IP del gateway come test di connettività devono essere configurati in modo da non considerare l'impossibilità di inviare un ping a un gateway virtuale come una condizione di errore.

Intervalli IPv4 in modalità automatica

Questa tabella elenca gli intervalli IPv4 per le subnet create automaticamente in una rete VPC in modalità automatica. Gli intervalli IP per queste subnet rientrano nel blocco CIDR 10.128.0.0/9. Le reti VPC in modalità automatica sono create con una subnet per regione al momento della creazione e ricevono automaticamente nuove subnet in nuove regioni. Le parti inutilizzate di 10.128.0.0/9 vengono riservate per un uso futuro di Google Cloud.

Regione	Intervallo IP (CIDR)	Gateway predefinito	Indirizzi utilizzabili (inclusi)
africa-sud1	10.218.0.0/20	10.218.0.1	Da 10.218.0.2 a 10.218.15.253
asia-east1	10.140.0.0/20	10.140.0.1	Da 10.140.0.2 a 10.140.15.253
asia-east2	10.170.0.0/20	10.170.0.1	Da 10.170.0.2 a 10.170.15.253
asia-northeast1	10.146.0.0/20	10.146.0.1	Da 10.146.0.2 a 10.146.15.253
asia-northeast2	10.174.0.0/20	10.174.0.1	Da 10.174.0.2 a 10.174.15.253
asia-northeast3	10.178.0.0/20	10.178.0.1	Da 10.178.0.2 a 10.178.15.253
asia-south1	10.160.0.0/20	10.160.0.1	Da 10.160.0.2 a 10.160.15.253
asia-south2	10.190.0.0/20	10.190.0.1	Da 10.190.0.2 a 10.190.15.253
asia-southeast1	10.148.0.0/20	10.148.0.1	Da 10.148.0.2 a 10.148.15.253
asia-southeast2	10.184.0.0/20	10.184.0.1	Da 10.184.0.2 a 10.184.15.253
australia-southeast1	10.152.0.0/20	10.152.0.1	Da 10.152.0.2 a 10.152.15.253
australia-southeast2	10.192.0.0/20	10.192.0.1	Da 10.192.0.2 a 10.192.15.253
europe-central2	10.186.0.0/20	10.186.0.1	Da 10.186.0.2 a 10.186.15.253
europe-north1	10.166.0.0/20	10.166.0.1	Da 10.166.0.2 a 10.166.15.253
europe-west1	10.132.0.0/20	10.132.0.1	Da 10.132.0.2 a 10.132.15.253
europe-west2	10.154.0.0/20	10.154.0.1	Da 10.154.0.2 a 10.154.15.253
europe-west3	10.156.0.0/20	10.156.0.1	Da 10.156.0.2 a 10.156.15.253
europe-west4	10.164.0.0/20	10.164.0.1	Da 10.164.0.2 a 10.164.15.253
europe-west6	10.172.0.0/20	10.172.0.1	Da 10.172.0.2 a 10.172.15.253
Europa-west8	10.198.0.0/20	10.198.0.1	Da 10.198.0.2 a 10.198.15.253
Europa-west9	10.200.0.0/20	10.200.0.1	Da 10.200.0.2 a 10.200.15.253
Europa-west10	10.214.0.0/20	10.214.0.1	Da 10.214.0.2 a 10.214.15.253
Europa-west12	10.210.0.0/20	10.210.0.1	Da 10.210.0.2 a 10.210.15.253
europe-southwest1	10.204.0.0/20	10.204.0.1	Da 10.204.0.2 a 10.204.15.253
me-central1	10.212.0.0/20	10.212.0.1	Da 10.212.0.2 a 10.212.15.253
me-central2	10.216.0.0/20	10.216.0.1	Da 10.216.0.2 a 10.216.15.253
me-ovest1	10.208.0.0/20	10.208.0.1	Da 10.208.0.2 a 10.208.15.253
northamerica-northeast1	10.162.0.0/20	10.162.0.1	Da 10.162.0.2 a 10.162.15.253
northamerica-northeast2	10.188.0.0/20	10.188.0.1	Da 10.188.0.2 a 10.188.15.253
southamerica-east1	10.158.0.0/20	10.158.0.1	Da 10.158.0.2 a 10.158.15.253
southamerica-west1	10.194.0.0/20	10.194.0.1	Da 10.194.0.2 a 10.194.15.253
us-central1	10.128.0.0/20	10.128.0.1	Da 10.128.0.2 a 10.128.15.253
us-east1	10.142.0.0/20	10.142.0.1	Da 10.142.0.2 a 10.142.15.253
us-east4	10.150.0.0/20	10.150.0.1	Da 10.150.0.2 a 10.150.15.253
us-east5	10.202.0.0/20	10.202.0.1	Da 10.202.0.2 a 10.202.15.253
us-sud1	10.206.0.0/20	10.206.0.1	Da 10.206.0.2 a 10.206.15.253
us-west1	10.138.0.0/20	10.138.0.1	Da 10.138.0.2 a 10.138.15.253
us-west2	10.168.0.0/20	10.168.0.1	Da 10.168.0.2 a 10.168.15.253
us-west3	10.180.0.0/20	10.180.0.1	Da 10.180.0.2 a 10.180.15.253
us-west4	10.182.0.0/20	10.182.0.1	Da 10.182.0.2 a 10.182.15.253

Ulteriori considerazioni

Assicurati che tutti gli intervalli di indirizzi IPv4 principali e secondari della subnet non siano in conflitto con gli intervalli di indirizzi IPv4 che il software in esecuzione all'interno delle tue VM deve utilizzare. Alcuni prodotti Google e di terze parti utilizzano 172.17.0.0/16 per il routing all'interno del sistema operativo ospite. Ad esempio, la rete di bridge Docker predefinita utilizza questo intervallo. Se dipendi da un prodotto che utilizza 172.17.0.0/16, non utilizzarlo come intervallo di indirizzi IPv4 principali e secondari della subnet.

Intervalli di subnet IPv6

Quando abiliti IPv6 su una subnet in una rete VPC, scegli un tipo di accesso IPv6 per la subnet. Il tipo di accesso IPv6 determina se la subnet è configurata con indirizzi IPv6 interni o indirizzi IPv6 esterni.

• Gli indirizzi IPv6 interni vengono utilizzati per la comunicazione da VM a VM all'interno di reti VPC. Possono essere instradate solo nell'ambito delle reti VPC e non su internet.

• Gli indirizzi IPv6 esterni possono essere utilizzati per la comunicazione da VM a VM all'interno di reti VPC e sono instradabili anche su internet.

Se l'interfaccia di una VM è connessa a una subnet con un intervallo di subnet IPv6, puoi configurare gli indirizzi IPv6 sulla VM. Il tipo di accesso IPv6 della subnet determina se alla VM è assegnato un indirizzo IPv6 interno o un indirizzo IPv6 esterno.

Specifiche IPv6

• Gli intervalli di subnet IPv6 sono risorse di regione.

• Gli intervalli di subnet IPv6 interni ed esterni sono disponibili in tutte le regioni.

• Agli intervalli di subnet IPv6 vengono assegnati automaticamente intervalli /64.

• Non puoi modificare il tipo di accesso IPv6 (interno o esterno) di una subnet.

• Non puoi modificare una subnet a doppio stack in singola stack, se il tipo di accesso IPv6 è interno.

Specifiche IPv6 interne

• Gli intervalli IPv6 interni utilizzano indirizzi locali univoci (ULA).

• Gli UDA per IPv6 sono analoghi agli indirizzi RFC 1918 per IPv4. Gli UDA non sono raggiungibili da internet e non sono instradabili pubblicamente.

• Per creare subnet con intervalli IPv6 interni, devi prima assegnare un intervallo IPv6 interno alla rete VPC. È stato assegnato un intervallo IPv6 /48. Quando crei una subnet con un intervallo IPv6 interno, l'intervallo /64 della subnet viene assegnato dall'intervallo della rete VPC.

  • L'intervallo IPv6 interno di una rete VPC è univoco all'interno di Google Cloud.

  • Puoi consentire a Google di assegnare l'intervallo IPv6 interno della rete VPC oppure puoi selezionare un intervallo specifico. Se la tua rete VPC si connette a reti esterne a Google Cloud, puoi scegliere un intervallo che non si sovrapponga a quelli utilizzati in quegli ambienti.

• L'assegnazione dell'intervallo IPv6 interno /48 di una rete VPC è definitiva. Non puoi disattivarla o modificarla in un secondo momento.

• Puoi prenotare indirizzi IPv6 interni statici a livello di regione.

Nessun'altra rete VPC può utilizzare lo stesso intervallo, il che elimina la possibilità di sovrapporre intervalli di subnet IPv6 quando si utilizza il peering di rete VPC.

Specifiche IPv6 esterne

• Gli intervalli di indirizzi IPv6 esterni utilizzano indirizzi unicast globali (GUA).

• Gli indirizzi IPv6 esterni possono essere utilizzati per la comunicazione da VM a VM all'interno di reti VPC e sono instradabili anche su internet. Per controllare il traffico in uscita e in entrata da internet, configura regole firewall o criteri firewall gerarchici. Per disabilitare completamente il routing IPv6 verso internet, elimina la route predefinita IPv6 nella rete VPC.

• Gli indirizzi IPv6 esterni sono disponibili solo nel livello Premium.

• Puoi prenotare indirizzi IPv6 statici esterni a livello regionale.

Assegnazione intervallo IPv6

Gli intervalli IPv6 possono essere assegnati a reti, subnet e istanze di macchine virtuali (VM).

Tipo di risorsa	Dimensione intervallo	Dettagli
Rete VPC	/48	Per abilitare il protocollo IPv6 interno su una subnet, devi prima assegnare un intervallo IPv6 interno sulla rete VPC. Alla rete è assegnato un intervallo ULA di /48 all'interno di fd20::/20. Tutti gli intervalli di subnet IPv6 interni nella rete sono assegnati da questo intervallo /48. L'intervallo /48 può essere assegnato automaticamente oppure puoi selezionare un intervallo specifico all'interno di fd20::/20.
Subnet	/64	L'impostazione del tipo di accesso IPv6 controlla se gli indirizzi IPv6 sono interni o esterni. Una subnet può avere indirizzi IPv6 interni o esterni, ma non entrambi. Quando attivi IPv6, si verifica quanto segue: Se abiliti il protocollo IPv6 interno su una subnet, viene assegnato un intervallo /64 di ULA interni dall'intervallo /48 della rete VPC. Se abiliti IPv6 esterno su una subnet, viene assegnato un intervallo /64 di GUA esterne.
Istanza di macchina virtuale (VM)	/96	Quando abiliti IPv6 su una VM, alla VM viene assegnato un intervallo /96 dalla subnet a cui è connessa. Il primo indirizzo IP in questo intervallo viene assegnato all'interfaccia principale mediante DHCPv6. Non devi configurare se una VM riceve indirizzi IPv6 interni o esterni. La VM eredita il tipo di accesso IPv6 dalla subnet a cui è connessa.

Passaggi successivi

• Crea reti VPC

• Crea una subnet solo IPv4

• Assegna un intervallo IPv6 interno per una rete VPC

• Crea una subnet a doppio stack.

Provalo

Se non hai mai utilizzato Google Cloud, crea un account per valutare le prestazioni di Cloud NAT in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Prova Cloud NAT gratuitamente