Topologia sieci piasty i szprych

W tym artykule wyjaśniono, jak zaprojektować sieć typu hub-and-spoke na platformie Azure. Centralna sieć wirtualna typu hub obsługuje usługi wspólne, podczas gdy izolowane sieci wirtualne typu spoke obsługują poszczególne obciążenia robocze.

Co opisano w tym artykule

W tym artykule omówiono usługi współdzielone w wirtualnej sieci centrum, izolację sieci podrzędnych oraz wzorce routingu (standardowe, bezpośredni peering i oparte na stemplach). Obejmuje również tranzyt przez bramę dla łączności hybrydowej oraz skalowanie topologii typu koncentrator-szprycha za pomocą usługi Azure Virtual Network Manager.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli ma zastosowanie co najmniej jeden z następujących warunków:

  • Potrzebujesz współdzielonych usług sieciowych, takich jak zapora sieciowa, DNS, Bastion, VPN Gateway lub ExpressRoute, do obsługi wielu obciążeń.
  • Chcesz scentralizować inspekcję ruchu, kontrolę routingu lub administrację zamiast powtarzać te usługi w każdej sieci wirtualnej.
  • Potrzebna jest powtarzalna topologia do oddzielenia współdzielonych usług platformowych od sieci wirtualnych obciążeń.
  • Chcesz porównać model piasty i szprych z innymi modelami przesyłu przed ujednoliceniem topologii.

Jeśli masz pojedyncze obciążenie bez wymagań dotyczących usług udostępnionych, zamiast tego zacznij od płaskiej topologii sieci .

Tip

Podążasz ścieżką scenariusza? Wybierz swój scenariusz w górnej części strony, aby uzyskać dostosowane wskazówki. Poniższe podstawowe wskazówki dotyczą wszystkich czytelników.

Scenariusz lift-and-shift: Przeczytaj ten artykuł, jeśli przenosisz lokalne obciążenia do platformy Azure i potrzebujesz scentralizowanych usług wspólnych (DNS, zapory sieciowe, VPN Gateway) w wielu sieciach wirtualnych typu spoke. Topologia typu piasta-szprychy jest domyślną topologią dla migracji metodą „lift-and-shift” wielu obciążeń, wymagających współdzielonej infrastruktury w jednym koncentratorze.

Obszar modernizacji: Przeczytaj ten artykuł, jeśli wdrażasz usługi PaaS w wielu regionach i potrzebujesz topologii z dwoma hubami, w której huby należą do działu IT, a spoke’i do zespołów aplikacyjnych. Model hub-and-spoke można skalować tak, aby obsługiwał oddzielne granice subskrypcji dla usług platformowych i obciążeń aplikacyjnych.

Skupienie na środowiskach wielochmurowych: Przeczytaj ten artykuł, jeśli oceniasz rozwiązania hub-and-spoke i Virtual WAN pod kątem tranzytu między chmurami. Jeśli środowisko wielochmurowe jest na tyle małe, że wdrożenie usługi Virtual WAN nie jest uzasadnione, tradycyjna architektura typu hub-and-spoke z połączeniami VPN Gateway do innych chmur stanowi prostszy punkt wyjścia.

Usługi i funkcje platformy Azure

W poniższej tabeli wymieniono usługi i funkcje Azure, które obsługują topologię piasty i szprych:

Usługa lub funkcja Rola w szprychach piasty Learn more
Azure Virtual Network Udostępnia sieci wirtualne w architekturze hub-and-spoke Omówienie sieci wirtualnej
Komunikacja równorzędna sieci VNet Łączy każdą szprychę z piastą Peering sieci wirtualnych
Azure Firewall Centralna inspekcja ruchu i filtrowanie w koncentratorze Omówienie usługi Azure Firewall
VPN Gateway lub brama usługi ExpressRoute Łączność hybrydowa współdzielona we wszystkich szprychach Omówienie usługi VPN Gateway
Azure Bastion Zabezpieczanie zdalnego dostępu do maszyn wirtualnych między szprychami równorzędnymi Omówienie usługi Azure Bastion
Azure Prywatna strefa DNS Resolver Przekazywanie DNS między Azure i środowiskiem lokalnym Omówienie narzędzia Prywatna strefa DNS Resolver
Azure DDoS Protection Współdzielony plan ochrony przed atakami DDoS obejmujący publiczne adresy IP w topologii spoke Omówienie usługi DDoS Protection
Azure Virtual Network Manager (AVNM) Zautomatyzowane komunikacje równorzędne sieci typu spoke, zarządzanie trasami definiowanymi przez użytkownika oraz grupy sieciowe na dużą skalę Omówienie usługi AVNM

Jak to działa

