Networking

Last reviewed 2023-12-20 UTC

La rete è necessaria per consentire alle risorse di comunicare all'interno della tua Google Cloud organizzazione e tra il tuo ambiente cloud e quello on-premise. Questa sezione descrive la struttura del blueprint per le reti VPC, lo spazio indirizzi IP, DNS, i criteri di firewall e la connettività all'ambiente on-premise.

Il repository di blueprint fornisce le seguenti opzioni per la topologia della rete:

  • Utilizza reti VPC condivise separate per ogni ambiente, senza traffico di rete consentito direttamente tra gli ambienti.
  • Utilizza un modello hub-and-spoke che aggiunge una rete hub per connettere ogni ambiente in Google Cloud, con il traffico di rete tra gli ambienti controllato da un'appliance virtuale di rete (NVA).

Scegli la topologia di rete VPC condivisa doppia quando non vuoi la connettività di rete diretta tra gli ambienti. Scegli la topologia di rete hub-and-spoke quando vuoi consentire la connettività di rete tra ambienti filtrata da un NVA, ad esempio quando ti affidi a strumenti esistenti che richiedono un percorso di rete diretto a ogni server nel tuo ambiente.

Entrambe le topologie utilizzano VPC condiviso come principale elemento di rete perché consente una chiara separazione delle responsabilità. Gli amministratori di rete gestiscono le risorse di rete in un progetto host centralizzato, mentre i team dei carichi di lavoro eseguono il deployment delle proprie risorse di applicazione e utilizzano le risorse di rete nei progetti di servizio collegati al progetto host.

Entrambe le topologia includono una versione di base e una limitata di ogni rete VPC. La rete VPC di base viene utilizzata per le risorse che contengono dati non sensibili, mentre la rete VPC con limitazioni viene utilizzata per le risorse con dati sensibili che richiedono i Controlli di servizio VPC. Per ulteriori informazioni sull'implementazione dei Controlli di servizio VPC, consulta Proteggere le risorse con i Controlli di servizio VPC.

Topologia di rete VPC condivisa doppia

Se hai bisogno di isolamento della rete tra le reti di sviluppo, non di produzione e di produzione su Google Cloud, ti consigliamo la topologia di rete VPC condivisa doppia. Questa topologia utilizza reti VPC condivise separate per ogni ambiente, con ogni ambiente suddiviso ulteriormente in una rete VPC condivisa di base e una rete VPC condivisa con limitazioni.

Il seguente diagramma mostra la topologia della rete VPC condivisa doppia.

La rete VPC del blueprint.

Il diagramma descrive i seguenti concetti chiave della topologia VPC condivisa doppia:

  • Ogni ambiente (di produzione, non di produzione e di sviluppo) ha una rete VPC condivisa per la rete di base e una rete VPC condivisa per la rete con limitazioni. Questo diagramma mostra solo l'ambiente di produzione, ma lo stesso schema viene ripetuto per ogni ambiente.
  • Ogni rete VPC condivisa ha due subnet, ciascuna in una distinta regione.
  • La connettività con le risorse on-premise è abilitata tramite quattro VLAN collegamenti all'istanza di interconnessione dedicata per ogni rete VPC condivisa, utilizzando quattro servizi Cloud Router (due in ogni regione per la ridondanza). Per saperne di più, consulta Connettività ibrida tra l'ambiente on-premise e Google Cloud.

Per impostazione predefinita, questa topologia non consente il flusso diretto del traffico di rete tra gli ambienti. Se vuoi che il traffico di rete fluisca direttamente tra gli ambienti, devi eseguire ulteriori passaggi per consentire questo percorso di rete. Ad esempio, potresti configurare gli endpoint Private Service Connect per esporre un servizio da una rete VPC a un'altra rete VPC. In alternativa, puoi configurare la rete on-premise in modo che il traffico fluisca da un ambienteGoogle Cloud all'ambiente on-premise e poi a un altro Google Cloud .

Topologia di rete hub and spoke

