Private NAT per gli spoke NCC

Private NAT consente di creare un gateway Private NAT che funziona in combinazione con gli spoke di Network Connectivity Center per eseguire la Network Address Translation (NAT) tra le seguenti reti:

  • Reti Virtual Private Cloud (VPC). In questo scenario, le reti VPC che vuoi connettere sono collegate a un hub NCC come spoke VPC.
  • Reti VPC e reti esterne a Google Cloud. In questo scenario, una o più reti VPC sono collegate a un hub NCC come spoke VPC e connesse alle tue reti on-premise o di altri provider cloud tramite spoke ibridi.

Specifiche

Oltre alle specifiche generali di Private NAT, Private NAT per gli spoke NCC ha le seguenti specifiche:

  • NAT privato utilizza una configurazione NAT di type=PRIVATE per consentire la comunicazione tra reti con intervalli di indirizzi IP di subnet sovrapposti. Tuttavia, solo le subnet non sovrapposte possono connettersi tra loro.
  • Devi creare una regola NAT personalizzata facendo riferimento a un hub NCC. La regola NAT specifica un intervallo di indirizzi IP NAT da una subnet di destinazione PRIVATE_NAT che NAT privato utilizza per eseguire NAT sul traffico tra le reti connesse.
  • Quando crei un'istanza VM in un intervallo di subnet in cui si applica NAT privato, tutto il traffico in uscita da questa istanza di macchina virtuale (VM) viene tradotto dal gateway se lo spoke di destinazione si trova nello stesso hub NCC del gateway. Private NAT traduce il traffico verso gli spoke di destinazione all'interno della stessa regione del gateway Private NAT e tra le regioni.
  • Un gateway Private NAT è associato a intervalli di indirizzi IP di subnet in una singola regione di una singola rete VPC. Ciò significa che un gateway Private NAT creato in una rete VPC non fornisce servizi NAT alle VM in altri spoke dell'hub NCC, anche se le VM si trovano nella stessa regione del gateway.

Traffico tra reti VPC

Per il traffico tra reti VPC (Inter-VPC NAT) si applicano le seguenti specifiche aggiuntive:

  • Per abilitare Inter-VPC NAT tra due reti VPC, ogni rete VPC deve essere configurata come spoke VPC di un hub NCC. Devi assicurarti che non ci siano intervalli di indirizzi IP sovrapposti negli spoke VPC. Per saperne di più, consulta Crea uno spoke VPC.
  • L'hub NCC associato al gateway Private NAT deve avere almeno due spoke VPC, uno dei quali è la rete VPC del gateway Private NAT.
  • Inter-VPC NAT supporta la NAT solo tra gli spoke VPC di NCC e non tra le reti VPC connesse tramite il peering di rete VPC.

Traffico tra reti VPC e altre reti

Per il traffico tra le reti VPC e le reti esterne a Google Cloudsi applicano le seguenti specifiche aggiuntive:

  • La rete VPC di origine deve essere configurata come uno spoke VPC di un hub NCC.
  • Uno spoke ibrido deve essere collegato allo stesso hub NCC per stabilire la connettività tra lo spoke VPC e la rete di destinazione al di fuori di Google Cloud. Per ulteriori informazioni, consulta Stabilire la connettività tra gli spoke ibridi e gli spoke VPC.

Per informazioni sui requisiti per l'utilizzo di spoke VPC e spoke ibridi nello stesso hub NCC, consulta Scambio di route con gli spoke VPC.

Configurazione e flusso di lavoro di base

Il seguente diagramma mostra una configurazione Private NAT di base per il traffico tra due spoke VPC:

Esempio di conversione Inter-VPC NAT.
Esempio di conversione NAT tra VPC (fai clic per ingrandire).

In questo esempio, Private NAT è configurato nel seguente modo:

  • 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 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 NCC.
  • Il gateway pvt-nat-gw è configurato per fornire NAT tra le reti VPC configurate come spoke VPC nello stesso hub NCC.

Workflow di esempio

Nel diagramma precedente, vm-a con l'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 NCC come spoke VPC. Supponiamo che vpc-b contenga un'altra subnet 192.168.1.0/24 che si sovrappone alla subnet in vpc-a. Per consentire a subnet-a di vpc-a di comunicare con subnet-b di vpc-b, devi configurare un gateway Private NAT, pvt-nat-gw, in vpc-a nel seguente modo:

  • Subnet Private NAT: prima di configurare il gateway Private NAT, crea una subnet Private NAT con scopo PRIVATE_NAT, ad esempio 10.1.2.0/29. Assicurati che questa subnet non si sovrapponga a una subnet esistente in uno degli spoke VPC collegati allo stesso hub NCC.

  • Una regola NAT il cui nexthop.hub corrisponde all'URL dell'hub NCC.

  • NAT per tutti gli intervalli di indirizzi di subnet-a.

La tabella seguente riepiloga 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

Private NAT per gli spoke NCC segue la procedura di prenotazione delle porte per prenotare le seguenti tuple di indirizzo IP di origine NAT e porta di origine per ciascuna delle VM nella rete. Ad esempio, il gateway Private NAT riserva 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:

  1. La VM invia un pacchetto di richiesta con questi attributi:

    • Indirizzo IP di origine: 192.168.1.2, l'indirizzo IP interno della VM
    • Porta di origine: 24000, la porta di origine effimera 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 al server di aggiornamento
    • Protocollo: TCP

  2. Il gateway pvt-nat-gw esegue la Network Address Translation dell'origine (SNAT o source NAT) per il traffico in uscita, riscrivendo l'indirizzo IP di origine NAT e la porta di origine del pacchetto di richiesta:

    • Indirizzo IP di origine NAT: 10.1.2.2, da una delle tuple di porta di origine e indirizzo IP di origine NAT riservate della VM
    • Porta di origine: 34022, una porta di origine non utilizzata da una delle tuple di porte di origine riservate della VM
    • Indirizzo di destinazione: 192.168.2.2, invariato
    • Porta di destinazione: 80, invariata
    • Protocollo: TCP, invariato

  3. Il server di aggiornamento invia un pacchetto di risposta che arriva sul gateway pvt-nat-gw con questi attributi:

    • Indirizzo IP di origine: 192.168.2.2, l'indirizzo IP interno del server di aggiornamento
    • Porta di origine: 80, la risposta HTTP dal server di aggiornamento
    • Indirizzo di destinazione: 10.1.2.2, che corrisponde all'indirizzo IP di origine NAT originale del pacchetto di richiesta
    • Porta di destinazione: 34022, che corrisponde alla porta di origine del pacchetto di richiesta
    • Protocollo: TCP, invariato

  4. Il gateway pvt-nat-gw esegue Network Address Translation di destinazione (DNAT) sul pacchetto di risposta, riscrivendo l'indirizzo di destinazione e la porta di destinazione del pacchetto di risposta in modo che il pacchetto venga recapitato alla VM che ha richiesto l'aggiornamento con i seguenti attributi:

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

Passaggi successivi