Mai multe proiecte Google Cloud, un singur VPN hibrid? Decideți mai întâi
VPC partajat, peering și un hub de conectivitate răspund la întrebări de proprietate diferite. Alegeți granița rețelei înainte de a implementa un VPN pe proiect.
Când mai multe proiecte Google Cloud au nevoie de acces hibrid, instinctul este un VPN pe proiect, iar aceasta este aproape întotdeauna forma greșită. Proprietatea proiectului și rutarea pachetelor sunt chestiuni legate, dar diferite, iar arhitectura utilă păstrează granițele administrative de care aveți nevoie și, în același timp, oferă prefixelor vizate o singură cale deliberată către birou sau centrul de date. Aceste verificări decid ce model de rețea doriți de fapt, în ordinea care evită reluarea lucrului. Fiecare dintre ele poate încheia discuția devreme, și acesta este scopul.
O graniță de proiect nu necesită automat propriul tunel.
Verificați dacă obiectul partajat este rețeaua
Începeți cu o întrebare despre proprietate, nu despre conectivitate: poate proprietatea centrală a rețelei să susțină aceste încărcări de lucru? Dacă răspunsul este da și organizația are o configurație eligibilă, un proiect gazdă deține VPC-ul, subrețelele și conectivitatea, în timp ce proiectele de serviciu își dețin propriile resurse de aplicație. O singură conexiune Cloud VPN în acea rețea partajată poate apoi deservi prefixele de încărcare de lucru vizate, sub rezerva politicilor de rutare și securitate .
Fiți precis despre ce face asocierea. Atașarea unui proiect de serviciu nu fuzionează VPC-ul său independent existent cu rețeaua gazdă și nu mută automat fiecare resursă. Atașarea încărcărilor de lucru, permisiunile, spațiul de adrese și DNS fac parte din arhitectură, nu sunt consecințe ale setării. Citiți asocierea mai întâi ca o schimbare de permisiuni și apoi ca o schimbare de rutare, pentru că echipele descoperă de obicei diferența în timpul migrării.
Dacă proprietatea centrală nu este acceptabilă pentru echipele implicate, opriți-vă aici și tratați restul ca un design de peering sau de hub. Impunerea Shared VPC asupra unui grup care are nevoie de cicluri de viață de rețea independente produce o problemă politică cu un nume tehnic.
Verificați dacă VPC-urile independente pot rămâne independente
Peering-ul păstrează VPC-uri separate, și exact de aceea atrage echipe care vor propriile planuri de adrese și propriul control al modificărilor. Capcana este că peering-ul nu este tranzitiv: peering-ul A-către-B și B-către-C nu creează de la sine rutare A-către-C prin B. Dacă trei proiecte trebuie să atingă o singură destinație hibridă, aveți nevoie de un plan de schimb deliberat, nu de un lanț de peering-uri.
Partajarea accesibilității hibride depinde și de schimbul documentat de rute personalizate și de anunțurile Cloud Router vizate. Un status de peering activ dovedește că peering-ul există, nu că prefixele care contează pentru fiecare parte au fost vreodată exportate. Verificați intervalele exportate pe ambele părți ale peer-ului, în configurația care face exportul, și comparați-le cu adresele pe care încărcările dumneavoastră le folosesc efectiv. O nepotrivire acolo este cel mai frecvent motiv pentru care un peering pare sănătos în timp ce un prefix rămâne inaccesibil.
Scrieți planul de adrese înainte de orice altceva. Intervalele care nu se suprapun, rutele către fiecare destinație vizată și anunțurile de retur sunt cele trei artefacte pe care acest model trăiește sau moare.
Verificați dacă un model de hub se potrivește topologiei
Pentru un design mai mare sau segmentat diferit, prezentarea generală Google Network Connectivity Center descrie modelele de hub și spiță. Citiți-o pentru ceea ce acceptă versiunea actuală, nu pentru ceea ce sugerează diagrama: ce combinații de VPC și hibride, ce familii de rute și ce politici permite fiecare tip de spiță.
Verificați explicit familia de adrese. Exemplele de planificare din majoritatea ghidurilor, inclusiv acesta, privesc IPv4, iar o funcție care există pentru un tip de spiță nu se aplică automat neschimbată altuia. Dacă mediul dumneavoastră este cu stivă dublă, acea întrebare aparține alegerii modelului, nu unei migrări ulterioare.
Tabelul de mai jos este rezumatul celor trei modele și întrebarea care decide fiecare.
| 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? |
Verificați ce nu acordă rutarea
Schimbul de rute nu este o acordare globală de încredere. Rezolvarea DNS, permisiunea paravanului de foc și autorizarea aplicațiilor rămân responsabilități proprii, iar fiecare este configurată de un proprietar diferit în majoritatea organizațiilor. Un design care presupune că accesibilitatea implică autorizare va trece testul de conectivitate și va eșua la revizuirea de securitate.
Confirmați și povestea DNS pentru fiecare model, deoarece aranjamentele de zonă și de redirecționare diferă între o rețea partajată și rețele cu peering. Numele private care se rezolvă într-un proiect nu urmează o rută către altul.
Înregistrați decizia și proprietarul ei
Centralizați acolo unde organizația dorește un proprietar de rețea partajat; păstrați VPC-uri separate acolo unde ciclul de viață sau politica o cere. Apoi alegeți o relație de conectivitate acceptată și notați pe care ați ales-o, cine deține rețeaua partajată și ce poate anunța fiecare proiect.
Numărarea proiectelor și cumpărarea unui VPN pentru fiecare nu înlocuiește acea decizie de proprietate. Este aceeași decizie, luată mai târziu, de cel care moștenește factura și tabelul de rutare.