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. Loro sono utilizzati in modo intercambiabile nella console Google Cloud, nei comandi Google Cloud CLI e 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 regione. Personalizzate che iniziano senza subnet e offrono il controllo completo nella creazione di subnet. Puoi creare più di una 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 ne seleziona implicitamente la 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, selezioni una zona per l'istanza. Se non selezioni una rete per la VM, viene utilizzata la rete VPC predefinita, che include una subnet regione. Se selezioni una rete per la VM, devi selezionare una rete contiene una subnet nella regione padre 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'istanza modello con una configurazione adeguata; il modello deve specificare 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 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 che si trovano nella zona o 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 solo un IPv4 esistente subnet per configurarla una subnet a doppio stack.

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

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 della subnet Valori validi Dettagli
Tipo di accesso IPv6

  • Interno
  • Esterno

Un intervallo di indirizzi IPv6 /64 viene assegnato automaticamente alla subnet.

Scopi delle subnet

Le sottoreti possono essere utilizzate per diversi scopi:

  • Subnet normali: il tipo di subnet predefinito. Le subnet normali creati dagli utenti o creati automaticamente in un VPC in modalità automatica da utilizzare con le istanze VM. Le sottoreti normali hanno uno scopo di PRIVATE nell'API o nell'interfaccia a riga di comando gcloud. Lo scopo è None nel nella console Google Cloud.
  • Subnet Private Service Connect: una subnet da utilizzare per pubblicare un servizio gestito utilizzando Private Service Connect.
  • Subnet solo proxy: A una subnet solo proxy da utilizzare con di bilanciatori del carico basati su Envoy a livello di regione.
  • Subnet NAT private: una subnet riservata per l'utilizzo come intervallo di origine per il 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 un VPC a meno che non sia un membro di quella rete. All'interno di un progetto, le subnet la stessa regione deve avere nomi univoci. Ad esempio, una rete denominata production può avere più subnet denominate anche production, purché ognuna di queste si trova in una regione univoca.

  • Non puoi modificare il nome o la regione di una sottorete dopo averla creata. Tuttavia, puoi eliminare una subnet e sostituirla a condizione che non siano presenti risorse utilizzandolo.

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:

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

Le subnet IPv4 non devono necessariamente formare un blocco CIDR contiguo predefinito, se lo desideri. 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 hanno le seguenti limitazioni:

  • Ogni intervallo IPv4 principale o secondario per tutte le subnet in un VPC La rete 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 solo l'intervallo di indirizzi IPv4 secondari di una subnet se nessuna istanza utilizza quell'intervallo.

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

  • La subnet mask più breve che puoi utilizzare è /4. Tuttavia, per la maggior parte /4 intervalli di indirizzi IP; ulteriori convalide ti impediscono di creare per una subnet di dimensioni così grandi. 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 le subnet che si sovrappongono a uno intervallo allocato, qualsiasi intervallo secondario di un'altra subnet nella stessa rete o qualsiasi intervallo IPv4 di subnet nelle reti in 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.

  • Un intervallo di subnet non può corrispondere, essere più stretto o essere più ampio di un intervallo. Ad esempio, 169.0.0.0/8 non è una subnet valida 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 172.16.0.0/12 Intervallo di indirizzi IP e 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) e 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 uno con 192.0.0.0/24. In alternativa, puoi utilizzare entrambi questi intervalli sulla stessa subnet ne imposti uno come intervallo secondario.

Intervalli IPv4 validi

Gli intervalli di indirizzi IPv4 primari e secondari di una subnet sono IPv4 interni a livello di regione indirizzi IP esterni. 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, consulta Considerazioni aggiuntive.

100.64.0.0/10 Spazio 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 (non più supportato) 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, pertanto verifica che prima di creare subnet che utilizzino questo intervallo.
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 account proibito intervallo di subnet

Quando utilizzi questi indirizzi come intervalli di subnet, Google Cloud non annuncia queste route e non indirizza il traffico da Internet a internet.

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 nello stesso La rete VPC non deve sovrapporsi.

