Panoramica del peering di rete VPC

Il peering di rete VPC di Google Cloud consente la connettività di indirizzi IP interni su due reti Virtual Private Cloud (VPC) indipendentemente dal fatto che appartengano allo stesso progetto o alla stessa organizzazione.

Il peering di rete VPC consente di connettere reti VPC in modo che i carichi di lavoro in diverse reti VPC possano comunicare internamente. Il traffico rimane all'interno della rete Google e non attraversa la rete Internet pubblica.

Il peering di rete VPC è utile nei seguenti ambienti:

  • ecosistemi SaaS (Software-as-a-Service) in Google Cloud. Puoi rendere disponibili i servizi privatamente in diverse reti VPC all'interno e all'interno delle organizzazioni.
  • Organizzazioni con diversi domini amministrativi di rete che devono comunicare utilizzando indirizzi IP interni.

Se nella tua organizzazione sono presenti più domini amministrativi di rete, il peering di rete VPC ti consente di rendere disponibili i servizi sulle reti VPC utilizzando indirizzi IP interni. Se offri servizi ad altre organizzazioni, il peering di rete VPC ti consente di rendere disponibili tali servizi utilizzando indirizzi IP interni per tali organizzazioni. La capacità di offrire servizi tra le organizzazioni è utile se vuoi offrire servizi ad altre aziende ed è utile anche se possiedi o controlli più di un'organizzazione.

Il peering di rete VPC offre diversi vantaggi rispetto all'utilizzo di indirizzi IP esterni o VPN per la connessione di reti, tra cui:

  • Latenza di rete: la connettività che utilizza solo indirizzi interni fornisce una latenza inferiore rispetto alla connettività che utilizza indirizzi esterni.
  • Sicurezza della rete: i proprietari dei servizi non devono necessariamente esporre i propri servizi alla rete Internet pubblica e affrontare i rischi associati.
  • Costo della rete: Google Cloud addebita in aumento i prezzi della larghezza di banda per le reti che utilizzano IP esterni per comunicare anche se il traffico si trova nella stessa zona. Tuttavia, se le reti sono in peering possono utilizzare IP interni per comunicare e risparmiare sui costi in uscita. Il regolare prezzo della rete continua a essere applicato a tutto il traffico.

Per informazioni sulla creazione di connessioni in peering, consulta Utilizzo del peering di rete VPC.

Proprietà chiave

Le reti VPC in peering presentano le seguenti proprietà chiave:

  • Il peering di rete VPC funziona con Compute Engine, GKE e ambiente flessibile di App Engine.
  • Le reti VPC in peering rimangono separate a livello amministrativo. Route, firewall, VPN e altri strumenti di gestione del traffico vengono amministrati e applicati separatamente in ciascuna rete VPC.
  • Ogni lato di un'associazione di peering viene configurato in modo indipendente. Il peering sarà attivo solo quando la configurazione da entrambi i lati corrisponde. Entrambi i lati possono scegliere di eliminare l'associazione di peering in qualsiasi momento.
  • Il peering e l'opzione di importazione ed esportazione di route personalizzate possono essere configurate per una rete VPC anche prima che venga creata l'altra rete VPC. Lo scambio del percorso si verifica solo dopo la configurazione di entrambi i lati.
  • I peer VPC scambiano sempre route di subnet che non utilizzano indirizzi IP pubblici utilizzati privatamente. Le reti devono esportare esplicitamente le route di subnet IP pubbliche utilizzate privatamente in modo che altre reti possano utilizzarle. Inoltre, devono importarle esplicitamente per riceverle da altre reti.
  • Puoi scambiare route personalizzate (route statiche e dinamiche), a seconda che le configurazioni di peering siano state configurate per importarle o esportarle. Per ulteriori informazioni, consulta Importazione ed esportazione di percorsi personalizzati.
  • Le route statiche e di subnet sono globali. Le route dinamiche possono essere a livello di area geografica o globale, a seconda della modalità di routing dinamico della rete VPC.
  • Una determinata rete VPC può essere in peering con più reti VPC, ma esiste un limite.
  • Le autorizzazioni IAM per la creazione e l'eliminazione del peering di rete VPC sono incluse nel ruolo Amministratore di rete Compute (roles/compute.networkAdmin).
  • Il traffico in peering (traffico tra reti in peering) ha la stessa latenza, velocità effettiva e disponibilità del traffico privato nella stessa rete.
  • Il criterio di fatturazione per il traffico di peering è uguale al criterio di fatturazione per il traffico privato nella stessa rete.

