Wiele projektów Google Cloud, jeden hybrydowy VPN? Zdecyduj najpierw

Gdy kilka projektów Google Cloud potrzebuje dostępu hybrydowego, odruchem jest jeden VPN na projekt, a to prawie zawsze zły kształt. Własność projektu i routing pakietów to zagadnienia powiązane, ale różne, a użyteczna architektura zachowuje potrzebne granice administracyjne i daje docelowym prefiksom jedną przemyślaną drogę do biura lub centrum danych. Te kontrole rozstrzygają, jakiego modelu sieci naprawdę chcesz, w kolejności, która unika przeróbek. Każda z nich może wcześnie zakończyć dyskusję i o to chodzi.

Granica projektu nie wymaga automatycznie własnego tunelu.

Sprawdź, czy wspólnym obiektem jest sieć

Zacznij od pytania o własność, nie o łączność: czy centralna własność sieci może obsłużyć te obciążenia? Jeśli odpowiedź brzmi tak i organizacja ma odpowiednią konfigurację, projekt hosta posiada VPC, podsieci i łączność, a projekty usługowe posiadają własne zasoby aplikacji. Jedno połączenie Cloud VPN w tej wspólnej sieci może następnie obsługiwać docelowe prefiksy obciążeń, z zastrzeżeniem zasad routingu i bezpieczeństwa .

Bądź precyzyjny co do tego, co robi powiązanie. Dołączenie projektu usługowego nie scala jego istniejącego niezależnego VPC z siecią hosta i nie przenosi automatycznie każdego zasobu. Dołączenie obciążeń, uprawnienia, przestrzeń adresowa i DNS są częścią architektury, a nie skutkiem ustawienia. Czytaj powiązanie najpierw jako zmianę uprawnień, a potem jako zmianę routingu, ponieważ zespoły zwykle odkrywają różnicę podczas przejścia.

Jeśli centralna własność nie jest akceptowalna dla zaangażowanych zespołów, zatrzymaj się tutaj i potraktuj resztę jako projekt peeringu lub centrum. Narzucenie Shared VPC grupie potrzebującej niezależnych cykli życia sieci tworzy problem polityczny o technicznej nazwie.

Sprawdź, czy niezależne VPC mogą pozostać niezależne

Peering zachowuje osobne VPC i właśnie dlatego przyciąga zespoły, które chcą własnych planów adresowych i własnej kontroli zmian. Haczyk polega na tym, że peering nie jest tranzytowy: peering A-do-B i B-do-C sam z siebie nie tworzy routingu A-do-C przez B. Jeśli trzy projekty muszą dotrzeć do jednego celu hybrydowego, potrzebujesz przemyślanego planu wymiany, a nie łańcucha peeringów.

Współdzielenie osiągalności hybrydowej zależy też od udokumentowanej wymiany tras niestandardowych i zamierzonych ogłoszeń Cloud Router. Status peeringu aktywny dowodzi, że peering istnieje, a nie że prefiksy ważne dla każdej strony kiedykolwiek wyeksportowano. Sprawdź wyeksportowane zakresy po obu stronach peera, w konfiguracji, która wykonuje eksport, i porównaj je z adresami, których Twoje obciążenia faktycznie używają. Niezgodność tam jest najczęstszą przyczyną tego, że peering wygląda zdrowo, a prefiks pozostaje nieosiągalny.

Napisz plan adresacji przed wszystkim innym. Nieprzecinające się zakresy, trasy do każdego zamierzonego celu i ogłoszenia zwrotne to trzy artefakty, na których ten model żyje lub umiera.

Sprawdź, czy model centrum pasuje do topologii

Dla większego lub inaczej segmentowanego projektu przegląd Google Network Connectivity Center opisuje modele centrum i szprychy. Czytaj go pod kątem tego, co obsługuje bieżące wydanie, a nie tego, co sugeruje diagram: które kombinacje VPC i hybrydowe, które rodziny tras i jakie zasady dopuszcza każdy typ szprychy.

Wyraźnie sprawdź rodzinę adresów. Przykłady planowania w większości przewodników, w tym w tym, dotyczą IPv4, a funkcja istniejąca dla jednego typu szprychy nie stosuje się automatycznie bez zmian do innego. Jeśli Twoje środowisko jest dwustosowe, to pytanie należy do wyboru modelu, a nie do późniejszej migracji.

Poniższa tabela jest podsumowaniem trzech modeli i pytania, które rozstrzyga każdy z nich.

Sprawdź, czego routing nie daje

Wymiana tras nie jest ogólnym udzieleniem zaufania. Rozwiązywanie DNS, uprawnienie zapory i autoryzacja aplikacji pozostają własnymi obowiązkami, a każdą z nich w większości organizacji konfiguruje inny właściciel. Projekt, który zakłada, że osiągalność oznacza autoryzację, przejdzie test łączności i obleje przegląd bezpieczeństwa.

Potwierdź też historię DNS dla każdego modelu, ponieważ układy stref i przekazywania różnią się między siecią wspólną a sieciami z peeringiem. Prywatne nazwy rozwiązywane w jednym projekcie nie podążają trasą do innego.

Zapisz decyzję i jej właściciela

Centralizuj tam, gdzie organizacja chce wspólnego właściciela sieci; zachowaj osobne VPC tam, gdzie wymaga tego cykl życia lub zasady. Następnie wybierz obsługiwaną relację łączności i zapisz, którą wybrałeś, kto posiada wspólną sieć i co każdy projekt może ogłaszać.

Liczenie projektów i kupowanie jednego VPN dla każdego nie zastępuje tej decyzji o własności. To ta sama decyzja, podjęta później, przez tego, kto dziedziczy rachunek i tablicę routingu.