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 subnetwork sono sinonimi. Vengono utilizzati in modo intercambiabile nella console Google Cloud, nei comandi Google Cloud CLI e nella documentazione dell'API.

Reti e subnet

Per poter essere usata, una rete deve avere almeno una subnet. Le reti VPC in modalità automatica creano automaticamente delle subnet in ogni regione. Le reti VPC in modalità personalizzata vengono avviate senza subnet e offrono il controllo completo della procedura di creazione delle subnet. Puoi creare più subnet per regione. Per informazioni sulle differenze tra le reti VPC in modalità automatica e in modalità personalizzata, consulta la sezione Tipi di reti VPC.

Quando crei una risorsa in Google Cloud, scegli una rete e una subnet. Per le risorse diverse dai modelli di istanze, seleziona anche una zona o una regione. La selezione di una zona comporta implicitamente la selezione della regione principale. 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, devi selezionare 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 selezionare una rete che contenga una subnet nella regione principale della zona selezionata.

• Quando crei un gruppo di istanze gestite, seleziona una zona o una regione, a seconda del tipo di gruppo, e un modello di istanza. Il modello di istanza definisce la rete VPC da utilizzare. Pertanto, 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 sottoreti nella zona o nella regione selezionata. Le reti VPC in modalità automatica hanno sempre una subnet in ogni regione.

• La procedura di creazione di un cluster di contenitori Kubernetes richiede la selezione di una zona o una regione (a seconda del tipo di cluster), di una rete e di una subnet. Devi selezionare una subnet disponibile nella zona o nella regione selezionata.

Tipi di subnet

Le reti VPC supportano i seguenti tipi di subnet:

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

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

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

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

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

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

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

Scopi delle subnet

Le sottoreti possono essere utilizzate per diversi scopi:

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

Nella maggior parte dei casi, non puoi modificare lo scopo di una subnet dopo che è stata creata. Per ulteriori informazioni, consulta la documentazione di riferimento del comando gcloud compute networks subnets update.

Limitazioni per la denominazione delle subnet

I nomi delle subnet presentano le seguenti limitazioni:

• All'interno di un progetto Google Cloud, una subnet non può avere lo stesso nome di una rete VPC, a meno che non sia un membro di quella rete. All'interno di un progetto, le subnet nella stessa regione devono avere nomi univoci. Ad esempio, una rete denominata production può avere più subnet denominate anche production, a condizione che ognuna di queste subnet si trovi in una regione univoca.

• Non puoi modificare il nome o la regione di una sottorete dopo averla creata. Tuttavia, puoi eliminare una sottorete e sostituirla a condizione che non sia in uso da alcuna risorsa.

Intervalli di subnet IPv4

Le subnet devono avere un intervallo di indirizzi IPv4 principale. Quando il scopo di una subnet è PRIVATE o NONE, l'intervallo IPv4 principale può essere utilizzato da quanto segue:

• Indirizzi IPv4 interni principali delle interfacce di rete delle VM Compute Engine, inclusi i nodi GKE.
• Intervalli IP alias delle interfacce di rete delle VM.
• Regole di inoltro utilizzate dal forwarding del protocollo interno.
• Regole di inoltro utilizzate dai bilanciatori del carico delle applicazioni interni, dai bilanciatori del carico di rete proxy interni e dai bilanciatori del carico di rete passthrough interni.
• Punti di contatto dei criteri del server in entrata di Cloud DNS.
• Endpoint Private Service Connect per i servizi pubblicati.

Facoltativamente, le subnet possono avere uno o più intervalli di indirizzi IPv4 secondari, che possono essere utilizzati solo dagli intervalli IP alias. Un intervallo IP alias può provenire dall'intervallo IPv4 principale o da un intervallo IPv4 secondario di una subnet.

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 in modalità automatica predefinito. Tuttavia, l'intervallo principale di una subnet può essere 10.0.0.0/24, mentre l'intervallo principale di un'altra subnet nella stessa rete può essere 192.168.0.0/16.

Limitazioni per gli intervalli di subnet IPv4

Gli intervalli di subnet IPv4 presentano le seguenti limitazioni:

• Ogni intervallo IPv4 principale o secondario per tutte le subnet in una rete VPC deve essere un blocco CIDR valido univoco.

• Il numero di intervalli di indirizzi IP secondari che puoi definire è descritto in Limiti per rete.