Diagram przedstawiający topologię typu gwiazda z odgałęzieniami, z sieciami lokalnymi połączonymi za pośrednictwem usługi ExpressRoute i sieci VPN typu lokacja-lokacja z centralną siecią wirtualną zawierającą podsieci bramy, Azure Firewall i Azure Bastion, połączoną komunikacją równorzędną z trzema sieciami wirtualnymi odgałęzień obsługującymi różne obciążenia.

W topologii piasty i szprych:

  1. Wirtualna sieć centralna pełni funkcję centralnego punktu łączności. Zawiera współdzielone usługi sieciowe, takie jak zapora, brama i host bastionowy.
  2. Wirtualne sieci typu spoke są połączone komunikacją równorzędną z koncentratorem. Każda odnoga obsługuje obciążenie: aplikację, środowisko zespołowe lub izolowaną usługę.
  3. Komunikacja równorzędna sieci wirtualnej nie jest tranzytywna. Szprychy mogą dotrzeć do piasty, ale szprychy nie mogą się łączyć bezpośrednio przez piastę, chyba że skonfigurujesz routing lub bezpośrednią komunikację równorzędną między nimi.

Co znajduje się w wirtualnej sieci koncentratora

Skorzystaj z poniższej tabeli, aby określić, które usługi należy umieścić w centrum:

Service Uwzględnić? Notatki
Azure Firewall Zalecane Zapewnia scentralizowaną inspekcję ruchu dla całego ruchu wschodnio-zachodniego i północno-południowego. Wymaga podsieci o nazwie dokładnie AzureFirewallSubnet.
Sieć VPN lub brama usługi ExpressRoute Jeśli wymagana jest łączność hybrydowa Wszystkie sieci typu „spoke” współdzielą jedną bramę sieciową za pośrednictwem tranzytu bramy sieciowej. Wymaga podsieci o nazwie dokładnie GatewaySubnet (minimum /27).
Azure Bastion Zalecane Jeden host Bastion w sieci centralnej uzyskuje dostęp do maszyn wirtualnych we wszystkich sieciach wirtualnych typu spoke połączonych komunikacją równorzędną. Wymaga jednostki SKU Basic lub wyższej: jednostka SKU Developer nie obsługuje dostępu do komunikacji równorzędnej między sieciami wirtualnymi.
Prywatny resolver DNS Jeśli jest wymagany niestandardowy system DNS Przekazuje zapytania DNS między Azure hostowanymi prywatnymi strefami DNS i lokalnymi serwerami DNS.
plan usługi Azure DDoS Protection Jeśli ochrona przed atakami DDoS jest włączona Pojedynczy plan może chronić publiczne adresy IP we wszystkich sieciach wirtualnych szprych połączonych z subskrypcją koncentratora.

Ważna

Nie umieszczaj obciążeń aplikacji w hubie. Hub hostuje wyłącznie współdzielone usługi infrastrukturalne: zaporę, bramy sieciowe, usługę Bastion i system DNS. Maszyny wirtualne aplikacji, kontenery i zasoby PaaS powinny znajdować się w wirtualnych sieciach typu spoke. Ta separacja zapewnia czyste centrum, upraszcza komunikację równorzędną i umożliwia zespołowi platformy zarządzanie usługami udostępnionymi niezależnie od zespołów aplikacji.

Układ podsieci węzła centralnego

Dobrze zaprojektowana sieć wirtualna koncentratora zwykle obejmuje następujące podsieci:

Nazwa podsieci Purpose Minimalny rozmiar
AzureFirewallSubnet wdrażanie Azure Firewall /26
AzureFirewallManagementSubnet Karta sieciowa do zarządzania do wymuszonego tunelowania (tylko Standard/Premium) /26
GatewaySubnet Bramy sieci VPN i usługi ExpressRoute /27
AzureBastionSubnet Azure Bastion /26
Podsieć wejściowa resolvera DNS wejściowy punkt końcowy usługi Prywatna strefa DNS Resolver /28
Wychodząca podsieć programu rozpoznawania nazw DNS wychodzący punkt końcowy usługi Prywatna strefa DNS Resolver /28

Aby uzyskać szczegółowe wskazówki dotyczące określania rozmiaru podsieci, zobacz Sieci wirtualne i podsieci.

Jak wybrać wariant

Topologia hub-and-spoke ma trzy popularne warianty. Wybierz na podstawie wymagań dotyczących izolacji i komunikacji:

Schemat przedstawiający trzy warianty topologii: izolowane stemple, piasta‑szprychy z bezpośrednim połączeniem równorzędnym oraz standardowa topologia piasta‑szprychy przez zaporę sieciową

