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, offrendoti il controllo completo della creazione delle subnet. Puoi creare più subnet per ogni regione. Per informazioni sulle differenze tra le reti VPC in modalità automatica e 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 istanza, seleziona anche una zona o una regione. La selezione di una zona comporta la selezione implicita della relativa regione principale. Poiché le subnet sono oggetti regionali, la regione selezionata per una risorsa determina le subnet che può utilizzare:

  • Quando crei un'istanza di macchina virtuale (VM), 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 contenga una subnet nella regione principale della zona selezionata.

  • Quando crei un gruppo di istanze gestite, selezioni 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 subnet 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 container Kubernetes prevede 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 le subnet con i seguenti tipi di stack. Una singola rete VPC può contenere qualsiasi combinazione di queste subnet.

Tipo di stack Intervalli di subnet Interfacce di rete VM compatibili
Solo IPv4 (stack singolo) Solo intervalli di subnet IPv4 Interfacce solo IPv4
IPv4 e IPv6 (stack doppio) Intervalli di subnet IPv4 e IPv6 Interfacce solo IPv4, a doppio stack e solo IPv6 (anteprima)
Solo IPv6 (stack singolo) (anteprima) Solo intervalli di subnet IPv6 Interfacce solo IPv6 (anteprima)

Quando crei una subnet, specifichi il tipo di stack da utilizzare. Puoi anche modificare il tipo di stack di una subnet nei seguenti scenari:

Le subnet con intervalli di indirizzi IPv6 sono supportate solo sulle reti VPC in modalità personalizzata. Le subnet con intervalli di indirizzi IPv6 non sono supportate nelle reti VPC in modalità automatica o nelle reti legacy.

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

Impostazione della subnet Valori validi Dettagli
Intervallo IPv4 Un intervallo valido a tua scelta Obbligatorio
Intervallo IPv4 secondario Un intervallo valido a tua scelta Facoltativo

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

Impostazione della subnet Valori validi Dettagli
Tipo di accesso IPv6
  • Interno
  • Esterno

Alla subnet viene assegnato un intervallo di indirizzi IPv6 /64.

Scopi delle subnet

Le subnet possono essere utilizzate per scopi diversi:

  • Subnet regolari: questo è il tipo di subnet predefinito. Le subnet regolari vengono create dagli utenti o automaticamente nelle reti VPC in modalità automatica per essere utilizzate con le istanze VM. Le subnet regolari hanno lo scopo di PRIVATE nell'interfaccia alla gcloud CLI o nell'API. Lo scopo è Nessuno 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 regionali.
  • Subnet NAT privata: una subnet riservata per l'utilizzo come intervallo di origine per NAT privato.
  • Subnet di migrazione del peering: una subnet da utilizzare per migrare un servizio VPC condiviso a Private Service Connect.

Nella maggior parte dei casi, non puoi modificare lo scopo di una subnet dopo la sua creazione. Per ulteriori informazioni, consulta il riferimento ai comandi gcloud compute networks subnets update.

Limitazioni per l'assegnazione dei nomi alle subnet

I nomi delle subnet presentano le seguenti limitazioni:

  • All'interno di un Google Cloud progetto, 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 anch'esse production, a condizione che ciascuna di queste subnet si trovi in una regione univoca.

  • Non puoi modificare il nome o la regione di una subnet dopo averla creata. Tuttavia, puoi eliminare una subnet e sostituirla a condizione che non venga utilizzata da risorse.

Intervalli di subnet IPv4

Ogni subnet solo IPv4 o a doppio stack deve avere un intervallo di indirizzi IPv4 primario. Quando lo scopo di una subnet è PRIVATE o NONE, l'intervallo IPv4 primario può essere utilizzato da quanto segue:

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

Non è necessario che le subnet IPv4 formino un blocco CIDR contiguo predefinito, ma puoi farlo se preferisci. 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 primario 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 nei limiti per rete.

  • Dopo aver creato una subnet, l'intervallo IPv4 primario per la subnet può essere espanso, ma non sostituito o ridotto.

  • Puoi rimuovere e sostituire l'intervallo di indirizzi IPv4 secondari di una subnet solo se nessuna istanza utilizza questo intervallo.

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

  • La maschera di rete più breve che puoi utilizzare è /4. Tuttavia, per la maggior parte degli intervalli di indirizzi IP /4, ulteriori convalide impediscono di creare una subnet così grande. 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 possibilità di scegliere un intervallo di subnet non valido, ti consigliamo di limitare la dimensione massima della subnet a /8.

  • Non puoi creare intervalli primari e secondari per 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 di subnet in reti in peering. Google Cloud impedisce la creazione di intervalli di subnet sovrapposti in questi scenari.

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

  • 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 con limitazioni.

  • 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 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 primari diversi, una con 192.168.0.0/16 e l'altra con 192.0.0.0/24. In alternativa, puoi utilizzare entrambi gli intervalli nella stessa subnet se uno dei due è un intervallo secondario.

