Interazioni con i prodotti Cloud NAT

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

Interazioni con Routes

Un NAT pubblico può utilizzare solo 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 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. Di conseguenza, i gateway Public NAT non possono utilizzare questa route. Analogamente, 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, NAT pubblico gateway non può 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 NAT pubblico non esegue mai la traduzione NAT per il traffico inviato agli indirizzi IP esterni selezionati per le API e i servizi Google. Google Cloud abilita automaticamente l'accesso privato Google per un intervallo di indirizzi IP di subnet quando configuri un gateway Public NAT 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 NAT pubblico Il gateway non cambia 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 NAT pubblico 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 almeno ai seguenti intervalli di indirizzi IP 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 NAT pubblico 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 in modo da fornire NAT per un cluster privato, prenota 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 da Public NAT , Google Kubernetes Engine esegue la traduzione degli indirizzi di rete di origine (NAT o SNAT di origine) 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, 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 entrambe le condizioni seguenti sono vere, i pacchetti inviati dai pod in un cluster non privato possono essere elaborati da un NAT pubblico gateway:

  • Per i cluster VPC nativi, il gateway Public NAT è configurato per applicarsi all'intervallo di indirizzi IP secondari per i pod del cluster.

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

L'esempio seguente mostra l'interazione di Public NAT 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 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

NAT pubblico I gateway possono eseguire NAT per i servizi o i job Cloud Run configurati con il traffico VPC diretto in uscita. Per abilitare Cloud Run per l'utilizzo di un NAT pubblico gateway, configura il tuo 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 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 tuo Public NAT 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 tua 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 NAT pubblico per instradare il traffico verso 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 Public NAT procedi come segue:

  • 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.

Visualizza 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