Več projektov Google Cloud, en hibridni VPN? Najprej se odločite
Skupni VPC, peering in vozlišče povezljivosti odgovarjajo na različna vprašanja lastništva. Izberite mejo omrežja, preden uvedete en VPN na projekt.
Ko več projektov Google Cloud potrebuje hibridni dostop, je instinkt en VPN na projekt, in to je skoraj vedno napačna oblika. Lastništvo projekta in usmerjanje paketov sta povezani, a različni vprašanji, in koristna arhitektura ohranja mejne upravne meje, ki jih potrebujete, hkrati pa nameravanim prefiksom daje eno premišljeno pot do pisarne ali podatkovnega središča. Te preveritve odločijo, kateri omrežni model pravzaprav želite, v vrstnem redu, ki se izogne predelavi. Vsaka od njih lahko razpravo konča zgodaj, in to je bistvo.
Meja projekta ne zahteva samodejno svojega tunela.
Preverite, ali je skupni objekt omrežje
Začnite z vprašanjem o lastništvu, ne o povezljivosti: ali lahko osrednje lastništvo omrežja podpira te delovne obremenitve? Če je odgovor da in ima organizacija ustrezno konfiguracijo, gostiteljski projekt ima v lasti VPC, podomrežja in povezljivost, medtem ko imajo storitveni projekti svoje aplikacijske vire. Ena povezava Cloud VPN v tem skupnem omrežju lahko nato služi nameravanim prefiksom delovne obremenitve, ob upoštevanju pravil usmerjanja in varnosti .
Bodite natančni glede tega, kaj asociacija počne. Pripenjanje storitvenega projekta ne združi njegovega obstoječega neodvisnega VPC z gostiteljskim omrežjem in ne premakne samodejno vsakega vira. Pripenjanje delovnih obremenitev, dovoljenja, naslovni prostor in DNS so del arhitekture, ne posledice nastavitve. Asociacijo berite najprej kot spremembo dovoljenj in šele nato kot spremembo usmerjanja, ker ekipe razliko običajno odkrijejo med prehodom.
Če osrednje lastništvo ni sprejemljivo za vključene ekipe, se ustavite tukaj in preostanek obravnavajte kot zasnovo s peeringom ali vozliščem. Vsiljevanje Shared VPC skupini, ki potrebuje neodvisne življenjske cikle omrežja, ustvari politični problem s tehničnim imenom.
Preverite, ali lahko neodvisni VPC ostanejo neodvisni
Peering ohranja ločene VPC, in prav zato privlači ekipe, ki želijo lastne naslovne načrte in lasten nadzor sprememb. Past je v tem, da peering ni tranzitiven: peering A-proti-B in B-proti-C sam po sebi ne ustvari usmerjanja A-proti-C prek B. Če morajo trije projekti doseči en hibridni cilj, potrebujete premišljen načrt izmenjave, ne verige peeringov.
Deljenje hibridne dosegljivosti je odvisno tudi od dokumentirane izmenjave prilagojenih poti in od nameravanih objav Cloud Router. Aktiven status peeringa dokazuje, da peering obstaja, ne pa da so bili prefiksi, ki so pomembni za vsako stran, kdaj izvoženi. Preverite izvožene razpone na obeh straneh peera, v konfiguraciji, ki izvaja izvoz, in jih primerjajte z naslovi, ki jih vaše delovne obremenitve dejansko uporabljajo. Neujemanje tam je najpogostejši razlog, da je peering videti zdrav, medtem ko prefiks ostaja nedosegljiv.
Napišite naslovni načrt pred vsem drugim. Razponi, ki se ne prekrivajo, poti do vsakega nameravanega cilja in povratne objave so trije artefakti, na katerih ta model živi ali umre.
Preverite, ali model vozlišča ustreza topologiji
Za večjo ali drugače segmentirano zasnovo pregled Google Network Connectivity Center opisuje modela vozlišča in žarka. Berite ga zaradi tega, kar podpira trenutna izdaja, ne zaradi tega, kar nakazuje diagram: katere kombinacije VPC in hibridnih povezav, katere družine poti in katera pravila dovoljuje vsak tip žarka.
Izrecno preverite družino naslovov. Primeri načrtovanja v večini vodnikov, vključno s tem, se nanašajo na IPv4, in funkcija, ki obstaja za en tip žarka, se samodejno brez sprememb ne uporablja za drugega. Če je vaše okolje z dvojnim skladom, to vprašanje spada k izbiri modela, ne k poznejši selitvi.
Spodnja tabela je povzetek treh modelov in vprašanja, ki odloči vsakega od njih.
| 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? |
Preverite, česa usmerjanje ne daje
Izmenjava poti ni splošna podelitev zaupanja. Razreševanje DNS, dovoljenje požarnega zidu in avtorizacija aplikacij ostajajo lastne odgovornosti, in vsako od njih v večini organizacij konfigurira drug lastnik. Zasnova, ki predpostavlja, da dosegljivost pomeni avtorizacijo, bo prestala test povezljivosti in padla na varnostnem pregledu.
Potrdite tudi zgodbo DNS za vsak model, ker se ureditev območij in posredovanja razlikuje med skupnim omrežjem in omrežji s peeringom. Zasebna imena, ki se razrešijo v enem projektu, ne sledijo poti v drugega.
Zabeležite odločitev in njenega lastnika
Centralizirajte tam, kjer organizacija želi skupnega lastnika omrežja; ohranite ločene VPC tam, kjer to zahteva življenjski cikel ali politika. Nato izberite podprt odnos povezljivosti in zapišite, katerega ste izbrali, kdo ima v lasti skupno omrežje in kaj sme vsak projekt oglaševati.
Štetje projektov in nakup enega VPN za vsakega ne nadomesti te odločitve o lastništvu. To je ista odločitev, sprejeta pozneje, s strani tistega, ki podeduje račun in usmerjevalno tabelo.