Variant Ścieżka ruchu Kiedy stosować
Standardowa piasta i szprycha Cały ruch między szprychami jest kierowany przez zaporę w hubie Potrzebna jest scentralizowana inspekcja ruchu. Szprychy nie wymagają bezpośredniej komunikacji typu peer-to-peer.
Architektura piasty i szprych z bezpośrednim peeringiem Konkretne pary szprych również łączą się bezpośrednio ze sobą Ściśle powiązane obciążenia wymagają komunikacji między szprychami z małym opóźnieniem, bez przechodzenia przez zaporę.
Sygnatury (w pełni izolowane) Brak koncentratora. Każda sieć wirtualna jest całkowicie niezależna. Ścisła izolacja ograniczająca zasięg awarii, separacja wynikająca z wymogów zgodności lub wielodzierżawna usługa SaaS z niezależnymi stosami technologicznymi.

Standardowa piasta i szprycha

Ten wariant jest najbardziej typowy. Cały ruch między szprychami przechodzi przez zaporę centralnego węzła w celu inspekcji. Węzły podrzędne komunikują się wyłącznie przez węzeł centralny, nigdy bezpośrednio.

Wzorzec routingu: Zastosuj trasę zdefiniowaną przez użytkownika (UDR) do każdej podsieci typu spoke, z trasą domyślną (0.0.0.0/0) wskazującą prywatny adres IP zapory w centrum. Wymusza to kierowanie całego ruchu wychodzącego, w tym ruchu między sieciami szprychowymi, przez zaporę w celu rejestrowania i filtrowania.

Limit komunikacji równorzędnej: Pojedyncza wirtualna sieć centralna obsługuje do 500 połączeń komunikacji równorzędnej (standardowy limit platformy). Jeśli używasz usługi Azure Virtual Network Manager (AVNM) z konfiguracją połączeń typu hub-and-spoke, limit zwiększa się do 1 000 sieci podrzędnych.

Topologia hub-and-spoke z bezpośrednim peeringiem

W niektórych architekturach określone pary segmentów typu spoke wymagają komunikacji z niskimi opóźnieniami bez przechodzenia przez zaporę hubu. W takich przypadkach dodaj bezpośrednią komunikację równorzędną sieci wirtualnej między parą sieci typu spoke lub skorzystaj z połączonych grup AVNM.

Użyj bezpośredniego peeringu między sieciami typu spoke, gdy:

  • Dwa obciążenia wymieniają dane o wysokiej przepływności (na przykład replikację bazy danych między szprychami).
  • Opóźnienie na przeskoku przez zaporę jest niedopuszczalne na określonej ścieżce danych.
  • Przyjmujesz do wiadomości, że ruch z bezpośredniego peeringu omija centralną kontrolę zapory sieciowej.

Note

Połączenia między szprychami nie eliminują potrzeby piasty. Ruch związany z koncentratorem (ruch wychodzący, łączność hybrydowa, usługi udostępnione) nadal kieruje się przez zaporę koncentratora.

Wzorzec stempli (w pełni odizolowany)

Wzorzec sygnatur jest alternatywą dla scenariuszy wymagających ścisłej izolacji promienia wybuchu. Każde obciążenie robocze wdrażane jest do całkowicie niezależnej sieci wirtualnej, bez huba i bez połączeń równorzędnych z innymi obciążeniami roboczymi.

Kiedy należy używać sygnatur:

  • Zgodność z przepisami nie wymaga ścieżki sieciowej między obciążeniami.
  • Środowisko SaaS z wieloma dzierżawcami, w którym każdy dzierżawca ma niezależny stos technologiczny.
  • Maksymalna izolacja usterek: awaria w jednym stampie nie może rozprzestrzenić się na inne.

Przykład: wielodostępna izolacja SaaS

Dostawca SaaS utrzymuje każdego klienta korporacyjnego w wydzielonym, dedykowanym środowisku. Każda sygnatura zawiera własną sieć wirtualną (10.x.0.0/16), bramę aplikacji, warstwę obliczeniową i bazę danych. Żadna komunikacja równorzędna sieci wirtualnych nie istnieje między sygnaturami, więc nieprawidłowo skonfigurowana sieciowa grupa zabezpieczeń lub naruszone obciążenie w sygnaturze dzierżawy A nie może uzyskać dostępu do zasobów dzierżawy B za pośrednictwem sieci. Dostawca zarządza sygnaturami za pomocą szablonów Azure Resource Manager i wdraża je w osobnych grupach zasobów lub oddzielnych subskrypcjach dla dużych dzierżaw. Wymiana danych między dzierżawami, w razie potrzeby, korzysta ze wspólnej przestrzeni nazw Azure Service Bus. Każda sygnatura uzyskuje dostęp do tej przestrzeni nazw za pośrednictwem prywatnych punktów końcowych.

