Interazioni con i prodotti Cloud NAT

In questa pagina vengono descritte le importanti interazioni 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 un route con destinazione 0.0.0.0/0 e il cui hop successivo è il valore predefinito un gateway internet standard. Per informazioni di base importanti, consulta panoramica dei percorsi.

I seguenti esempi illustrano situazioni che potrebbero causare NAT pubblico a rendere inutilizzabili i gateway:

  • 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 gateway NAT, un firewall o un proxy creare route statiche per indirizzare il traffico a queste VM nell'hop successivo. Le VM dell'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 è Cloud VPN tunnel, NAT pubblico non utilizza questo percorso. 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 pubblicizza una route dinamica a un Un router Cloud che gestisce un tunnel Cloud VPN collegamento VLAN, NAT pubblico non possono utilizzare questa route. Ad esempio, se il router on-premise pubblicizza una route dinamica con destinazione 0.0.0.0/0, 0.0.0.0/0 viene indirizzato al tunnel Cloud VPN o un 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 le 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 un hub Network Connectivity Center contenente solo spoke VPC, Private NAT utilizza le route di subnet scambiati dagli spoke VPC collegati. Per informazioni sugli spoke VPC, consulta Panoramica degli spoke VPC.
    • Se un hub di Network Connectivity Center contiene sia spoke VPC sia spoke ibridi come i collegamenti VLAN per Cloud Interconnect, i tunnel VPN Cloud o le VM dell'appliance router, il NAT privato utilizza le route dinamiche apprese dagli spoke ibridi tramite BGP (anteprima) 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 Cloud Router tramite Cloud Interconnect o Cloud VPN.

Interazione di accesso privato Google

Un gateway NAT pubblico non esegue mai il NAT per il traffico inviato agli indirizzi IP esterni selezionati per API e servizi Google. Invece, Google Cloud abilita automaticamente l'accesso privato Google per un intervallo di indirizzi IP di subnet, NAT pubblico gateway principale, da applicare a quell'intervallo di subnet, sia primario che secondaria. Finché il gateway fornisce NAT per l'intervallo di una subnet, L'accesso privato Google è attivo per quell'intervallo e non può essere disattivata manualmente.

Un gateway NAT pubblico 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 VPC condiviso

Un VPC condiviso abilita più progetti di servizio per usare 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 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. R Il gateway Cloud NAT creato in una rete VPC non può il servizio NAT alle VM in altre reti VPC connesse utilizzando il peering di rete VPC, anche se le VM nelle reti in peering si trovano nella stessa regione del gateway.

Interazione con GKE

R NAT pubblico un gateway 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 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 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 a NAT pubblico il gateway deve essere applicato 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 della subnet, vedi Intervalli IP per VPC nativo cluster.

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 di porte statiche, 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 è maggiore di 1024, viene utilizzato questo valore.

  • Se l'allocazione dinamica delle porte è configurato, il valore specificato per il numero minimo di porte per VM è inizialmente allocati 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 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.

Indipendente da NAT pubblico , Google Kubernetes Engine esegue la rete di origine traduzione indirizzi (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 il mascheramento IP del cluster configurazione automatica. 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 ai VPC nativi di VPC. Poiché i nodi in un cluster non privato hanno indirizzi IP esterni, e i pacchetti inviati dall'indirizzo IP interno primario del nodo non vengono mai elaborati Cloud NAT. Tuttavia, se entrambe le seguenti condizioni sono vere, i pacchetti inviati I pod in un cluster non privato possono essere elaborati NAT pubblico gateway:

  • 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 NAT pubblico con GKE:

NAT pubblico con GKE.
NAT pubblico 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 tutte le 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 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 VPC

I gateway Public NAT possono eseguire la NAT per i servizi Cloud Run o i job configurati con il traffico in uscita VPC diretto. Per abilitare Cloud Run all'utilizzo di un oggetto NAT pubblico Gateway, configura la tua NAT pubblico con i seguenti impostazioni:

  • Per configurare le subnet e gli intervalli di indirizzi IP associati al tuo Le istanze Cloud Run possono utilizzare NAT pubblico gateway, 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 NAT pubblico Gateway, specifica il --nat-all-subnet-ip-ranges flag.
    • 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 il traffico in uscita da un ambiente Cloud Run devi impostare il flag --vpc-egress su all-traffic quando crea 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 è necessaria 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 NAT pubblico gateway 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.

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

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

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

Interazioni con Connectivity Tests

Puoi utilizzare i test di connettività per verificare la connettività tra gli endpoint di rete che utilizzano le configurazioni Cloud NAT. Puoi eseguire i test di connettività 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