Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Panoramica di Cloud NAT

Cloud NAT (traduzione indirizzo di rete) consente a determinate risorse senza indirizzi IP esterni di creare connessioni in uscita a Internet.

Cloud NAT offre connettività in uscita per le seguenti risorse:

Architettura

Cloud NAT è un servizio gestito distribuito e software-defined. Non si basa su VM o appliance proxy. Cloud NAT configura il software Andromeda basato sulla tua rete Virtual Private Cloud (VPC) per fornire la traduzione degli indirizzi di rete del codice sorgente (NAS o SNAT di origine) per le VM senza indirizzi IP esterni. Cloud NAT fornisce anche la traslazione degli indirizzi di rete di destinazione ( NAT o DNAT di destinazione) per i pacchetti di risposta in entrata consolidati.

Confronto tra NAT tradizionale e Cloud NAT (fai clic per ingrandire)
Confronto tra NAT tradizionale e Cloud NAT (fai clic per ingrandire)

Cloud NAT implementa la mappatura NAT in uscita insieme a route statiche nella tua rete VPC i cui hop successivi sono il gateway Internet predefinito. In una configurazione di base, un percorso predefinito nella rete VPC soddisfa questo requisito.

Cloud NAT non implementa connessioni in entrata indesiderate da Internet. DNAT viene eseguito solo per i pacchetti che arrivano come risposte ai pacchetti in uscita.

Vantaggi

Cloud NAT offre i seguenti vantaggi:

  • Sicurezza

    Puoi ridurre la necessità che le singole VM abbiano indirizzi IP esterni. Soggetti alle regole di firewall in uscita, le VM senza indirizzi IP esterni possono accedere alle destinazioni su Internet. Ad esempio, potresti avere VM che richiedono solo l'accesso a Internet per scaricare gli aggiornamenti o completare il provisioning.

    Se utilizzi l'assegnazione manuale degli indirizzi IP NAT per configurare un gateway Cloud NAT, puoi condividere con sicurezza un insieme di indirizzi IP di origine esterni comuni con un gruppo di destinazione. Ad esempio, un servizio di destinazione potrebbe consentire solo le connessioni da indirizzi IP esterni noti.

  • Disponibilità

    Cloud NAT è un servizio gestito distribuito a livello di software. Non dipende da nessuna VM nel progetto o da un singolo dispositivo gateway fisico. Puoi configurare un gateway NAT su un router Cloud, che fornisce il piano di controllo per NAT e contiene i parametri di configurazione da te specificati. Google Cloud esegue e gestisce i processi sulle macchine fisiche che eseguono le VM Google Cloud.

  • Scalabilità

    Cloud NAT può essere configurato per scalare automaticamente il numero di indirizzi IP NAT che utilizza e supporta VM che appartengono ai gruppi di istanze gestite, inclusi quelli con scalabilità automatica abilitata.

  • Prestazioni

    Cloud NAT non riduce la larghezza di banda di rete per VM. Cloud NAT è implementato dal networking software-defined di Google Andromeda. Per ulteriori informazioni, consulta la sezione Larghezza di banda di rete nella documentazione di Compute Engine.

Specifiche

Cloud NAT può essere configurato per fornire NAT a Internet per i pacchetti inviati dai seguenti server:

  • L'indirizzo IP principale interno dell'interfaccia di rete della VM di Compute Engine, a condizione che all'interfaccia di rete non sia assegnato un indirizzo IP esterno. Se all'interfaccia di rete è assegnato un indirizzo IP esterno, Google Cloud esegue automaticamente NAT uno a uno per i pacchetti le cui origini corrispondono all'indirizzo IP interno principale dell'interfaccia, perché l'interfaccia di rete soddisfa i requisiti di accesso a Internet di Google Cloud. L'esistenza di un indirizzo IP esterno su un'interfaccia ha sempre la precedenza ed esegue sempre un NAT individuale uno a uno, senza utilizzare Cloud NAT.

  • Un intervallo IP alias assegnato all'interfaccia di rete della VM. Anche se all'interfaccia di rete è assegnato un indirizzo IP esterno, puoi configurare un gateway Cloud NAT per fornire NAT per i pacchetti le cui origini provengono da un intervallo IP alias dell'interfaccia. Un indirizzo IP esterno su un'interfaccia non esegue mai un NAT individuale per gli indirizzi IP alias.

  • Per i cluster GKE, Cloud NAT può fornire servizi anche se il cluster ha indirizzi IP esterni in determinate circostanze. Per i dettagli, consulta Interazione con GKE.