Se esegui il deployment di risorse in Google Cloud che richiedono un percorso di rete diretto alle risorse in più ambienti, ti consigliamo la topologia di rete hub and spoke.

La topologia hub-and-spoke utilizza diversi concetti che fanno parte della doppia topologia VPC condivisa, ma la modifica per aggiungere una rete hub. Il seguente diagramma mostra la topologia hub-and-spoke.

La struttura di rete VPC di example.com quando si utilizza la connettività hub-and-spoke basata sul peering VPC

Il diagramma descrive i seguenti concetti chiave della topologia di rete hub-and-spoke:

  • Questo modello aggiunge una rete hub e ciascuna delle reti di sviluppo, non di produzione e di produzione (spoke) è collegata alla rete hub tramite il peering di rete VPC. In alternativa, se prevedi di superare il limite di quota, puoi utilizzare un gateway VPN ad alta disponibilità.
  • La connettività alle reti on-premise è consentita solo tramite la rete dell'hub. Tutte le reti spoke possono comunicare con le risorse condivise nella rete hub e utilizzare questo percorso per connettersi alle reti on-premise.
  • Le reti hub includono un NVA per ogni regione, di cui è stato eseguito il deployment in modo ridondante dietro le istanze del bilanciatore del carico di rete interno. Questa NVA funge da gateway per consentire o negare la comunicazione tra le reti spoke.
  • La rete hub ospita anche strumenti che richiedono la connettività a tutte le altre reti. Ad esempio, potresti eseguire il deployment di strumenti sulle istanze VM per la gestione della configurazione nell'ambiente comune.
  • Il modello hub-and-spoke viene duplicato per una versione di base e una versione limitata di ogni rete.

Per abilitare il traffico da spoke a spoke, il blueprint esegue il deployment di NVA sulla rete VPC condivisa dell'hub che fungono da gateway tra le reti. Le route vengono scambiate tra le reti VPC hub-to-spoke tramite lo scambio di route personalizzate. In questo scenario, la connettività tra gli spoke deve essere instradata tramite l'NVA perché il peering di rete VPC non è transitivo e, pertanto, le reti VPC spoke non possono scambiarsi dati direttamente. Devi configurare le appliance virtuali per consentire in modo selettivo il traffico tra gli spoke.

Pattern di deployment dei progetti

Quando crei nuovi progetti per i carichi di lavoro, devi decidere in che modo le risorse di questo progetto si connettono alla tua rete esistente. La tabella seguente descrive i pattern di implementazione dei progetti utilizzati nel blueprint.

Pattern Descrizione Esempio di utilizzo
Progetti di base condivisi

Questi progetti sono configurati come progetti di servizio per un progetto host VPC condiviso di base.

Utilizza questo pattern quando le risorse del progetto soddisfano i seguenti criteri:

  • Richiedi la connettività di rete all'ambiente on-premise o alle risorse nella stessa topologia VPC condiviso.
  • Richiedi un percorso di rete per i servizi Google contenuti nell'indirizzo IP virtuale privato.
  • Non richiedono i Controlli di servizio VPC.
example_base_shared_vpc_project.tf
Progetti condivisi con limitazioni

Questi progetti sono configurati come progetti di servizio per un progetto host VPC condiviso limitato.

Utilizza questo pattern quando le risorse del progetto soddisfano i seguenti criteri:

  • Richiedi la connettività di rete all'ambiente on-premise o alle risorse nella stessa topologia VPC condiviso.
  • Richiedi un percorso di rete per i servizi Google contenuti nell'indirizzo IP virtuale soggetto a limitazioni.
  • Richiedi i Controlli di servizio VPC.
example_restricted_shared_vpc_project.tf
Progetti inutilizzati

I progetti mobili non sono connessi ad altre reti VPC nella tua topologia.

Utilizza questo pattern quando le risorse del progetto soddisfano i seguenti criteri:

  • Non richiedono connettività mesh completa a un ambiente on-premise o alle risorse nella topologia VPC condivisa.
  • Non hai bisogno di una rete VPC o vuoi gestire la rete VPC per questo progetto indipendentemente dalla topologia della rete VPC principale (ad esempio quando vuoi utilizzare un intervallo di indirizzi IP in conflitto con gli intervalli già in uso).