Limitazioni

Quando esegui il peering con le reti VPC, considera le seguenti restrizioni:

  • Il peering di rete VPC supporta solo la connettività IPv4. Puoi configurare il peering di rete VPC su una rete VPC contenente subnet a doppio stack. Tuttavia, non esiste una connettività IPv6 tra le reti.
  • Un intervallo CIDR di subnet in una rete VPC in peering non può sovrapporsi a una route statica in un'altra rete in peering. Questa regola copre sia le route di subnet sia le route statiche. Google Cloud verifica la presenza di sovrapposizioni nei seguenti casi e genera un errore quando si verifica una sovrapposizione.
    • Quando colleghi le reti VPC per la prima volta
    • Quando crei una route statica in una rete VPC in peering
    • Quando crei una nuova subnet in una rete VPC in peering
  • Una route dinamica può sovrapporsi a una route di subnet in una rete peer. Per le route dinamiche, gli intervalli di destinazione che si sovrappongono a una route della subnet dalla rete peer vengono ignorati. Google Cloud utilizza la route della subnet.
  • Per il peering di rete VPC sono supportate solo le reti VPC. Il peering NON è supportato per le reti legacy.
  • Non puoi disabilitare lo scambio di route di subnet o selezionare quali route di subnet vengono scambiate. Una volta stabilito il peering, tutte le risorse all'interno degli indirizzi IP di subnet sono accessibili su reti in peering diretto. Il peering di rete VPC non fornisce controlli di route granulari per filtrare gli intervalli CIDR delle subnet raggiungibili nelle reti in peering. Devi utilizzare le regole firewall per filtrare il traffico, se necessario. I seguenti tipi di endpoint e risorse sono raggiungibili su qualsiasi rete in peering diretto:
    • IP interni delle macchine virtuali (VM) in tutte le subnet
    • IP con bilanciamento del carico interno in tutte le subnet
  • Possono comunicare soltanto le reti in peering. Il peering transitorio non è supportato. In altre parole, se la rete VPC N1 è in peering con N2 e N3, ma N2 e N3 non sono connessi direttamente, la rete VPC N2 non può comunicare con la rete VPC N3 su peering di rete VPC.
  • Non puoi utilizzare un tag o un account di servizio di una rete in peering nell'altra rete in peering.
  • I nomi DNS interni di Compute Engine creati in una rete non sono accessibili alle reti in peering. Utilizza l'indirizzo IP per raggiungere le istanze VM in una rete in peering.
  • Per impostazione predefinita, è supportato il peering di rete VPC con GKE quando viene utilizzato con alias IP. Se non utilizzi gli alias IP, puoi esportare route personalizzate in modo che i container GKE siano raggiungibili dalle reti in peering.

Ordine di routing

Esamina attentamente l'ordine di routing per sapere come Google Cloud risolve i conflitti di route tra le reti in un gruppo di peering.

Importazione ed esportazione di route personalizzate

Le route di subnet che non utilizzano indirizzi IP pubblici utilizzati privatamente sono sempre scambiate tra reti in peering. Puoi anche scambiare route personalizzate, che includono route statiche e dinamiche, e route per le subnet che utilizzano indirizzi IP pubblici utilizzati privatamente se gli amministratori di rete di entrambe le reti hanno le configurazioni di peering appropriate.

Quando importi route personalizzate, la tua rete VPC può ricevere route personalizzate dalla rete peer solo se sono esportate dalla rete in questione. Allo stesso modo, se esporti route personalizzate, la rete peer può ricevere route personalizzate solo se la rete le sta importando.

