Panoramica delle subnet
Le reti Virtual Private Cloud (VPC) sono risorse globali. Ogni rete VPC è costituita da uno o più intervalli di indirizzi IP denominati subnet. Le subnet sono risorse di area geografica e sono associate a intervalli di indirizzi IP.
In Google Cloud, i termini subnet e subnetwork sono sinonimi. Vengono utilizzati in modo intercambiabile nella console di Google Cloud Console, nei comandi dell'interfaccia a riga di comando di Google Cloud e nella documentazione dell'API.
Reti e subnet
Per poter essere usata, una rete deve avere almeno una subnet. Modalità automatica Le reti VPC creano automaticamente subnet in ogni area geografica. Le reti VPC in modalità personalizzata iniziano senza subnet, offrendo il pieno controllo sulla creazione delle subnet. Puoi creare più di una subnet per area geografica. Per informazioni sulle differenze tra la modalità automatica e le reti VPC in modalità personalizzata, consulta Tipi di reti VPC.
Quando crei una risorsa in Google Cloud, scegli una rete e una subnet. Per risorse diverse dai modelli di istanza, puoi anche selezionare una zona o un'area geografica. Selezionando una zona, viene implicitamente selezionata la rispettiva area geografica principale. Poiché le subnet sono oggetti a livello di area geografica, l'area geografica 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 area geografica. Se selezioni una rete per la VM, devi selezionare una rete che contiene una subnet nell'area geografica principale della zona selezionata.
Quando crei un gruppo di istanze gestite, devi selezionare una zona o un'area geografica, 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 e il modello deve specificare una rete VPC con subnet nella zona o nell'area geografica selezionata. Le reti VPC in modalità automatica hanno sempre una subnet in ogni area geografica.
Il processo di creazione di un cluster di container Kubernetes prevede la selezione di una zona o di un'area geografica (a seconda del tipo di cluster), di una rete e di una subnet. Devi selezionare una subnet disponibile nella zona o nell'area geografica 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, devi specificare 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.
Quando crei un intervallo di subnet IPv4, fornisci le seguenti informazioni:
Impostazione subnet | Valori validi | Dettagli |
---|---|---|
Intervallo IPv4 | Un intervallo valido scelto | Obbligatorie |
Intervallo IPv4 secondario | Un intervallo valido scelto | Facoltativo |
Quando crei un intervallo di subnet IPv6, fornisci le seguenti informazioni:
Impostazione subnet | Valori validi | Dettagli |
---|---|---|
Tipo di accesso IPv6 |
|
Alla subnet viene assegnato automaticamente un intervallo di indirizzi IPv6 di
|
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 di protocolli interni. Se vuoi, puoi aggiungere intervalli di indirizzi IP secondari a una subnet, che vengono 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. Fai riferimento ai limiti per rete per il numero di intervalli di indirizzi IP secondari che puoi definire.
Le tue subnet IPv4 non devono formare un blocco CIDR contiguo predefinito, ma puoi farlo se lo desideri. Ad esempio, le reti VPC in modalità automatica creano subnet che si adattano a un intervallo IP predefinito in modalità automatica.
Per ulteriori informazioni, vedi Utilizzo delle subnet.
Intervalli IPv4 validi
Gli intervalli di indirizzi IPv4 principali e secondari di una subnet sono indirizzi IPv4 interni a livello di area geografica. La tabella seguente descrive gli intervalli validi.
Range | 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 |
100.64.0.0/10 |
Spazio di indirizzi condiviso RFC 6598 |
192.0.0.0/24 |
Assegnazioni 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 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'uso di questo intervallo, quindi verifica che il tuo 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:
Quando utilizzi questi indirizzi come intervalli di subnet, Google Cloud non annuncia queste route a Internet e non indirizza il traffico da Internet alle destinazioni. Se hai importato indirizzi IP pubblici in Google utilizzando 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 delle subnet vengono esportate automaticamente per impostazione predefinita, ma per poter essere utilizzate, le reti peer devono essere configurate in modo esplicito per importarle. |
Gli intervalli di subnet IPv4 hanno i seguenti vincoli:
Gli intervalli di subnet non possono corrispondere, essere più limitati 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 di link169.254.0.0/16
(RFC 3927), che è un intervallo limitato.Gli intervalli di subnet non possono includere un intervallo RFC (descritto nella tabella precedente) e un intervallo di indirizzi IP pubblici utilizzato privatamente. Ad esempio,
172.0.0.0/10
non è un intervallo di subnet valido perché include sia l'intervallo di indirizzi IP privati di172.16.0.0/12
sia gli indirizzi IP pubblici.Gli intervalli di subnet non possono coprire più intervalli RFC. Ad esempio,
192.0.0.0/8
non è un intervallo di subnet valido perché include sia192.168.0.0/16
(da RFC 1918) che192.0.0.0/24
(da RFC 6890). Tuttavia, puoi creare due subnet con intervalli primari diversi, una con192.168.0.0/16
e una con192.0.0.0/24
. In alternativa, puoi utilizzare entrambi gli intervalli sulla stessa subnet se ne imposti uno come intervallo secondario.
Intervalli di subnet IPv4 vietati
Gli intervalli di subnet vietati includono gli indirizzi IP pubblici di Google e gli intervalli RFC comunemente prenotati, come descritto nella tabella seguente. Questi intervalli non possono essere utilizzati per gli intervalli di subnet.
Range | Descrizione |
---|---|
Indirizzi IP pubblici per API e 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 di Google Access |
0.0.0.0/8 |
Rete RFC 1122 attuale (locale) |
127.0.0.0/8 |
Host locale RFC 1122 |
169.254.0.0/16 |
RFC 3927 link-local |
224.0.0.0/4 |
Multicast (classe D) RFC 5771 |
255.255.255.255/32 |
Indirizzo di destinazione della trasmissione limitato: RFC 8190 e RFC 919 |
Indirizzi IP riservati nelle subnet IPv4
Ogni subnet ha quattro indirizzi IP riservati nel proprio intervallo IP principale. Non sono presenti indirizzi IP riservati negli intervalli IP secondari.
Indirizzo IP riservato | Descrizione | Esempio |
---|---|---|
Rete | Il primo indirizzo nell'intervallo IP principale per la subnet | 10.1.2.0 in 10.1.2.0/24
|
Gateway predefinito | Secondo indirizzo nell'intervallo IP principale per la subnet | 10.1.2.1 in 10.1.2.0/24
|
Ultimo indirizzo | Ultimo indirizzo nell'intervallo IP principale per la subnet prenotato da Google Cloud per uso futuro futuro | 10.1.2.254 in 10.1.2.0/24
|
Trasmissione | Ultimo indirizzo nell'intervallo IP principale per la subnet | 10.1.2.255 in 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 si adattano al blocco CIDR 10.128.0.0/9
. Le reti VPC in modalità automatica vengono create con una subnet per area geografica al momento della creazione e ricevono automaticamente nuove subnet in nuove aree geografiche. Le parti inutilizzate di 10.128.0.0/9
sono riservate per l'utilizzo futuro di Google Cloud.
regione | Intervallo IP (CIDR) | Gateway predefinito | Indirizzi utilizzabili (inclusi) |
---|---|---|---|
asia-east1 | 10.140.0.0/20 | 10,140,0,1 | Dal 10.140.0.2 al 10.140.15.253 |
asia-east2 | 10.170.0.0/20 | 10,170,0,1 | Dal 10.170.0.2 al 10.170.15.253 |
asia-northeast1 | 10.146.0.0/20 | 10.146.0.1 | Dal 10.146.0.2 al 10.146.15.253 |
asia-northeast2 | 10.174.0.0/20 | 10.174.0.1 | Dal 10.174.0.2 al 10.174.15.253 |
asia-northeast3 | 10.178.0.0/20 | 10.178.0.1 | Dal 10.178.0.2 al 10.178.15.253 |
asia-south1 | 10.160.0.0/20 | 10,160,0,1 | Dal 10.160.0.2 al 10.160.15.253 |
asia-south2 | 10.190.0.0/20 | 10.190.0.1 | Dal 10.190.0.2 al 10.190.15.253 |
asia-southeast1 | 10.148.0.0/20 | 10.148.0.1 | Dal 10.148.0.2 al 10.148.15.253 |
asia-southeast2 | 10.184.0.0/20 | 10.184.0.1 | Dal 10.184.0.2 al 10.184.15.253 |
australia-southeast1 | 10.152.0.0/20 | 10.152.0.1 | Dal 10.152.0.2 al 10.152.15.253 |
australia-southeast2 | 10.192.0.0/20 | 10.192.0.1 | Dal 10.192.0.2 al 10.192.15.253 |
europe-central2 | 10.186.0.0/20 | 10.186.0.1 | Dal 10.186.0.2 al 10.186.15.253 |
europe-north1 | 10.166.0.0/20 | 10.166.0.1 | Dal 10.166.0.2 al 10.166.15.253 |
europe-west1 | 10.132.0.0/20 | 10,132,0,1 | Dal 10.132.0.2 al 10.132.15.253 |
europe-west2 | 10.154.0.0/20 | 10.154.0.1 | Dal 10.154.0.2 al 10.154.15.253 |
europe-west3 | 10.156.0.0/20 | 10,156,0,1 | Dal 10.156.0.2 al 10.156.15.253 |
europe-west4 | 10.164.0.0/20 | 10.164.0.1 | Dal 10.164.0.2 al 10.164.15.253 |
europe-west6 | 10.172.0.0/20 | 10.172.0.1 | Dal 10.172.0.2 al 10.172.15.253 |
europe-west8 | 10.198.0.0/20 | 10.198.0.1 | Dal 10.198.0.2 al 10.198.0.253 |
europe-west9 | 10.200.0.0/20 | 10.200.0.1 | Da 10.200.0.2 a 10.200.0.253 |
europe-southwest1 | 10.204.0.0/20 | 10.204.0.1 | Dal 10.204.0.2 al 10.204.15.253 |
northamerica-northeast1 | 10.162.0.0/20 | 10.162.0.1 | Dal 10.162.0.2 al 10.162.15.253 |
northamerica-northeast2 | 10.188.0.0/20 | 10.188.0.1 | Dal 10.188.0.2 al 10.188.15.253 |
southamerica-east1 | 10.158.0.0/20 | 10,158,0,1 | Dal 10.158.0.2 al 10.158.15.253 |
southamerica-west1 | 10.194.0.0/20 | 10.194.0.1 | Dal 10.194.0.2 al 10.194.15.253 |
us-central1 | 10.128.0.0/20 | 10.128.0.1 | Dal 10.128.0.2 al 10.128.15.253 |
us-east1 | 10.142.0.0/20 | 10.142.0.1 | Dal 10.142.0.2 al 10.142.15.253 |
us-east4 | 10.150.0.0/20 | 10,150,0,1 | Dal 10.150.0.2 al 10.150.15.253 |
us-east5 | 10.202.0.0/20 | 10.202.0.1 | Dal 10.202.0.2 al 10.202.15.253 |
us-sud1 | 10.206.0.0/20 | 10.206.0.1 | Dal 10.206.0.2 al 10.206.15.253 |
us-west1 | 10.138.0.0/20 | 10,138,0,1 | Dal 10.138.0.2 al 10.138.15.253 |
us-west2 | 10.168.0.0/20 | 10.168.0.1 | Dal 10.168.0.2 al 10.168.15.253 |
us-west3 | 10.180.0.0/20 | 10.180.0 | Dal 10.180.0.2 al 10.180.15.253 |
us-west4 | 10.182.0.0/20 | 10.182.0.1 | Dal 10.182.0.2 al 10.182.15.253 |
Intervalli di subnet IPv6
Quando attivi 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 le comunicazioni da VM a VM all'interno delle reti VPC. Possono essere instradati solo nell'ambito delle reti VPC e non in Internet.
Gli indirizzi IPv6 esterni possono essere utilizzati per le comunicazioni da VM a VM all'interno delle reti VPC e sono inoltre instradabili su Internet.
Se un'interfaccia VM è connessa a una subnet che ha 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 a livello di area geografica.
Gli intervalli di subnet IPv6 interni ed esterni sono disponibili in tutte le aree geografiche.
Gli intervalli di subnet IPv6 vengono assegnati automaticamente
/64
intervalli.Non è possibile modificare il tipo di accesso IPv6 (interno o esterno) di una subnet.
Non puoi modificare una subnet a doppio stack in stack singolo se il tipo di accesso IPv6 è interno.
Specifiche IPv6 interne
Gli intervalli IPv6 interni utilizzano indirizzi locali univoci (ULA).
Gli ULA per IPv6 sono analoghi agli indirizzi RFC 1918 per IPv4. Gli ULA non possono essere raggiunti 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
/48
IPv6. 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 agli intervalli utilizzati in tali ambienti.
L'assegnazione di un intervallo IPv6 interno alla rete VPC di
/48
è permanente. Non puoi disattivarlo o modificarlo in un secondo momento.
Specifiche IPv6 esterne
Gli intervalli di indirizzi IPv6 esterni utilizzano indirizzi unicast (GUA) globali.
Gli indirizzi IPv6 esterni possono essere utilizzati per le comunicazioni da VM a VM all'interno delle reti VPC e sono inoltre instradabili su Internet. Per controllare l'accesso in entrata e in uscita da Internet, configura le regole firewall o i criteri firewall gerarchici. Per disabilitare completamente il routing IPv6 a Internet, elimina il percorso predefinito IPv6 nella rete VPC.
Gli indirizzi IPv6 esterni sono disponibili solo nel livello Premium.
La prenotazione di indirizzi IPv6 esterni a livello di area geografica è disponibile come funzionalità di anteprima limitata.
Assegnazione intervallo IPv6
Gli intervalli IPv6 possono essere assegnati a reti, subnet e istanze di macchine virtuali (VM).
Tipo di risorsa | Dimensioni intervallo | Dettagli |
---|---|---|
Rete VPC | /48 |
Per abilitare IPv6 interno su una subnet, devi prima assegnare un intervallo IPv6 interno sulla rete VPC. All'intervallo di L'intervallo |
Subnet | /64 |
L'impostazione del tipo di accesso IPv6 consente di stabilire 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:
|
Istanza di macchina virtuale (VM) | /96 |
Quando abiliti IPv6 su una VM, alla VM viene assegnato un intervallo Non devi configurare se una VM riceve indirizzi IPv6 interni o esterni. La VM eredita il tipo di accesso IPv6 dalla subnet a cui è collegata. |
Passaggi successivi
Provalo
Se non hai mai utilizzato Google Cloud, crea un account per valutare le prestazioni di VPC 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 VPC gratuitamente