Intervalli IPv4 validi

Gli intervalli di indirizzi IPv4 primari e secondari di una subnet sono indirizzi IPv4 interni regionali. La tabella seguente descrive gli 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, vedi Considerazioni aggiuntive.

100.64.0.0/10 Spazio di indirizzi condiviso RFC 6598
192.0.0.0/24 Assegnazioni di 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 Relay da IPv6 a IPv4 (ritirato) RFC 7526
198.18.0.0/15 Test di benchmark RFC 2544
240.0.0.0/4

Riservato per uso futuro (classe E) come indicato in RFC 5735 e RFC 1112.

Alcuni sistemi operativi non supportano l'utilizzo di questo intervallo, quindi verifica che il tuo sistema operativo lo supporti prima di creare subnet che lo utilizzano.
Intervalli di indirizzi IP pubblici utilizzati privatamente
Indirizzi IPv4 pubblici utilizzati privatamente Indirizzi IPv4 pubblici utilizzati privatamente:
  • Sono indirizzi IPv4 normalmente instradabili su internet, ma 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 di loro.

Se hai importato indirizzi IP pubblici in Google utilizzando Bring Your Own IP (BYOIP), i tuoi 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 per importarle per poterle utilizzare.

Intervalli di subnet IPv4 vietati

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

Intervallo Descrizione
Indirizzi IP pubblici per le API e i servizi Google, inclusi Google Cloud netblock. 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 specifici per l'accesso privato 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 Link-local RFC 3927
224.0.0.0/4 Multicast (classe D) RFC 5771
255.255.255.255/32 Indirizzo di destinazione di trasmissione limitata 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 primari della subnet per ospitare la subnet. Google Cloud ti 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 dall'intervallo 10.1.2.0/24
Indirizzo del gateway predefinito Secondo indirizzo nell'intervallo IPv4 principale 10.1.2.1 dall'intervallo 10.1.2.0/24
Penultimo indirizzo Penultimo indirizzo nell'intervallo IPv4 principale

Questo intervallo è riservato da Google Cloud per un potenziale utilizzo futuro.

 10.1.2.254 dall'intervallo 10.1.2.0/24
Indirizzo di broadcast Ultimo indirizzo nell'intervallo IPv4 principale 10.1.2.255 dall'intervallo 10.1.2.0/24

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 vengono create con una subnet per regione al momento della creazione e ricevono automaticamente nuove subnet nelle nuove regioni. Le parti non utilizzate di 10.128.0.0/9 sono riservate per un futuro Google Cloud utilizzo.

Regione Intervallo IP (CIDR) Gateway predefinito Indirizzi utilizzabili (inclusi)
africa-south1 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-north2 10.226.0.0/20 10.226.0.1 Da 10.226.0.2 a 10.226.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
europe-west8 10.198.0.0/20 10.198.0.1 Da 10.198.0.2 a 10.198.15.253
europe-west9 10.200.0.0/20 10.200.0.1 Da 10.200.0.2 a 10.200.15.253
europe-west10 10.214.0.0/20 10.214.0.1 Da 10.214.0.2 a 10.214.15.253
europe-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-west1 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
northamerica-south1 10.224.0.0/20 10.224.0.1 Da 10.224.0.2 a 10.224.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-south1 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 primari 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 guest. Ad esempio, la rete bridge Docker predefinita utilizza questo intervallo. Se utilizzi un prodotto che utilizza 172.17.0.0/16, non utilizzarlo come intervallo di indirizzi IPv4 primari e secondari di alcuna subnet.

Intervalli di subnet IPv6

Quando crei una subnet con un intervallo di indirizzi IPv6 o abiliti IPv6 in una subnet esistente 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 delle reti VPC. Possono essere instradati solo nell'ambito delle reti VPC e non possono essere instradati a internet.

  • Gli indirizzi IPv6 esterni possono essere utilizzati per la comunicazione da VM a VM all'interno delle reti VPC e sono anche instradabili 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 con intervalli di indirizzi IPv6 sono disponibili in tutte le regioni e supportano intervalli di subnet IPv6 sia interni che esterni:

  • Gli intervalli di subnet IPv6 interni vengono sempre assegnati automaticamente da Google Cloud.
  • Gli intervalli di subnet IPv6 esterni possono essere assegnati automaticamente daGoogle Cloudoppure puoi portare i tuoi indirizzi IP (BYOIP).
  • Gli intervalli di subnet IPv6 sono sempre intervalli /64.

