Più progetti Google Cloud, un solo VPN ibrido? Decidete prima
VPC condiviso, peering e un hub di connettività rispondono a domande di proprietà diverse. Scegliete il confine della rete prima di distribuire un VPN per progetto.
Quando più progetti Google Cloud hanno bisogno di accesso ibrido, l'istinto è un VPN per progetto, ed è quasi sempre la forma sbagliata. La proprietà del progetto e l'inoltro dei pacchetti sono questioni correlate ma diverse, e l'architettura utile conserva i confini amministrativi necessari mentre dà ai prefissi previsti un unico percorso deliberato verso l'ufficio o il data center. Questi controlli stabiliscono quale modello di rete si vuole davvero, nell'ordine che evita rifacimenti. Ognuno può chiudere la discussione in anticipo, e questo è il punto.
Un confine di progetto non richiede automaticamente il proprio tunnel.
Verificate se l'oggetto condiviso è la rete
Iniziate con una domanda sulla proprietà, non sulla connettività: la proprietà centrale della rete può sostenere questi carichi di lavoro? Se la risposta è sì e l'organizzazione dispone di una configurazione idonea, un progetto host possiede il VPC, le sottoreti e la connettività, mentre i progetti di servizio possiedono le proprie risorse applicative. Una connessione Cloud VPN in quella rete condivisa può quindi servire i prefissi dei carichi di lavoro previsti, fatte salve le politiche di inoltro e sicurezza .
Siate precisi su cosa fa l'associazione. Collegare un progetto di servizio non fonde il suo VPC indipendente esistente nella rete host e non sposta automaticamente ogni risorsa. Il collegamento dei carichi di lavoro, le autorizzazioni, lo spazio degli indirizzi e il DNS fanno tutti parte dell'architettura, non sono conseguenze dell'impostazione. Leggete l'associazione prima come cambiamento di autorizzazioni e poi come cambiamento di inoltro, perché i team di solito scoprono la differenza durante il passaggio.
Se la proprietà centrale non è accettabile per i team coinvolti, fermatevi qui e trattate il resto come un progetto di peering o di hub. Imporre Shared VPC a un gruppo che necessita di cicli di vita di rete indipendenti produce un problema politico con un nome tecnico.
Verificate se VPC indipendenti possono restare indipendenti
Il peering preserva VPC separati, ed è esattamente per questo che attrae team che vogliono i propri piani di indirizzamento e il proprio controllo delle modifiche. Il tranello è che il peering non è transitivo: il peering A-verso-B e B-verso-C non crea da solo l'inoltro A-verso-C attraverso B. Se tre progetti devono raggiungere un'unica destinazione ibrida, serve un piano di scambio deliberato e non una catena di peering.
La condivisione della raggiungibilità ibrida dipende anche dallo scambio documentato di route personalizzate e dagli annunci Cloud Router previsti. Uno stato di peering attivo dimostra che il peering esiste, non che i prefissi che interessano a ciascun lato siano mai stati esportati. Controllate gli intervalli esportati su entrambi i lati del peer, nella configurazione che esegue l'esportazione, e confrontateli con gli indirizzi che i vostri carichi di lavoro usano davvero. Un disallineamento lì è la ragione più comune per cui un peering sembra sano mentre un prefisso resta irraggiungibile.
Scrivete il piano degli indirizzi prima di ogni altra cosa. Gli intervalli non sovrapposti, le route verso ogni destinazione prevista e gli annunci di ritorno sono i tre artefatti su cui questo modello vive o muore.
Verificate se un modello a hub si adatta alla topologia
Per un progetto più grande o segmentato diversamente, la panoramica di Google Network Connectivity Center descrive i modelli a hub e a spoke. Leggetela per ciò che la versione attuale supporta, non per ciò che implica il diagramma: quali combinazioni VPC e ibride, quali famiglie di route e quali politiche ogni tipo di spoke consente.
Verificate esplicitamente la famiglia di indirizzi. Gli esempi di pianificazione nella maggior parte delle guide, inclusa questa, riguardano IPv4, e una funzione che esiste per un tipo di spoke non si applica automaticamente senza modifiche a un altro. Se il vostro ambiente è a doppio stack, quella domanda appartiene alla scelta del modello, non a una migrazione successiva.
La tabella seguente è il riepilogo dei tre modelli e della domanda che decide ciascuno.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Verificate cosa non concede l'inoltro
Lo scambio di route non è una concessione generale di fiducia. La risoluzione DNS, l'autorizzazione del firewall e l'autorizzazione applicativa restano responsabilità proprie, e ciascuna è configurata da un proprietario diverso nella maggior parte delle organizzazioni. Un progetto che presume che la raggiungibilità implichi l'autorizzazione supererà il test di connettività e fallirà la revisione di sicurezza.
Confermate anche la storia DNS per ogni modello, perché le disposizioni di zona e di inoltro differiscono tra una rete condivisa e reti in peering. I nomi privati che si risolvono in un progetto non seguono una route verso un altro.
Registrate la decisione e il suo proprietario
Centralizzate dove l'organizzazione vuole un proprietario di rete condiviso; mantenete VPC separati dove lo richiede il ciclo di vita o la politica. Poi scegliete una relazione di connettività supportata e annotate quale avete scelto, chi possiede la rete condivisa e cosa ogni progetto può annunciare.
Contare i progetti e acquistare un VPN per ciascuno non sostituisce quella decisione di proprietà. È la stessa decisione, presa più tardi, da chi eredita la fattura e la tabella di inoltro.