Quando importi o esporti route personalizzate, le reti scambiano solo route personalizzate con peer diretti. Ad esempio, se la tua rete VPC è in peering con più reti, le route che la tua rete importa da una rete in peering non vengono esportate nelle altre reti in peering.

Quando crei o modifichi una configurazione di peering, puoi scegliere di importare route, esportazioni o entrambe le opzioni. L'amministratore di rete peer deve configurare in modo analogo la propria configurazione di peering prima dello scambio delle route. Questo processo garantisce che entrambi gli amministratori di rete acconsentano esplicitamente allo scambio di route personalizzate prima dello scambio.

Vantaggi dello scambio di percorsi personalizzati

La condivisione di route personalizzate con reti VPC in peering consente alle reti di apprendere le route direttamente dalle loro reti in peering. Ad esempio, se una route personalizzata in una rete in peering viene aggiornata, la tua rete VPC apprende automaticamente e utilizza la route personalizzata aggiornata senza che tu debba fare nulla.

Lo scambio dei percorsi personalizzati può essere utile nei seguenti scenari:

  • Se hai cluster GKE senza indirizzi nativi VPC, potresti avere più route statiche che indirizzano il traffico a istanze VM che ospitano i tuoi container. Puoi esportare queste route statiche in modo che i container siano raggiungibili da reti in peering.
  • Se hai un tunnel VPN o una connessione, puoi condividere le route personalizzate in modo che le reti peer possano raggiungere la tua rete on-premise. Per le route dinamiche, devi aggiungere le pubblicità personalizzata delle route al router Cloud nella rete VPC per annunciare le subnet di rete in peering con la tua rete on-premise.

Considerazioni

Quando configuri l'importazione o l'esportazione di route personalizzate, considera i seguenti comportamenti:

  • Al momento del peering, Google Cloud verifica se ci sono intervalli IP di subnet che si sovrappongono agli intervalli IP di subnet nell'altra rete. In caso di sovrapposizione, non viene stabilito il peering. Questo controllo di sovrapposizione riguarda solo gli intervalli di subnet VPC. Le route statiche e dinamiche non vengono controllate. Se il peering continua, vengono esportate così come sono.
  • Vengono esportate o importate sia le route statiche che quelle dinamiche. Non puoi importare o esportare solo un tipo di percorso.
  • Le route personalizzate importate da una rete VPC non possono essere esportate in un'altra rete VPC in peering in modo transitorio.
  • Le seguenti route sono escluse dall'importazione ed esportazione:
    • Le route codificate non vengono mai scambiate tra reti peer. Le route con tag sono route statiche personalizzate con ambito a istanze VM specifiche mediante tag di rete. I tag di rete possono essere risolti solo nella rete VPC in cui sono stati creati.
    • Le route statiche con un hop successivo al gateway Internet predefinito non vengono mai scambiate. Ad esempio, la route predefinita (0.0.0.0/0) con un hop successivo di gateway Internet predefinito non viene scambiata tra reti peer.
  • Le route importate possono comportare modifiche indesiderate nel flusso del traffico, ad esempio modifiche all'ordine di routing. Per ulteriori informazioni, consulta la sezione Ordine di routing.
  • Quando una rete VPC importa route personalizzate da una rete in peering, gli intervalli di destinazione vengono importati così come sono. Tuttavia, l'hop successivo per una route importata è impostato sul nome della connessione in peering. Il traffico viene instradato alla rete in peering dove è definito l'hop successivo effettivo.

Funzionalità di networking negli scenari di peering di rete VPC

Le seguenti sezioni illustrano il comportamento del peering di rete VPC in determinati scenari.

Subnet sovrapposte al momento del peering

Al momento del peering, Google Cloud verifica se esistono subnet con intervalli IP sovrapposti tra le due reti VPC o una delle loro reti in peering. In caso di sovrapposizione, non viene stabilito il peering. Poiché viene creata una connettività mesh completa tra le istanze VM, le subnet delle reti VPC in peering non possono avere intervalli IP sovrapposti, poiché questo potrebbe causare problemi di routing.

Intervalli IP subnet sovrapposti tra due peer (fai clic per ingrandire)
Intervalli IP di subnet sovrapposti tra due peer (fai clic per ingrandire)