Cloud NAT consente le connessioni in uscita e le risposte in entrata per tali connessioni. Ogni gateway Cloud NAT esegue NAT in origine e in uscita e un NAT di destinazione per i pacchetti di risposta stabiliti.

Cloud NAT non consente richieste in entrata richieste da Internet, anche se le regole firewall consentirebbero altrimenti tali richieste. Per ulteriori informazioni, consulta le RFC applicabili.

Ogni gateway Cloud NAT è associato a una singola rete VPC, a una singola regione e a un router Cloud. Il gateway Cloud NAT e il router Cloud forniscono un piano di controllo, non sono coinvolti nel piano dati, quindi i pacchetti non passano attraverso il gateway Cloud NAT o il router Cloud.

Route e regole firewall

Cloud NAT si basa su route statiche personalizzate i cui hop successivi rappresentano il gateway Internet predefinito. Per utilizzare completamente un gateway Cloud NAT, la rete VPC richiede una route predefinita il cui hop successivo è il gateway Internet predefinito. Per ulteriori informazioni, consulta la sezione sulle interazioni con i percorsi.

Cloud NAT non ha requisiti delle regole firewall di Google Cloud. Le regole firewall si applicano direttamente alle interfacce di rete delle VM di Compute Engine, non ai gateway Cloud NAT.

Non devi creare regole firewall speciali che consentano le connessioni da o verso indirizzi IP NAT. Quando un gateway Cloud NAT fornisce NAT per un'interfaccia di rete VM, le regole firewall in uscita applicabili vengono valutate come pacchetti per l'interfaccia di rete prima NAT. Le regole firewall in entrata vengono valutate dopo che i pacchetti sono stati elaborati da NAT.

Applicabilità intervallo di indirizzi IP subnet

Un gateway Cloud NAT può fornire servizi NAT per i pacchetti inviati da un'interfaccia di rete di Compute Engine VM, purché all'interfaccia di rete non sia assegnato un indirizzo IP esterno. Per i cluster GKE, Cloud NAT può fornire il servizio anche se i nodi del cluster hanno indirizzi IP esterni in determinate circostanze. Per i dettagli, consulta Interazione con GKE.

Il gateway Cloud NAT può essere configurato in modo da fornire NAT per l'indirizzo IP interno principale dell'interfaccia di rete della VM, intervalli IP alias o entrambi. Per effettuare questa configurazione scegli gli intervalli di indirizzi IP di subnet a cui deve essere applicato il gateway.

Puoi configurare un gateway Cloud NAT per fornire NAT per quanto segue:

  • Intervalli di indirizzi IP principali e secondari di tutte le subnet nella regione. Un singolo gateway Cloud NAT fornisce NAT per gli indirizzi IP interni principali e per tutti gli intervalli IP alias delle VM idonee le cui interfacce di rete utilizzano una subnet nella regione. Questa opzione utilizza esattamente un gateway NAT per area geografica.

  • Intervalli di indirizzi IP principali di tutte le subnet nella regione. Un singolo gateway Cloud NAT fornisce NAT per gli indirizzi IP interni principali e per gli intervalli IP alias da intervalli di indirizzi IP principali della subnet delle VM idonee le cui interfacce di rete utilizzano una subnet nella regione. Puoi creare gateway Cloud NAT aggiuntivi nella regione per fornire NAT per intervalli IP alias da intervalli di indirizzi IP secondari della subnet delle VM idonee.

  • Intervalli di indirizzi IP della subnet personalizzati. Puoi creare tutti i gateway Cloud NAT necessari, in base alle quote e ai limiti di Cloud NAT. Sei tu a scegliere quali intervalli di indirizzi IP principali o secondari devono essere forniti da ogni gateway.

Larghezza di banda

L'utilizzo di un gateway Cloud NAT non modifica la quantità di larghezza di banda in uscita o in entrata che una VM può utilizzare. Per le specifiche della larghezza di banda, che variano in base al tipo di macchina, vedi Larghezza di banda di rete nella documentazione di Compute Engine.

VM con più interfacce di rete