Potresti trovarti in uno scenario in cui vuoi mantenere la rete VPC di un progetto mobile separata dalla topologia della rete VPC principale, ma anche esporre un numero limitato di endpoint tra le reti. In questo caso, pubblica i servizi utilizzando Private Service Connect per condividere l'accesso alla rete a un singolo endpoint tra le reti VPC senza esporre l'intera rete.

example_floating_project.tf
Progetti di peering

I progetti di peering creano le proprie reti VPC e si connettono in peering ad altre reti VPC nella tua topologia.

Utilizza questo pattern quando le risorse del progetto soddisfano i seguenti criteri:

  • Richiedi la connettività di rete nella rete VPC con peering diretto, ma non la connettività transitiva a un ambiente on-premise o ad altre reti VPC.
  • Devi gestire la rete VPC per questo progetto indipendentemente dalla topologia di rete principale.

Se crei progetti di peering, è tua responsabilità allocare intervalli di indirizzi IP non in conflitto e pianificare la quota del gruppo di peering.

example_peering_project.tf

Allocazione degli indirizzi IP

Questa sezione illustra in che modo l'architettura del blueprint alloca gli intervalli di indirizzi IP. Potresti dover modificare gli intervalli di indirizzi IP specifici utilizzati in base alla disponibilità degli indirizzi IP nel tuo ambiente ibrido esistente.

La tabella seguente fornisce un'analisi dello spazio degli indirizzi IP allocato per il blueprint. L'ambiente hub si applica solo alla topologia hub and spoke.

Finalità Tipo di VPC Regione Ambiente hub Ambiente di sviluppo Ambiente non di produzione Ambiente di produzione
Intervalli di subnet principali Livelli Regione 1 10.0.0.0/18 10.0.64.0/18 10.0.128.0/18 10.0.192.0/18
Regione 2 10.1.0.0/18 10.1.64.0/18 10.1.128.0/18 10.1.192.0/18
Risorse non allocate 10.{2-7}.0.0/18 10.{2-7}.64.0/18 10.{2-7}.128.0/18 10.{2-7}.192.0/18
Con restrizioni Regione 1 10.8.0.0/18 10.8.64.0/18 10.8.128.0/18 10.8.192.0/18
Regione 2 10.9.0.0/18 10.9.64.0/18 10.9.128.0/18 10.9.192.0/18
Risorse non allocate 10.{10-15}.0.0/18 10.{10-15}.64.0/18 10.{10-15}.128.0/18 10.{10-15}.192.0/18
Accesso privato ai servizi Livelli Globale 10.16.0.0/21 10.16.8.0/21 10.16.16.0/21 10.16.24.0/21
Con restrizioni Globale 10.16.32.0/21 10.16.40.0/21 10.16.48.0/21 10.16.56.0/21
Endpoint di Private Service Connect Livelli Globale 10.17.0.1/32 10.17.0.2/32 10.17.0.3/32 10.17.0.4/32
Con restrizioni Globale 10.17.0.5/32 10.17.0.6/32 10.17.0.7/32 10.17.0.8/32
Subnet solo proxy Livelli Regione 1 10.18.0.0/23 10.18.2.0/23 10.18.4.0/23 10.18.6.0/23
Regione 2 10.19.0.0/23 10.19.2.0/23 10.19.4.0/23 10.19.6.0/23
Risorse non allocate 10.{20-25}.0.0/23 10.{20-25}.2.0/23 10.{20-25}.4.0/23 10.{20-25}.6.0/23
Con restrizioni Regione 1 10.26.0.0/23 10.26.2.0/23 10.26.4.0/23 10.26.6.0/23
Regione 2 10.27.0.0/23 10.27.2.0/23 10.27.4.0/23 10.27.6.0/23
Risorse non allocate 10.{28-33}.0.0/23 10.{28-33}.2.0/23 10.{28-33}.4.0/23 10.{28-33}.6.0/23
Intervalli di subnet secondari Livelli Regione 1 100.64.0.0/18 100.64.64.0/18 100.64.128.0/18 100.64.192.0/18
Regione 2 100.65.0.0/18 100.65.64.0/18 100.65.128.0/18 100.65.192.0/18
Risorse non allocate 100.{66-71}.0.0/18 100.{66-71}.64.0/18 100.{66-71}.128.0/18 100.{66-71}.192.0/18
Con restrizioni Regione 1 100.72.0.0/18 100.72.64.0/18 100.72.128.0/18 100.72.192.0/18
Regione 2 100.73.0.0/18 100.73.64.0/18 100.73.128.0/18 100.73.192.0/18
Risorse non allocate 100.{74-79}.0.0/18 100.{74-79}.64.0/18 100.{74-79}.128.0/18 100.{74-79}.192.0/18

