Il networking è necessario per consentire alle risorse di comunicare all'interno della tua organizzazione Google Cloud e tra l'ambiente cloud e l'ambiente on-premise. Questa sezione descrive la struttura nel progetto per reti VPC, spazio di indirizzi IP, DNS, criteri firewall e connettività all'ambiente on-premise.
Topologia di rete
Il repository di progetti offre le seguenti opzioni per la topologia di rete:
- Utilizza reti VPC condiviso separate per ogni ambiente, senza traffico di rete consentito direttamente tra gli ambienti.
- Utilizza un modello hub e spoke che aggiunga una rete hub per connettere ogni ambiente in Google Cloud, con il traffico di rete tra gli ambienti controllati da un'appliance virtuale di rete (NVA).
Scegli la topologia di rete VPC condiviso doppia quando non vuoi connettività di rete diretta tra ambienti. Scegli la topologia di rete hub e spoke quando vuoi consentire la connettività di rete tra ambienti filtrati da un NVA, ad esempio quando fai affidamento su strumenti esistenti che richiedono un percorso di rete diretto a ogni server nel tuo ambiente.
Entrambe le topologie utilizzano il VPC condiviso come principale costrutto di networking perché il VPC condiviso consente una chiara separazione delle responsabilità. Gli amministratori di rete gestiscono le risorse di rete in un progetto host centralizzato e i team dei carichi di lavoro eseguono il deployment delle proprie risorse delle applicazioni e consumano le risorse di rete nei progetti di servizio collegati al progetto host.
Entrambe le topologie 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 limitata viene utilizzata per le risorse con dati sensibili che richiedono 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 doppia condivisa
Se hai bisogno dell'isolamento della rete tra le tue reti di sviluppo, non di produzione e di produzione su Google Cloud, ti consigliamo la topologia di rete VPC condiviso doppia. Questa topologia utilizza reti VPC condiviso separate per ogni ambiente, con ogni ambiente suddiviso ulteriormente tra una rete VPC condiviso di base e una rete VPC condiviso limitata.
Il seguente diagramma mostra la topologia di rete VPC condiviso a doppia.
Il diagramma descrive i seguenti concetti chiave della topologia VPC condiviso doppia:
- Ogni ambiente (di produzione, non di produzione e di sviluppo) ha una rete VPC condiviso per la rete di base e una rete VPC condiviso per la rete limitata. Questo diagramma mostra solo l'ambiente di produzione, ma lo stesso pattern viene ripetuto per ogni ambiente.
- Ogni rete VPC condivisa ha due subnet, ognuna in una regione diversa.
- La connettività con le risorse on-premise viene abilitata attraverso quattro collegamenti VLAN all'istanza Dedicated Interconnect per ogni rete VPC condiviso, utilizzando quattro servizi router Cloud (due in ogni regione per la ridondanza). Per maggiori informazioni, consulta Connettività ibrida tra ambiente on-premise e Google Cloud.
Questa topologia non consente il flusso del traffico di rete direttamente tra gli ambienti. Se invece hai bisogno che il traffico di rete passi direttamente da un ambiente all'altro, devi adottare ulteriori passaggi per consentire questo percorso di rete. Ad esempio, puoi configurare gli endpoint Private Service Connect per esporre un servizio da una rete VPC a un'altra. In alternativa, puoi configurare la rete on-premise in modo da consentire il flusso del traffico da un ambiente Google Cloud all'ambiente on-premise e poi a un altro ambiente Google Cloud.
Topologia di rete hub e 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 e spoke.
La topologia hub e spoke utilizza molti dei concetti che fanno parte della topologia di due VPC condiviso, ma modifica la topologia per aggiungere una rete hub. Il seguente diagramma mostra la topologia hub e spoke.
Il diagramma descrive i seguenti concetti chiave della topologia di rete hub e spoke:
- Questo modello aggiunge una rete hub e ciascuna delle reti di sviluppo, non di produzione e di produzione (spoke) è connessa 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 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, il cui deployment viene eseguito in modo ridondante dietro istanze di Network Load Balancer interni. Questo NVA funge da gateway per consentire o negare il traffico per la comunicazione tra 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 su istanze VM per la gestione della configurazione nell'ambiente comune.
- Il modello hub e spoke è duplicato per una versione di base e una versione limitata di ogni rete.
Per abilitare il traffico spoke-to-spoke, il progetto esegue il deployment di NVA sulla rete VPC condiviso dell'hub che agiscono da gateway tra le reti. Le route vengono scambiate da reti VPC hub-spoke attraverso lo scambio di route personalizzate. In questo scenario, la connettività tra spoke deve essere instradata attraverso l'NVA perché il peering di rete VPC non è transitorio e, di conseguenza, le reti VPC spoke non possono scambiarsi dati direttamente tra loro. Devi configurare le appliance virtuali per consentire selettivamente il traffico tra gli spoke.
Per ulteriori informazioni sull'utilizzo di NVA per controllare il traffico tra spoke, consulta appliance di rete centralizzate su Google Cloud.
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 rete esistente. La tabella seguente descrive i pattern per il deployment dei progetti utilizzati nel progetto base.
| Pattern | Descrizione | Esempio di utilizzo |
|---|---|---|
| Progetti di base condivisi | Questi progetti sono configurati come progetti di servizio in un progetto host VPC condiviso di base. Utilizza questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri:
|
example_base_shared_vpc_project.tf |
| Progetti limitati condivisi | Questi progetti sono configurati come progetti di servizio in un progetto host VPC condiviso limitato. Utilizza questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri:
|
example_restricted_shared_vpc_project.tf |
| Progetti mobili | I progetti floating non sono connessi ad altre reti VPC nella topologia. Utilizza questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri:
Potresti avere uno scenario in cui vuoi mantenere la rete VPC di un progetto mobile separata dalla topologia di 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 di rete a un singolo endpoint nelle reti VPC senza esporre l'intera rete. |
example_floating_project.tf |
| Progetti di peering | I progetti di peering creano le proprie reti VPC e sono in peering con altre reti VPC della tua topologia. Utilizza questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri:
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 progetto alloca gli intervalli di indirizzi IP. Potrebbe essere necessario modificare gli intervalli specifici di indirizzi IP utilizzati in base alla disponibilità degli indirizzi IP nell'ambiente ibrido esistente.
La seguente tabella fornisce un'analisi dello spazio di indirizzi IP allocato per il progetto base. L'ambiente hub si applica solo nella topologia hub e 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 | ||
| Non allocata | 10.{2-7}.0.0/18 | 10.{2-7},64,0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
| Limitato | 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 | ||
| Non allocata | 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 |
| Limitato | 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 |
| Limitato | 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 | ||
| Non allocata | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
| Limitato | 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 | ||
| Non allocata | 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 secondarie | 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 | ||
| Non allocata | 100,{66-71},0,0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
| Limitato | 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 | ||
| Non allocata | 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 deployment del progetto base viene eseguito in due regioni. Inoltre, esistono intervalli di indirizzi IP inutilizzati che ti consentono di espandere la copertura in altre sei regioni.
- La rete hub viene utilizzata solo nella topologia di rete hub e spoke, mentre gli ambienti di sviluppo, non produzione e produzione vengono utilizzati in entrambe le topologie di rete.
La tabella seguente illustra come viene utilizzato ogni tipo di intervallo di indirizzi IP.
| Finalità | Descrizione |
|---|---|
| Intervalli di subnet principali | Le risorse di cui esegui il deployment nella rete VPC, ad esempio istanze di macchina virtuale, utilizzano gli indirizzi IP interni di questi intervalli. |
| Accesso privato ai servizi | Alcuni servizi Google Cloud, come Cloud SQL, richiedono di preallocare un intervallo di subnet per l'accesso privato ai servizi. Il progetto riserva un intervallo /21 a livello globale per ciascuna delle reti VPC condiviso per allocare indirizzi IP per i servizi che richiedono l'accesso privato ai servizi. Quando crei un servizio che dipende dall'accesso privato ai servizi, allochi una subnet /24 a livello di regione dall'intervallo /21 prenotato. |
| Private Service Connect | Il progetto esegue il provisioning di ogni rete VPC con un endpoint Private Service Connect per comunicare con le API Google Cloud. Questo endpoint consente alle tue risorse nella rete VPC di raggiungere le API Google Cloud senza fare affidamento sul traffico in uscita verso internet o su intervalli internet pubblicizzati pubblicamente. |
| Bilanciatori del carico basati su proxy | Alcuni tipi di bilanciatori del carico delle applicazioni richiedono di preallocare subnet solo proxy. Anche se il progetto base non esegue il deployment di bilanciatori del carico delle applicazioni che richiedono questo intervallo, l'allocazione anticipata degli intervalli aiuta a ridurre l'attrito per i carichi di lavoro quando è necessario richiedere un nuovo intervallo di subnet per abilitare determinate risorse del bilanciatore del carico. |
| Intervalli di subnet secondarie | Alcuni casi d'uso, ad esempio i carichi di lavoro basati su container, richiedono intervalli secondari. Il progetto assegna intervalli dallo spazio di indirizzi IP RFC 6598 per gli intervalli secondari. |
Configurazione del DNS centralizzato
Per la risoluzione DNS tra Google Cloud e ambienti on-premise, consigliamo di utilizzare un approccio ibrido con due sistemi DNS autorevoli. In questo approccio, Cloud DNS gestisce la risoluzione DNS autoritativa per il tuo ambiente Google Cloud e i tuoi server DNS on-premise esistenti gestiscono una risoluzione DNS autorevole per le risorse on-premise. L'ambiente on-premise e l'ambiente Google Cloud eseguono ricerche DNS tra gli ambienti tramite richieste di inoltro.
Il seguente diagramma mostra la topologia DNS tra le diverse reti VPC utilizzate nel progetto base.
Il diagramma descrive i seguenti componenti della progettazione DNS di cui viene eseguito il deployment dal progetto base:
- Il progetto hub DNS nella cartella comune è il punto centrale dello scambio DNS tra l'ambiente on-premise e l'ambiente Google Cloud. L'inoltro DNS utilizza le stesse istanze di Dedicated Interconnect e gli stessi router Cloud già configurati nella tua 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 condiviso 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 del VPC condiviso e nell'hub DNS.
- I server on-premise possono risolvere i record DNS negli ambienti Google Cloud utilizzando i criteri dei server DNS che consentono query dai server on-premise. Il progetto 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 inviate a Google Cloud raggiungono prima l'hub DNS, che poi risolve i record relativi ai peer DNS.
- I server in Google Cloud possono risolvere i record DNS nell'ambiente on-premise utilizzando le zone di forwarding che eseguono query sui server on-premise. Tutte le richieste DNS inviate all'ambiente on-premise provengono dall'hub DNS. L'origine della richiesta DNS è 35.199.192.0/19.
Criteri firewall
Google Cloud ha diversi 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 nella gerarchia. Inoltre, puoi configurare i criteri firewall di rete per ogni rete VPC. Il progetto combina questi criteri firewall per applicare configurazioni comuni in tutti gli ambienti utilizzando criteri firewall gerarchici e per applicare configurazioni più specifiche a ogni singola rete VPC utilizzando i criteri firewall di rete.
Il progetto non utilizza regole firewall VPC legacy. Consigliamo di utilizzare solo i criteri firewall ed evitare di combinare l'utilizzo con le regole firewall VPC legacy.
Criteri firewall gerarchici
Il progetto definisce un singolo criterio firewall gerarchico e lo collega a ciascuna delle cartelle di produzione, non di produzione, di sviluppo, bootstrap e comuni. Questo criterio firewall gerarchico contiene le regole che devono essere applicate in modo ampio in 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 dei criteri firewall gerarchici di cui è stato eseguito il deployment dal progetto base.
| 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 a 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 forwarding TCP | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
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 progetto configura un criterio firewall di rete per ogni rete. Ogni criterio firewall di rete inizia con un insieme minimo di regole che consentono l'accesso ai servizi Google Cloud e negano il traffico in uscita verso tutti gli altri indirizzi IP.
Nel modello hub e spoke, i criteri firewall di rete contengono regole aggiuntive per consentire la comunicazione tra spoke. Il criterio firewall di rete consente il traffico in uscita da uno all'hub o a un altro spoke e consente il traffico in entrata dall'NVA nella rete dell'hub.
La seguente tabella descrive le regole nel criterio firewall di rete globale di cui è stato eseguito il deployment per ogni rete VPC nel progetto.
| 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. Vedi Accesso privato alle API di Google. | tcp:443 |
| Rifiuta il traffico in uscita che non corrisponde ad altre regole. | Egress |
tutte | all |
Consenti il traffico in uscita da uno spoke a un altro (solo per il modello hub e spoke). |
Egress |
L'aggregazione di tutti gli indirizzi IP utilizzati nella topologia hub e spoke. Il traffico che lascia un VPC spoke viene instradato prima all'NVA nella rete hub. | all |
Consenti il traffico in entrata verso uno spoke dall'NVA nella rete hub (solo per il modello hub e spoke). |
Ingress |
Traffico proveniente dagli NVA nella rete hub. | all |
Al primo deployment del progetto base, 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 la comunicazione tra le istanze VM, devi aggiungere regole aggiuntive al criterio firewall di rete e ai tag che consentono esplicitamente alle istanze VM di comunicare. I tag vengono aggiunti alle istanze VM e il traffico viene valutato in base a questi tag. I tag dispongono inoltre di controlli IAM che consentono di definirli centralmente e delegare il loro utilizzo ad altri team.
Il seguente diagramma mostra un esempio di come aggiungere tag personalizzati e regole dei criteri firewall di rete per consentire ai carichi di lavoro di comunicare all'interno di una rete VPC.
Il diagramma illustra 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 tag
service=frontendalle istanze con tagservice=backendcon priorità 999. - La VM istanza-2 può ricevere traffico dall'istanza-1 perché corrisponde ai tag consentiti dalla regola 2. La corrispondenza della regola 2 viene eseguita prima della valutazione della regola 1, in base al valore di priorità.
- La VM istanza-3 non riceve traffico. L'unica regola del criterio firewall che corrisponde a questo traffico è la Regola 1, quindi il traffico in uscita dall'istanza-1 viene negato.
Accesso privato alle API Google Cloud
Per consentire alle risorse nelle reti VPC o nell'ambiente on-premise di raggiungere i servizi Google Cloud, consigliamo la connettività privata anziché in uscita del traffico internet verso endpoint API pubblici. Il progetto configura l'accesso privato Google su ogni subnet e crea endpoint interni con Private Service Connect per comunicare con i servizi Google Cloud. Utilizzati insieme, questi controlli consentono un percorso privato ai servizi Google Cloud, senza fare affidamento sul traffico in uscita da Internet o sugli intervalli internet pubblicizzati pubblicamente.
Il progetto configura gli endpoint Private Service Connect con
pacchetti API
per differenziare i servizi in cui è possibile accedere in quale rete. La rete di base utilizza il pacchetto all-apis e può raggiungere qualsiasi servizio Google, mentre la rete limitata utilizza il pacchetto vpcsc, che consente l'accesso a un insieme limitato di servizi che supportano i Controlli di servizio VPC.
Per l'accesso da host che si trovano in un ambiente on-premise, consigliamo di utilizzare una convenzione di nome di dominio completo personalizzato per ogni endpoint, come descritto nella tabella seguente. Il progetto utilizza un endpoint Private Service Connect univoco per ogni rete VPC, configurato per l'accesso a un set diverso di bundle API. Pertanto, devi considerare come instradare il traffico dei servizi dall'ambiente on-premise alla rete VPC con l'endpoint API corretto e, se utilizzi Controlli di servizio VPC, assicurati che il traffico verso i servizi Google Cloud raggiunga l'endpoint all'interno del perimetro previsto. Configura i controlli on-premise per DNS, firewall e router per consentire l'accesso a questi endpoint e configura gli host on-premise per l'utilizzo dell'endpoint appropriato. Per ulteriori informazioni, consulta Accedere alle API di Google tramite endpoint.
La tabella seguente descrive gli endpoint Private Service Connect creati per ogni rete.
| VPC | Ambiente | Bundle di API | Indirizzo IP dell'endpoint Private Service Connect | Nome di dominio completo 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 |
|||||
| Production | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
| Limitato | 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 |
|||||
| Production | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
|||||
Per garantire che il traffico per i servizi Google Cloud abbia una ricerca DNS verso l'endpoint corretto, il progetto configura le 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 limitate) |
private.googleapis.com (per le reti di base) o restricted.googleapis.com (per le reti limitate) |
A |
L'indirizzo IP dell'endpoint di Private Service Connect per quella rete VPC. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
L'indirizzo IP dell'endpoint di Private Service Connect per quella rete VPC. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
L'indirizzo IP dell'endpoint di Private Service Connect per quella rete VPC. |
Il progetto prevede configurazioni aggiuntive per fare in modo che questi endpoint Private Service Connect vengano utilizzati in modo coerente. Ogni rete VPC condiviso applica anche le seguenti impostazioni:
- Una regola del criterio firewall di rete che consente il traffico in uscita da tutte le origini all'indirizzo IP dell'endpoint Private Service Connect su TCP:443.
- Una regola del criterio firewall di rete che nega il traffico in uscita a 0.0.0.0/0, che include i domini predefiniti utilizzati per l'accesso ai servizi Google Cloud.
Connessione a internet
Il progetto non consente il traffico in entrata o in uscita tra le sue reti VPC e internet. Per i carichi di lavoro che richiedono una connessione a internet, devi seguire ulteriori passaggi per progettare i percorsi di accesso richiesti.
Per i carichi di lavoro che richiedono il traffico 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 o tramite Secure Web Proxy per un controllo più granulare e consentire il traffico in uscita solo verso 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 sfruttare le 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 Dedicated Interconnect è un collegamento diretto tra la tua rete on-premise e Google Cloud.
Il seguente diagramma introduce la connettività ibrida tra l'ambiente on-premise e una rete Google Virtual Private Cloud.
Il diagramma descrive i seguenti componenti del pattern per la disponibilità del 99,99% per Dedicated Interconnect:
- Quattro connessioni Dedicated Interconnect, con due in un'area metropolitana (area metropolitana) e due in un'altra.
- Le connessioni sono divise in due coppie, ciascuna delle quali è 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 condiviso. Questi collegamenti VLAN sono ospitati nel progetto
prj-c-interconnect. - Ogni rete VPC condivisa ha quattro router Cloud, due in ogni regione, con la modalità di routing dinamico impostata su
globalin modo che ogni router Cloud possa annunciare tutte le subnet, indipendentemente dalla regione.
Con il routing dinamico globale, il router Cloud pubblicizza le route a tutte le subnet nella rete VPC. Il router Cloud pubblicizza route verso subnet remote (subnet all'esterno della regione del router Cloud) con una priorità più bassa rispetto alle subnet locali (subnet che si trovano nella regione del router Cloud). Facoltativamente, puoi modificare i prefissi e le 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 una singola regione, più route verso reti on-premise hanno lo stesso valore MED (multi-exit discriminator) e Google Cloud utilizza il routing ECMP (equal cost multi-path) per distribuire il traffico in uscita tra tutte le route possibili.
Modifiche alla configurazione on-premise
Per configurare la connettività tra l'ambiente on-premise e Google Cloud, devi configurare ulteriori modifiche all'ambiente on-premise. Il codice Terraform nel progetto configura automaticamente le risorse Google 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 abilitati automaticamente dal progetto, inclusi i seguenti:
- Cloud DNS è configurato con l'inoltro DNS tra tutte le reti VPC condiviso a un singolo hub, come descritto in Configurazione DNS. Un criterio del server Cloud DNS è configurato con indirizzi IP del forwarding in entrata.
- Il router Cloud è configurato per esportare le route per tutte le subnet e le route personalizzate per gli indirizzi IP utilizzati dagli endpoint Private Service Connect.
Per abilitare la connettività ibrida, devi seguire questi passaggi aggiuntivi:
- Ordina una connessione Dedicated Interconnect.
- Configura router e firewall on-premise per consentire il traffico in uscita verso lo spazio di indirizzi IP interni definito nell'allocazione dello spazio di indirizzi IP.
- Configura i tuoi server DNS on-premise per inoltrare le ricerche DNS associate a Google Cloud agli indirizzi IP del forwarding in entrata già configurati dal progetto base.
- Configura i server DNS, i firewall e i router on-premise in modo che accettino query DNS dalla zona di forwarding di Cloud DNS (35.199.192.0/19).
- Configura i server DNS on-premise per rispondere alle query dagli host on-premise ai servizi Google Cloud con gli indirizzi IP definiti nell'accesso privato alle API Cloud.
- Per la crittografia dei dati in transito sulla connessione Dedicated Interconnect, configura MACsec per Cloud Interconnect o la VPN ad alta disponibilità su Cloud Interconnect per la crittografia IPsec.
Per maggiori informazioni, consulta Accesso privato Google per gli host on-premise.
Passaggi successivi
- Leggi informazioni sui controlli di rilevamento (prossimo documento di questa serie).