Se configuri una VM con più interfaccia di rete, ogni interfaccia deve trovarsi in una rete VPC separata. Di conseguenza, si verifica quanto segue:

  • Un gateway Cloud NAT può essere applicato solo a una singola interfaccia di rete di una VM. I gateway Cloud NAT separati possono fornire NAT alla stessa VM, dove ogni gateway si applica a un'interfaccia separata.

  • Un'interfaccia di una VM con più interfacce di rete può avere un indirizzo IP esterno e quindi non essere idonea per Cloud NAT, mentre un'altra interfaccia può essere idonea per NAT se l'interfaccia non ha un indirizzo IP esterno e hai configurato un gateway Cloud NAT da applicare all'intervallo di indirizzi IP della subnet appropriato.

Indirizzi IP e porte NAT

Quando crei un gateway Cloud NAT, puoi decidere che il gateway assegni automaticamente gli indirizzi IP esterni a livello di regione. In alternativa, puoi assegnare manualmente al gateway un numero fisso di indirizzi IP esterni a livello di regione. Per informazioni dettagliate su ciascun metodo, consulta gli indirizzi IP NAT.

Puoi configurare il numero di porte di origine che ogni gateway di Cloud NAT riserva per ogni VM per cui deve fornire i servizi NAT. Puoi configurare l'allocazione statica delle porte, in cui lo stesso numero di porte è riservato per ogni VM, oppure l'allocazione dinamica delle porte, dove il numero di porte prenotate può variare tra i limiti minimo e massimo specificati.

Le VM per cui deve essere fornito NAT sono determinate dagli intervalli di indirizzi IP di subnet che il gateway è configurato per la pubblicazione.

Per ulteriori informazioni, consulta Porte e la procedura di prenotazione delle porte.

RFC applicabili

Cloud NAT supporta Mapping indipendente dagli endpoint e Filtro dipendente dagli endpoint come definito nel documento RFC 5128. Puoi attivare o disattivare la mappatura indipendente degli endpoint. Per impostazione predefinita, la mappatura indipendente dagli endpoint viene disattivata quando crei un gateway NAT.

Mappatura indipendente dagli endpoint significa che se una VM invia pacchetti da un determinato indirizzo IP interno e da una coppia di porte a più destinazioni diverse, il gateway mappa tutti i pacchetti alla stessa coppia di indirizzi IP e porta NAT, indipendentemente dalla destinazione dei pacchetti. Per dettagli e implicazioni relativi alla mappatura indipendente dagli endpoint, vedi Riutilizzo simultaneo della porta e mappatura indipendente dagli endpoint.

Filtri dipendenti dagli endpoint indica che i pacchetti di risposta da Internet possono entrare solo se provengono da un indirizzo IP e da una porta a cui una VM ha già inviato pacchetti. I filtri dipendono dall'endpoint, indipendentemente dal tipo di mappatura degli endpoint. Questa funzionalità è sempre attiva e non è configurabile dall'utente.

Per ulteriori informazioni sulla relazione tra porte e connessioni, consulta Porte e connessioni e l'esempio di flusso NAT.

Cloud NAT è un Cone con restrizioni della porta come definito nel documento RFC 3489.

Attraversamento NAT

Se è abilitata la mappatura indipendente degli endpoint, Cloud NAT è compatibile con i comuni protocolli di attraversamento NAT come STUN e turn, se esegui il deployment dei tuoi server STUN o turn:

  • STUN (Session Traversal Utilities for NAT, RFC 5389) consente la comunicazione diretta tra VM dietro NAT, quando viene stabilito un canale di comunicazione.
  • turn (Traversal using Relaysround NAT, RFC 5766) consente la comunicazione tra VM dietro NAT mediante un terzo server in cui il server ha un indirizzo IP esterno. Ogni VM si connette all'indirizzo IP esterno del server e inoltra la comunicazione tra le due VM. turn è più robusto, ma consuma più larghezza di banda e risorse.

Timeout NAT

I gateway Cloud NAT utilizzano i seguenti timeout. Puoi modificare i valori predefiniti di timeout per diminuire o aumentare la frequenza di riutilizzo delle porte. Ogni valore di timeout è un equilibrio tra l'uso efficiente delle risorse Cloud NAT e la possibile interruzione di connessioni attive, flussi o sessioni.

Timeout Descrizione Valore predefinito Cloud NAT Configurabile