Kompromisy:

  • Brak usług udostępnionych. Każda sygnatura wymaga własnej zapory, bramy i hosta usługi Bastion (w razie potrzeby), co zwiększa koszt.
  • Brak komunikacji między obciążeniami za pośrednictwem sieci prywatnej.
  • Obciążenie operacyjne zwiększa się, ponieważ zarządzasz niezależnymi sieciami zamiast scentralizowanej infrastruktury.
  • Koszt rośnie liniowo wraz z liczbą stempli, ponieważ oszczędności wynikające ze współdzielenia usługi nie mają zastosowania.

Jeśli Twoje obciążenia robocze wymagają jakichkolwiek usług wspólnych lub komunikacji między obciążeniami, użyj zamiast tego standardowego wariantu hub-and-spoke.

Wzorce komunikacji szprycha-szprych

Ponieważ komunikacja równorzędna sieci wirtualnych nie ma charakteru przechodniego, komunikacja między szprychami wymaga jawnej konfiguracji routingu. W tej sekcji opisano przepływ ruchu między szprychami przy użyciu zapory piasty.

Przepływ ruchu: Spoke A do Spoke B przez zaporę sieciową węzła centralnego

Poniższa sekwencja opisuje, jak pakiet przemieszcza się z maszyny wirtualnej w Spoke A (10.1.0.4) do maszyny wirtualnej w Spoke B (10.2.0.4):

  1. Maszyna wirtualna typu spoke wysyła pakiet skierowany do 10.2.0.4. Obowiązująca tabela tras maszyny wirtualnej zawiera trasę zdefiniowaną przez użytkownika (UDR) z 0.0.0.0/0 → 10.0.1.4 (prywatnym adresem IP zapory Azure Firewall).
  2. Pakiet przechodzi przez łącze komunikacji równorzędnej sieci wirtualnych ze Spoke A do centralnej sieci wirtualnej (hub). Peering umożliwia kierowanie ruchu do podsieci zapory sieciowej.
  3. Azure Firewall odbiera pakiet w interfejsie wewnętrznym. Ocenia pakiet względem reguł sieci i reguł aplikacji w kolejności priorytetu.
  4. Jeśli reguła zezwala na przepływ, zapora przekazuje pakiet do 10.2.0.4. Pakiet przechodzi przez łącze komunikacji równorzędnej między hubem a Spoke-B.
  5. Maszyna wirtualna Spoke B odbiera pakiet. Ruch powrotny podąża tą samą ścieżką w odwrotnym kierunku. UDR usługi Spoke B wysyła odpowiedź z powrotem przez zaporę.

Konfigurowanie tabel tras

Zastosuj te tabele tras, aby włączyć poprzedni wzorzec:

  1. Utwórz tabelę tras dla podsieci typu spoke. Wyłącz propagację tras protokołu BGP, jeśli chcesz zapobiec zastępowaniu tras zdefiniowanych przez użytkownika (UDR) przez trasy lokalne.
  2. Dodaj trasę domyślną (0.0.0.0/0) z typem VirtualAppliance następnego przeskoku i adresem następnego przeskoku ustawionym na prywatny adres IP Azure Firewall.
  3. Skojarz tabelę tras z każdą podsiecią szprych, która musi dotrzeć do innych szprych lub Internetu.
  4. Utwórz reguły sieciowe zapory, które zezwalają na określony ruch między sieciami typu spoke. Na przykład zezwalaj na 10.1.0.0/16 → 10.2.0.0/16 na portach 443 i 1433.

Tip

Użyj grup adresów IP w Azure Firewall, aby zorganizować zakresy adresów szprych. Upraszcza to zarządzanie regułami podczas dodawania szprych.

Alternatywa: połączone grupy AVNM do bezpośredniej komunikacji między szprychami

Jeśli nie potrzebujesz inspekcji zapory między określonymi szprychami, połączone grupy AVNM zapewniają model łączności siatki. Szprychy należące do tej samej połączonej grupy komunikują się bezpośrednio, bez przechodzenia przez koncentrator. Zmniejsza to opóźnienia i wymagania dotyczące przepływności zapory, ale pomija scentralizowaną inspekcję.

Ważna

Jeśli włączysz wymuszone tunelowanie na Azure Firewall (w celu kierowania ruchu powiązanego z Internetem do urządzenia lokalnego), potrzebujesz warstwy Standardowa lub Premium. Wymuszone tunelowanie wymaga również podsieci do zarządzania (AzureFirewallManagementSubnet) i wyłącza reguły DNAT.