Per Peering di rete VPC, la subnet per gli indirizzi IP pubblici non vengono scambiate automaticamente. La subnet le route vengono esportate automaticamente per impostazione predefinita, ma le reti peer devono essere configurata in modo esplicito per importarle al fine di utilizzarle.

Intervalli di subnet IPv4 vietati

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

Intervallo Descrizione
Indirizzi IP pubblici per le API e i servizi Google, tra cui Netblock di Google Cloud. Puoi trovare questi indirizzi IP su https://gstatic.com/ipranges/goog.txt.
199.36.153.4/30
e
199.36.153.8/30		 Indirizzi IP virtuali specifici dell'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 Locale rispetto al collegamento RFC 3927
224.0.0.0/4 Multicast (Classe D) RFC 5771
255.255.255.255/32 Indirizzo di destinazione della 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 principale della subnet per ospitarla. Google Cloud ti consente di utilizzare tutti gli indirizzi in 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 gateway predefinito Secondo indirizzo nell'intervallo IPv4 principale 10.1.2.1 dall'intervallo 10.1.2.0/24
Penultimo all'ultimo indirizzo Dal penultimo all'ultimo indirizzo nell'intervallo IPv4 principale

Questo intervallo è riservato da Google Cloud per un potenziale uso 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 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.

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 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 10.152.0.2 a 10.152.15.253
australia-southeast2 10.192.0.0/20 10.192.0.1 10.192.0.2 - 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 10.164.0.2 - 10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2 - 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
io-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 10.162.0.2 - 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 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 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 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 del 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 attivi 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 le comunicazioni da VM a VM all'interno di 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 sia gli intervalli di subnet IPv6 interni che quelli esterni:

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

Le sottoreti dual-stack presentano le seguenti limitazioni:

  • Non puoi modificare il tipo di accesso IPv6 (interno o esterno) di una subnet.
  • Non puoi cambiare 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 a RFC 1918 addresses per IPv4. Gli ULA non sono raggiungibili da internet e non sono indirizzabili pubblicamente.

Prima di poter creare subnet con intervalli IPv6 interni, devi assegnare un /48 Intervallo IPv6 ULA al VPC Google Cloud. Tieni presente quanto segue quando assegni un intervallo di indirizzi IPv6 ULA /48 a un 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 tua rete VPC e le reti on-premise connesse o reti in altri cloud provider.

  • 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 seleziona automaticamente un intervallo IPv6 /64 inutilizzato dal VPC nell'intervallo IPv6 ULA /48 della rete. Gli intervalli IPv6 /64 interni della subnet possono essere utilizzati le seguenti:

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

Specifiche IPv6 esterno

Gli intervalli di indirizzi IPv6 esterni sono unicast globali indirizzi IP (GUA). Gli indirizzi IPv6 esterni sono disponibili solo su Premium Livello.

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

Puoi anche prenotare un indirizzo IPv6 /96 esterno regionale statico intervalli di questo tipo.

Assegnazione intervallo IPv6

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

Tipo di risorsa Dimensione intervallo Dettagli
Rete VPC /48

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

Alla rete viene assegnato un intervallo ULA di /48 all'interno di fd20::/20. per tutti gli intervalli di subnet IPv6 interne rete sono assegnate 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 consente di controllare 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 attivi IPv6 interno su una subnet, viene assegnato un intervallo /64 di ULA interni dall'intervallo /48 della rete VPC.

  • Se attivi IPv6 esterno su una subnet, viene assegnato un /64 intervallo di GUA esterni.
Istanza di macchina virtuale (VM) o regola di forwarding /96

Quando abiliti IPv6 su una VM, alla VM viene assegnato un intervallo /96 dalla subnet a cui è connessa. Il primo indirizzo IP dell'intervallo viene assegnato all'interfaccia principale utilizzando 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

Provalo

Se non hai mai utilizzato Google Cloud, crea un account per valutare in che modo Cloud NAT funziona diversi scenari. 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