Interazioni con i prodotti Cloud NAT

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

Interazioni con Routes

Un gateway Public NAT può utilizzare solo le 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 di base importanti, consulta la panoramica dei percorsi.

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

  • Se crei una route statica personalizzata con gli hop successivi impostati su qualsiasi altro tipo di hop successivo della 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 queste VM come hop successivo. Le VM dell'hop successivo richiedono indirizzi IP esterni. Di conseguenza, il traffico proveniente dalle VM che si basano sulle VM dell'hop successivo o sulle VM dell'hop successivo non può utilizzare i gateway di Public NAT.

  • Se crei una route statica personalizzata il cui hop successivo è un tunnel Cloud VPN, Public NAT non utilizza questa route. Ad esempio, una route statica personalizzata con destinazione 0.0.0.0/0 e un tunnel Cloud VPN dell'hop successivo indirizza il traffico a quel tunnel e non al gateway internet predefinito. Pertanto, i gateway Public NAT non possono utilizzare questa route. Allo stesso modo, i gateway Public NAT 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 pubblici 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 viene indirizzato al tunnel Cloud VPN o al collegamento VLAN. Questo comportamento vale anche per le destinazioni più specifiche, tra cui 0.0.0.0/1 e 128.0.0.0/1.

Private NAT utilizza le seguenti route:

  • Per Inter-VPC NAT, Private NAT utilizza solo le route subnet scambiate da due spoke VPC di Network Connectivity Center collegati a un hub di Network Connectivity Center. Per ulteriori informazioni sugli spoke VPC di Network Connectivity Center, vedi Panoramica degli spoke VPC.
  • Per il NAT ibrido (anteprima), il NAT privato utilizza le route dinamiche apprese dal router Cloud su Cloud VPN.

Interazione di accesso privato Google

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

Un gateway Public NAT non modifica il funzionamento dell'accesso privato Google. Per maggiori informazioni, vedi Accesso privato Google.

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

Interazione VPC condiviso

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

Interazione con peering di rete VPC

I gateway Cloud NAT sono associati a intervalli di indirizzi IP della 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 il peering di rete VPC o tramite gli spoke VPC di Network Connectivity Center, anche se le VM nelle reti in peering si trovano nella stessa regione del gateway.

Interazione GKE

Un gateway Public NAT può eseguire NAT per nodi e pod in un cluster privato, che è un tipo di cluster nativo di VPC. Il gateway Public NAT deve essere configurato in modo da essere applicato almeno ai seguenti intervalli di indirizzi IP di subnet 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 Public 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 Intervalli IP per i cluster nativi di VPC.

Quando un gateway Public NAT è configurato per fornire NAT per un cluster privato, riserva gli indirizzi IP e le porte di origine NAT per ogni VM nodo. Le porte e gli indirizzi IP di origine NAT possono essere utilizzati dai pod perché gli indirizzi IP dei pod sono implementati come intervalli IP alias assegnati a ciascuna VM 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 l'allocazione statica delle porte è configurata, 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 quel valore.

  • Se è configurata l'allocazione dinamica delle porte, il valore specificato per il numero minimo di porte per VM viene allocato inizialmente per nodo. Il numero di porte allocate successivamente varia tra i valori specificati per il numero minimo e il numero massimo di porte 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 secondari della 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 i pacchetti a internet, a meno che tu non abbia modificato 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, Public NAT può essere utile anche per i cluster non privati VPC nativi. 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 Public NAT, procedi nel seguente modo:

  • Configura il gateway Public NAT 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 il tuo agente di mascheramento IP specificando i CIDR appropriati come destinazioni non di mascheramento, in modo che l'agente conservi gli indirizzi IP per gli oggetti pod di origine dei pacchetti inviati alle destinazioni non di mascheramento.

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

NAT pubblico con GKE.
Public 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 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 Private NAT può eseguire NAT per nodi e pod in un cluster privato e in un cluster non privato. Il gateway Private NAT si applica automaticamente a tutti gli intervalli di indirizzi IP della subnet per la subnet privata utilizzata dal cluster.

Interazioni dirette in uscita VPC

I gateway NAT pubblici possono eseguire NAT per i servizi o i job Cloud Run configurati con il traffico VPC diretto in uscita. 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 della 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 nella regione di utilizzare il gateway Public NAT, specifica il flag --nat-all-subnet-ip-ranges.
    • Per consentire solo a subnet e intervalli di indirizzi IP 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 in uscita del VPC diretto possano utilizzare il gateway Public NAT.
  • In caso di allocazione statica delle porte, imposta il valore del flag --min-ports-per-vm su 4 volte il numero di porte richieste da una singola istanza Cloud Run.
  • In caso di allocazione manuale di indirizzi IP NAT, assegna un numero appropriato di indirizzi IP al gateway Public NAT per tenere conto della somma del numero di istanze Google Cloud e del numero di istanze Cloud Run di cui viene eseguito il deployment nella rete VPC.

Oltre alla configurazione del gateway, per inviare 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 un job Cloud Run con il flag --vpc-egress impostato su private-ranges-only, il servizio o il job invia traffico solo agli indirizzi IP interni. Non hai bisogno di un gateway Public NAT per instradare il traffico a 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 Public NAT 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 i gateway Public NAT:

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

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

Interazioni con Connectivity Tests

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

Puoi visualizzare i dettagli della configurazione NAT nel riquadro Traccia analisi della configurazione nella pagina Dettagli test 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 (NEG) internet regionali. Configurando i gateway Cloud NAT per i NEG internet a livello di regione, puoi allocare il tuo set di intervalli di indirizzi IP esterni da cui deve avere origine il traffico Google Cloud. I controlli di integrità e il traffico del piano dati provengono dagli indirizzi IP NAT allocati.

Altri bilanciatori del carico e sistemi di controllo di integrità esterni di Google Cloud comunicano con le VM mediante route speciali. Le VM di backend non richiedono indirizzi IP esterni né un gateway Cloud NAT gestisce le comunicazioni 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