Interazioni dei prodotti Cloud NAT

Questa pagina descrive le interazioni importanti tra Cloud NAT e altri prodotti Google Cloud.

Interazioni con le route

Un gateway NAT pubblico può utilizzare solo route i cui hop successivi sono il gateway internet predefinito. Ogni rete Virtual Private Cloud (VPC) viene avviata con una route predefinita la cui destinazione è 0.0.0.0/0 e il cui hop successivo è il gateway internet predefinito. Per informazioni importanti di base, consulta la panoramica dei percorsi.

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

• Se crei una route statica personalizzata con hop successivi impostati su qualsiasi altro tipo di hop successivo di route statica personalizzata, i pacchetti con indirizzi IP di destinazione corrispondenti alla destinazione della route vengono inviati all'hop successivo anziché al gateway internet predefinito. Ad esempio, se utilizzi istanze di macchine virtuali (VM) che eseguono un gateway NAT, un firewall o un software proxy, crei route statiche personalizzate per indirizzare il traffico a quelle VM come hop successivo. Le VM dell'hop successivo richiedono indirizzi IP esterni. Pertanto, il traffico proveniente dalle VM che si basano sulle VM dell'hop successivo o sulle VM dell'hop successivo non può utilizzare i gateway NAT pubblico.

• Se crei una route statica personalizzata il cui hop successivo è un tunnel Cloud VPN, Public NAT non utilizzerà quella route. Ad esempio, una route statica personalizzata con destinazione 0.0.0.0/0 e un tunnel Cloud VPN dell'hop successivo indirizzano il traffico a quel tunnel, non al gateway internet predefinito. Pertanto, i gateway NAT pubblico non possono utilizzare questa route. Analogamente, i gateway NAT pubblico non possono utilizzare route statiche personalizzate con 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 verso un router Cloud che gestisce un tunnel Cloud VPN o un collegamento VLAN, i gateway NAT pubblico non possono utilizzare quella route. Ad esempio, se il tuo router on-premise pubblicizza una route dinamica personalizzata con destinazione 0.0.0.0/0, 0.0.0.0/0 viene indirizzato al tunnel Cloud VPN o al collegamento VLAN. Questo comportamento vale anche per destinazioni più specifiche, tra cui 0.0.0.0/1 e 128.0.0.0/1.

Il servizio NAT privato utilizza le seguenti route:

• Per il servizio Inter-VPC NAT, Private NAT utilizza solo route di subnet scambiate da due spoke VPC di Network Connectivity Center collegati a un hub di Network Connectivity Center. Per saperne di più sugli spoke VPC di Network Connectivity Center, consulta Panoramica degli spoke VPC.
• Per Hybrid NAT (anteprima), Private NAT utilizza le route dinamiche apprese dal router Cloud su Cloud VPN.

Interazione con accesso privato Google

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

Un gateway NAT pubblico non cambia il funzionamento dell'accesso privato Google. Per ulteriori informazioni, consulta Accesso privato Google.

I gateway NAT privati non si applicano all'accesso privato Google.

Interazione con il VPC condiviso

Un VPC condiviso consente a più progetti di servizio in una singola organizzazione di utilizzare una rete VPC condivisa in un progetto host. Per fornire NAT per le VM nei progetti di servizio che utilizzano una rete VPC condiviso, 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 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 o spazi VPC di Network Connectivity Center, anche se le VM nelle reti in peering si trovano nella stessa regione del gateway.

Interazione con GKE

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

• Intervallo di indirizzi IP principali della 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 NAT pubblico da applicare a tutti gli intervalli di indirizzi IP della subnet della subnet del cluster.

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

Quando un gateway NAT pubblico è configurato per fornire NAT per un cluster privato, prenota gli indirizzi IP di origine NAT e le porte di origine per ogni VM del nodo. Gli indirizzi IP e le porte di origine NAT possono essere utilizzati dai pod perché gli indirizzi IP dei pod vengono implementati come intervalli IP alias assegnati a ciascuna VM del nodo.

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

• Se è configurata l'allocazione statica delle porte, la procedura di prenotazione delle porte Public NAT riserva almeno 1024 porte di origine per nodo. Se il valore specificato per il numero minimo di porte per VM è maggiore di 1024, viene utilizzato questo 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 varia successivamente 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 dal NAT pubblico, Google Kubernetes Engine esegue la traduzione degli indirizzi di rete di origine (NAT di origine o SNAT) utilizzando il software in esecuzione su ciascun nodo quando i pod inviano pacchetti a internet, a meno che tu non abbia modificato la configurazione dell'accesso mascherato 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, Public NAT può essere utile anche per i cluster nativi VPC non privati. Poiché i nodi in un cluster non privato hanno indirizzi IP esterni, i pacchetti inviati dall'indirizzo IP interno principale del nodo non vengono mai elaborati da Cloud NAT. Tuttavia, se vuoi che il cluster pubblico utilizzi indirizzi IP esterni statici forniti da un gateway NAT pubblico, procedi nel seguente modo:

• Configura il gateway NAT pubblico in modo che si applichi solo all'intervallo di indirizzi IP secondari degli oggetti pod del cluster.
• Configura il cluster per disabilitare la SNAT predefinita, in modo che GKE conservi gli indirizzi IP per gli oggetti pod di origine dei pacchetti inviati a internet.
• Configura l'agente di mascheramento IP specificando i CIDR appropriati come destinazioni non mascherate, in modo che l'agente conservi gli indirizzi IP per gli oggetti pod di origine dei pacchetti inviati alle destinazioni non mascherate.

L'esempio seguente mostra una tipica interazione del NAT pubblico con GKE:

NAT pubblico con GKE (fai clic per ingrandire).

In questo esempio, vuoi che i container siano tradotti in NAT. Per abilitare NAT per tutti i container e il nodo GKE, devi scegliere tutti gli intervalli di indirizzi IP di Subnet 1 come candidato NAT:

• Intervallo di indirizzi IP principali della subnet: 10.240.0.0/24
• Intervallo di indirizzi IP secondari della subnet utilizzato per i pod: 10.0.0.0/16

Non è possibile abilitare NAT solo per Pod1 o Pod2.

Un gateway NAT privato può eseguire NAT per nodi e pod in un cluster privato e non privato. Il gateway NAT privato si applica automaticamente a tutti gli intervalli di indirizzi IP della subnet per la subnet privata utilizzata dal cluster.

Interazioni dirette in uscita da VPC

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

I gateway NAT pubblici possono eseguire NAT per i servizi Cloud Run o i job configurati con il traffico in uscita da VPC diretto. Per consentire alle tue istanze VPC dirette di utilizzare un gateway NAT pubblico, configura il gateway NAT pubblico con le seguenti impostazioni:

• Specifica il flag --nat-all-subnet-ip-ranges per consentire a tutti gli intervalli di indirizzi IP di tutte le subnet nella regione di utilizzare il gateway NAT pubblico.
• Imposta il valore del flag --endpoint-types su ENDPOINT_TYPE_VM. Questo valore garantisce che solo le VM (incluse le VM in uscita con VPC diretto) possano utilizzare il gateway NAT pubblico.
• In caso di allocazione statica delle porte, imposta il valore del flag --min-ports-per-vm su quattro volte il numero di porte richieste da una singola istanza di Cloud Run.
• In caso di allocazione manuale degli indirizzi IP NAT, assegna un numero appropriato di indirizzi IP al gateway NAT pubblico per tenere conto della somma del numero di istanze Google Cloud e del numero di istanze VPC dirette in uscita di cui hai eseguito il deployment nella rete VPC.

Oltre alla configurazione del gateway, per inviare il traffico in uscita da un servizio o un job Cloud Run, devi impostare il flag --vpc-egress su all-traffic quando crei il servizio o il job.

Se hai configurato un servizio o job Cloud Run con il flag --vpc-egress impostato su private-ranges-only, il servizio o il job invia il traffico solo agli indirizzi IP interni. Non hai bisogno di un gateway NAT pubblico per instradare il traffico alle destinazioni interne.

Per impedire ai servizi o ai job Cloud Run con il flag --vpc-egress impostato su private-ranges-only di utilizzare un gateway NAT pubblico, segui questi passaggi:

• Configura il gateway NAT pubblico con il flag --nat-custom-subnet-ip-ranges.
• Imposta il valore del flag --nat-custom-subnet-ip-ranges sui nomi delle subnet in cui hai eseguito il deployment di servizi o job Cloud Run con il flag --vpc-egress impostato su all-traffic.

Le seguenti limitazioni si applicano ai servizi e ai job Cloud Run che utilizzano gateway NAT pubblici:

• Le metriche di Cloud NAT per gli endpoint in uscita dal VPC diretto non vengono esportate in Cloud Monitoring.
• I log di Cloud NAT per il traffico VPC diretto non mostrano il nome di un servizio, una revisione o un job Cloud Run.

Non puoi utilizzare i gateway NAT privati con le istanze VPC dirette in uscita.

Interazioni con Connectivity Tests

Puoi utilizzare Connectivity Tests per verificare la connettività tra endpoint di rete che utilizzano configurazioni di Cloud NAT. Puoi eseguire Connectivity Tests su reti che utilizzano gateway NAT pubblici o gateway NAT privati oppure entrambi.

Puoi visualizzare i dettagli della configurazione NAT nel riquadro Traccia di analisi della configurazione nella pagina Dettagli del test di connettività.

Interazioni con Cloud Load Balancing

Google Cloud Application Load Balancer interni regionali e gli Application Load Balancer esterni regionali comunicano con più backend di gruppi di endpoint di rete internet (NEG) regionali. Configurando i gateway Cloud NAT per i NEG internet a livello di regione, puoi allocare il tuo insieme di intervalli di indirizzi IP esterni da dove deve avere origine il traffico Google Cloud. I controlli di integrità e il traffico del piano dati provengono dagli indirizzi IP NAT che assegni.

Altri bilanciatori del carico esterni e sistemi di controllo di integrità 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 Panoramica di Cloud Load Balancing e Panoramica dei controlli di integrità.

Passaggi successivi

• Scopri di più sugli indirizzi e porte di Cloud NAT.
• Configura un gateway Public NAT.
• Configura le regole di Cloud NAT.
• Configura un gateway Private NAT.