Tranzyt przez bramę

Tranzyt bramy umożliwia wszystkim szprychom współużytkowanie jednej sieci VPN lub bramy usługi ExpressRoute wdrożonej w centrum. Bez tranzytu bramy każda sieć typu spoke potrzebuje własnej bramy, aby łączyć się z sieciami lokalnymi.

Kroki konfiguracji

  1. Wdróż bramę sieci VPN lub usługi ExpressRoute w centrum GatewaySubnet.
  2. W połączeniu komunikacji równorzędnej po stronie hubu (hub → spoke): włącz opcję Zezwalaj na tranzyt bramy.
  3. W połączeniu komunikacji równorzędnej po stronie szprych (szprychy → piasty): włącz opcję Użyj bram zdalnych.
  4. Zweryfikuj propagację trasy. Po skonfigurowaniu sprawdź efektywne trasy na karcie sieciowej maszyny wirtualnej typu spoke. Tabela tras pokazuje prefiksy lokalne uzyskane przez bramę koncentratora z typem następnego przeskoku VNetGlobalPeering lub VNetPeering.

Po skonfigurowaniu trasy pobrane przez bramę centrum (na przykład prefiksy sieci lokalnej z usługi ExpressRoute) są automatycznie propagowane do tabel routingu sieci szprychowych.

Ograniczenia tranzytu przez bramę

  • Tranzyt bramy sieci VPN działa ze wszystkimi warstwami usługi VPN Gateway z wyjątkiem warstwy Basic. Jeśli używasz VPN Gateway Podstawowa, nie możesz udostępnić jej równorzędnym sieciom wirtualnym.
  • Wirtualna sieć podrzędna może korzystać tylko z jednej bramy zdalnej. Nie można włączyć Use remote gateways w szprysze, która ma komunikację równorzędną z wieloma koncentratorami.
  • Jeśli używasz tras zdefiniowanych przez użytkownika do wymuszania ruchu przez zaporę, upewnij się, że trasa zdefiniowana przez użytkownika nie zastępuje niezamierzonych tras lokalnych propagowanych przez bramę. W razie potrzeby ustaw bardziej szczegółowe trasy dla prefiksów lokalnych.

Note

W przypadku korzystania z usługi ExpressRoute z tranzytem bramy włącz opcję Zezwalaj na tranzyt bramy przed ustanowieniem połączeń równorzędnych sieci typu spoke. Brama musi już istnieć i zostać najpierw wdrożona.

Azure Virtual Network Manager na dużą skalę

Gdy środowisko rozrasta się poza kilka połączeń typu spoke, ręczne zarządzanie połączeniami peeringowymi i tabelami tras staje się skomplikowane. AVNM zapewnia automatyzację dla topologii typu piasta-szprycha:

Obsługa AVNM Do czego służy
Konfiguracja łączności w topologii hub-and-spoke Automatycznie tworzy i utrzymuje komunikację partnerską między hubem a wszystkimi połączeniami typu spoke w grupie sieciowej. Obsługuje do 1 000 szprych na jedną piastę.
Połączone grupy Umożliwia bezpośrednią łączność między sieciami typu spoke bez ręcznego parowania. Domyślny limit: 250 sieci wirtualnych na grupę (można rozszerzyć do 1000 według żądania).
Grupy sieciowe z członkostwem dynamicznym Używa warunków Azure Policy do automatycznego dodawania sieci wirtualnych do grup na podstawie tagów, nazewnictwa lub subskrypcji.
Zarządzanie UDR Automatyzuje wdrażanie tabel tras w wielu topologiach typu piasta-szprycha.

Usługa AVNM jest szczególnie cenna, gdy zarządzasz topologiami typu piasta–szprychy w wielu regionach lub gdy potrzebne jest dynamiczne członkostwo w miarę uruchamiania nowych wirtualnych sieci szprych.

Zagadnienia dotyczące skalowania

W miarę rozwoju topologii typu piasta–szprychy uwzględnij następujące ograniczenia platformy i wzorce organizacyjne:

Ograniczenia peeringu i łączności sieciowej

Wymiar Limit standardowy Za pomocą programu AVNM Notatki
Połączenia równorzędne VNet na jedną sieć wirtualną 500 1,000 (konfiguracja piasta-szprychy) Każde połączenie równorzędne typu spoke-to-hub zajmuje jeden slot po obu stronach
Sieci wirtualne dla połączonej grupy AVNM 250 (ustawienie domyślne) Maksymalnie 1000 (według żądania) Wniosek o zwiększenie za pośrednictwem pomocy technicznej platformy Azure
Subskrypcje na zakres AVNM N/A 1 000 Zakres może obejmować wiele subskrypcji w grupie zarządzania

