Interazioni con i prodotti Cloud NAT

In questa pagina vengono descritte le importanti interazioni tra Cloud NAT e altri prodotti Google Cloud.

Interazioni con Routes

R NAT pubblico il gateway può usare solo le route i cui hop successivi sono gateway internet predefinito. Ogni rete Virtual Private Cloud (VPC) viene avviata con un route la cui 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 personalizzata con gli hop successivi impostati su qualsiasi altro tipo di hop successivo della route statica personalizzata, quindi i pacchetti con indirizzi IP di destinazione corrispondenti a quella 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 proxy puoi creare route statiche personalizzate per indirizzare il traffico a queste VM come nell'hop successivo. Le VM dell'hop successivo richiedono indirizzi IP esterni. Pertanto, Traffico proveniente dalle VM che si basano sulle VM dell'hop successivo o delle VM dell'hop successivo non possono utilizzare NAT pubblico gateway VPN ad alta disponibilità.

  • Se crei una route statica personalizzata il cui hop successivo è Cloud VPN tunnel, NAT pubblico non utilizza questo percorso. Ad esempio, un route statica con destinazione 0.0.0.0/0 e Cloud VPN dell'hop successivo indirizza il traffico a quel tunnel, non al gateway internet predefinito. Pertanto, NAT pubblico gateway non può utilizzarlo percorso. Analogamente, NAT pubblico per i gateway non possono utilizzare percorsi 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 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 personalizzata 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 Inter-VPC NAT, Private NAT utilizza solo la subnet di routing scambiate da due spoke VPC di Network Connectivity Center collegato a un hub di Network Connectivity Center. Per ulteriori informazioni su Network Connectivity Center Vedi Panoramica degli spoke VPC sugli spoke VPC.
  • Per il NAT ibrido (anteprima), il NAT privato utilizza le route dinamiche apprese dal router Cloud tramite Cloud VPN.

Interazione di accesso privato Google

R NAT pubblico il gateway non esegue mai la traduzione NAT per il traffico inviato indirizzi IP esterni per le API di Google e Google Cloud. 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.

R NAT pubblico gateway non cambia il modo L'accesso privato Google funziona. Per ulteriori informazioni, vedi 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 a intervalli di indirizzi IP della 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 tramite Peering di rete VPC o utilizzando spoke VPC di Network Connectivity Center, anche se le VM nelle reti in peering si trovano nella stessa regione del gateway.

Interazione GKE

R NAT pubblico un gateway può eseguire NAT per nodi e pod in cluster privato, che è un tipo di cluster nativo di VPC. La NAT pubblico gateway deve essere configurato affinché si applichi 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 a NAT pubblico il gateway affinché si applichi 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 NAT pubblico gateway è configurato in modo da fornire NAT per una prenota gli indirizzi IP e le porte di origine NAT per ogni VM nodo. Gli indirizzi IP e le porte di origine NAT sono utilizzabili dai pod perché sono implementati come intervalli IP alias assegnati a ciascuna VM del nodo.

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

  • Se l'allocazione statica delle porte è configurato, il Public NAT procedura di prenotazione delle porte prenota 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 per i cluster nativi di VPC, Intervallo di indirizzi IP secondari 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 granulare sul traffico in uscita dai pod, puoi utilizzare una .

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 nativi di VPC, NAT pubblico il gateway è configurato in modo da 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 nel 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 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 non privato. La Il gateway Private NAT applica automaticamente a tutti gli intervalli di indirizzi IP della subnet privata utilizzata dal cluster.

Interazioni dirette in uscita VPC

NAT pubblico i gateway possono eseguire NAT per i servizi Cloud Run o job configurati Traffico VPC diretto in uscita. 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 specifiche e a intervalli di indirizzi IP di subnet, utilizza il NAT pubblico , specificali con 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 NAT pubblico gateway VPN ad alta disponibilità.
  • In caso di allocazione statica delle porte, imposta il valore dell'attributo --min-ports-per-vm un flag a quattro volte il numero di porte richieste da una singola di Cloud Run.
  • Nel caso dell'allocazione manuale degli indirizzi IP NAT, assegna un numero appropriato di gli indirizzi IP al tuo NAT pubblico gateway per tenere conto la somma del numero di istanze Google Cloud e del numero le istanze Cloud Run di cui viene eseguito il deployment 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 che il flag --vpc-egress impostato su private-ranges-only, il servizio o il job invia solo verso indirizzi IP interni. Non è necessaria NAT pubblico per instradare il traffico verso destinazioni interne.

Per impedire servizi o job Cloud Run che il flag --vpc-egress è impostato su private-ranges-only dall'utilizzo di un oggetto NAT pubblico Gateway, 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 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 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 gateway Private NAT con VPC diretto in uscita endpoint.

Interazioni con Connectivity Tests

Puoi utilizzare Connectivity Tests per verificare la connettività tra la rete che utilizzano configurazioni Cloud NAT. Puoi eseguire Connectivity Tests sulle reti che utilizzano gateway Public NAT e/o gateway NAT privato.

Visualizza i dettagli della configurazione NAT in Traccia di analisi della configurazione riquadro nella pagina Dettagli test connettività.

Interazioni con Cloud Load Balancing

Bilanciatori del carico delle applicazioni interni regionali Google Cloud e bilanciatori del carico delle applicazioni esterni regionali comunicare con più backend di gruppi di endpoint di rete internet (NEG) a livello di regione. Configurando i gateway Cloud NAT NEG internet a livello di regione, puoi allocare il tuo set di intervalli di indirizzi IP esterni da dove ha origine il traffico di Google Cloud. I controlli di integrità il traffico del piano dati proviene dagli indirizzi IP NAT allocati.

Altri bilanciatori del carico esterni e sistemi di controllo di integrità di Google Cloud comunicano con le VM usando route speciali. VM di backend non richiedono indirizzi IP esterni né un gateway Cloud NAT gestisce comunicazione per bilanciatori del carico e controlli di integrità. Per ulteriori informazioni, vedi Panoramica di Cloud Load Balancing e Panoramica dei controlli di integrità.

Passaggi successivi