L'eventuale presenza di subnet con intervalli IP sovrapposti tra peer di una determinata rete VPC potrebbe causare un conflitto di routing. Ad esempio, supponiamo che la rete VPC N1 abbia già eseguito il peering con la rete VPC N2, quindi la rete VPC N3 tenta di eseguire il peering con N2. Questo è un peering non valido perché N3 ha una subnet Subnet_5 il cui intervallo IP si sovrappone a Subnet_1 nella rete N1.

Intervalli IP di subnet sovrapposti con tre peer (fai clic per ingrandire)
Sovrapposizione degli intervalli IP di subnet con tre peer (fai clic per ingrandire)

Subnet sovrapposte durante la creazione o l'espansione delle subnet

Quando viene creata una subnet VPC o viene espanso un intervallo IP di subnet, Google Cloud esegue un controllo per assicurarsi che il nuovo intervallo di subnet non si sovrapponga a intervalli IP delle subnet nella stessa rete VPC o in reti VPC direttamente in peering. In caso contrario, l'azione di creazione o espansione non andrà a buon fine. Ad esempio, quando viene creata una nuova subnet_3 nella rete N2 nella figura seguente, gli intervalli IP non devono sovrapporsi agli intervalli IP definiti nella rete N1 direttamente in peering.

Controllo creazione subnet (fai clic per ingrandire)
Controllo creazione subnet (fai clic per ingrandire)

Google Cloud garantisce inoltre che non siano consentiti intervalli IP di subnet che si sovrappongono nelle reti VPC con una rete in peering. In caso contrario, l'azione di creazione o espansione non funziona. Ad esempio, quando nella nuova figura viene creata una nuova subnet_5 nella rete N3 nella figura seguente, gli intervalli IP non devono sovrapporsi agli intervalli IP definiti nella rete N2 direttamente in peering, o con la rete N1, perché N1 è già in peering con N2.

Controllo creazione subnet con tre peer (fai clic per ingrandire)
Controllo della creazione delle subnet con tre peer (fai clic per ingrandire)

Accesso on-premise dalla rete peer

Puoi utilizzare Cloud VPN o Cloud Interconnect per connettere in modo sicuro la tua rete on-premise alla rete VPC. Se esporti route personalizzate, le reti VPC in peering possono connettersi anche alla tua rete on-premise. Sul lato on-premise, devi creare route in modo che il traffico diretto alle reti VPC sia indirizzato al tunnel VPN.

La VPN ad alta disponibilità e Cloud Interconnect richiedono il routing dinamico. I tunnel VPN classici possono utilizzare il routing statico o dinamico; tuttavia, alcuni casi d'uso dei tunnel VPN classici sono stati ritirati.

Per il routing dinamico, utilizza il router Cloud per aggiornare in modo dinamico le route tra la tua rete VPC e la tua rete on-premise utilizzando il protocollo BGP (Border Gateway Protocol). I router Cloud possono apprendere e propagare le route all'interno della sua area geografica o per tutte le aree geografiche all'interno di una rete VPC. Questo comportamento dipende dalla modalità di routing dinamico della rete VPC, che può essere regionale o globale.

I seguenti casi d'uso mostrano come le risorse nelle reti VPC in peering sono accessibili dopo aver importato ed esportato le route personalizzate. Ogni esempio mostra due reti (network-a e network-b) in peering tra loro. In un esempio, la modalità di routing dinamico per network-b è a livello di area geografica e nell'altro è globale.

Routing dinamico a livello di area geografica

Se utilizzi il routing dinamico a livello di area geografica, solo le risorse nella stessa area geografica del router Cloud possono accedere alla rete on-premise. Questa restrizione si applica alla rete VPC del router Cloud e a qualsiasi rete VPC in peering, indipendentemente dalla modalità di routing dinamico in peering. Nell'esempio seguente, network-b contiene un tunnel VPN (che potrebbe anche essere un'interconnessione) e un router Cloud. La modalità di routing dinamico di network-b è impostata su un'area geografica. Nella rete in peering, subnet-a si trova nella stessa area geografica del router Cloud in network-b.