Organizacja subskrypcji

  • Rozdziel szprychy na subskrypcje specyficzne dla obciążeń dla środowisk z więcej niż 10 szprychami. To izoluje rozliczenia, RBAC i limity przydziałów dla każdego zespołu odpowiedzialnego za obciążenia.
  • Użyj dedykowanej subskrypcji przeznaczonej do obsługi łączności dla sieci wirtualnej koncentratora, bram sieciowych i zapory. Jest to wzorzec zalecany przez strefy docelowe Azure (subskrypcja platformy).
  • Grupuj subskrypcje w ramach grupy zarządzania, aby usługa AVNM mogła dynamicznie odnajdywać sieci wirtualne typu spoke w różnych subskrypcjach i zarządzać nimi za pomocą warunków usługi Azure Policy.

Wymuszanie topologii za pomocą Azure Policy

Użyj Azure Policy, aby zapobiec dryfowi konfiguracji:

  • Odmów komunikacji równorzędnej z sieciami wirtualnymi innymi niż sieć centralna. Przypisz na poziomie grupy zarządzania zasadę, która blokuje tworzenie komunikacji równorzędnej sieci wirtualnych, chyba że siecią docelową jest wyznaczona sieć wirtualna typu hub.
  • Wymagaj powiązania UDR. Przypisz politykę, która przeprowadza inspekcję (lub odrzuca) podsieci typu spoke bez tabeli tras zawierającej trasę 0.0.0.0/0 → Firewall.
  • Wymuszanie członkostwa w grupie AVNM. Użyj reguł członkostwa dynamicznego w AVNM opartych na tagach (na przykład NetworkRole:Spoke), aby nowe sieci VNet były automatycznie dołączane.

Ścieżka migracji z płaskiej do szprychy

Jeśli początkowo stosowano płaską topologię sieci, a środowisko rozrosło się na tyle, że wymaga współdzielonych usług lub segmentacji między obciążeniami, postępuj zgodnie z tą ścieżką migracji:

Krok 1: Zaplanuj sieć wirtualną typu hub

  1. Przydziel nową przestrzeń adresową dla centrum (na przykład 10.0.0.0/16), która nie pokrywa się z istniejącą płaską siecią VNet.
  2. Ustal, które usługi udostępnione mają zostać wdrożone: zapora, brama, bastion, program rozpoznawania nazw DNS.
  3. Dostosuj rozmiar podsieci koncentratora zgodnie z tabelą układu podsieci koncentratora.

Krok 2. Wdrażanie usług udostępnionych w centrum

  1. Utwórz koncentrator VNet i wdróż usługę Azure Firewall (lub wybrane rozwiązanie NVA).
  2. Wdróż bramę sieci VPN/usługi ExpressRoute, jeśli potrzebujesz łączności hybrydowej.
  3. Wdróż Azure Bastion na potrzeby bezpiecznego dostępu do maszyny wirtualnej.
  4. Skonfiguruj Prywatna strefa DNS Resolver, jeśli używasz niestandardowego systemu DNS.

Krok 3. Migrowanie obciążeń do szprych

  1. Utwórz sieci wirtualne typu spoke z nowymi przestrzeniami adresowymi dla każdego obciążenia roboczego. Jeśli nie możesz zmienić adresacji IP, możesz zachować istniejące zakresy, o ile nie nakładają się one na węzeł centralny.
  2. Skonfiguruj połączenie typu peering między każdą odnogą a koncentratorem. Włącz tranzyt przez bramę po stronie huba i użyj zdalnej bramy po stronie spoke.
  3. Zastosuj trasy zdefiniowane przez użytkownika do podsieci podrzędnych, z domyślną trasą wskazującą centralną zaporę.
  4. Przenieś lub ponownie wdroż maszyny wirtualne i usługi z płaskiej sieci VNet do odpowiedniego spoke. Użyj Azure Resource Mover lub ponownego wdrożenia, w zależności od złożoności obciążenia.
  5. Utwórz reguły zapory, aby zezwolić na schematy ruchu między szprychami oraz ze szprych do Internetu, na które wcześniej zezwolono w płaskiej sieci wirtualnej.

Krok 4. Zlikwidowanie płaskiej sieci wirtualnej

  1. Sprawdź, czy wszystkie obciążenia są osiągalne za pomocą nowej topologii piasty i szprych.
  2. Zaktualizuj rekordy DNS, jeśli prywatne adresy IP uległy zmianie.
  3. Usuń stary płaski VNet po przeprowadzeniu migracji i zweryfikowaniu całego ruchu.

Tip

