NAT privato

Il NAT privato consente traduzioni da private a privato sulle reti Google Cloud. NAT tra VPC, un'offerta NAT privato, consente di creare un gateway NAT privato che funzioni insieme agli spoke Virtual Private Cloud (VPC) di Network Connectivity Center per eseguire Network Address Translation (NAT) tra le reti VPC.

Configurazione e flusso di lavoro di NAT privato di base

Il seguente diagramma mostra una configurazione NAT Inter-VPC di base:

Esempio di traduzione NAT tra VPC.
Esempio di traduzione NAT tra VPC (fai clic per ingrandire).

In questo esempio, il NAT tra VPC è configurato come segue:

  • Il gateway pvt-nat-gw è configurato in vpc-a per essere applicato a tutti gli intervalli di indirizzi IP di subnet-a nella regione us-east1. Utilizzando gli intervalli IP NAT di pvt-nat-gw, un'istanza di macchina virtuale (VM) in subnet-a di vpc-a può inviare il traffico a una VM in subnet-b di vpc-b, anche se subnet-a di vpc-a si sovrappone a subnet-c di vpc-b.
  • Sia vpc-a che vpc-b sono configurati come spoke di un hub di Network Connectivity Center.
  • Il gateway pvt-nat-gw è configurato per fornire NAT tra reti VPC configurate come spoke VPC allo stesso hub di Network Connectivity Center.

Flusso di lavoro per NAT privato di esempio

Nel diagramma precedente, una VM vm-a con indirizzo IP interno 192.168.1.2 in subnet-a di vpc-a deve scaricare un aggiornamento da vm-b con l'indirizzo IP interno 192.168.2.2 in subnet-b di vpc-b. Entrambe le reti VPC sono connesse allo stesso hub Network Connectivity Center degli spoke VPC. Supponiamo che vpc-b contenga un'altra subnet 192.168.1.0/24 che si sovrapponga alla subnet in vpc-a. Affinché subnet-a di vpc-a comunichi con subnet-b di vpc-b, devi configurare un gateway NAT privato, pvt-nat-gw, in vpc-a nel seguente modo:

  • Subnet NAT privata: 10.1.2.0/29. Crea questa subnet con lo scopo PRIVATE_NAT prima di configurare il gateway NAT privato. Assicurati che questa subnet non si sovrapponga a una subnet esistente in nessuno degli spoke VPC collegati allo stesso hub di Network Connectivity Center.
  • Una regola NAT il cui nexthop.hub corrisponde all'URL dell'hub di Network Connectivity Center.
  • NAT per tutti gli intervalli di indirizzi di subnet-a.

La tabella seguente riassume la configurazione di rete specificata nell'esempio precedente:

Nome rete Componente di rete Indirizzo/intervallo IP Regione
VPC-A

subnet-a 192.168.1.0/24 us-east1
VM-A 192.168.1.2
pvt-nat-gw 10.1.2.0/29
Vpc-B

subnet-b 192.168.2.0/24 us-west1
VM-B 192.168.2.2
subnet-c 192.168.1.0/24
VM-C 192.168.1.3

Il NAT privato segue la procedura di prenotazione delle porte per prenotare i seguenti indirizzi IP di origine NAT e tuple di porte di origine per ciascuna delle VM nella rete. Ad esempio, il gateway NAT privato prenota 64 porte di origine per vm-a: da 10.1.2.2:34000 a 10.1.2.2:34063.

Quando la VM utilizza il protocollo TCP per inviare un pacchetto al server di aggiornamento 192.168.2.2 sulla porta di destinazione 80, si verifica quanto segue:

  • La VM invia un pacchetto di richiesta con i seguenti attributi:

    • Indirizzo IP di origine: 192.168.1.2, l'indirizzo IP interno della VM
    • Porta di origine: 24000, la porta di origine temporanea scelta dal sistema operativo della VM
    • Indirizzo di destinazione: 192.168.2.2, l'indirizzo IP del server di aggiornamento
    • Porta di destinazione: 80, la porta di destinazione per il traffico HTTP verso il server di aggiornamento
    • Protocollo: TCP
  • Il gateway pvt-nat-gw esegue Network Address Translation di origine (SNAT o NAT di origine) in uscita, riscrivendo l'indirizzo IP di origine e la porta di origine del pacchetto della richiesta:

    • Indirizzo IP di origine NAT: 10.1.2.2, da uno degli indirizzi IP riservati dell'origine NAT della VM e dalle tuple della porta di origine
    • Porta di origine: 34022, una porta di origine inutilizzata da una delle tuple di porte di origine riservate della VM
    • Indirizzo di destinazione: 192.168.2.2, invariato
    • Porta di destinazione: 80, non modificata
    • Protocollo: TCP, invariato
  • Quando il server di aggiornamento invia un pacchetto di risposta, questo arriva al gateway pvt-nat-gw con i seguenti attributi:

    • Indirizzo IP di origine: 192.168.2.2, l'indirizzo IP interno del server di aggiornamento
    • Porta di origine: 80, la risposta HTTP del server di aggiornamento
    • Indirizzo di destinazione: 10.1.2.2, corrispondente all'indirizzo IP di origine NAT originale del pacchetto di richiesta
    • Porta di destinazione: 34022, corrispondente alla porta di origine del pacchetto di richiesta
    • Protocollo: TCP, invariato
  • Il gateway pvt-nat-gw esegue il DNAT (Network Address Translation) sul pacchetto di risposta, riscrivendo l'indirizzo e la porta di destinazione del pacchetto di risposta in modo che il pacchetto venga consegnato alla VM che ha richiesto l'aggiornamento con i seguenti attributi:

    • Indirizzo IP di origine: 192.168.2.2, invariato
    • Porta di origine: 80, non modificata
    • Indirizzo di destinazione: 192.168.1.2, l'indirizzo IP interno della VM
    • Porta di destinazione: 24000, corrispondente alla porta di origine temporanea originale del pacchetto di richiesta
    • Protocollo: TCP, invariato