La tabella precedente illustra questi concetti per l'allocazione di intervalli di indirizzi IP:

  • L'allocazione degli indirizzi IP è suddivisa in intervalli per ogni combinazione di VPC condiviso di base, VPC condiviso limitato, regione e ambiente.
  • Alcune risorse sono globali e non richiedono suddivisioni per ogni regione.
  • Per impostazione predefinita, per le risorse di regione il blueprint viene implementato in due regioni. Inoltre, sono disponibili intervalli di indirizzi IP inutilizzati che ti consentono di espandere la tua attività in altre sei regioni.
  • La rete hub viene utilizzata solo nella topologia di rete hub-and-spoke, mentre gli ambienti di sviluppo, non di produzione e di produzione vengono utilizzati in entrambe le topologie di rete.

La seguente tabella illustra la modalità di utilizzo di ciascun tipo di intervallo di indirizzi IP.

Finalità Descrizione
Intervalli di subnet principali Le risorse di cui esegui il deployment nella rete VPC, ad esempio le istanze di macchine virtuali, utilizzano gli indirizzi IP interni di questi intervalli.
Accesso privato ai servizi Alcuni Google Cloud servizi come Cloud SQL richiedono di preallocare un intervallo di subnet per l'accesso privato ai servizi. Il blueprint riserva un intervallo /21 a livello globale per ciascuna delle reti VPC condivise per allocare indirizzi IP per i servizi che richiedono l'accesso ai servizi privati. Quando crei un servizio che dipende dall'accesso privato ai servizi, alloca una subnet regionale /24 dall'intervallo /21 riservato.
Private Service Connect Il blueprint esegue il provisioning di ogni rete VPC con un endpoint Private Service Connect per comunicare con le API Google Cloud. Questo endpoint consente alle risorse nella rete VPC di raggiungere le API di Google Cloud senza fare affidamento sul traffico in uscita verso internet o su intervalli internet pubblicizzati.
Bilanciatori del carico basati su proxy Alcuni tipi di bilanciatori del carico delle applicazioni richiedono di preallocare subnet solo proxy. Anche se il blueprint non esegue il deployment di bilanciatori del carico delle applicazioni che richiedono questo intervallo, l'allocazione degli intervalli in anticipo contribuisce a ridurre le difficoltà per i carichi di lavoro quando devono richiedere un nuovo intervallo di sottorete per attivare determinate risorse del bilanciatore del carico.
Intervalli di subnet secondari Alcuni casi d'uso, come i carichi di lavoro basati su container, richiedono intervalli secondari. Il blueprint alloca intervalli dallo spazio di indirizzi IP RFC 6598 per gli intervalli secondari.

Configurazione DNS centralizzata

Per la risoluzione DNS tra Google Cloud e gli ambienti on-premise, consigliamo di utilizzare un approccio ibrido con due sistemi DNS autorevoli. In questo approccio, Cloud DNS gestisce la risoluzione DNS autorevole per il tuo ambiente e i tuoi server DNS on-premise esistenti gestiscono la risoluzione DNS autorevole per le risorse on-premise.Google Cloud L'ambiente on-premise e l'ambiente Google Cloud eseguono ricerche DNS tra gli ambienti tramite le richieste di inoltro.