Migrowanie obciążeń w fazach. Zacznij od obciążenia niekrytycznego, aby zweryfikować reguły routingu i zapory, a następnie przejść do obciążeń produkcyjnych.

Kiedy należy rozważyć Virtual WAN zamiast tego

Jeśli topologia typu piasta-szprychy staje się coraz bardziej złożona, oceń, czy usługa Azure Virtual WAN będzie lepszym rozwiązaniem:

Czynnik Architektura hub-and-spoke (tradycyjna) Azure Virtual WAN
Management Infrastruktura koncentratora zarządzanego przez klienta Routing i łączność koncentratora zarządzane przez firmę Microsoft
Najlepsze dla Mniej niż 30 połączeń gałęzi SIECI VPN, wymagana jest pełna kontrola 30+ gałęzie sieci VPN, wiele regionów Azure
Routing Klient ręcznie konfiguruje trasy UDR Automatyczne trasowanie w centrum
integracja SD-WAN Ręczne wdrażanie NVA Natywna integracja partnerów SD-WAN
Tranzyt globalny Wymaga routingu między koncentratorami zarządzanego przez klienta Wbudowana funkcja: wszystkie huby łączą się ze sobą automatycznie

Aby uzyskać szczegółowe porównanie, zobacz topologia Azure Virtual WAN.

Uwagi dotyczące projektowania

W przypadku migracji metodą „lift-and-shift” wdroż pojedynczy węzeł centralny ze współdzielonymi usługami, z których korzystają wszystkie migrowane obciążenia:

  • Pojedynczy koncentrator z VPN Gateway. Wdróż VPN Gateway (lub bramę usługi ExpressRoute) w podsieci GatewaySubnet centrum. Wszystkie obciążenia w sieciach spoke współdzielą tę bramę za pośrednictwem tranzytu bramy na potrzeby łączności ze środowiskiem lokalnym podczas migracji i po jej zakończeniu.
  • Azure Bastion w centrum. Pojedyncze wdrożenie usługi Bastion w centrum zapewnia bezpieczny dostęp RDP/SSH do maszyn wirtualnych we wszystkich szprychach równorzędnych bez uwidaczniania publicznych adresów IP na zmigrowanych serwerach.
  • Scentralizowana zapora dla ruchu wychodzącego. Wdróż Azure Firewall w centrum. Skonfiguruj trasy zdefiniowane przez użytkownika (UDR) w każdej podsieci typu spoke, z trasą domyślną wskazującą na zaporę. Cały ruch wychodzący i szprychowy przepływa przez ten pojedynczy punkt inspekcji.
  • Zacznij od jednego węzła, a następnie stopniowo dodawaj odnogi. Połącz pomocniczą sieć wirtualną (VNet) każdego obciążenia komunikacją równorzędną z siecią centralną w miarę migrowania każdego z nich. Pojedyncze centrum obsługuje maksymalnie 500 połączeń komunikacji równorzędnej (1000 z usługą AVNM).

W przypadku scenariusza migracji i modernizacji należy zaplanować topologię z dwoma koncentratorami, która oddziela infrastrukturę platformy od obciążeń aplikacji:

  • Wdrożenie z dwoma centralami. Wdróż centrum w regionie podstawowym i drugim centrum w regionie kopii zapasowej. Każdy hub obejmuje własną zaporę, bramę i Bastion. Obsługuje to architektury aktywne-aktywne dla obciążeń PaaS.
  • Huby zarządzane przez IT, spoke’i zarządzane przez zespół aplikacyjny. Zespół platformy zarządza subskrypcjami centralnego koncentratora (wzorzec subskrypcji łączności, czyli dedykowana subskrypcja Azure dla współdzielonych zasobów sieciowych centralnego koncentratora, oddzielona od subskrypcji obciążeń). Zespoły aplikacyjne są właścicielami swoich subskrypcji typu spoke, z delegowaną kontrolą nad ich podsieciami Private Link i zasobami obciążeń roboczych.
  • Podsieci Private Link dla każdej szprychy. Każda sieć wirtualna typu spoke zawiera dedykowaną podsieć dla prywatnych punktów końcowych. Zespoły aplikacyjne tworzą połączenia Private Link do swoich usług PaaS (Azure SQL, Storage, Key Vault) we własnych sieciach typu spoke.
  • Zapora hubu dla SNAT/DNAT. Centralna zapora w każdym węźle zapewnia translację adresów źródłowych (SNAT) dla ruchu wychodzącego oraz translację adresów docelowych (DNAT) dla ruchu przychodzącego. Zespoły aplikacji nie mogą pominąć scentralizowanej inspekcji.