Una volta stabilita una connessione in peering, network-a può accedere al tunnel VPN in network-b. Questo accesso è limitato alle subnet che si trovano nella stessa area geografica del router Cloud. Ad esempio, l'istanza VM vm-a può raggiungere il tunnel VPN perché si trova nella stessa area geografica del router Cloud. Le istanze VM in altre aree geografiche non possono raggiungere il tunnel.

Il router Cloud non impara le route e propaga le route dalle reti VPC in peering. Di conseguenza, devi avere una pubblicità route personalizzata sul router Cloud che propaga l'intervallo 10.8.1.0/24 alla rete on-premise nella sessione BGP.

La tabella seguente riepiloga i percorsi risultanti per network-a e network-b se importano ed esportano route personalizzate:

Rete Destinazione Next hop Origine
rete-a 0.0.0.0/0 Gateway Internet local
10.8.1.0/24 rete-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 peering-a-b peer
10.10.0.0/16
(percorso dinamico limitato a us-west1)
peering-a-b peer
rete-b 0.0.0.0/0 Gateway Internet local
10.8.2.0/24 rete-b local
10.10.0.0/16
(percorso dinamico limitato a us-west1)
VPN-B local
10.8.1.0/24 peering-b-a-a peer
10.30.0.0/16 peering-b-a-a peer

Routing dinamico globale

Se network-b abilita il routing dinamico globale, le risorse in tutte le aree geografiche possono accedere alla rete on-premise. Questo vale per la rete VPC del router Cloud e per qualsiasi rete VPC in peering, indipendentemente dalla modalità di routing dinamico della rete VPC in peering.

Nell'esempio seguente, le risorse in network-a possono accedere al tunnel VPN in network-b, indipendentemente dalla loro area geografica. Ad esempio, le istanze VM vm-a1 e vm-a2 possono raggiungere la rete on-premise anche se vm-a2 si trova in un'area geografica diversa rispetto al tunnel VPN.

Il router Cloud deve inoltre includere pubblicità di route personalizzata per annunciare gli intervalli 10.8.1.0/24 e 10.9.1.0/24 alla rete on-premise della sessione BGP.

La tabella seguente riepiloga i percorsi risultanti per network-a e network-b se importano ed esportano route personalizzate:

Rete Destinazione Next hop Origine
rete-a 0.0.0.0/0 Gateway Internet local
10.8.1.0/24 rete-a local
10.9.1.0/24 rete-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 peering-a-b peer
10.10.0.0/16
(percorso dinamico globale)
peering-a-b peer
rete-b 0.0.0.0/0 Gateway Internet local
10.8.2.0/24 rete-b local
10.10.0.0/16
(percorso dinamico globale)
VPN-B local
10.8.1.0/24 peering-b-a-a peer
10.9.1.0/24 peering-b-a-a peer
10.30.0.0/16 peering-b-a-a peer

Rete VPC come rete di transito

Immagina di avere una singola connessione on-premise, come un tunnel VPN o un'interconnessione, tra la tua rete VPC e la rete on-premise. Vuoi condividere questa connessione con altre reti VPC in modo da non dover ricreare una connessione on-premise per tutte le altre reti VPC.

Puoi avere altre reti VPC in peering con la tua rete VPC (nota anche come rete di transito) in modo che le altre reti possano utilizzare la connessione on-premise. Tutte le reti in peering possono sfruttare la connessione on-premise, ma non saranno in grado di instradare traffico a un altro peer attraverso la rete di transito.