Il seguente diagramma mostra la topologia DNS nelle varie reti VPC utilizzate nel progetto.

Configurazione di Cloud DNS per il blueprint.

Il diagramma descrive i seguenti componenti del design DNS di cui viene eseguito il deployment dal blueprint:

  • Il progetto DNS hub nella cartella comune è il punto centrale dello scambio DNS tra l'ambiente on-premise e l'ambiente Google Cloud. Il forwarding DNS utilizza le stesse istanze di interconnessione dedicata e gli stessi router Cloud già configurati nella topologia di rete.
    • Nella topologia VPC condiviso doppia, l'hub DNS utilizza la rete VPC condiviso di produzione di base.
    • Nella topologia hub e spoke, l'hub DNS utilizza la rete VPC condivisa dell'hub di base.
  • I server di ogni rete VPC condivisa possono risolvere i record DNS di altre reti VPC condivise tramite l'inoltro DNS, che viene configurato tra Cloud DNS in ogni progetto host VPC condiviso e l'hub DNS.
  • I server on-premise possono risolvere i record DNS negli Google Cloud ambienti utilizzando criteri dei server DNS che consentono le query dai server on-premise. Il blueprint configura un criterio del server in entrata nell'hub DNS per allocare gli indirizzi IP e i server DNS on-premise inoltrano le richieste a questi indirizzi. Tutte le richieste DNS devono Google Cloud prima raggiungere l'hub DNS, che poi risolve i record dei peer DNS.
  • I server in Google Cloud possono risolvere i record DNS nell'ambiente on-premise utilizzando zone di inoltro che eseguono query sui server on-premise. Tutte le richieste DNS all'ambiente on-premise provengono dall'hub DNS. L'origine della richiesta DNS è 35.199.192.0/19.

Criteri firewall

Google Cloud ha più tipi di criteri firewall. I criteri firewall gerarchici vengono applicati a livello di organizzazione o cartella per ereditare le regole dei criteri firewall in modo coerente in tutte le risorse della gerarchia. Inoltre, puoi configurare le policy firewall di rete per ogni rete VPC. Il blueprint combina questi criteri firewall per applicare configurazioni comuni a tutti gli ambienti utilizzando i criteri firewall gerarchici e per applicare configurazioni più specifiche a ogni singola rete VPC utilizzando i criteri firewall di rete.

Il blueprint non utilizza regole firewall VPC legacy. Ti consigliamo di utilizzare solo i criteri firewall ed evitare di combinarli con le regole firewall VPC legacy.

Criteri firewall gerarchici

Il blueprint definisce un singolo criterio firewall gerarchico e lo associa a ciascuna delle cartelle di produzione, non di produzione, sviluppo, bootstrap e comuni. Questo criterio firewall gerarchico contiene le regole che devono essere applicate in modo generale a tutti gli ambienti e delega la valutazione di regole più granulari al criterio firewall di rete per ogni singolo ambiente.

La tabella seguente descrive le regole delle policy firewall gerarchiche implementate dal blueprint.

Descrizione regola Direzione del traffico Filtro (intervallo IPv4) Protocolli e porte Azione
Delega la valutazione del traffico in entrata da RFC 1918 ai livelli inferiori della gerarchia. Ingress

192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12

all Go to next
Delega la valutazione del traffico in uscita per RFC 1918 ai livelli inferiori della gerarchia. Egress

192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12

all Go to next
IAP per inoltro TCP Ingress

35.235.240.0/20

tcp:22,3389 Allow
Attivazione di Windows Server Egress

35.190.247.13/32

tcp:1688 Allow
Controlli di integrità per Cloud Load Balancing Ingress

130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22

tcp:80,443 Allow

Criteri firewall di rete

Il blueprint configura un criterio firewall di rete per ogni rete. Ogni criterio del firewall di rete inizia con un insieme minimo di regole che consentono l'accesso ai servizi e negano l'uscita a tutti gli altri indirizzi IP. Google Cloud