Specifiche

Specifiche generali

  • Il NAT tra VPC consente alle risorse di rete VPC nelle subnet sovrapposte di comunicare con le risorse in subnet non sovrapposte utilizzando una configurazione NAT type=PRIVATE.
  • Per abilitare il NAT inter-VPC tra due reti VPC, configura ciascuna rete VPC come spoke VPC di un hub di Network Connectivity Center. Quando crei lo spoke, devi evitare che gli intervalli di indirizzi IP sovrapposti vengano condivisi con altri spoke VPC. Per ulteriori informazioni, consulta Creare uno spoke VPC.
  • Devi creare una regola NAT personalizzata facendo riferimento a un hub di Network Connectivity Center. La regola NAT specifica un intervallo di indirizzi IP NAT da una subnet di scopo PRIVATE_NAT che le VM possono utilizzare per comunicare con un'altra rete VPC.
  • Il NAT tra VPC supporta la traduzione degli indirizzi per le subnet VPC all'interno di una regione e tra regioni.
  • Il NAT privato consente le connessioni in uscita e le risposte in entrata verso queste connessioni. Ogni gateway NAT privato esegue il NAT di origine sul traffico in uscita e il NAT di destinazione per i pacchetti di risposta stabiliti.

  • La NAT privata non consente richieste in entrata non richieste da spoke VPC peer, anche se le regole firewall consentirebbero tali richieste. Per ulteriori informazioni, vedi RFC applicabili.

  • Ogni gateway NAT privato è associato a una singola rete VPC, regione e a un singolo router Cloud. Il gateway NAT privato e il router Cloud forniscono un piano di controllo, non sono coinvolti nel piano dati, quindi i pacchetti non passano attraverso il gateway NAT privato o il router Cloud.

Route e regole firewall

Il NAT privato si basa solo sulle route di 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, consulta Panoramica degli spoke VPC.

La NAT privata non ha requisiti per le regole firewall di Cloud. Le regole firewall vengono applicate direttamente alle interfacce di rete delle VM di Compute Engine, non ai gateway NAT privati.

Non devi creare regole firewall speciali che consentano le connessioni da o verso gli indirizzi IP NAT. Quando un gateway NAT privato fornisce NAT per l'interfaccia di rete di una VM, le regole firewall in uscita applicabili vengono valutate come pacchetti per l'interfaccia di rete specifica prima di NAT. Le regole firewall in entrata vengono valutate dopo che i pacchetti sono stati elaborati da NAT.

Applicabilità dell'intervallo di indirizzi IP della subnet

Puoi configurare un gateway NAT privato per fornire NAT per:

  • Intervalli di indirizzi IP principali e secondari di tutte le subnet nella regione. Un singolo gateway NAT privato fornisce NAT per gli indirizzi IP interni principali e tutti gli intervalli IP alias delle VM idonee le cui interfacce di rete utilizzano una subnet nella regione. Questa opzione utilizza esattamente un gateway NAT per regione.
  • Elenco di subnet personalizzate. Un singolo gateway NAT privato fornisce NAT per gli indirizzi IP interni principali e tutti gli intervalli IP alias delle VM idonee le cui interfacce di rete utilizzano una subnet da un elenco di subnet specificate.

Larghezza di banda

L'utilizzo di un gateway NAT privato non modifica la quantità di larghezza di banda in uscita o in entrata che una VM può utilizzare. Per le specifiche relative alla larghezza di banda, che variano in base al tipo di macchina, consulta Larghezza di banda di rete nella documentazione di Compute Engine.

VM con più interfacce di rete

Se configuri una VM in modo che abbia più interfacce di rete, ogni interfaccia deve trovarsi in una rete VPC separata. Di conseguenza, un gateway NAT privato può essere applicato a una sola interfaccia di rete di una VM. Gateway NAT privati separati possono fornire NAT alla stessa VM, dove ogni gateway si applica a un'interfaccia separata.