• Dopo aver creato una subnet, l'intervallo IPv4 principale della subnet può essere ampliato, ma non può essere sostituito o ridotto.

• Puoi rimuovere e sostituire l'intervallo di indirizzi IPv4 secondario di una subnet solo se non è utilizzato da nessuna istanza.

• La dimensione minima dell'intervallo principale o secondario è di otto indirizzi IPv4. In altre parole, la subnet mask più lunga che puoi utilizzare è /29.

• La subnet mask più breve che puoi utilizzare è /4. Tuttavia, per la maggior parte degli intervalli di indirizzi IP/4, le verifiche aggiuntive ti impediscono di creare una subnet di queste dimensioni. Ad esempio, un intervallo di subnet non può sovrapporsi a un intervallo IPv4 privato o a un altro intervallo riservato. Per ridurre al minimo la probabilità di scegliere un intervallo di subnet non valido, ti consigliamo di limitare la dimensione massima della subnet a /8.

• Non puoi creare intervalli principali e secondari per le subnet che si sovrappongono a qualsiasi intervallo allocato, a qualsiasi intervallo primario o secondario di un'altra subnet nella stessa rete o a qualsiasi intervallo IPv4 delle subnet nelle reti con peering. Google Cloud impedisce la creazione di intervalli di subnet sovrapposti in questi scenari.

• Google Cloud crea route di subnet corrispondenti sia per gli intervalli IP principali che per quelli secondari. Le route delle subnet e, di conseguenza, gli intervalli IP delle subnet devono avere per definizione gli intervalli IP più specifici.

  • Assicurati che gli intervalli principali e secondari non siano in conflitto con gli intervalli IP on-premise se hai collegato la tua rete VPC a un'altra rete con Cloud VPN, Dedicated Interconnect o Partner Interconnect. Per ulteriori informazioni, consulta la sezione Verificare gli intervalli di sottorete in sovrapposizione.

  • Gli intervalli IPv4 della subnet non possono essere in conflitto con le destinazioni per le route statiche.

  • Evita di utilizzare indirizzi IPv4 del blocco 10.128.0.0/9 per gli intervalli IPv4 principali o secondari di una subnet. Le subnet create automaticamente nelle reti VPC in modalità automatica utilizzano gli indirizzi IPv4 di questo blocco. Se utilizzi indirizzi IP nel blocco 10.128.0.0/9, non puoi connettere la tua rete a una rete VPC in modalità automatica utilizzando il peering di rete VPC o i tunnel Cloud VPN.

• Gli intervalli di subnet non possono essere corrispondenti, più ristretti o più ampi rispetto a un intervallo limitato. Ad esempio, 169.0.0.0/8 non è un intervallo di subnet valido perché si sovrappone all'intervallo link-local 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 pubblico utilizzato privatamente. Ad esempio, 172.0.0.0/10 non è un intervallo di subnet valido perché include sia l'intervallo di indirizzi IP privato 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, una con 192.168.0.0/16 e una con 192.0.0.0/24. In alternativa, puoi utilizzare entrambi questi intervalli nella stessa subnet se ne imposti uno come intervallo secondario.

Intervalli IPv4 validi

Gli intervalli di indirizzi IPv4 principali e secondari di una subnet sono indirizzi IPv4 interni regionali. La tabella seguente descrive gli intervalli validi.

Intervalli di subnet IPv4 vietati

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

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 principale della subnet per ospitarla. Google Cloud ti consente di utilizzare tutti gli indirizzi negli intervalli IPv4 secondari.

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 di queste subnet rientrano nel blocco CIDR 10.128.0.0/9. Le reti VPC in modalità automatica vengono create con una subnet per regione al momento della creazione e ricevono automaticamente nuove subnet nelle nuove regioni. Le parti inutilizzate di 10.128.0.0/9 sono riservate per un futuro utilizzo di Google Cloud.

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 VM deve utilizzare. Alcuni prodotti Google e di terze parti utilizzano 172.17.0.0/16 per il routing all'interno del sistema operativo guest. Ad esempio, la rete bridge Docker predefinita utilizza questo intervallo. Se utilizzi un prodotto che impiega 172.17.0.0/16, non utilizzarlo come intervallo di indirizzi IPv4 primario e secondario della subnet.

Intervalli di subnet IPv6

Quando abiliti IPv6 in 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. La subnet diventa una subnet a doppio stack.