Nel modello hub and spoke, i criteri del firewall di rete contengono regole aggiuntive per consentire la comunicazione tra gli spoke. Il criterio del firewall di rete consente il traffico in uscita da uno spoke all'hub o a un altro spoke e consente il traffico in entrata dall'NVA nella rete dell'hub.

La tabella seguente descrive le regole nel criterio del firewall di rete globale impiegato per ogni rete VPC nel blueprint.

Descrizione regola Direzione del traffico Filtro Protocolli e porte
Consenti il traffico in uscita verso le API Google Cloud. Egress L'endpoint Private Service Connect configurato per ogni singola rete. Consulta Accesso privato alle API di Google. tcp:443
Rifiuta il traffico in uscita non corrispondente ad altre regole. Egress tutte all

Consenti il traffico in uscita da uno spoke a un altro spoke (solo per il modello hub and spoke).

Egress L'insieme di tutti gli indirizzi IP utilizzati nella topology hub-and-spoke. Il traffico che esce da un VPC spoke viene instradato prima all'NVA nella rete hub. all

Consenti il traffico in entrata a uno spoke dall'NVA nella rete hub (solo per il modello hub and spoke).

Ingress Traffico proveniente dalle NVA nella rete hub. all

Al primo dispiegamento del blueprint, un'istanza VM in una rete VPC può comunicare con i servizi Google Cloud , ma non con altre risorse di infrastruttura nella stessa rete VPC. Per consentire alle istanze VM di comunicare, devi aggiungere regole aggiuntive al criterio del firewall di rete e ai tag che consentano esplicitamente alle istanze VM di comunicare. I tag vengono aggiunti alle istanze VM e il traffico viene valutato in base a questi tag. Inoltre, i tag dispongono di controlli IAM per consentirti di definirli in modo centralizzato e di delegare il loro utilizzo ad altri team.

Il seguente diagramma mostra un esempio di come puoi aggiungere tag personalizzati e regole dei criteri del firewall di rete per consentire ai carichi di lavoro di comunicare all'interno di una rete VPC.

Regole firewall in example.com.

Il diagramma mostra i seguenti concetti di questo esempio:

  • Il criterio firewall di rete contiene la regola 1 che nega il traffico in uscita da tutte le origini con priorità 65530.
  • Il criterio firewall di rete contiene la regola 2 che consente il traffico in entrata dalle istanze con il tag service=frontend alle istanze con il tag service=backend con priorità 999.
  • La VM istanza-2 può ricevere traffico dall'istanza-1 perché il traffico corrisponde ai tag consentiti dalla regola 2. La regola 2 viene associata prima della valutazione della regola 1, in base al valore della priorità.
  • La VM instance-3 non riceve traffico. L'unica regola del criterio firewall che corrisponde a questo traffico è la Regola 1, pertanto il traffico in uscita dall'istanza 1 viene negato.

Accesso privato alle API Google Cloud

Per consentire alle risorse nelle tue reti VPC o nel tuo ambiente on-premise di raggiungere i serviziGoogle Cloud , consigliamo di utilizzare la connettività privata anziché il traffico internet in uscita verso gli endpoint API pubblici. Il blueprint configura Accesso privato Google su ogni sottorete e crea endpoint interni con Private Service Connect per comunicare con i servizi Google Cloud . Se usati insieme, questi controlli consentono un percorso privato ai servizi Google Cloud , senza fare affidamento sul traffico in uscita di internet o su intervalli di internet pubblicizzati.

Il blueprint configura gli endpoint Private Service Connect con bundle di API per distinguere i servizi a cui è possibile accedere in ciascuna rete. La rete di base utilizza il bundle all-apis e può raggiungere qualsiasi servizio Google, mentre la rete con limitazioni utilizza il bundle vpcsc che consente l'accesso a un insieme limitato di servizi che supportano Controlli di servizio VPC.

