Několik projektů Google Cloud, jedna hybridní VPN? Rozhodněte nejprve

Když několik projektů Google Cloud potřebuje hybridní přístup, instinktem je jedna VPN na projekt, a to je téměř vždy špatný tvar. Vlastnictví projektu a směrování paketů spolu souvisejí, ale jsou to různé otázky, a užitečná architektura zachovává administrativní hranice, které potřebujete, a přitom dává zamýšleným prefixům jednu promyšlenou cestu do kanceláře nebo datového centra. Tyto kontroly rozhodnou, který síťový model vlastně chcete, v pořadí, které se vyhýbá předělávání. Každá z nich může diskusi ukončit brzy, a o to jde.

Hranice projektu automaticky nevyžaduje vlastní tunel.

Ověřte, zda je sdíleným objektem síť

Začněte otázkou o vlastnictví, ne o konektivitě: může centrální vlastnictví sítě podpořit tyto úlohy? Pokud je odpověď ano a organizace má vhodnou konfiguraci, hostitelský projekt vlastní VPC, podsítě a konektivitu, zatímco servisní projekty vlastní své aplikační prostředky. Jedno připojení Cloud VPN v této sdílené síti pak může obsluhovat zamýšlené prefixy úloh, v souladu se zásadami směrování a zabezpečení .

Buďte přesní v tom, co přidružení dělá. Připojení servisního projektu neslévá jeho stávající nezávislou VPC do hostitelské sítě a nepřesouvá automaticky každý prostředek. Připojení úloh, oprávnění, adresní prostor a DNS jsou součástí architektury, ne důsledkem nastavení. Čtěte přidružení nejprve jako změnu oprávnění a teprve potom jako změnu směrování, protože týmy rozdíl obvykle objeví při přechodu.

Pokud centrální vlastnictví není pro zúčastněné týmy přijatelné, zastavte se zde a zbytek berte jako návrh s peeringem nebo centrem. Vnucování Shared VPC skupině, která potřebuje nezávislé životní cykly sítě, vytváří politický problém s technickým názvem.

Ověřte, zda nezávislé VPC mohou zůstat nezávislé

Peering zachovává oddělené VPC, a právě proto přitahuje týmy, které chtějí vlastní adresní plány a vlastní řízení změn. Háček je v tom, že peering není tranzitivní: peering A-k-B a B-k-C sám o sobě nevytváří směrování A-k-C přes B. Pokud tři projekty potřebují dosáhnout jednoho hybridního cíle, potřebujete promyšlený plán výměny, ne řetěz peeringů.

Sdílení hybridní dosažitelnosti závisí také na dokumentované výměně vlastních tras a na zamýšlených inzerátech Cloud Router. Stav peeringu „aktivní“ dokazuje, že peering existuje, ne že prefixy, na kterých každé straně záleží, byly někdy exportovány. Zkontrolujte exportované rozsahy na obou stranách peeru, v konfiguraci, která export provádí, a porovnejte je s adresami, které vaše úlohy skutečně používají. Nesoulad tam je nejčastějším důvodem, proč peering vypadá zdravě, zatímco prefix zůstává nedostupný.

Napište adresní plán dřív než cokoli jiného. Nepřekrývající se rozsahy, trasy ke každému zamýšlenému cíli a zpětné inzeráty jsou tři artefakty, na kterých tento model stojí a padá.

Ověřte, zda model centra odpovídá topologii

Pro větší nebo jinak segmentovaný návrh přehled Google Network Connectivity Center popisuje modely centra a paprsků. Čtěte ho kvůli tomu, co současné vydání podporuje, ne kvůli tomu, co naznačuje diagram: které kombinace VPC a hybridních připojení, které rodiny tras a jaké zásady každý typ paprsku povoluje.

Ověřte rodinu adres výslovně. Příklady plánování ve většině příruček, včetně této, se týkají IPv4, a funkce, která existuje pro jeden typ paprsku, se automaticky bez změny nevztahuje na jiný. Pokud je vaše prostředí s duálním zásobníkem, tato otázka patří k volbě modelu, ne k pozdější migraci.

Tabulka níže je shrnutím tří modelů a otázky, která rozhoduje každý z nich.

Ověřte, co směrování neuděluje

Výměna tras není plošným udělením důvěry. Rozlišení DNS, povolení firewallu a autorizace aplikací zůstávají vlastní odpovědností a každé z nich ve většině organizací konfiguruje jiný vlastník. Návrh, který předpokládá, že dosažitelnost znamená autorizaci, projde testem konektivity a neprojde bezpečnostní kontrolou.

Potvrďte také příběh DNS pro každý model, protože uspořádání zón a předávání se liší mezi sdílenou sítí a sítěmi s peeringem. Privátní názvy, které se překládají v jednom projektu, nenásledují trasu do jiného.

Zaznamenejte rozhodnutí a jeho vlastníka

Centralizujte tam, kde organizace chce sdíleného vlastníka sítě; ponechte oddělené VPC tam, kde to vyžaduje životní cyklus nebo zásady. Poté vyberte podporovaný vztah konektivity a zapište, který jste zvolili, kdo vlastní sdílenou síť a co smí každý projekt inzerovat.

Počítat projekty a kupovat jednu VPN pro každý není náhradou za to rozhodnutí o vlastnictví. Je to stejné rozhodnutí, učiněné později, tím, kdo zdědí účet a směrovací tabulku.