Indirizzi IP e porte NAT

Quando crei un gateway NAT privato, devi specificare una subnet di scopo PRIVATE_NAT da cui vengono assegnati gli indirizzi IP NAT per le VM. Per ulteriori informazioni sull'assegnazione degli indirizzi IP NAT privati, consulta Indirizzi IP NAT privati.

Puoi configurare il numero di porte di origine che ogni gateway NAT privato prenota su ogni VM per la quale deve fornire i servizi NAT. Puoi configurare l'allocazione statica delle porte, in cui è riservato lo stesso numero di porte per ogni VM, oppure l'allocazione dinamica delle porte, in cui il numero di porte prenotate può variare tra i limiti minimo e massimo specificati.

Le VM per cui fornire NAT sono determinate dagli intervalli di indirizzi IP delle subnet che il gateway è configurato per gestire.

Per saperne di più sulle porte, consulta la sezione Porte.

RFC applicabili

Il NAT privato è un NAT cone limitato alla porta, come definito nel documento RFC 3489.

Timeout NAT

I gateway NAT privati utilizzano i timeout seguenti. Puoi modificare i valori di timeout predefiniti per ridurre o aumentare la frequenza di riutilizzo delle porte. Ogni valore di timeout è un equilibrio tra un utilizzo efficiente delle risorse NAT privato e possibili interruzioni di connessioni, flussi o sessioni attivi.

Timeout Descrizione Valore predefinito per NAT privato Configurabile

Timeout di inattività della mappatura UDP

RFC 4787 REQ-5

Specifica l'intervallo di tempo in secondi trascorso il quale i flussi UDP devono interrompere l'invio del traffico agli endpoint in modo che le mappature NAT private vengano rimosse.

Il timeout di inattività della mappatura UDP interessa due endpoint che smettono di inviare il traffico l'uno verso l'altro. Interessa anche gli endpoint che richiedono più tempo per rispondere o la latenza di rete aumentata.

Puoi aumentare il valore di timeout specificato per ridurre la frequenza di riutilizzo delle porte. Un valore di timeout maggiore indica che le porte vengono trattenute per connessioni più lunghe e protegge anche da pause nel traffico su un socket UDP specifico.

30 secondi

Timeout di inattività connessione stabilita TCP

RFC 5382 REQ-5

Specifica il tempo in secondi di inattività di una connessione prima che le mappature NAT private vengano rimosse.

Il timeout di inattività della connessione stabilita tramite TCP influisce sugli endpoint che impiegano più tempo per rispondere o in caso di maggiore latenza di rete.

Puoi aumentare il valore di timeout quando vuoi aprire le connessioni TCP e mantenerle aperte per un lungo periodo di tempo senza un meccanismo keepalive attivo.

1200 secondi (20 minuti)

Timeout di inattività connessione transitoria TCP

RFC 5382 REQ-5

Specifica l'intervallo di tempo in secondi durante il quale le connessioni TCP possono rimanere nello stato semiaperto prima che le mappature NAT private possano essere eliminate.

Il timeout di inattività della connessione transitoria TCP influisce su un endpoint quando un endpoint esterno dura un periodo più lungo rispetto al tempo specificato o quando si verifica una maggiore latenza di rete. A differenza del timeout di inattività della connessione TCP stabilito, il timeout di inattività della connessione TCP ha effetto solo sulle connessioni semi-aperte.

30 secondi

Nota: indipendentemente dal valore impostato per questo timeout, il NAT privato potrebbe richiedere fino a 30 secondi in più prima di poter utilizzare un indirizzo IP di origine NAT privato e una tupla di porte di origine per elaborare una nuova connessione.

Timeout TCP TIME_WAIT

RFC 5382 REQ-5

Specifica il tempo in secondi in cui una connessione TCP completamente chiusa viene mantenuta nelle mappature NAT private dopo la scadenza della connessione.

Il timeout TCP TIME_WAIT protegge gli endpoint interni dalla ricezione di pacchetti non validi che appartengono a una connessione TCP chiusa che vengono ritrasmessi.

Puoi ridurre il valore di timeout per migliorare il riutilizzo delle porte NAT private, con la possibilità di ricevere pacchetti ritrasmessi da una connessione non correlata e precedentemente chiusa.

120 secondi

Nota: indipendentemente dal valore impostato per questo timeout, il NAT privato potrebbe richiedere fino a 30 secondi in più prima di poter utilizzare un indirizzo IP di origine NAT privato e una tupla di porte di origine per elaborare una nuova connessione.

Timeout di inattività della mappatura ICMP

RFC 5508 REQ-2

Specifica il periodo di tempo in secondi trascorso il quale vengono chiuse le mappature NAT private ICMP (Internet Control Message Protocol) che non hanno flussi di traffico.

Il timeout per inattività della mappatura ICMP interessa un endpoint quando impiega più tempo per rispondere al tempo specificato o quando la latenza di rete aumenta.

30 secondi

Passaggi successivi