La rete è necessaria per la comunicazione delle risorse all'interno della tua organizzazione Google Cloud e tra l'ambiente cloud e quello on-premise. Questa sezione descrive la struttura del progetto base per le reti VPC, di indirizzi IP, DNS, criteri firewall e connettività completamente gestito di Google Cloud.
Topologia di rete
Il repository dei progetti offre le seguenti opzioni per la tua rete topologia:
- Utilizza reti VPC condivise separate per ogni ambiente, senza traffico di rete consentito direttamente tra gli ambienti.
- Usa un modello hub e spoke che aggiunge una rete hub per collegare ogni in Google Cloud, con il traffico di rete tra ambienti controllati 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 il 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, i team che si occupano di carichi di lavoro e di carichi di lavoro eseguono il deployment delle proprie risorse delle applicazioni e utilizzano di risorse di rete nei progetti di servizio collegate al progetto host.
Entrambe le topologia includono una versione di base e una limitata di ogni rete VPC. La La rete VPC di base viene utilizzata per le risorse che contengono dati non sensibili, mentre 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 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.
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, ognuna delle quali in un regione diversa.
- La connettività con risorse on-premise è abilitata tramite quattro VLAN di connessione all'istanza Dedicated Interconnect Rete VPC condiviso, utilizzando quattro servizi di router Cloud (due in ogni regione per la ridondanza). Per ulteriori informazioni, vedi Connettività ibrida tra ambiente on-premise e Google Cloud.
Per impostazione predefinita, questa topologia non consente al traffico di rete di fluire direttamente tra ambienti cloud-native. Se vuoi che il traffico di rete fluisca direttamente tra gli ambienti, devi eseguire ulteriori passaggi per consentire questo percorso di rete. Per 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 tua rete on-premise per consentire il flusso del traffico da dall'ambiente Google Cloud all'ambiente on-premise e quindi in un altro ambiente 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 e spoke.
Il diagramma descrive questi concetti chiave della topologia di rete hub e spoke:
- Questo modello aggiunge una rete hub e ciascuna delle risorse di sviluppo, non di produzione e le reti di produzione (spoke) siano collegate tramite 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 sulla tua rete Hub. Tutte le reti spoke possono comunicare con dispositivi di risorse nella rete hub e usa questo percorso per connetterti a reti on-premise reti.
- 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. Questo NVA funge da gateway per consentire o negare al traffico la comunicazione tra spoke reti.
- La rete hub ospita anche strumenti che richiedono la connettività ad 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 è 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 sono scambiato da reti VPC hub-to-spoke attraverso lo scambio di route personalizzate. In questo scenario, la connettività tra gli spoke deve essere instradata tramite la 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 per connetterti alla tua rete esistente. Nella tabella seguente vengono descritti 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 per un progetto host VPC condiviso di base. Usa questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri:
|
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:
|
example_restricted_shared_vpc_project.tf |
| Progetti inutilizzati | I progetti mobili non sono connessi ad altre reti VPC nella tua topologia. Usa questo pattern quando le risorse nel tuo progetto hanno i seguenti criteri:
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 servizi utilizzando Private Service Connect per condividere l'accesso di rete un singolo endpoint nelle reti VPC senza esporre dell'intera rete. |
example_floating_project.tf |
| Progetti di peering | I progetti di peering creano le proprie reti VPC ed eseguono il peering ad altri reti VPC nella tua topologia. Utilizza questo pattern quando le risorse del progetto soddisfano 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 blueprint alloca gli intervalli di indirizzi IP. Potrebbe essere necessario modificare gli intervalli di indirizzi IP specifici utilizzati in base la disponibilità dell'indirizzo 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 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 allocati | 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 | ||
| Non allocati | 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 | ||
| Non allocati | 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 | ||
| Non allocati | 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 | ||
| 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 | ||
| 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 | ||
| Non allocati | 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. Nella Inoltre, esistono intervalli di indirizzi IP inutilizzati che ti consentono di sei regioni aggiuntive.
- 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 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 sulla rete VPC, ad esempio di Compute Engine, utilizza indirizzi IP interni di questi intervalli. |
| Accesso privato ai servizi | Alcuni servizi Google Cloud, come Cloud SQL, richiedono è possibile 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 dipende dall'accesso privato ai servizi, allochi un /24 a livello di regione una subnet dall'intervallo /21 riservato. |
| Private Service Connect | Il progetto esegue il provisioning di ogni rete VPC con un servizio Private Service Connect per comunicare con le API Google Cloud. Questo endpoint consente alle risorse nella rete VPC di raggiungere le API Cloud senza dover fare affidamento sul traffico in uscita verso o intervalli internet pubblicizzati pubblicamente. |
| Bilanciatori del carico basati su proxy | Alcuni tipi di bilanciatori del carico delle applicazioni richiedono prealloca subnet solo proxy. Sebbene Il progetto base non esegue il deployment di bilanciatori del carico delle applicazioni che lo richiedono l'allocazione in anticipo degli intervalli contribuisce a ridurre l'attrito carichi di lavoro quando devono richiedere un nuovo intervallo di subnet per abilitare alcune risorse del bilanciatore del carico. |
| Intervalli di subnet secondari | Alcuni casi d'uso, come i carichi di lavoro basati su container, richiedono intervalli secondari. Lo schema alloca intervalli dallo spazio di indirizzi IP RFC 6598 per intervalli di tempo. |
Configurazione DNS centralizzata
Per la risoluzione DNS tra Google Cloud e gli ambienti on-premise, ti consigliamo di utilizzare un approccio ibrido con due sistemi DNS autorevoli. Nella questo approccio, Cloud DNS gestisce la risoluzione DNS autoritativa per i tuoi L'ambiente Google Cloud e i tuoi server DNS on-premise esistenti gestiscono una risoluzione DNS autoritativa per le risorse on-premise. 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 in più VPC reti usate nel progetto.
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 dedicate e gli stessi router Cloud già configurati nella topologia di rete.
- Nella doppia topologia VPC condiviso, l'hub DNS utilizza rete VPC condiviso di produzione di base.
- Nella topologia hub and 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 in Google Cloud ambienti che utilizzano Criteri del server DNS che consentono query da server on-premise. Il progetto configura 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. Tutti i DNS a Google Cloud raggiungono prima l'hub DNS, che poi viene risolto e record dei peer DNS.
- I server in Google Cloud possono risolvere i record DNS nell'ambiente on-premise utilizzando le 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 dispone di diversi tipi di criteri firewall. I criteri firewall gerarchici sono applicati a livello di organizzazione o cartella livello per ereditare le regole del criterio firewall in modo coerente su tutte le risorse nella gerarchia. Inoltre, puoi configurare criteri firewall di rete per ogni VPC in ogni rete. Il progetto combina questi criteri firewall per applicare criteri configurazioni in tutti gli ambienti utilizzando i criteri firewall gerarchici di applicare configurazioni più specifiche a ogni singola rete VPC utilizzando e i criteri firewall di rete.
Il progetto 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 progetto definisce un singolo criterio firewall gerarchico e allega le norme a ciascun team di produzione, non di produzione, sviluppo bootstrap e cartelle comuni. Questo criterio firewall gerarchico contiene le regole che devono essere applicate 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 dei criteri firewall gerarchici di cui è stato eseguito il deployment in base al progetto.
| 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 TCP inoltro | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
Allow |
| Attivazione server Windows | 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 criterio firewall di rete per ogni rete. Ogni criterio firewall di rete viene avviato con un set minimo di che consentono l'accesso ai servizi Google Cloud e negano il traffico in uscita verso tutti da altri indirizzi IP.
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 del criterio firewall di rete globale per ogni rete VPC nel progetto base.
| 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 lascia un VPC spoke viene instradato all'NVA nella prima 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 dalle NVA nella rete hub. | all |
Quando esegui il deployment del progetto per la prima volta, un'istanza VM in una rete VPC comunicare con i servizi Google Cloud, ma non con altre infrastrutture 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 consentono 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 aggiungere tag personalizzati e regole del criterio firewall di rete per consentire ai carichi di lavoro di comunicare all'interno di un VPC in ogni rete.
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=frontenda quelle con il tagservice=backendcon priorità 999. - La VM istanza 2 può ricevere traffico dall'istanza 1 perché corrisponde ai tag consentiti dalla Regola 2. La regola 2 corrisponde prima della regola 1 viene valutato 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 servizi Google Cloud, consigliamo la connettività privata anziché il traffico internet in uscita verso gli endpoint API pubblici. Il progetto configura Accesso privato Google su ogni subnet e crea endpoint interni 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 base
utilizza il bundle all-apis e può raggiungere qualsiasi servizio Google, mentre
rete con restrizioni usa il bundle vpcsc, che consente l'accesso a un
insieme di servizi
supportano i Controlli di servizio VPC.
Per l'accesso da host che si trovano in un ambiente on-premise, è consigliabile utilizzare una convenzione di nome di dominio completo personalizzato 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 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 configurare host on-premise per utilizzare l'endpoint appropriato. Per ulteriori informazioni, vedi 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 | 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 assicurarti che il traffico per i servizi Google Cloud abbia una ricerca DNS verso il endpoint corretto, il progetto configura zone DNS private per ogni VPC in ogni rete. 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 base
reti) o restricted.googleapis.com. (per
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 di Private Service Connect per quella 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 progetto prevede configurazioni aggiuntive per assicurare che tali Gli endpoint di Private Service Connect vengono utilizzati in modo coerente. Ciascuna La rete VPC condiviso applica anche 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 firewall di rete che nega il traffico in uscita verso 0.0.0.0/0, che include domini predefiniti utilizzate per accedere ai servizi Google Cloud.
Connettività a 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 una connessione a internet, per progettare i percorsi di accesso richiesti.
Per i carichi di lavoro 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 servizi web attendibili.
Per i carichi di lavoro che richiedono traffico in entrata da internet, consigliamo di devi progettare il tuo carico di lavoro Cloud Load Balancing e Google Cloud Armor per trarre vantaggio dalle protezioni DDoS e WAF.
Sconsigliamo di progettare carichi di lavoro che consentano la connettività diretta connessione tra internet e una VM usando un indirizzo IP esterno sulla VM.
Connettività ibrida tra un ambiente on-premise e Google Cloud
a stabilire la connettività tra l'ambiente on-premise e Google Cloud, ti consigliamo di utilizzare Interconnessione dedicata 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 illustra la connettività ibrida tra ambienti on-premise dell'ambiente di rete e una rete Google Virtual Private Cloud.
Il diagramma descrive i seguenti componenti del pattern per 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, sono presenti due zone distinte all'interno della completamente gestita.
- 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,
ogni regione, con la modalità di routing dinamico impostata su
globalin modo che ogni Il router Cloud può annunciare tutte le subnet, indipendentemente dalla regione.
Con il routing dinamico globale, Cloud Router annuncia le route a tutte le subreti della 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 una singola regione, più route a reti on-premise hanno lo stesso discriminatore di uscita con più uscite (MED) e Google Cloud utilizza 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 modifiche aggiuntive nella tua struttura completamente gestito di Google Cloud. Il codice Terraform nel progetto configura automaticamente alle risorse Google Cloud, ma non modifica nessuna rete on-premise Google Cloud.
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 il forwarding DNS tra tutti Reti VPC condiviso in un singolo hub, come descritto in Configurazione DNS. È stato configurato un criterio del server Cloud DNS con indirizzi IP di inoltro 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 abilitare la connettività ibrida, devi seguire questi passaggi aggiuntivi:
- Ordina una connessione Dedicated Interconnect.
- 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.
- Configura i server DNS on-premise in modo che inoltrino le ricerche DNS destinate a Google Cloud agli indirizzi IP dei forwarder in entrata già configurati dal blueprint.
- Configura i server DNS, i firewall e i router on-premise in modo che accettino Query DNS da Cloud DNS zona di inoltro (35.199.192.0/19).
- Configura i server DNS on-premise in modo che rispondano alle query degli host on-premise ai servizi Google Cloud con gli indirizzi IP definiti nell'accesso privato alle API Cloud.
- Per la crittografia in transito tramite la connessione di Cloud Interconnect dedicato, configura MACsec per Cloud Interconnect o VPN ad alta disponibilità su Cloud Interconnect per la crittografia IPsec.
Per ulteriori informazioni, vedi Accesso privato Google per gli host on-premise.
Passaggi successivi
- Scopri di più sui controlli di rilevamento (documento successivo di questa serie).