Le subnet con intervalli di indirizzi IPv6 presentano le seguenti limitazioni:

  • Gli intervalli di subnet IPv6 esterni forniti da BYOIP supportano solo l'assegnazione di intervalli di indirizzi /96 alle interfacce di rete delle VM. Gli indirizzi IP dell'intervallo di indirizzi IPv6 esterni della subnet non possono essere assegnati ad altre risorseGoogle Cloud , ad esempio regole di forwarding.

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

  • Non puoi modificare una subnet dual-stack in solo IPv4 se il tipo di accesso IPv6 è interno.

  • Non puoi modificare una subnet a doppio stack o solo IPv4 in solo IPv6 (anteprima). Al contrario, non puoi modificare una subnet solo IPv6 in una subnet solo IPv4 o dual-stack.

Specifiche IPv6 interne

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

Prima di poter creare subnet con intervalli IPv6 interni, devi prima assegnare un intervallo IPv6 ULA /48 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 si elimina la possibilità di sovrapposizione degli intervalli di subnet IPv6 quando si utilizza 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 VPCGoogle Cloud , ricevi un errore.

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

  • Dopo che a una rete VPC è stato assegnato 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 seleziona automaticamente un intervallo IPv6 /64 non utilizzato dall'intervallo IPv6 ULA /48 della rete VPC. Gli intervalli IPv6 interni /64 della subnet possono essere utilizzati da:

Gli intervalli di indirizzi IPv6 interni /96 possono essere assegnati nei seguenti modi:

  • Se non specificato, Google Cloud assegna automaticamente un intervallo di indirizzi IPv6 interni temporanei /96.
  • Puoi specificare un intervallo di indirizzi IPv6 interni statici regionali prenotati./96
  • Per le istanze VM, puoi specificare un intervallo di indirizzi IPv6 interni temporanei personalizzato /96. Questo metodo non è supporta le regole di forwarding.

Specifiche IPv6 esterno

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

Esistono due opzioni per creare una subnet con un intervallo di indirizzi IPv6 esterno:

  • Puoi fare in modo che Google Cloud venga selezionato automaticamente un intervallo IPv6 /64 non utilizzato dagli indirizzi IPv6 esterni regionali di Google.

  • Puoi assegnare un intervallo IPv6 /64 all'interno di un prefisso secondario BYOIP, specificando un intervallo particolare o lasciando che Google Cloud selezioni un intervallo inutilizzato.

Le risorse che possono utilizzare l'intervallo di indirizzi IPv6 esterni di una subnet dipendono dall'origine dell'intervallo di indirizzi.

  • Gli intervalli di subnet IPv6 forniti da BYOIP possono essere utilizzati solo per gli intervalli di indirizzi IPv6 /96 esterni delle interfacce di rete VM. Puoi assegnare indirizzi BYOIP IPv6 alle regole di forwarding, ma questi indirizzi non fanno parte di una subnet.

  • Gli intervalli di subnet IPv6 esterni forniti da Google possono essere utilizzati nel seguente modo:

    Devi creare le risorse precedenti utilizzando indirizzi IP dell'intervallo /65 corrispondente allocato per la risorsa; in caso contrario, Google Cloudrestituisce un errore.

    Considera un esempio in cui l'intervallo di indirizzi IPv6 esterni di una subnet è 2001:db8:981:4:0:0:0:0/64:

    • L'intervallo /65 allocato per l'utilizzo da parte delle istanze VM è 2001:db8:981:4:0:0:0:0/65.
    • L'intervallo /65 allocato per l'utilizzo da parte di Cloud Load Balancing è 2001:db8:981:4:8000:0.

Per controllare l'origine dell'intervallo di indirizzi IPv6 esterni di una subnet, puoi descrivere la subnet. Se la proprietà ipv6AccessType è EXTERNAL e la proprietà ipCollection non è vuota, la subnet è stata creata con un intervallo di indirizzi IPv6 BYOIP.

Gli intervalli di indirizzi IPv6 esterni /96 possono essere assegnati nei seguenti modi:

  • Se non specificato, Google Cloud assegna automaticamente un intervallo di indirizzi IPv6 esterni temporanei /96.
  • Puoi specificare un intervallo di indirizzi IPv6 esterni regionali statici riservati /96. Se prenoti un intervallo /96 IPv6 esterno statico regionale da un intervallo di subnet IPv6 fornito da BYOIP, devi specificare VM per il tipo di endpoint.
  • Per le istanze VM, puoi specificare un intervallo di indirizzi /96 IPv6 esterno temporaneo personalizzato. Questo metodo non è supporta le regole di forwarding.