Nell'esempio seguente, sono presenti tre reti VPC. network-b è in peering con network-a e network-c. Tutte le reti esportano e importano route personalizzate. network-b funge da rete di trasporto pubblico, in cui si trova il tunnel VPN.

  • Per impostazione predefinita, il router Cloud che gestisce le route per i tunnel collegati al gateway Cloud VPN in network-b pubblicizza automaticamente gli intervalli di indirizzi IP delle subnet delle subnet in network-b.

  • Le route per le destinazioni on-premise vengono installate come route dinamiche personalizzate in network-b dal router Cloud, che gestisce le route per i tunnel collegati al gateway Cloud VPN in network-b.

  • Devi aggiungere gli intervalli di indirizzi IP delle subnet per le subnet in network-a e network-c configurando pubblicità di route personalizzate sul router Cloud che gestisce le route per i tunnel connessi al gateway Cloud VPN in network-b.

  • Le route dinamiche personalizzate (verso le destinazioni on-premise) vengono scambiate utilizzando il peering di rete VPC sia a network-a che a network-c perché network-b è stata configurata per esportare le route personalizzate e le altre due reti sono state configurate per importarle.

  • L'esempio fornisce la seguente connettività:

    • Le istanze VM in network-a possono raggiungere altre VM in network-b e sistemi nella rete on-premise.
    • Le istanze VM in network-b possono raggiungere altre VM sia in network-a che network-c, nonché nei sistemi nella rete on-premise.
    • Le istanze VM in network-c possono raggiungere altre VM in network-b e sistemi nella rete on-premise.
    • Poiché il peering di rete VPC non è transitivo, le istanze VM in network-a e network-c non possono comunicare tra loro a meno che non utilizzi anche la rete peer network-a con network-c.

Bilanciatori del carico interni

Le istanze VM nelle reti peer possono accedere agli indirizzi IP interni dei bilanciatori del carico TCP/UDP interni nella rete VPC se sono soddisfatte le seguenti condizioni:

  • Se l'accesso globale è disabilitato su un bilanciatore del carico TCP/UDP interno, i client devono trovarsi nella stessa area geografica del bilanciatore del carico. Inoltre, devono trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC collegata alla rete VPC del bilanciatore del carico utilizzando il peering di rete VPC.

  • Se l'accesso globale è abilitato su un bilanciatore del carico TCP/UDP interno, i client possono essere in qualsiasi area geografica. Devono ancora trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico tramite peering di rete VPC.

  • Le regole firewall in entrata che si applicano alle VM di backend del bilanciatore del carico consentono il traffico dalle origini in reti peer. Queste regole firewall in entrata devono essere create nella rete VPC che contiene il bilanciatore del carico.

Per ulteriori informazioni, vedi:

Regole firewall

Quando colleghi reti tramite peering di rete VPC, le regole firewall non vengono scambiate tra le reti. Per consentire il traffico in entrata da istanze VM in una rete peer, devi creare regole firewall di autorizzazione in entrata. Per impostazione predefinita, il traffico in entrata verso le VM è bloccato dalla regola di traffico in entrata implicito.

Se devi limitare l'accesso alle VM in modo che solo le altre VM nella tua rete VPC abbiano accesso, assicurati che le origini per le regole firewall allow in entrata identifichino solo le VM nella tua rete VPC, non quelle delle reti peer. Ad esempio, puoi specificare intervalli IP di origine solo per le subnet nella tua rete VPC.

Per limitare l'accesso a un bilanciatore del carico TCP/UDP interno, crea regole firewall in entrata che si applicano alle VM di backend del bilanciatore del carico.

VPC condiviso

Il peering di rete VPC consente il peering con un VPC condiviso. Un progetto host del VPC condiviso è un progetto che consente ad altri progetti di utilizzare una delle sue reti. Il seguente diagramma mostra questa configurazione.

VPC condiviso con peering di rete (fai clic per ingrandire)
VPC condiviso con peering di rete (fai clic per ingrandire)

Network-SVPC si trova in una rete VPC condivisa nel progetto host P1. I progetti di servizio P3 e P4 sono in grado di collegare istanze VM a Network-SVPC. peer SVPC di rete con Network-A. Di conseguenza:

  • Le istanze VM nei progetti di servizi VPC condivisi che utilizzano Network-SVPC (VM3 e VM4) hanno una connettività IP interna privata con qualsiasi endpoint associato alla rete A.
  • Le istanze VM associate a network-A avranno una connettività IP interna privata con qualsiasi endpoint associato a Network-SVPC, indipendentemente dal fatto che tali endpoint si trovino nel progetto host o in un progetto di servizio.