Timeout di inattività della mappatura UDP

RFC 4787 REQ-5

Specifica il tempo in secondi dopo il quale i flussi UDP devono interrompere l'invio del traffico agli endpoint in modo che le mappature di Cloud NAT vengano rimosse.

Il timeout per inattività della mappatura UDP interessa due endpoint che interrompono l'invio del traffico tra loro. Influisce anche sugli endpoint che richiedono tempi di risposta più lunghi o se aumenta la latenza di rete.

Puoi aumentare il valore di timeout specificato per ridurre la frequenza di riutilizzo delle porte. Un valore di timeout maggiore significa che le porte sono mantenute per connessioni più lunghe e protegge anche dalle pause del traffico su uno specifico socket UDP.

30 secondi

Timeout di inattività della connessione stabilita TCP

RFC 5382 REQ-5

Specifica il tempo in secondi in cui una connessione è inattiva prima che le mappature di Cloud NAT vengano rimosse.

Il timeout di inattività della connessione stabilita TCP influisce sugli endpoint che richiedono tempi di risposta più lunghi o se si verifica un aumento della latenza di rete.

Puoi aumentare il valore di timeout quando vuoi aprire le connessioni TCP e mantenere le connessioni aperte per un lungo periodo senza un meccanismo keepalive in atto.

1200 secondi (20 minuti)

Timeout di inattività della connessione transitoria TCP

RFC 5382 REQ-5

Specifica il tempo in secondi in cui le connessioni TCP possono rimanere nello stato semiaperto prima di poter eliminare i mapping Cloud NAT.

Il timeout per inattività della connessione transitoria TCP influisce su un endpoint quando un endpoint esterno richiede un periodo più lungo rispetto all'ora specificata o quando la latenza di rete aumenta. A differenza di Timeout di inattività della connessione stabilita TCP, il timeout di inattività della connessione transitoria TCP influisce solo sulle connessioni semiaperte.

30 secondi

Nota: indipendentemente dal valore impostato per questo timeout, Cloud NAT potrebbe richiedere fino a 30 secondi in più prima che un indirizzo IP di origine e una tupla porta di origine di Cloud NAT possano essere utilizzati per elaborare una nuova connessione.

Timeout TCP_WAIT

RFC 5382 REQ-5

Specifica il tempo in secondi in cui una connessione TCP completamente chiusa viene mantenuta nelle mappature Cloud NAT dopo la scadenza della connessione.

Il timeout TIME_WAIT TCP protegge gli endpoint interni dalla ricezione di pacchetti non validi che appartengono a una connessione TCP chiusa e ritrasmessa.

Puoi diminuire il valore di timeout per migliorare il riutilizzo delle porte di Cloud NAT al costo di ricevere pacchetti ritrasmessi da una connessione non correlata precedentemente chiusa.

120 secondi

Nota: indipendentemente dal valore impostato per questo timeout, Cloud NAT potrebbe richiedere fino a 30 secondi in più prima che un indirizzo IP di origine e una tupla porta di origine di Cloud NAT possano essere utilizzati per elaborare una nuova connessione.

Timeout di inattività della mappatura ICMP

RFC 5508 REQ-2

Specifica il tempo in secondi dopo il quale le mappature Cloud NAT di Internet Control Message Protocol (ICMP) che non hanno flussi di traffico vengono chiusi.

Il timeout di inattività della mappatura ICMP influisce su un endpoint quando quest'ultimo impiega più tempo a rispondere rispetto al tempo specificato o a una maggiore latenza di rete.

30 secondi

Interazioni con i prodotti

Le seguenti sezioni descrivono le interazioni importanti tra Cloud NAT e altri prodotti Google Cloud.

Interazioni con route

Un gateway Cloud NAT può utilizzare solo route i cui hop successivi rappresentano il gateway Internet predefinito. Ogni rete VPC inizia con un percorso predefinito la cui destinazione è 0.0.0.0/0 e il cui hop successivo è il gateway Internet predefinito. Per informazioni di base importanti, consulta la panoramica dei percorsi.

