Verskeie Google Cloud-projekte, een hibriede VPN? Besluit eers
Gedeelde VPC, peering en 'n verbindingshub beantwoord verskillende eienaarskapvrae. Kies die netwerkgrens voordat jy een VPN per projekt ontplooi.
Wanneer verskeie Google Cloud-projekte hibriede toegang nodig het, is die instink een VPN per projekt, en dit is amper altyd die verkeerde vorm. Projekeienaarskap en pakketroetering is verwante maar verskillende kwessies, en die nuttige argitektuur behou die administratiewe grense wat jy nodig het terwyl dit die beoogde prefikse een doelbewuste pad na die kantoor of datacentrum gee. Hierdie kontroles beslis watter netwerkmodel jy werklik wil hê, in die orde wat herwerk vermy. Elkeen kan die bespreking vroeg beëindig, en dit is die punt.
'n Projekgrens vereis nie outomaties sy eie tonnel nie.
Kyk of die gedeelde objek die netwerk is
Begin met 'n vraag oor eienaarskap, nie konnektiwiteit nie: kan sentrale netwerkeienaarskap hierdie werklaste ondersteun? As die antwoord ja is en die organisasie het 'n geskikte konfigurasie, dan besit 'n gasheerprojek die VPC, subnetwerke en konnektiwiteit terwyl diensprojekte hul eie toepassingshulpbronne besit. Een Cloud VPN-verbinding in daardie gedeelde netwerk kan dan die beoogde werklasprefikse bedien, onderhewig aan roetering- en sekuriteitsbeleid .
Wees presies oor wat assosiasie doen. Die koppeling van 'n diensprojek voeg nie sy bestaande onafhanklike VPC by die gasheernetwerk in nie, en dit skuif nie elke hulpbron outomaties nie. Werklaskoppeling, toestemmings, adresruimte en DNS is alles deel van die argitektuur, nie gevolge van die instelling nie. Lees die assosiasie eerste as 'n toestemmingsverandering en tweede as 'n roeteringverandering, want spanne ontdek gewoonlik die verskil tydens oorskakeling.
As sentrale eienaarskap nie vir die betrokke spanne aanvaarbaar is nie, stop hier en behandel die res as 'n peering- of hubontwerp. Om Shared VPC te forseer op 'n groep wat onafhanklike netwerklewensiklusse nodig het, skep 'n politieke probleem met 'n tegniese naam.
Kyk of onafhanklike VPC's onafhanklik kan bly
Peering bewaar aparte VPC's, en dit is juis hoekom dit spanne lok wat hul eie adresplanne en hul eie veranderingsbeheer wil hê. Die vangnet is dat peering nie transitief is nie: A-na-B- en B-na-C-peering skep nie op sigself A-na-C-roetering deur B nie. As drie projekte een hibriede bestemming moet bereik, het jy 'n doelbewuste uitruilplan nodig eerder as 'n ketting van peerings.
Die deel van hibriede bereikbaarheid hang ook af van die gedokumenteerde uitruil van pasgemaakte roetes en die beoogde Cloud Router-advertensies. 'n Peeringstatus van aktief bewys dat die peering bestaan, nie dat die prefikse waaroor elke kant gee om ooit uitgevoer is nie. Kontroleer die uitgevoerde reekse aan beide kante van die peer, in die konfigurasie wat die uitvoer doen, en vergelyk hulle met die adresse wat jou werklaste werklik gebruik. 'n Wanpassing daar is die algemeenste rede waarom 'n peering gesond lyk terwyl 'n prefiks onbereikbaar bly.
Skryf die adresplan voor enigiets anders. Nie-oorvleuelende reekse, die roetes na elke beoogde bestemming en die terugadvertensies is die drie artefakte waarop hierdie model leef of sterf.
Kyk of 'n hubmodel by die topologie pas
Vir 'n groter of anders gesegmenteerde ontwerp beskryf Google se oorsig van Network Connectivity Center die hub-en-spoke-modelle. Lees dit vir wat die huidige weergawe ondersteun eerder as vir wat die diagram impliseer: watter VPC- en hibriede kombinasies, watter roetefamilies en watter beleide elke spoke-tipe toelaat.
Kontroleer die adresfamilie uitdruklik. Beplanningsvoorbeelde in die meeste gidse, insluitend hierdie een, gaan oor IPv4, en 'n kenmerk wat vir een spoke-tipe bestaan, geld nie outomaties onveranderd vir 'n ander nie. As jou omgewing dubbelstapel is, hoort daardie vraag by die modelkeuse, nie by 'n latere migrasie nie.
Die tabel hieronder is die opsomming van die drie modelle en die vraag wat elkeen beslis.
| 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? |
Kyk wat roetering nie toestaan nie
Roete-uitruil is nie 'n algemene trust-toekenning nie. DNS-resolusie, firewalltoestemming en toepassingsmagtiging bly hul eie verantwoordelikhede, en elkeen word in die meeste organisasies deur 'n ander eienaar gekonfigureer. 'n Ontwerp wat aanvaar dat bereikbaarheid magtiging impliseer, sal sy konnektiwiteitstoets slaag en sy sekuriteitshersiening faal.
Bevestig ook die DNS-storie vir elke model, want die sone- en aanstuurregelings verskil tussen 'n gedeelde netwerk en gepeerde netwerke. Privaat name wat in een projekt oplos, volg nie 'n roete na 'n ander nie.
Teken die besluit en sy eienaar aan
Sentraaliseer waar die organisasie 'n gedeelde netwerkeienaar wil hê; hou aparte VPC's waar lewensiklus of beleid dit vereis. Kies dan 'n ondersteunde konnektiwiteitsverhouding en skryf neer watter een jy gekies het, wie die gedeelde netwerk besit, en wat elke projekt mag adverteer.
Om projekte te tel en een VPN vir elkeen te koop is nie 'n plaasvervanger vir daardie eienaarskapbesluit nie. Dit is dieselfde besluit, later geneem, deur wie ook al die rekening en die roeteringstabel erf.