Per l'accesso da host in un ambiente on-premise, ti consigliamo di utilizzare una convenzione di FQDN personalizzati per ogni endpoint, come descritto nella tabella seguente. Il blueprint utilizza un endpoint Private Service Connect unico per ogni rete VPC, configurato per l'accesso a un insieme diverso di bundle di API. Pertanto, devi considerare come instradare il traffico di servizio dall'ambiente on-premise alla rete VPC con l'endpoint API corretto e, se utilizzi i Controlli di servizio VPC, assicurarti che il traffico verso i servizi raggiunga l'endpoint all'interno del perimetro previsto. Google Cloud Configura i controlli on-premise per DNS, firewall e router in modo da consentire l'accesso a questi endpoint e configura gli host on-premise in modo che utilizzino l'endpoint appropriato. Per saperne di più, consulta accedere alle API di Google tramite endpoint.

La tabella seguente descrive gli endpoint Private Service Connect creati per ogni rete.

VPC Ambiente Pacchetto di API Indirizzo IP dell'endpoint Private Service Connect FQDN personalizzato
Livelli Comune all-apis 10.17.0.1/32 c.private.googleapis.com
Sviluppo all-apis 10.17.0.2/32 d.private.googleapis.com
Non di produzione all-apis 10.17.0.3/32 n.private.googleapis.com
Produzione all-apis 10.17.0.4/32 p.private.googleapis.com
Con restrizioni Comune vpcsc 10.17.0.5/32 c.restricted.googleapis.com
Sviluppo vpcsc 10.17.0.6/32 d.restricted.googleapis.com
Non di produzione vpcsc 10.17.0.7/32 n.restricted.googleapis.com
Produzione vpcsc 10.17.0.8/32 p.restricted.googleapis.com

Per garantire che il traffico per i Google Cloud servizi abbia una ricerca DNS per l'endpoint corretto, il blueprint configura zone DNS private per ogni rete VPC. La tabella seguente descrive queste zone DNS private.

Nome zona privata Nome DNS Tipo di record Dati
googleapis.com. *.googleapis.com. CNAME private.googleapis.com. (per le reti di base) o restricted.googleapis.com. (per le reti con limitazioni)
private.googleapis.com (per le reti di base) o restricted.googleapis.com (per le reti con limitazioni) A L'indirizzo IP dell'endpoint Private Service Connect per la rete VPC.
gcr.io. *.gcr.io CNAME gcr.io.
gcr.io A L'indirizzo IP dell'endpoint Private Service Connect per la rete VPC.
pkg.dev. *.pkg.dev. CNAME pkg.dev.
pkg.dev. A L'indirizzo IP dell'endpoint Private Service Connect per la rete VPC.

Il blueprint contiene configurazioni aggiuntive per garantire che questi endpoint Private Service Connect vengano utilizzati in modo coerente. Ogni rete VPC condivisa applica inoltre quanto segue:

  • Una regola del criterio del firewall di rete che consente il traffico in uscita da tutte le fonti all'indirizzo IP dell'endpoint Private Service Connect su TCP:443.
  • Una regola del criterio del firewall di rete che nega il traffico in uscita a 0.0.0.0/0, inclusi i domini predefiniti che vengono utilizzati per accedere ai Google Cloud servizi.

Connettività internet

Il blueprint non consente il traffico in entrata o in uscita tra le sue reti VPC e internet. Per i carichi di lavoro che richiedono la connettività a internet, devi eseguire ulteriori passaggi per progettare i percorsi di accesso richiesti.

Per i workload che richiedono traffico in uscita verso internet, ti consigliamo di gestire il traffico in uscita tramite Cloud NAT per consentire il traffico in uscita senza connessioni in entrata non richieste oppure tramite Secure Web Proxy per un controllo più granulare in modo da consentire il traffico in uscita solo per i servizi web attendibili.

Per i carichi di lavoro che richiedono traffico in entrata da internet, ti consigliamo di progettarli con Cloud Load Balancing e Google Cloud Armor per usufruire delle protezioni DDoS e WAF.

Sconsigliamo di progettare carichi di lavoro che consentano la connettività diretta tra internet e una VM utilizzando un indirizzo IP esterno sulla VM.

Connettività ibrida tra un ambiente on-premise e Google Cloud

