Interazioni del prodotto Cloud NAT

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

Interazioni con i percorsi

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 delle route.

I seguenti esempi illustrano situazioni che potrebbero causare NAT pubblico gateway che diventano inutilizzabili:

  • Se crei una route statica con 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 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 delle VM che si basano sulle VM di hop successivo o delle 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 utilizza questa route. Ad esempio, una route statica con destinazione 0.0.0.0/0 e un tunnel Cloud VPN come hop successivo indirizza il traffico a quel tunnel, 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 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 gatewayNAT pubbliconon 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 verrà 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 gli spoke di Network Connectivity Center, Private NAT utilizza le route di subnet e le route dinamiche:
    • Per il traffico tra due spoke VPC collegati a un hub NCC che contiene solo spoke VPC, Private NAT utilizza le route di subnet scambiate dagli spoke VPC collegati. Per informazioni sugli spoke VPC, consulta Panoramica degli spoke VPC.
    • Se un hub NCC contiene sia spoke VPC sia spoke ibridi, come collegamenti VLAN per Cloud Interconnect, tunnel Cloud VPN o VM appliance router, Private NAT utilizza le route dinamiche apprese dagli spoke ibridi tramite BGP e le route subnet scambiate dagli spoke VPC collegati. Per informazioni sugli spoke ibridi, vedi Spoke ibridi.
  • Per NAT ibrido, NAT privato utilizza le route dinamiche apprese dal router Cloud tramite Cloud Interconnect o Cloud VPN.

Interazioni con l'accesso privato Google

Un gateway NAT pubblico non esegue mai NAT per il traffico inviato agli indirizzi IP esterni selezionati per i servizi e le API di Google. Al contrario, 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, principale o secondario. Finché il gateway fornisce NAT per un intervallo di subnet, l'accesso privato Google è attivo per quell'intervallo e non può essere disattivato manualmente.

Un gateway NAT pubblico non modifica il funzionamento dell'accesso privato Google. Per saperne di più, consulta Accesso privato Google.

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

Interazioni VPC condiviso

VPC condivisa consente a più progetti di servizio in una singola organizzazione di utilizzare una reteVPC condivisoa 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.

Interazioni del 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 in peering si trovano nella stessa regione del gateway.

Interazioni 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 per essere applicato ad almeno i 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 gatewayNAT pubblicoda applicare a tutti gli intervalli di indirizzi IP della subnet del cluster.

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

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

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

  • Se è configurata l'allocazione statica delle porte, la procedura di prenotazione delle porte di Public NAT 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 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 VPC nativi, vedi Intervallo di indirizzi IP secondari della subnet per i pod.

Indipendentemente da NAT pubblico , Google Kubernetes Engine esegue la conversione dell'indirizzo di rete di origine (source NAT 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 di 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, NAT pubblico può essere utile anche per i cluster VPC nativi 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 dai pod in un cluster non privato possono essere elaborati da un gateway NAT pubblico :

  • Per i cluster VPC nativi, il gateway Public NAT è configurato per essere applicato all'intervallo di indirizzi IP secondari 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 Public NAT con GKE:

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

In questo esempio, vuoi che i tuoi container vengano tradotti 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 attivare 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 viene applicato automaticamente a tutti gli intervalli di indirizzi IP della subnet per la subnet privata utilizzata dal cluster.

Interazioni VPC diretto in uscita

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

  • Quando esegui il deployment delle risorse Cloud Run, imposta il flag --vpc-egress. Se vuoi utilizzare Public NAT, il valore deve essere impostato su all-traffic.

  • Configura il gateway Cloud NAT con le seguenti impostazioni:

    • Specifica quali intervalli di subnet di origine possono utilizzare il gateway impostando il flag --nat-custom-subnet-ip-ranges. Imposta il valore sui nomi delle subnet in cui vengono implementate le risorse Cloud Run.
    • Imposta il valore del flag --endpoint-types su ENDPOINT_TYPE_VM.

    • Per NAT pubblico, assicurati che il valore del flag --min-ports-per-vm sia impostato sul doppio del numero di porte necessarie a una singola istanza Cloud Run. Per NAT privato, questo flag deve essere impostato su un valore pari a quattro volte il numero di porte necessarie per istanza Cloud Run.

    • Se vuoi configurare l'allocazione manuale degli indirizzi IP NAT (solo NAT pubblico), 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 di 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 di Cloud Load Balancing

IGoogle Cloud 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 (NEG) internet regionali. Configurando i gateway Cloud NAT per i NEG internet regionali, puoi allocare il tuo insieme di intervalli di indirizzi IP esterni da cui deve provenire il traffico Google Cloud . I controlli di integrità e il traffico del data plane provengono dagli indirizzi IP NAT che allochi.

Altri Google Cloud 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 saperne di più, consulta la panoramica di Cloud Load Balancing e la panoramica dei controlli di integrità.

Interazioni delle 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 NAT privato, il traffico dalla subnet alle connessioni propagate di Private Service Connect viene eliminato.

  • Per evitare l'eliminazione del traffico da subnet non sovrapposte, tieni presente quanto segue quando configuri NAT privato:

    • Specifica le subnet sovrapposte utilizzando il flag --nat-custom-subnet-ip-ranges.
    • Non specificare subnet non sovrapposte che devono accedere alle connessioni propagate.
    • Non utilizzare il flag --nat-all-subnet-ip-ranges.

Passaggi successivi