Interazioni con i 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) inizia con una route predefinita 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.

Gli esempi riportati di seguito illustrano situazioni che potrebbero causare il malfunzionamento dei gateway NAT pubblico :

  • Se crei una route statica con gli hop successivi impostati su qualsiasi altro tipo di hop successivo della route statica, 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 di macchine virtuali (VM) che eseguono un software proxy, firewall o gateway NAT, crei route statiche per indirizzare il traffico a queste VM come hop successivo. Le VM di hop successivo richiedono indirizzi IP esterni. Pertanto, il traffico proveniente dalle VM che si basano sulle VM di hop successivo o dalle VM di hop successivo stesse non può utilizzare i gateway NAT pubblico .

  • Se crei una route statica personalizzata il cui hop successivo è un tunnel Cloud VPN, NAT pubblico non la utilizza. Ad esempio, una route statica con destinazione 0.0.0.0/0 e un tunnel Cloud VPN per l'hop successivo indirizza il traffico a quel tunnel, non al gateway internet predefinito. Pertanto, i gateway Public NAT non possono utilizzare questo route. Analogamente, i gateway Public NAT non possono utilizzare route statici con destinazioni più specifiche, tra cui 0.0.0.0/1 e 128.0.0.0/1.

  • Se un router on-premise annuncia una route dinamica a un router Cloud che gestisce un tunnel Cloud VPN o un collegamento VLAN, i gateway NAT pubblico non possono utilizzare questa route. Ad esempio, se il router on-premise annunci una route dinamica con destinazione 0.0.0.0/0,0.0.0.0/0 verrà indirizzata 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.

Private NAT utilizza i seguenti route:

  • Per gli spoke di Network Connectivity Center, Private NAT utilizza route di subnet e route dinamiche:
    • Per il traffico tra due spoke VPC collegati a un hub Network Connectivity Center contenente solo spoke VPC, Private NAT utilizza le route di subnet scambiate dagli spoke VPC collegati. Per informazioni sugli spoke VPC, consulta la panoramica degli spoke VPC.
    • Se un hub Network Connectivity Center contiene sia spoke VPC sia spoke ibridi, come i collegamenti VLAN per Cloud Interconnect, i tunnel Cloud VPN o le VM dell'appliance router, Private NAT utilizza le route dinamiche apprese dagli spoke ibridi tramite BGP e le route di sottorete scambiate dagli spoke VPC collegati. Per informazioni sugli spoke ibridi, consulta Spoke ibridi.
  • Per Hybrid NAT, Private NAT utilizza le route dinamiche apprese da router Cloud tramite Cloud Interconnect o Cloud VPN.

Interazione con Accesso privato Google

Un gateway Public NAT non esegue mai il NAT per il traffico inviato agli indirizzi IP esterni selezionati per API e servizi Google. Al contrario, Google Cloud abilita automaticamente l'accesso privato Google per un intervallo di indirizzi IP di una subnet quando configuri un gateway Public NAT da applicare a quell'intervallo di subnet, principale o secondario. Finché il gateway fornisce NAT per l'intervallo di una subnet, l'accesso privato Google è attivo per quell'intervallo e non può essere disattivato manualmente.

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

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

Interazione con VPC condiviso

La VPC condivisa consente a più progetti di servizio di una singola organizzazione di utilizzare una rete VPC condiviso comune 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 con il peering di rete VPC

I gateway Cloud NAT sono associati ad intervalli di indirizzi IP delle 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 collegate tramite il peering di rete VPC, 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 NAT per i nodi e i pod in un cluster privato, che è un tipo di cluster nativo di VPC. Il gateway Public NAT deve essere configurato in modo da applicarsi ad almeno i seguenti intervalli di indirizzi IP della subnet per la subnet utilizzata dal cluster:

  • Intervallo di indirizzi IP principale della subnet (utilizzato dai nodi)
  • Intervallo di indirizzi IP secondario della subnet utilizzato per i pod nel cluster
  • Intervallo di indirizzi IP secondario 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 VPC utilizzano gli intervalli di indirizzi IP delle subnet, consulta Intervalli IP per i cluster nativi VPC.

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