È possibile configurare il peering di rete VPC tra due reti VPC condivise.

Interfacce di rete multiple per istanza VM

Un'istanza VM può avere più interfaccia di rete, una per rete VPC. In questi casi, Google Cloud assegna route IP basate sulla destinazione, dove ogni interfaccia riceve una route dalla subnet in cui si trova. Inoltre, Google Cloud fornisce una route predefinita all'interfaccia di rete principale. Con il routing basato su destinazione, tutto il traffico che non è destinato a nessuna delle subnet in uscita dall'interfaccia di rete principale. Per ulteriori informazioni, consulta la sezione sul comportamento DHCP con più interfaccia di rete.

Se hai reti peer che includono istanze VM con più interfacce di rete, potresti dover cambiare il criterio di routing predefinito basato sulla destinazione impostandolo su un criterio di routing basato sull'origine. Per ulteriori informazioni, consulta la sezione Configurare il routing dei criteri.

I seguenti scenari mostrano quando un'istanza VM può richiedere o meno un criterio di routing basato sull'origine

Criterio di routing obbligatorio

Nell'esempio seguente, vm1 richiede un criterio di routing basato su origine in modo che vm1 e vm2 possano comunicare correttamente. Senza un criterio di routing, tutto il traffico in uscita attraverso vm1-nic0 verso network-a è destinato a subnet-b, dove si trova nic1. Ciò significa che il traffico da vm1 destinato a network-c viene eliminato o inviato alla destinazione sbagliata, perché l'istanza VM invia sempre il traffico fuori dalla sua interfaccia principale.

Il requisito del criterio di routing dipende dagli intervalli IP di subnet

Nel seguente esempio, l'interfaccia di rete principale di vm1 si trova in una rete in peering con un'altra rete. Non è necessario configurare il routing dei criteri su vm1.

Nell'esempio seguente, vm1-nic1 e vm2-nic0 si trovano in subnet sovrapposte. Una volta stabilito il peering, Google Cloud verifica la presenza di intervalli IP sovrapposti solo tra peer e non tra altre reti in cui le istanze contengono interfacce di rete. Per garantire che la comunicazione tra vm1 e vm2 funzioni, devi aggiungere un criterio di routing basato su origine su vm1-nic0.

Peering tra interfacce

L'esempio seguente mostra un'istanza VM con più interfacce di rete, in cui ciascuna si trova in una rete in peering tra loro. In questo caso, vm1 non richiede un criterio di routing basato sull'origine. Il traffico che lascia l'istanza VM in ogni subnet utilizza l'interfaccia di rete corrispondente.

Se vm1 invia il traffico all'indirizzo IP di vm2-nic1, il traffico entra in nic1, ma in uscita da nic0. Allo stesso modo, se vm3 invia il traffico all'indirizzo IP di vm2-nic0, il traffico va a nic0, ma in uscita da nic1.

Intervalli secondari di subnet

Una subnet ha un singolo intervallo di indirizzi IP principali e, facoltativamente, uno o più intervalli di indirizzi IP secondari. Per ogni intervallo di indirizzi IP subnet, Google Cloud crea un route subnet. Quando utilizzi il peering di rete VPC, Google Cloud scambia sempre le route di subnet che non utilizzano indirizzi IP pubblici utilizzati privatamente tra le due reti in peering. Se le regole firewall in ogni rete consentono la comunicazione, le istanze VM in un'unica rete possono comunicare con le istanze nella rete in peering.

Quando stabilisci una relazione di peering, Google Cloud verifica che gli intervalli primari e secondari di una subnet non si sovrappongano ad altri intervalli nelle reti in peering.

Vincoli dei criteri dell'organizzazione

Un amministratore dei criteri dell'organizzazione può utilizzare il vincolo constraints/compute.restrictVpcPeering per definire un insieme di reti VPC in grado di eseguire il peering con le reti VPC della tua organizzazione. Puoi negare le connessioni in peering a determinate reti VPC o a reti VPC in una determinata cartella o organizzazione. Il vincolo si applica alle nuove configurazioni di peering e non influisce sulle connessioni esistenti.

Passaggi successivi