Flera Google Cloud-projekt, en hybrid VPN? Bestäm först
Delad VPC, peering och ett anslutningsnav svarar på olika ägarfrågor. Välj nätverksgränsen innan du distribuerar en VPN per projekt.
När flera Google Cloud-projekt behöver hybrid åtkomst är instinkten en VPN per projekt, och det är nästan alltid fel form. Projektägande och paketdirigering är besläktade men olika frågor, och den användbara arkitekturen behåller de administrativa gränser du behöver och ger samtidigt de avsedda prefixen en medveten väg till kontoret eller datacentret. Dessa kontroller avgör vilken nätverksmodell du egentligen vill ha, i den ordning som undviker omarbete. Var och en kan avsluta diskussionen tidigt, och det är poängen.
En projektgräns kräver inte automatiskt en egen tunnel.
Kontrollera om det delade objektet är nätverket
Börja med en fråga om ägande, inte om anslutning: kan centralt nätverksägande stödja dessa arbetslaster? Om svaret är ja och organisationen har en lämplig konfiguration äger ett värdprojekt VPC:n, subnäten och anslutningen, medan tjänsteprojekt äger sina egna applikationsresurser. En Cloud VPN-anslutning i det delade nätverket kan då betjäna de avsedda arbetslastprefixen, med förbehåll för dirigerings- och säkerhetspolicyer .
Var exakt om vad associationen gör. Att koppla ett tjänsteprojekt slår inte samman dess befintliga oberoende VPC med värdnätverket och flyttar inte varje resurs automatiskt. Koppling av arbetslaster, behörigheter, adressutrymme och DNS är alla en del av arkitekturen, inte konsekvenser av inställningen. Läs associationen först som en behörighetsändring och sedan som en dirigeringsändring, eftersom team oftast upptäcker skillnaden under övergången.
Om centralt ägande inte är acceptabelt för de inblandade teamen, stanna här och behandla resten som en peering- eller navdesign. Att tvinga Shared VPC på en grupp som behöver oberoende nätverkslivscykler skapar ett politiskt problem med ett tekniskt namn.
Kontrollera om oberoende VPC:er kan förbli oberoende
Peering bevarar separata VPC:er, och det är just därför det lockar team som vill ha egna adressplaner och egen ändringskontroll. Haken är att peering inte är transitiv: peering A-till-B och B-till-C skapar inte i sig A-till-C-dirigering genom B. Om tre projekt måste nå en hybrid destination behöver du en medveten utbytesplan i stället för en kedja av peerings.
Delning av hybrid nåbarhet beror också på det dokumenterade utbytet av anpassade rutter och de avsedda Cloud Router-annonserna. En peeringstatus på aktiv bevisar att peeringen finns, inte att prefixen som varje sida bryr sig om någonsin exporterades. Kontrollera de exporterade intervallen på båda sidor av peeren, i den konfiguration som utför exporten, och jämför dem med de adresser som dina arbetslaster faktiskt använder. En avvikelse där är den vanligaste orsaken till att en peering ser frisk ut medan ett prefix förblir onåbart.
Skriv adressplanen före allt annat. Icke-överlappande intervall, rutterna mot varje avsedd destination och returannonserna är de tre artefakter som denna modell lever eller dör på.
Kontrollera om en navmodell passar topologin
För en större eller annorlunda segmenterad design beskriver Googles översikt över Network Connectivity Center nav- och ekermodellerna. Läs den för vad den aktuella versionen stöder, inte för vad diagrammet antyder: vilka VPC- och hybridkombinationer, vilka ruttfamiljer och vilka policyer varje ekertyp tillåter.
Kontrollera adressfamiljen uttryckligen. Planeringsexemplen i de flesta guider, inklusive denna, gäller IPv4, och en funktion som finns för en ekertyp gäller inte automatiskt oförändrad för en annan. Om din miljö är dubbelstackad hör den frågan till modellvalet, inte till en senare migrering.
Tabellen nedan är sammanfattningen av de tre modellerna och frågan som avgör var och en.
| 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? |
Kontrollera vad dirigering inte ger
Ruttutbyte är inte ett generellt beviljande av förtroende. DNS-uppslagning, brandväggstillstånd och applikationsauktorisering förblir egna ansvarsområden, och var och en konfigureras av en annan ägare i de flesta organisationer. En design som antar att nåbarhet innebär auktorisering kommer att klara sitt anslutningstest och misslyckas i sin säkerhetsgranskning.
Bekräfta också DNS-historien för varje modell, eftersom zon- och vidarebefordringsarrangemangen skiljer sig mellan ett delat nätverk och peerade nätverk. Privata namn som löses i ett projekt följer inte en rutt in i ett annat.
Registrera beslutet och dess ägare
Centralisera där organisationen vill ha en delad nätverksägare; behåll separata VPC:er där livscykel eller policy kräver det. Välj sedan en stödd anslutningsrelation och skriv ned vilken du valde, vem som äger det delade nätverket och vad varje projekt får annonsera.
Att räkna projekt och köpa en VPN till varje ersätter inte det ägarbeslutet. Det är samma beslut, fattat senare, av den som ärver fakturan och rutttabellen.