Nekoliko Google Cloud projekata, jedan hibridni VPN? Prvo odlučite
Dijeljeni VPC, peering i čvorište povezivosti odgovaraju na različita pitanja vlasništva. Odaberite granicu mreže prije nego što uvedete jedan VPN po projektu.
Kada nekoliko Google Cloud projekata treba hibridni pristup, instinkt je jedan VPN po projektu, a to je gotovo uvijek pogrešan oblik. Vlasništvo nad projektom i usmjeravanje paketa povezana su, ali različita pitanja, a korisna arhitektura zadržava administrativne granice koje su vam potrebne dok namjeravanim prefiksima daje jedan promišljen put do ureda ili podatkovnog centra. Ove provjere odlučuju koji mrežni model zapravo želite, redom koji izbjegava ponovni rad. Svaka od njih može rano završiti raspravu, i u tome je poanta.
Granica projekta ne zahtijeva automatski vlastiti tunel.
Provjerite je li zajednički objekt mreža
Počnite pitanjem o vlasništvu, a ne o povezivosti: može li središnje vlasništvo nad mrežom podržati ova radna opterećenja? Ako je odgovor da i organizacija ima prikladnu konfiguraciju, host projekt posjeduje VPC, podmreže i povezivost, dok servisni projekti posjeduju vlastite resurse aplikacija. Jedna Cloud VPN veza u toj dijeljenoj mreži tada može posluživati namjeravane prefikse radnih opterećenja, uz poštovanje pravila usmjeravanja i sigurnosti .
Budite precizni o tome što pridruživanje čini. Povezivanje servisnog projekta ne spaja njegov postojeći neovisni VPC u host mrežu i ne premješta automatski svaki resurs. Povezivanje radnih opterećenja, dopuštenja, adresni prostor i DNS dio su arhitekture, a ne posljedica postavke. Čitajte pridruživanje najprije kao promjenu dopuštenja, a zatim kao promjenu usmjeravanja, jer timovi razliku obično otkriju tijekom prelaska.
Ako središnje vlasništvo nije prihvatljivo uključenim timovima, zaustavite se ovdje i ostatak tretirajte kao dizajn s peeringom ili čvorištem. Nametanje Shared VPC-a grupi kojoj trebaju neovisni životni ciklusi mreže stvara politički problem s tehničkim imenom.
Provjerite mogu li neovisni VPC-ovi ostati neovisni
Peering čuva odvojene VPC-ove i upravo zato privlači timove koji žele vlastite adresne planove i vlastitu kontrolu promjena. Kvaka je u tome što peering nije tranzitivan: peering A-prema-B i B-prema-C sam po sebi ne stvara usmjeravanje A-prema-C kroz B. Ako tri projekta trebaju dosegnuti jedno hibridno odredište, trebate promišljen plan razmjene, a ne lanac peeringa.
Dijeljenje hibridne dosegljivosti također ovisi o dokumentiranoj razmjeni prilagođenih ruta i o namjeravanim objavama Cloud Routera. Status peeringa „aktivan“ dokazuje da peering postoji, a ne da su prefiksi do kojih je svakoj strani stalo ikada izvezeni. Provjerite izvezene raspone s obje strane peera, u konfiguraciji koja obavlja izvoz, i usporedite ih s adresama koje vaša radna opterećenja stvarno koriste. Neusklađenost tamo najčešći je razlog zašto peering izgleda zdravo dok prefiks ostaje nedostupan.
Napišite adresni plan prije svega ostalog. Rasponi koji se ne preklapaju, rute prema svakom namjeravanom odredištu i povratne objave tri su artefakta na kojima ovaj model živi ili umire.
Provjerite odgovara li model čvorišta topologiji
Za veći ili drukčije segmentiran dizajn Googleov pregled Network Connectivity Centera opisuje modele čvorišta i krakova. Čitajte ga zbog onoga što trenutno izdanje podržava, a ne zbog onoga što dijagram implicira: koje kombinacije VPC-a i hibridnih veza, koje obitelji ruta i koja pravila dopušta svaka vrsta kraka.
Izričito provjerite adresnu obitelj. Primjeri planiranja u većini vodiča, uključujući ovaj, tiču se IPv4, a značajka koja postoji za jednu vrstu kraka ne primjenjuje se automatski nepromijenjena na drugu. Ako je vaše okruženje dvostruki stog, to pitanje pripada odabiru modela, a ne kasnijoj migraciji.
Tablica u nastavku sažetak je triju modela i pitanja koje odlučuje svaki 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? |
Provjerite što usmjeravanje ne daje
Razmjena ruta nije sveobuhvatno davanje povjerenja. Razrješavanje DNS-a, dopuštenje vatrozida i autorizacija aplikacija ostaju vlastite odgovornosti i svaku od njih u većini organizacija konfigurira drugi vlasnik. Dizajn koji pretpostavlja da dosegljivost podrazumijeva autorizaciju proći će test povezivosti i pasti sigurnosni pregled.
Potvrdite i DNS priču za svaki model, jer se zone i prosljeđivanje razlikuju između dijeljene mreže i mreža s peeringom. Privatna imena koja se razrješavaju u jednom projektu ne slijede rutu u drugi.
Zabilježite odluku i njezina vlasnika
Centralizirajte gdje organizacija želi zajedničkog vlasnika mreže; zadržite odvojene VPC-ove gdje to zahtijeva životni ciklus ili pravila. Zatim odaberite podržani odnos povezivosti i zapišite koji ste odabrali, kome pripada dijeljena mreža i što svaki projekt smije objavljivati.
Brojanje projekata i kupnja jednog VPN-a za svaki nije zamjena za tu odluku o vlasništvu. To je ista odluka, donesena kasnije, od strane onoga koji naslijedi račun i tablicu usmjeravanja.