W przypadku łączności między chmurami należy ocenić, czy tradycyjna szprycha czy Virtual WAN zapewnia odpowiedni model tranzytowy:

  • Wybór między hub-spoke a Virtual WAN. Jeśli masz mniej niż 30 połączeń z oddziałami, niewielką liczbę tuneli VPN między chmurami i działasz w jednym lub dwóch regionach platformy Azure, tradycyjna topologia piasta-szprycha z VPN Gateway jest prostsza. Jeśli masz wiele sieci VPN, gałęzi, regionów lub krawędzi chmury, Virtual WAN zapewnia zautomatyzowany routing, który skaluje się lepiej.
  • VPN Gateway dla tuneli między chmurami. W modelu piasty i szprych wdróż VPN Gateway w centrum i utwórz połączenia typu lokacja-lokacja z wirtualnymi bramami prywatnymi platformy AWS i punktami końcowymi sieci VPN w chmurze Google. Każde połączenie używa szyfrowania IPSec/IKE.
  • Ocena wzrostu złożoności. Jeśli Twoje środowisko wielochmurowe się rozrasta (więcej kont AWS, projektów Google Cloud lub regionów Azure), ponownie przeanalizuj wybór między architekturą piasta-szprychy a usługą Virtual WAN. Virtual WAN staje się bardziej opłacalne podczas zarządzania wieloma tunelami na dużą skalę.

Aby uzyskać pełne porównanie, zobacz topologię usługi Azure Virtual WAN.

Prerequisites

Przed zaprojektowaniem sieci typu piasta-szprycha:

  • Ukończ sieć wirtualną i plan podsieci. Dowiedz się, ile potrzebnych szprych i jakich podsieci wymaga każda szprycha.
  • Zdefiniuj schemat adresów IP. Przestrzenie adresowe modelu hub-and-spoke nie mogą się nakładać.
  • Dowiedz się, że komunikacja równorzędna sieci wirtualnych nie jest przechodnia: szprychy nie dziedziczą łączności z innymi szprychami za pośrednictwem koncentratora.

Zagadnienia dotyczące zabezpieczeń

Topologia typu hub-and-spoke centralizuje egzekwowanie zasad bezpieczeństwa w centralnym węźle. Zastosuj następujące zasady:

  • Kieruj cały ruch ze szprych przez zaporę centrum. Użyj tras UDR, w których trasa domyślna wskazuje na zaporę. Ta konfiguracja zapewnia, że zapora inspekcjonuje i rejestruje każdy przepływ między szprychami oraz ze szprych do Internetu.
  • Użyj sieciowych grup zabezpieczeń (NSG) w podsieciach typu spoke jako dodatkowej warstwy zabezpieczeń. Nawet przy centralnej zaporze grupy zabezpieczeń sieciowych w podsieciach typu spoke zapewniają dodatkową warstwę segmentacji. Zablokuj niepożądany ruch boczny na poziomie podsieci. Aby uzyskać wskazówki dotyczące projektowania grup NSG, zobacz artykuł Sieciowe grupy zabezpieczeń i grupy zabezpieczeń aplikacji.
  • Włączaj tranzyt bramy sieciowej ostrożnie. Tranzyt przez bramę udostępnia wszystkim sieciom typu spoke trasy do sieci lokalnej. Upewnij się, że reguły zapory sieciowej uwzględniają rozszerzoną łączność.
  • Usuń publiczne adresy IP z maszyn wirtualnych spoke. Azure Bastion w centrum zapewnia bezpieczny dostęp do zarządzania bez ujawniania maszyn wirtualnych w Internecie.
  • Traktuj każdą szprychę jako granicę zabezpieczeń. Obciążenia w różnych szprychach pozostają domyślnie odizolowane. Łączność między szprychami wymaga jawnego routingu i reguł zapory.

Learn more

Następne kroki

Tip

Eksplorowanie na własną rękę? Wróć do nawigatora przeglądu , aby znaleźć następny artykuł według możliwości.

Kolejny etap w procesie migracji typu lift-and-shift:

Połącz się z siecią lokalną: skonfiguruj bramę VPN lub usługę ExpressRoute w centralnej sieci wirtualnej, aby utworzyć krytyczną zależność wymaganą do migracji.

Kolejny etap procesu modernizacji:

Zaplanuj wdrożenie w wielu regionach: Wdróż model active-active w regionach podstawowych i zapasowych dla aplikacji skierowanych do klientów.

Kolejny krok w Twojej wielochmurowej podróży:

Oceń usługę Azure Virtual WAN jako model sieci tranzytowej: sprawdź, czy Virtual WAN czy topologia hub-and-spoke lepiej odpowiada Twojemu środowisku wielochmurowemu z wieloma sieciami VPC, oddziałami i regionami.

  • Last updated on