I cluster nativi di VPC di Google Kubernetes Engine (GKE) assegnano sempre a ogni nodo un intervallo IP alias contenente più di un indirizzo IP (maschera di rete inferiore a /32).

  • Se è configurata l'allocazione statica delle porte, la procedura di prenotazione delle porte di NAT pubblico riserva almeno 1024 porte di origine per nodo. Se il valore specificato per il numero minimo di porte per VM è superiore a 1024, viene utilizzato questo valore.

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

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

Indipendentemente da NAT pubblico , Google Kubernetes Engine esegue la Network Address Translation (NAT di origine o SNAT) utilizzando il software in esecuzione su ogni nodo quando i pod inviano pacchetti a internet, a meno che tu non abbia modificato la configurazione della smorfia 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, NAT pubblico può essere utile anche per i cluster non privati basati su VPC. Poiché i nodi di 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 entrambe le seguenti condizioni sono vere, i pacchetti inviati dai pod di un cluster non privato possono essere elaborati da un gateway NAT pubblico :

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

  • La configurazione di IP masking del cluster non è configurata per eseguire SNAT all'interno del cluster per i pacchetti inviati dai pod a internet.

L'esempio seguente mostra l'interazione di Public NAT con GKE:

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

In questo esempio, vuoi che i container vengano tradotti tramite NAT. Per attivare NAT per tutti i contenitori 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 secondario della subnet utilizzato per i pod: 10.0.0.0/16

Non è possibile attivare il NAT solo per Pod1 o Pod2.

Un gateway Private NAT può eseguire NAT per nodi e pod in un cluster privato e in un cluster 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 con il traffico in uscita VPC diretto

I gateway Public NAT possono eseguire la NAT per i servizi Cloud Run o i job configurati con traffico in uscita VPC diretto. Per consentire a Cloud Run di utilizzare un gateway Public NAT , configura il gateway Public NAT con le seguenti impostazioni:

  • Per configurare le subnet e gli intervalli di indirizzi IP delle subnet associati alle tue istanze Cloud Run che possono utilizzare il gateway Public NAT , specifica il flag --nat-all-subnet-ip-ranges o --nat-custom-subnet-ip-ranges:
    • Per consentire a tutti gli intervalli di indirizzi IP di tutte le subnet della regione di utilizzare il gateway NAT pubblico , specifica il flag --nat-all-subnet-ip-ranges.
    • Per consentire solo a subnet e intervalli di indirizzi IP di subnet specifici di utilizzare il gateway Public NAT , specificali con il flag --nat-custom-subnet-ip-ranges.
  • Imposta il valore del flag --endpoint-types su ENDPOINT_TYPE_VM. Questo valore garantisce che solo le VM e gli endpoint VM di uscita VPC diretti possano utilizzare il gateway NAT pubblico .
  • In caso di allocazione delle porte statiche, imposta il valore del --min-ports-per-vm flag su quattro volte il numero di porte richieste da una singola istanza 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 Cloud Run di cui è stato eseguito il deployment nella rete VPC.

Oltre alla configurazione del gateway, per inviare traffico in uscita da un servizio o 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 un 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 è necessario un gateway NAT pubblico per instradare il traffico verso destinazioni interne.

Per impedire ai servizi o ai job Cloud Run per i quali il flag --vpc-egress è impostato su private-ranges-only di utilizzare un gateway Public NAT , procedi nel seguente modo:

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

Ai servizi e ai job Cloud Run che utilizzano gateway Public NAT si applicano le seguenti limitazioni:

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

Non puoi utilizzare i gateway Private NAT con endpoint VPC diretto in uscita.

Interazioni con Connectivity Tests

Puoi utilizzare Connectivity Tests per verificare la connettività tra gli endpoint di rete che utilizzano le configurazioni Cloud NAT. Puoi eseguire Connectivity Tests su reti che utilizzano gateway Public NAT o gateway Private NAT o entrambi.

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

Interazioni con Cloud Load Balancing

I bilanciatori del carico delle applicazioni interni regionali e i bilanciatori del carico delle applicazioni esterni regionali di Google Cloud comunicano con più backend di gruppi di endpoint di rete internet regionali (NEG). Configurando i gateway Cloud NAT per i NEG internet regionali, puoi allocare un tuo insieme di intervalli di indirizzi IP esterni da cui deve provenire il traffico di 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à di Google Cloud comunicano con le VM utilizzando percorsi di routing speciali. Le VM di backend non richiedono indirizzi IP esterni e un gateway Cloud NAT non 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à.

Passaggi successivi