Assegnazione dell'intervallo IPv6

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

Tipo di risorsa Dimensione intervallo Dettagli
Rete VPC /48

Per abilitare IPv6 interno su una subnet, devi prima assegnare un intervallo IPv6 interno alla rete VPC.

Alla rete viene assegnato un intervallo ULA /48 all'interno di fd20::/20. Tutti gli intervalli di subnet IPv6 interni nella rete vengono 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 IPv6 interno su una subnet, viene assegnato un intervallo /64 di ULA interni dall'intervallo /48 della tua rete VPC.
  • Se abiliti IPv6 esterno su una subnet, viene assegnato un intervallo /64 di GUA esterni in uno dei seguenti modi:
    • Google Cloud assegna automaticamente l'intervallo. Inoltre, Google Cloud alloca ogni metà dell'intervallo /64 per uno scopo specifico come segue:
      • L'intervallo /65 che rappresenta la prima metà della subnet è allocato per le istanze VM.
      • L'intervallo /65 che rappresenta la seconda metà della subnet è allocato per Cloud Load Balancing.
    • In alternativa, puoi allocare un intervallo da un sottoprefisso IPv6 BYOIP in modalità di creazione della subnet.
Istanza VM /96

Quando configuri un'interfaccia di rete a doppio stack o solo IPv6 su una VM, all'interfaccia viene assegnato un intervallo di indirizzi IP /96 dalla subnet dell'interfaccia. Google Cloud fornisce il primo indirizzo IP nell'intervallo /96 utilizzando DHCPv6.

Se un'interfaccia di rete VM utilizza un intervallo di indirizzi IPv6 /96 interno o esterno dipende dal tipo di accesso IPv6 della subnet dell'interfaccia.
Regola di forwarding per un bilanciatore del carico di rete passthrough interno, un bilanciatore del carico di rete passthrough esterno o il forwarding del protocollo /96 o specificato da un sottoprefisso BYOIP

L'intervallo di indirizzi IPv6 di una regola di forwarding per il forwarding del protocollo interno o di un bilanciatore del carico di rete passthrough interno è un intervallo di indirizzi IP interni /96 di un intervallo di indirizzi IPv6 interni di una subnet. Gli intervalli di indirizzi IP /96 interni possono essere selezionati automaticamente da Google Cloud oppure puoi prenotare un intervallo di indirizzi /96 IPv6 interno statico regionale.

L'intervallo di indirizzi IPv6 di una regola di forwarding per il forwarding di protocollo esterno o un bilanciatore del carico di rete passthrough esterno è uno dei seguenti:

  • Se utilizzi indirizzi IPv6 esterni forniti da Google, l'intervallo di indirizzi IPv6 è un intervallo di indirizzi esterni /96 selezionato automaticamente da Google Cloud da un intervallo di indirizzi IPv6 esterni di una subnet.
  • Se utilizzi indirizzi IPv6 esterni BYOIP, l'intervallo di indirizzi IPv6 proviene da un sottoprefisso di indirizzi IPv6 BYOIP in modalità di creazione della regola di forwarding. Le dimensioni dell'intervallo IPv6 sono determinate dalla lunghezza del prefisso allocabile del sottoprefisso.

Indirizzi inutilizzabili negli intervalli di subnet IPv6

Il primo e l'ultimo intervallo /96 dell'intervallo /64 interno di una subnet non possono essere specificati manualmente perché Google Cloud riserva il primo e l'ultimo intervallo /96 dell'intervallo /64 interno di una subnet per l'utilizzo del sistema. Puoi specificare manualmente qualsiasi altro intervallo IPv6 /96 valido dall'intervallo /64 interno della subnet da assegnare alle interfacce di rete della VM.

La specifica manuale non è supportata per le interfacce di rete VM IPv6 esterne.

Indirizzo IPv6 inutilizzabile Descrizione Esempio
Il primo intervallo /96 dall'intervallo IPv6 /64 interno della subnet Riservato per l'utilizzo da parte del sistema fd20:db8::/96 dall'intervallo fd20:db8::/64
L'ultimo intervallo /96 dell'intervallo IPv6 /64 interno della subnet Riservato per l'utilizzo da parte del sistema fd20:db8:0:0:ffff:ffff::/96 dall'intervallo fd20:db8::/64

Passaggi successivi

Provalo

Se non conosci Google Cloud, crea un account per valutare le prestazioni di Cloud NAT in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti senza addebiti per l'esecuzione, il test e il deployment dei workload.

Prova Cloud NAT gratuitamente