• Gli indirizzi IPv6 interni vengono utilizzati per la comunicazione tra VM all'interno delle reti VPC. Possono essere instradati solo nell'ambito delle reti VPC e non possono essere instradati su internet.

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

Se un'interfaccia 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 viene assegnato un indirizzo IPv6 interno o un indirizzo IPv6 esterno.

Specifiche IPv6

Le subnet a doppio stack sono disponibili in tutte le regioni e supportano gli intervalli di subnet IPv6 sia interni che esterni:

• Gli intervalli di subnet IPv6 vengono sempre assegnati automaticamente da Google Cloud.
• Gli intervalli di subnet IPv6 sono sempre intervalli /64.

Le sottoreti dual-stack presentano le seguenti limitazioni:

• Non puoi modificare il tipo di accesso IPv6 (interno o esterno) di una subnet.
• Non puoi modificare una subnet a doppio stack in una subnet a stack singolo se il tipo di accesso IPv6 è interno.

Specifiche IPv6 interne

Gli intervalli IPv6 interni sono indirizzi locali univoci (ULA). Gli ULA per IPv6 sono analoghi agli indirizzi RFC 1918 per IPv4. Gli ULA non sono raggiungibili da internet e non sono indirizzabili pubblicamente.

Prima di poter creare subnet con intervalli IPv6 interni, devi prima assegnare un /48 intervallo IPv6 ULA alla rete VPC. Tieni presente quanto segue quando assegni un intervallo IPv6 ULA /48 a una rete VPC:

• L'intervallo IPv6 ULA /48 per ogni rete VPC deve essere univoco con Google Cloud. In questo modo, viene eliminata la possibilità di sovrapposizione degli intervalli di subnet IPv6 quando utilizzi il peering di rete VPC.

• Puoi consentire a Google Cloud di assegnare automaticamente l'intervallo IPv6 ULA /48 della rete VPC oppure puoi fornire un intervallo IPv6 ULA /48 da utilizzare. Se l'intervallo IPv6 ULA /48 che fornisci è già utilizzato da un'altra rete VPC di Google Cloud, viene visualizzato un messaggio di errore.

• L'opzione per fornire un intervallo IPv6 ULA /48 è utile per evitare conflitti tra la rete VPC e le reti on-premise o le reti di altri provider cloud collegate.

• Dopo aver assegnato a una rete VPC un intervallo IPv6 ULA /48, non puoi rimuovere o modificare l'intervallo IPv6 ULA /48.

Quando crei una subnet con un intervallo IPv6 interno, Google Cloud selezionerà automaticamente un intervallo IPv6 /64 non utilizzato dall'intervallo IPv6 ULA /48 della rete VPC. Gli intervalli IPv6 /64 interni della subnet possono essere utilizzati da:

• Intervalli di indirizzi IPv6 /96 interni delle interfacce di rete delle VM

• Intervalli di indirizzi IPv6 /96 interni delle regole di inoltro per il forwarding del protocollo interno o per i bilanciatori del carico di rete passthrough interni

Puoi anche prenotare intervalli di indirizzi IPv6 interni regionali /96 statici.

Specifiche IPv6 esterne

Gli intervalli di indirizzi IPv6 esterni sono indirizzi unicast globali (GUA). Gli indirizzi IPv6 esterni sono disponibili solo nel livello Premium.

Quando crei una subnet con un intervallo di indirizzi IPv6 esterno, Google Cloud selezione automaticamente un intervallo IPv6 /64 non utilizzato. Gli intervalli di indirizzi IPv6 /64 external della subnet possono essere utilizzati da:

• Intervalli di indirizzi IPv6 /96 esterni delle interfacce di rete della VM

• Intervalli di indirizzi IPv6 /96 esterni delle regole di inoltro per il forwarding del protocollo esterno o per i bilanciatori del carico di rete passthrough esterni basati su servizi di backend

Puoi anche prenotare intervalli di indirizzi IPv6 /96 esterni regionali statici.

Assegnazione di intervalli IPv6

Gli intervalli di indirizzi IPv6 vengono assegnati a reti, subnet, istanze di macchine virtuali (VM) e regole di inoltro.

Passaggi successivi

• Scopri di più su Geografia e regioni

• Creare reti VPC

• Creare una subnet solo IPv4

• Assegnare un intervallo IPv6 interno per una rete VPC

• Creare una subnet dual-stack