I seguenti esempi illustrano situazioni che potrebbero rendere inutilizzabili i gateway Cloud NAT:

  • Se crei una route statica personalizzata con hop successivi impostati su qualsiasi altro tipo di hop successivo personalizzato della route, i pacchetti con indirizzi IP di destinazione corrispondenti alla destinazione della route vengono inviati a quell'hop successivo anziché al gateway Internet predefinito. Ad esempio, se utilizzi istanze VM che eseguono software NAT, firewall o proxy, devi creare route statiche personalizzate personalizzate per indirizzare il traffico a tali VM come hop successivo. Le VM dell'hop successivo richiedono indirizzi IP esterni. Pertanto, né il traffico proveniente dalle VM che si basano sulle VM dell'hop successivo né quello delle VM di hop successivo potrebbero utilizzare Cloud NAT.

  • Se crei una route statica personalizzata il cui hop successivo è un tunnel Cloud VPN, Cloud NAT non la utilizza. Ad esempio, una route statica personalizzata con destinazione 0.0.0.0/0 e un tunnel Cloud VPN hop successivo indirizza il traffico a quel tunnel e non al gateway Internet predefinito. Di conseguenza, i gateway Cloud NAT non sarebbero in grado di utilizzare tale percorso. Questo vale anche per destinazioni più specifiche, tra cui 0.0.0.0/1 e 128.0.0.0/1.

  • Se un router on-premise pubblicizza una route dinamica personalizzata a un router Cloud che gestisce un tunnel Cloud VPN o un collegamento Cloud Interconnect (VLAN), i gateway Cloud NAT non possono utilizzare questa route. Ad esempio, se il router on-premise pubblicizza una route dinamica personalizzata con destinazione 0.0.0.0/0, 0.0.0.0/0 verrà indirizzato al tunnel Cloud VPN o al collegamento Cloud Interconnect (VLAN). Questo vale anche per destinazioni più specifiche, tra cui 0.0.0.0/1 e 128.0.0.0/1.

Interazione privata con Google Access

Cloud NAT non esegue mai NAT per il traffico inviato agli indirizzi IP esterni per le API e i servizi Google selezionati. Invece, Google Cloud abilita automaticamente l'accesso privato Google per un intervallo di indirizzi IP della subnet quando configuri un gateway Cloud NAT per applicare a quell'intervallo di subnet, principale o secondario. Se il gateway fornisce NAT per un intervallo di subnet, l'accesso privato Google è attivo per quell'intervallo e non può essere disabilitato manualmente.

Un gateway Cloud NAT non cambia il funzionamento dell'accesso privato Google. Per ulteriori informazioni, consulta la pagina relativa all'accesso privato Google.

Interazione VPC condivisa

Il VPC condiviso consente a più progetti di servizio in una singola organizzazione di utilizzare una rete VPC condivisa comune in un progetto host. Per fornire NAT per VM nei progetti di servizio che utilizzano una rete VPC condivisa, devi creare gateway Cloud NAT nel progetto host.

Interazione peering di rete VPC

I gateway Cloud NAT sono associati a intervalli di indirizzi IP di subnet in una singola regione e in una singola rete VPC. Un gateway Cloud NAT creato in una rete VPC non può fornire NAT alle VM in altre reti VPC connesse tramite peering di rete VPC, anche se le VM nelle reti in peering si trovano nella stessa regione del gateway.

Interazione GKE

Un gateway Cloud NAT può eseguire NAT per nodi e pod in un cluster privato, che è un tipo di cluster nativo di VPC. Il gateway Cloud NAT deve essere configurato in modo da essere applicato ad almeno i seguenti intervalli di indirizzi IP di subnet per la subnet utilizzata dal cluster:

  • Intervallo di indirizzi IP principali delle subnet (utilizzato dai nodi)
  • Intervallo di indirizzi IP secondari della subnet utilizzato per i pod nel cluster
  • Intervallo di indirizzi IP secondari della subnet utilizzato per i servizi nel cluster

Il modo più semplice per fornire NAT per un intero cluster privato è configurare un gateway Cloud NAT da applicare a tutti gli intervalli di indirizzi IP della subnet del cluster.

Per informazioni di base su come i cluster nativi di VPC utilizzano gli intervalli di indirizzi IP della subnet, consulta gli intervalli IP per i cluster nativi di VPC.

Quando un gateway Cloud NAT è configurato per fornire NAT per un cluster privato, riserva gli indirizzi IP e le porte di origine NAT per ogni VM del nodo. Questi indirizzi IP e porte di origine NAT sono utilizzabili dai pod, in quanto gli indirizzi IP dei pod sono implementati come intervalli IP alias assegnati a ciascuna VM del nodo.

