Interazioni del prodotto Cloud NAT

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

Interazioni con i percorsi

Un gatewayCloud NATpuò 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 Cloud NAT 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 Cloud NAT .

  • Se crei una route statica personalizzata il cui hop successivo è un tunnel Cloud VPN, Cloud NAT 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 Cloud NAT non possono utilizzare questa route. Analogamente, i gateway Cloud 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 annuncia una route dinamica a un router Cloud che gestisce un tunnel Cloud VPN o un collegamento VLAN, i gatewayCloud NATnon 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.

Interazioni con l'accesso privato Google

Un gatewayCloud NATnon esegue mai NAT per il traffico inviato agli indirizzi IP esterni selezionati per i servizi e le API di Google. Al contrario, Cloud de Confiance abilita automaticamente l'accesso privato Google per un intervallo di indirizzi IP di subnet quando configuri un gateway Cloud NAT 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 Cloud NAT non modifica il funzionamento dell'accesso privato Google. Per saperne di più, consulta 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 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 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 gatewayCloud NATda 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 Cloud 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 Cloud NAT , 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 del 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, Cloud NAT 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 Cloud NAT :

  • Per i cluster VPC nativi, il gateway Cloud 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 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 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.

Interazioni VPC diretto in uscita

I gateway Cloud NAT possono fornire NAT per le risorse Cloud Run configurate con 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 flag --vpc-egress. Se vuoi utilizzare NAT pubblico, 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 Public NAT, 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 Private NAT, 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 i Connectivity Tests sulle reti che utilizzano i gateway Cloud NAT .

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

ICloud de Confiance 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 Cloud de Confiance . I controlli di integrità e il traffico del data plane provengono dagli indirizzi IP NAT che allochi.

Altri bilanciatori del carico esterni e sistemi di controllo di integrità comunicano con le VM utilizzando percorsi di routing speciali. Cloud de Confiance 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 Private NAT, 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.

Interazioni di Hybrid Subnets

Hybrid NAT non è supportato con Hybrid Subnets.

Se il traffico ha origine da una subnet in cui è configurato NAT ibrido 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 tradotto.

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

Passaggi successivi