Per stabilire la connettività tra l'ambiente on-premise e Google Cloud, ti consigliamo di utilizzare Dedicated Interconnect per massimizzare la sicurezza e l'affidabilità. Una connessione di Dedicated Interconnect è un collegamento diretto tra la tua rete on-premise eGoogle Cloud.

Il seguente diagramma mostra la connettività ibrida tra l'ambiente on-premise e una rete Google Virtual Private Cloud.

La struttura della connessione ibrida.

Il diagramma descrive i seguenti componenti del pattern per la disponibilità del 99,99% per Dedicated Interconnect:

  • Quattro connessioni Dedicated Interconnect, con due connessioni in un'area metropolitana (metro) e due connessioni in un'altra area metropolitana. All'interno di ogni area metropolitana, la struttura di colocation ha due zone distinte.
  • Le connessioni sono suddivise in due coppie, ciascuna connessa a un data center on-premise separato.
  • I collegamenti VLAN vengono utilizzati per connettere ogni istanza Dedicated Interconnect ai router cloud collegati alla topologia VPC condivisa.
  • Ogni rete VPC condivisa ha quattro router Cloud, due in ogni regione, con la modalità di routing dinamico impostata su global in modo che ogni router Cloud possa annunciare tutte le subnet, indipendentemente dalla regione.

Con il routing dinamico globale, Cloud Router pubblicizza le route per tutte le reti VPN nella rete VPC. Cloud Router annuncia le route alle subnet remote (subnet al di fuori della regione del router Cloud) con una priorità inferiore rispetto alle subnet locali (subnet nella regione del router Cloud). Se vuoi, puoi modificare prefi e priorità pubblicizzati quando configuri la sessione BGP per un router Cloud.

Il traffico da Google Cloud a un ambiente on-premise utilizza il router Cloud più vicino alle risorse cloud. All'interno di un'unica regione, più route per le reti on-premise hanno lo stesso valore del discriminatore di più uscite (MED) e Google Cloud utilizzano il routing ECMP (Equal-cost multipath) per distribuire il traffico in uscita tra tutti i route possibili.

Modifiche alla configurazione on-premise

Per configurare la connettività tra l'ambiente on-premise eGoogle Cloud, devi apportare ulteriori modifiche nell'ambiente on-premise. Il codice Terraform nel blueprint configura automaticamente le risorseGoogle Cloud , ma non modifica le risorse di rete on-premise.

Alcuni dei componenti per la connettività ibrida dal tuo ambiente on-premise a Google Cloud vengono attivati automaticamente dal blueprint, tra cui:

  • Cloud DNS è configurato con l'inoltro DNS tra tutte le reti VPC condivise a un singolo hub, come descritto nella configurazione DNS. Un criterio del server Cloud DNS è configurato con indirizzi IP dei forwarder in entrata.
  • Cloud Router è configurato per esportare route per tutte le subnet e route personalizzate per gli indirizzi IP utilizzati dagli endpoint Private Service Connect.

Per attivare la connettività ibrida, devi svolgere i seguenti passaggi aggiuntivi:

  1. Ordina una connessione Dedicated Interconnect.
  2. Configura i router e i firewall on-premise per consentire il traffico in uscita allo spazio degli indirizzi IP interno definito nell'allocazione dello spazio degli indirizzi IP.
  3. Configura i server DNS on-premise in modo che inoltrino le ricerche DNS destinate aGoogle Cloud agli indirizzi IP dei forwarder in entrata già configurati dal blueprint.
  4. Configura i server DNS, i firewall e i router on-premise in modo che accettino le query DNS dalla zona di inoltro Cloud DNS (35.199.192.0/19).
  5. Configura i server DNS on-premise in modo che rispondano alle query degli host on-premise ai Google Cloud servizi con gli indirizzi IP definiti in accesso privato alle API Cloud.
  6. Per la crittografia in transito tramite la connessione Dedicated Interconnect, configura MACsec per Cloud Interconnect o VPN ad alta disponibilità su Cloud Interconnect per la crittografia IPsec.

Per saperne di più, consulta Accesso privato Google per gli host on-premise.

Passaggi successivi