I cluster nativi di GKE assegnano sempre ogni nodo a un intervallo IP alias che contiene più di un indirizzo IP (netmask inferiore a /32).

  • Se è configurata l'allocazione statica delle porte, la procedura di prenotazione delle porte di Cloud NAT prenota almeno 1024 porte di origine per nodo. Se il valore specificato per il numero minimo di porte per VM è maggiore di 1024, verrà utilizzato tale valore.

  • Se è configurata l'allocazione dinamica delle porte, il valore specificato per il numero minimo di porte per VM viene inizialmente allocato per nodo. Il numero di porte allocate successivamente varia tra i valori specificati per il numero minimo e massimo di porte per VM, in base alla domanda.

Per informazioni sugli intervalli di indirizzi IP dei pod e sui cluster nativi di VPC, consulta Intervallo di indirizzi IP secondari delle subnet per i pod.

Indipendentemente da Cloud NAT, GKE esegue SNAT utilizzando un software in esecuzione su ciascun nodo quando i pod inviano pacchetti a Internet, a meno che tu non abbia cambiato la configurazione di mascheramento IP del cluster. Se hai bisogno di un controllo granulare sul traffico in uscita dai pod, puoi utilizzare un criterio di rete.

In determinate circostanze, Cloud NAT può essere utile anche ai cluster nativi VPC privati. Poiché i nodi in un cluster non privato hanno indirizzi IP esterni, i pacchetti inviati dall'indirizzo IP interno primario del nodo non vengono mai elaborati da Cloud NAT. Tuttavia, i pacchetti inviati dai pod in un cluster non privato possono essere elaborati da un gateway Cloud NAT se entrambe le seguenti condizioni sono vere:

  • Per i cluster nativi di VPC, il gateway Cloud NAT è configurato per essere applicato all'intervallo di indirizzi IP secondari per i pod del cluster.

  • La configurazione mascherata dell'IP del cluster non è configurata per l'esecuzione dello SNAT nel cluster per i pacchetti inviati dai pod a Internet.

Interazioni Cloud Load Balancing

I bilanciatori del carico esterni e i sistemi di controllo di integrità di Google Cloud comunicano con le VM utilizzando route speciali. Le VM di backend non richiedono indirizzi IP esterni né un gateway Cloud NAT gestisce la comunicazione per i bilanciatori del carico e i controlli di integrità. Per ulteriori informazioni, consulta la panoramica di Cloud Load Balancing e la panoramica dei controlli di integrità.

Esempi

Gli esempi seguenti illustrano i concetti di Cloud NAT.

Configurazione NAT di base

Cloud NAT (fai clic per ingrandire).
Cloud NAT (fai clic per ingrandire)

In questo esempio:

  • Il gateway nat-gw-us-east è configurato per essere applicato all'intervallo di indirizzi IP principali di subnet-1 nella regione us-east1. Una VM la cui interfaccia di rete non ha un indirizzo IP esterno può inviare traffico a Internet utilizzando il suo indirizzo IP interno principale o un intervallo IP alias dall'intervallo di indirizzi IP principali di subnet-1, 10.240.0.0/16.

  • Una VM la cui interfaccia di rete non ha un indirizzo IP esterno e il cui indirizzo IP interno principale si trova in subnet-2 non può accedere a Internet perché non si applica alcun gateway Cloud NAT a nessun intervallo di indirizzi IP della subnet.

  • Il gateway nat-gw-eu è configurato per essere applicato all'intervallo di indirizzi IP principali di subnet-3 nella regione europe-west1. Una VM la cui interfaccia di rete non ha un indirizzo IP esterno può inviare traffico a Internet utilizzando il suo indirizzo IP interno principale o un intervallo IP alias dall'intervallo di indirizzi IP principali di subnet-3, 192.168.1.0/24.

Esempio di GKE

Cloud NAT con GKE (fai clic per ingrandire).
Cloud NAT con GKE (fai clic per ingrandire)

In questo esempio, vuoi che i container vengano tradotti con NAT. Per abilitare NAT per tutti i container e il nodo GKE, devi scegliere tutti gli intervalli di indirizzi IP della subnet 1 come candidati NAT. Non è possibile abilitare NAT solo per container1 o container2.

Passaggi successivi