Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Cloud de Confiance di S3NS. Per maggiori dettagli, consulta Differenze rispetto a Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Interazioni del prodotto Cloud NAT

Questa pagina descrive le interazioni importanti tra Cloud NAT e altri Cloud de Confiance by S3NS prodotti.

Interazioni con le route

Un gateway Cloud NAT può utilizzare solo le 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 delle route.

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

Se crei una route statica con hop successivi impostati su qualsiasi altro tipo di hop successivo di 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 software proxy, 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 dalle VM che si basano sulle VM di hop successivo o sulle VM di hop successivo stesse non può utilizzare i gateway Cloud NAT .
Se crei una route statica personalizzata il cui hop successivo è un tunnel Cloud VPN tunnel, Cloud NAT non utilizza questa route. Ad esempio, una route statica con destinazione 0.0.0.0/0 e un tunnel Cloud VPN di hop successivo indirizza il traffico a quel tunnel, non al gateway internet predefinito. Pertanto, Cloud NAT non possono utilizzare questa route. Allo stesso modo, i gateway Cloud NAT non possono utilizzare route statiche 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, Cloud NAT i gateway non possono utilizzare questa route. Ad esempio, se il router on-premise annuncia una route dinamica con destinazione 0.0.0.0/0, 0.0.0.0/0 verrà indirizzato al tunnel Cloud VPN o al collegamento VLAN. Questo comportamento è valido anche per destinazioni più specifiche, tra cui 0.0.0.0/1 e 128.0.0.0/1.

Interazioni con l'accesso privato Google

Un gateway Cloud NAT non esegue mai NAT per il traffico inviato agli indirizzi IP esterni selezionati per le API e i servizi di Google. Al contrario, Cloud de Confiance abilita automaticamente l'accesso privato Google per un intervallo di indirizzi IP di subnet quando configuri un Cloud NAT gateway 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 disabilitato manualmente.

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

Interazioni con il VPC condiviso

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 alle VM nei progetti di servizio che utilizzano una rete VPC condiviso, devi creare gateway Cloud NAT nel progetto host.

Interazioni con il 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 il peering di rete VPC, anche se le VM nelle reti con peering si trovano nella stessa regione del gateway.

Interazioni con 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 per essere applicato ad almeno i seguenti intervalli di indirizzi IP di 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 a un intero cluster privato è configurare un Cloud NAT gateway in modo che venga applicato a tutti gli intervalli di indirizzi IP di subnet della subnet del cluster.

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

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

I cluster nativi VPC di Google Kubernetes Engine (GKE) assegnano sempre a ogni nodo 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 Public NAT riserva almeno 1024 porte di origine per nodo. Se il valore specificato per le porte minime per VM è maggiore di 1024, viene utilizzato questo valore.
Se l'allocazione dinamica delle porte è configurata, 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 Cloud NAT , Google Kubernetes Engine esegue la Network Address Translation di origine (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 IP masquerade 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 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 sono vere entrambe le seguenti condizioni, i pacchetti inviati da pod in un cluster non privato possono essere elaborati da un gateway Cloud NAT :

Per i cluster nativi VPC, il Cloud NAT gateway è configurato per essere applicato all'intervallo di indirizzi IP secondario per i pod del cluster.
La configurazione di IP masquerade 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 Cloud NAT con GKE:

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

In questo esempio, vuoi che i tuoi container vengano convertiti 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 candidati NAT:

Intervallo di indirizzi IP principale 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 abilitare NAT solo per Pod1 o Pod2.

Interazioni con il traffico in uscita VPC diretto

I gateway Cloud NAT possono fornire NAT per le risorse Cloud Run configurate con il traffico in uscita VPC diretto. Per consentire a Cloud Run di utilizzare un gateway Cloud NAT per Public NAT o Private NAT, configura quanto segue:

Quando esegui il deployment delle risorse Cloud Run, imposta il --vpc-egress flag. Se vuoi utilizzare Public NAT, il valore deve essere impostato su all-traffic.
Configura il gateway Cloud NAT con le seguenti impostazioni:
- Specifica gli intervalli di subnet di origine che possono utilizzare il gateway impostando il flag --nat-custom-subnet-ip-ranges. Imposta il valore sui nomi delle subnet in cui esegui il deployment delle risorse Cloud Run.
- Imposta il valore del flag --endpoint-types su ENDPOINT_TYPE_VM.
- Per Public NAT, assicurati che il valore del flag --min-ports-per-vm sia impostato sul doppio del numero di porte necessarie per una singola istanza Cloud Run. Per Private NAT, questo flag deve essere impostato su quattro volte il numero di porte necessarie per istanza Cloud Run.
- Se vuoi configurare l'allocazione manuale degli indirizzi IP NAT (solo Public NAT), assegna al gateway un numero di indirizzi IP sufficiente a coprire la somma delle istanze VM e delle istanze Cloud Run gestite dal gateway.

I log di Cloud NAT per il traffico in uscita VPC diretto non mostrano i nomi delle risorse Cloud Run.

Interazioni con Connectivity Tests

Puoi utilizzare Connectivity Tests per verificare la connettività tra gli endpoint di rete che utilizzano le configurazioni di Cloud NAT.

Puoi eseguire i Connectivity Tests sulle reti che utilizzano Cloud NAT gateway.

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

Cloud de Confiance I bilanciatori del carico delle applicazioni interni regionali e i bilanciatori del carico delle applicazioni esterni regionali 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 il tuo set di intervalli di indirizzi IP esterni da cui deve provenire il Cloud de Confiance traffico. I controlli di integrità e il traffico del piano dati provengono dagli indirizzi IP NAT che allochi.

Altri Cloud de Confiance bilanciatori del carico esterni e sistemi di controllo di integrità 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à.

Interazioni con le connessioni propagate di Private Service Connect

Quando utilizzi sia Private NAT per NCC sia le connessioni propagate di Private Service Connect nello stesso spoke VPC, si applica quanto segue:

Se una subnet è configurata con Private NAT, il traffico dalla subnet alle connessioni propagate di Private Service Connect viene eliminato.
Per evitare di eliminare il traffico da subnet non sovrapposte, tieni presente quanto segue quando configuri Private NAT:
- Specifica le subnet sovrapposte utilizzando il flag --nat-custom-subnet-ip-ranges.
- Non specificare le subnet non sovrapposte che devono accedere alle connessioni propagate.
- Non utilizzare il flag --nat-all-subnet-ip-ranges.

Interazioni con Hybrid Subnets

Hybrid NAT non è supportato con Hybrid Subnets.

Se il traffico proviene da una subnet in cui è configurato Hybrid NAT e l'indirizzo IP di destinazione corrisponde a una route di subnet ibrida, SNAT non viene eseguito. Questa configurazione comporta un comportamento di routing imprevedibile perché il traffico può raggiungere una rete non VPC utilizzando l'indirizzo IP di origine originale e non convertito.

Non utilizzare Hybrid Subnets nelle reti in cui è configurato Hybrid NAT.