Topologia sieci piasty i szprych IPv6

W tym artykule opisano sposób przenoszenia topologii sieci IPv4 piasty i szprych do protokołu IPv6. Przedstawia topologię sieci piasty i szprych jako punkt wyjścia i opisuje kroki, które można wykonać w celu zaimplementowania obsługi protokołu IPv6.

W sieci typu piasta–szprychy centralna sieć wirtualna jest centralnym punktem łączności dla sieci wirtualnych szprych. Sieci wirtualne typu spoke łączą się z siecią centralną i mogą zapewniać izolację zasobów aplikacji. Aby uzyskać więcej informacji, zobacz Przechodzenie do protokołu IPv6.

Architecture

Pobierz plik programu Visio tej architektury.

Workflow

1. Publiczny Internet i sieć między lokalami: użytkownicy lub usługi mogą uzyskiwać dostęp do zasobów platformy Azure za pośrednictwem publicznego Internetu. Sieć między lokacjami obejmuje lokalne maszyny wirtualne, które bezpiecznie łączą się z siecią Azure. Ruch IPv4 odbywa się za pośrednictwem bramy sieci VPN lub usługi Azure ExpressRoute. Ruch IPv6 korzysta z prywatnej komunikacji równorzędnej IPv6 usługi ExpressRoute. Azure VPN Gateway może przenosić ruch IPv6 w innych konfiguracjach, ale nie wtedy, gdy współistnieje z bramą usługi ExpressRoute z obsługą protokołu IPv6, tak jak w tym przypadku.

2. Azure Virtual Network Manager: Ta warstwa zarządzania centralnie grupuje i konfiguruje sieci wirtualne w topologii. Wdraża konfiguracje łączności, administratora zabezpieczeń i routingu w grupach sieciowych.

3. Wirtualna sieć koncentratora: Koncentrator jest centralnym punktem topologii sieci. Konfiguracja sieci obsługuje zarówno protokoły IPv4, jak i IPv6 (podwójny stos), z wyjątkiem składników wymienionych w ograniczeniach obsługi protokołu IPv6.

   • Azure Bastion zapewnia łączność protokołu Remote Desktop /Secure Shell (RDP/SSH) z portalu Azure do maszyn wirtualnych bezpośrednio za pośrednictwem protokołu Transport Layer Security (TLS).
   • Azure Firewall sprawdza i filtruje ruch IPv4 między centrum i publicznym Internetem. Obsługa IPv6 w trybie dual-stack jest dostępna w wersji zapoznawczej i obejmuje tylko reguły sieciowe oraz proxy DNS, dlatego w tej architekturze podsieć zapory pozostaje przeznaczona wyłącznie dla protokołu IPv4, a inspekcja ruchu IPv6 jest kierowana do puli NVA.
   • Zestaw wirtualnych urządzeń sieciowych obsługujących IPv6 (NVA) działa we własnej podsieci huba za wewnętrznym modułem równoważenia obciążenia. Pula zasobów kontroluje i filtruje ruch IPv6 między sieciami typu spoke, publicznym internetem i siecią między lokalizacjami. Zapewnia odpowiednik ścieżki inspekcji dla protokołu IPv6, którą Azure Firewall udostępnia dla protokołu IPv4. Wdróż co najmniej dwie instancje, aby awaria jednej z nich nie spowodowała przerwania łączności IPv6.
   • Usługa ExpressRoute łączy sieć między sieciami lokalnymi z koncentratorem i przenosi zarówno ruch IPv4, jak i IPv6.
   • Brama sieci VPN również łączy sieć lokalną z koncentratorem i może służyć jako zapasowa ścieżka IPv4 dla prywatnego peeringu usługi ExpressRoute. Samo współistnienie nie powoduje przejścia w tryb failover. Skonfiguruj sieć lokalną, aby preferować trasy, które uczy się za pośrednictwem usługi ExpressRoute, na przykład przez ustawienie wyższej preferencji lokalnej protokołu BGP. Ponieważ usługa VPN Gateway współistnieje z bramą ExpressRoute z obsługą protokołu IPv6 w tym koncentratorze, obsługuje tylko ruch IPv4.
   • Usługi w centralnej sieci wirtualnej wysyłają dzienniki i metryki (dane diagnostyczne) do usługi Azure Monitor w celu monitorowania.

4. Sieci wirtualne typu spoke: Cztery sieci spoke łączą się z hubem. Każda odnoga jest siecią dual-stack, obsługującą zarówno IPv4, jak i IPv6.

   • Trasy zdefiniowane przez użytkownika (UDR) protokołu IPv6 definiują trasy niestandardowe dla ruchu IPv6 ze szprychy.
   • Sieci wirtualne typu spoke są połączone za pomocą połączeń równorzędnych lub połączonych grup. Połączenia równorzędne i połączone grupy to nieprzechodnie połączenia o niskich opóźnieniach między sieciami wirtualnymi. Równorzędne lub połączone sieci wirtualne mogą wymieniać ruch przez sieć szkieletową platformy Azure.
   • Cały wychodzący ruch IPv4 z wirtualnych sieci spoke jest kierowany przez hub. Domyślna trasa IPv4 w tabeli routingu każdej podsieci typu spoke kieruje ten ruch do usługi Azure Firewall. Oddzielna domyślna trasa IPv6 wysyła ruch wychodzący IPv6 do puli NVA IPv6, ponieważ w tej architekturze usługa Azure Firewall obsługuje tylko protokół IPv4.
   • W każdym ramieniu znajdują się trzy podsieci przeznaczone jako podsieci zasobów, a w każdej z nich znajduje się maszyna wirtualna.
   • Każda maszyna wirtualna łączy się z wewnętrznym modułem równoważenia obciążenia skonfigurowanym do obsługi zakresów adresów IPv4 i IPv6. Moduł równoważenia obciążenia dystrybuuje przychodzący ruch sieciowy między maszynami wirtualnymi.

Components

• Usługa Azure Virtual Network to podstawowa warstwa sieci na platformie Azure, która umożliwia bezpieczną komunikację między zasobami platformy Azure, Internetem i sieciami lokalnymi. W tej architekturze stanowi topologię koncentratora i odgałęzień, która obsługuje konfiguracje dual-stack (IPv4 i IPv6), zapewniając scentralizowaną i izolowaną łączność.
• Interfejs sieciowy wirtualny to interfejs logiczny, który łączy zasoby platformy Azure z siecią wirtualną. W tej architekturze umożliwia maszynom wirtualnym komunikację za pośrednictwem protokołów IPv4 i IPv6. Pojedynczy interfejs staje się interfejsem dual-stack, gdy dodasz konfigurację IPv6 obok istniejącej konfiguracji IPv4.
• Publiczny adres IP zapewnia łączność przychodzącą z zasobami platformy Azure za pośrednictwem Internetu. W tej architekturze obsługuje zarówno dostęp IPv4, jak i IPv6 do usług hostowanych w sieci wirtualnej.
• Menedżer sieci wirtualnej to scentralizowana usługa zarządzania służąca do organizowania i konfigurowania sieci wirtualnych oraz ich łączności. W tej architekturze zarządza grupami sieci i połączeniami w sieciach typu hub-and-spoke.
• Azure Firewall to usługa zabezpieczeń sieci, która chroni zasoby platformy Azure, sprawdzając i filtrując ruch. W tej architekturze architektura ta wymusza kontrolę ruchu IPv4 między hubem a publicznym internetem. Zarządzane wystąpienie usługi Azure Firewall znajduje się we własnej podsieci, w której w tej architekturze zachowano wyłącznie obsługę protokołu IPv4, ponieważ obsługa podwójnego stosu IPv6 jest dostępna w wersji zapoznawczej i nie obejmuje reguł aplikacji, DNAT, analizy danych o zagrożeniach, IDPS, funkcji Explicit Proxy ani grup adresów IP.
• Wirtualne urządzenie sieciowe (WUS) to maszyna wirtualna, która pełni funkcję sieciową, taką jak zapora sieciowa lub router. W tej architekturze pula urządzeń NVA obsługujących protokół IPv6 w hubie kontroluje i filtruje ruch IPv6. Wewnętrzny moduł równoważenia obciążenia obsługuje pulę, dzięki czemu żadne pojedyncze urządzenie nie stanowi pojedynczego punktu awarii dla łączności IPv6.
• VPN Gateway i ExpressRoute to usługi, które zapewniają bezpieczną łączność między Azure i sieciami lokalnymi. Mogą tworzyć bramy sieci wirtualnej łączące sieci wirtualne platformy Azure z wirtualnymi urządzeniami sieci prywatnej (VPN) lub obwodami usługi ExpressRoute, co umożliwia zaszyfrowaną lub prywatną komunikację. W tej architekturze usługa ExpressRoute obsługuje ruch IPv6 między środowiskami lokalnymi za pośrednictwem prywatnego peeringu IPv6, a usługa VPN Gateway obsługuje wyłącznie ruch IPv4, ponieważ obie bramy współistnieją.
• Azure Load Balancer to usługa równoważenia obciążenia warstwy 4, która dystrybuuje przychodzący ruch sieciowy między wiele zasobów zaplecza w celu zapewnienia wysokiej dostępności i skalowalności. W tej architekturze wewnętrzny moduł równoważenia obciążenia w każdej szprysze rozkłada ruch IPv6 na maszyny wirtualne w tej szprysze, a wewnętrzny moduł równoważenia obciążenia w koncentratorze stanowi warstwę frontową dla puli wirtualnych urządzeń sieciowych IPv6.
• Azure NAT Gateway zapewnia łączność internetową tylko dla ruchu wychodzącego dla podsieci. W tej architekturze brama NAT StandardV2 dołączona do podsieci NVA zapewnia puli NVA IPv6 jawną ścieżkę ruchu wychodzącego, ponieważ wewnętrzny moduł równoważenia obciążenia, który obsługuje tę pulę, nie zapewnia łączności wychodzącej.
• Tablica tras to zestaw tras zdefiniowanych przez użytkownika (UDR), zapewniających niestandardową kontrolę nad sposobem przepływu ruchu w obrębie sieci wirtualnych platformy Azure i między nimi. W tej architekturze trasy zdefiniowane przez użytkownika (UDR) kierują ruchem IPv6 przez podsieci w topologii piasta-szprycha, aby wymuszać przepływ ruchu i zasady bezpieczeństwa.
• Azure Virtual Machines to rozwiązanie infrastruktury jako usługi (IaaS), które zapewnia elastyczne, skalowalne zasoby obliczeniowe. W tej architekturze maszyny wirtualne są wdrażane w podsieciach typu spoke, skonfigurowanych z użyciem interfejsów sieciowych dual stack, które umożliwiają obsługę obciążeń działających zarówno w IPv4, jak i IPv6.
• Azure Bastion to zarządzana platforma jako usługa (PaaS), która zapewnia bezpieczny dostęp RDP i SSH do maszyn wirtualnych bez ujawniania ich publicznej sieci Internet. W tej architekturze działa w centrum i umożliwia dostęp zdalny zabezpieczony przez protokół TLS do maszyn wirtualnych w równorzędnych sieciach wirtualnych szprych.
• Azure Monitor to platforma do obserwacji, która zbiera, analizuje i działa na danych telemetrycznych ze środowisk platformy Azure i środowisk hybrydowych. W tej architekturze zbiera dane diagnostyczne i metryki z usług centrum w celu obsługi monitorowania wydajności i widoczności operacyjnej.

Ograniczenia obsługi protokołu IPv6

Kilka usług, które często występują w topologii typu hub-and-spoke, nie obsługuje ruchu IPv6 albo obsługuje go tylko w określonych warunkach. Przed zaplanowaniem przestrzeni adresowej i routingu należy uwzględnić te ograniczenia.

Pełną listę można znaleźć w artykułach Ograniczenia IPv6 dla Azure Virtual Network i Ograniczenia IPv6 usługi ExpressRoute.

Wewnętrzny moduł równoważenia obciążenia dystrybuuje tylko ruch przychodzący i nie zapewnia łączności wychodzącej. Podsieci w sieciach wirtualnych tworzonych przy użyciu bieżącej wersji interfejsu API są domyślnie prywatne, więc nie mają domyślnego dostępu wychodzącego. Każda podsieć, która wysyła ruch IPv6 do internetu, wymaga jawnie określonej metody ruchu wychodzącego, w tym podsieć NVA. Ta architektura przypisuje do podsieci NVA bramę NAT StandardV2, która jest jedyną jednostką SKU bramy NAT obsługującą IPv6.

Nie łącz bramy NAT StandardV2 z regułami ruchu wychodzącego usługi Azure Load Balancer w tej samej podsieci. Brama NAT zakłóca działanie wychodzących połączeń IPv6 wykorzystujących te reguły. Brama NAT StandardV2 zapewnia również translację NAT64, dzięki czemu obciążenia robocze IPv6 mogą uzyskiwać dostęp do lokalizacji docelowych obsługujących wyłącznie IPv4, ale dostęp oparty na nazwach do tych lokalizacji wymaga zewnętrznego rozwiązania DNS64 do syntezy rekordów AAAA.

Przenoszenie sieci wirtualnej koncentratora do protokołu IPv6

Aby przenieść sieć wirtualną koncentratora do obsługi protokołu IPv6, należy zaktualizować infrastrukturę sieci w celu uwzględnienia zakresów adresów IPv6, aby centralna część sieci mogła obsługiwać ruch IPv6. Takie podejście gwarantuje, że centralne centrum może efektywnie kierować ruch między różnymi segmentami sieci (szprychami) i zarządzać nim przy użyciu protokołu IPv6. Aby zaimplementować protokół IPv6 w sieci wirtualnej koncentratora, wykonaj następujące kroki:

Dodawanie przestrzeni adresowej IPv6 do sieci wirtualnej koncentratora i podsieci koncentratora

Należy najpierw dodać zakresy adresów IPv6 do sieci wirtualnej koncentratora, a następnie do jej podsieci. Użyj bloku adresowego /56 dla sieci wirtualnej i bloku adresów /64 dla każdej podsieci. W poniższej tabeli przedstawiono przykładową konfigurację.

Nie dodawaj przestrzeni adresowej IPv6 do podsieci Azure Firewall. Ta architektura pozostawia usługę Azure Firewall wyłącznie w trybie IPv4, ponieważ jej obsługa trybu dual-stack jest w wersji zapoznawczej i nie obejmuje reguł aplikacji ani systemu IDPS. Brama sieci VPN współistnieje z bramą usługi ExpressRoute z obsługą protokołu IPv6, więc prowadzi tylko ruch IPv4. Nie należy kierować protokołu IPv6 przez nią nawet wtedy, gdy jej podsieć jest dwustosowa.

Podsieć Azure Bastion wymaga przestrzeni adresowej IPv6 tylko wtedy, gdy uruchamiasz hosta usługi Bastion z podwójnym stosem. Nie można przekonwertować istniejącego hosta obsługującego wyłącznie protokół IPv4, dlatego przed rozpoczęciem korzystania z tego zakresu ponownie wdroż usługę Bastion z włączonym trybem dual stack.

Adresy IPv6 w tabeli to przykłady. Zastąp element 2001:db8:1234:: blokiem adresów IPv6 organizacji. Starannie zaplanuj i udokumentowaj alokacje adresów IPv6, aby uniknąć nakładania się na siebie i zapewnić efektywne wykorzystanie przestrzeni adresowej. Aby dodać przestrzeń adresową IPv6 do sieci wirtualnej koncentratora, zobacz Dodawanie protokołu IPv6 do sieci wirtualnej, która zawiera instrukcje dotyczące korzystania z portalu Azure, programu PowerShell i Azure CLI.

Wdróż pulę NVA protokołu IPv6 dla wysokiej dostępności

Urządzenie NVA dla IPv6 obsługuje w tej architekturze każdy inspekcjonowany przepływ IPv6, więc pojedyncze urządzenie staje się pojedynczym punktem awarii dla łączności z internetem IPv6 i łączności między lokalizacjami. Wdróż pulę urządzeń zamiast jednej maszyny wirtualnej.

• Wdróż co najmniej dwa wystąpienia NVA i rozmieść je w strefach dostępności w regionach, które obsługują strefy.
• Umieść przed pulą wewnętrzny moduł równoważenia obciążenia w warstwie Standard z dwustosową konfiguracją frontonu. Skonfiguruj regułę portów wysokiej dostępności , ustawiając protokół na Wszystkie i port na 0 , tak aby moduł równoważenia obciążenia przekazuje wszystkie przepływy protokołu na wszystkich portach do wystąpień, w tym ICMP. Protokół ICMP ma znaczenie dla protokołu IPv6, ponieważ odnajdywanie sąsiadów i odnajdywanie ścieżki MTU zależą od protokołu ICMPv6. Aby uzyskać więcej informacji, zobacz Tworzenie wewnętrznego modułu równoważenia obciążenia typu dual-stack.
• Skieruj każdą trasę zdefiniowaną przez użytkownika (UDR) dla protokołu IPv6 na adres IPv6 frontonu modułu równoważenia obciążenia, a nie na pojedyncze urządzenie. W przykładach w tym artykule jako adresu frontonu użyto adresu 2001:db8:1234:0004::4 w podsieci NVA.
• Zastosuj grupę zabezpieczeń sieci do podsieci NVA. W konfiguracji dual-stack sondy kondycji modułu równoważenia obciążenia nie działają w przypadku IPv6, chyba że aktywna jest grupa zabezpieczeń sieciowych, więc moduł równoważenia obciążenia nie może wykryć nieprawidłowo działającego urządzenia.
• Dołącz bramę NAT StandardV2 do podsieci NVA. Wewnętrzny moduł równoważenia obciążenia nie zapewnia łączności wychodzącej, więc urządzenia potrzebują jawnej metody ruchu wychodzącego, aby uzyskać dostęp do Internetu.
• Upewnij się, że dostawca NVA zatwierdza i wspiera to rozwiązanie. Postępuj zgodnie ze wskazówkami dostawcy dotyczącymi topologii aktywna/aktywna lub aktywna/rezerwowa oraz tego, czy urządzenie wymaga źródłowego tłumaczenia adresów sieciowych (SNAT), aby zachować symetrię ruchu.

Informacje o dostępnych wzorcach projektowych, czasach ich zbieżności oraz kompromisach związanych z symetrią ruchu można znaleźć w temacie Wdrażanie wysoce dostępnych urządzeń NVA.

Skonfiguruj trasy UDR dla każdej podsieci koncentratora

Trasy zdefiniowane przez użytkownika (UDR) to trasy ręcznie konfigurowane w celu zastąpienia domyślnych tras systemowych platformy Azure. Na platformie Azure trasy definiowane przez użytkownika mają kluczowe znaczenie dla kontrolowania przepływu ruchu sieciowego w sieci wirtualnej. Za pomocą tras zdefiniowanych przez użytkownika (UDR) można kierować ruch z jednej podsieci do określonych urządzeń, bram lub miejsc docelowych w obrębie platformy Azure albo do sieci lokalnych. Po dodaniu obsługi protokołu IPv6 do sieci wirtualnej koncentratora należy wykonać następujące kroki:

• Dodaj trasy IPv6. Istniejące trasy IPv4 nie mają zastosowania do ruchu IPv6, ponieważ każda trasa ma jeden prefiks adresu docelowego. Utwórz oddzielne trasy, które określają prefiksy docelowe IPv6 i następne przeskoki, których wymagają.
• Skojarz tabelę tras z podsieciami. Po zdefiniowaniu tras skojarz tabelę tras z odpowiednimi podsieciami w sieci wirtualnej. To skojarzenie określa, które podsieci używają zdefiniowanych tras.

Trasy są definiowane dla prefiksów docelowych, a nie dla poszczególnych zasobów. Tabelę tras można skojarzyć z podsiecią, a każdy zasób w tej podsieci jest zgodny z trasami w tej tabeli. Aby uzyskać więcej informacji, zobacz Omówienie trasy zdefiniowanej przez użytkownika.

W przykładowej architekturze wirtualna sieć koncentratora ma trasy IPv6 dla podsieci bramy i podsieci NVA. Podsieć Azure Firewall nie ma tras IPv6, ponieważ obsługuje tylko protokół IPv4, a podsieć Azure Bastion nie ma tabeli tras, ponieważ Azure Bastion nie obsługuje tras definiowanych przez użytkownika na AzureBastionSubnet. Adres następnego przeskoku 2001:db8:1234:0004::4 to adres frontonu IPv6 wewnętrznego modułu równoważenia obciążenia, który stanowi fronton dla puli NVA, a nie adres poszczególnego urządzenia. W poniższej tabeli przedstawiono przykładowe trasy UDR protokołu IPv6.

Powtórz trasę inspekcji dla każdego prefiksu sieci spoke, który ma być kontrolowany przez pulę NVA. Nie wyłączaj propagacji tras protokołu BGP w podsieci GatewaySubnet, ponieważ brama nie będzie działać. Pozostaw włączoną propagację w podsieciach NVA i szprych, aby prefiksy IPv6 środowiska lokalnego wyuczone przez BGP pozostawały dostępne dla ruchu poddawanego inspekcji.

Nie twórz tras używających Virtual network gateway typu następnego przeskoku. Azure obsługuje ten typ następnego przeskoku tylko wtedy, gdy brama sieci wirtualnej jest bramą sieci VPN. Gdy brama sieci VPN i brama usługi ExpressRoute są wdrażane w tej samej sieci wirtualnej, Azure traktuje bramę usługi ExpressRoute jako bramę sieci wirtualnej, dzięki czemu typ następnego przeskoku nie ma zastosowania w tej architekturze.

Podczas konfigurowania tras zdefiniowanych przez użytkownika należy dostosować je do zasad sieciowych obowiązujących w organizacji oraz architektury wdrożenia na platformie Azure.

Modyfikowanie obwodu usługi ExpressRoute (jeśli dotyczy)

Aby włączyć protokół IPv6 w obwodzie usługi ExpressRoute, należy:

• Włącz prywatne połączenie równorzędne IPv6. Włącz prywatny peering IPv6 dla obwodu ExpressRoute. Ta konfiguracja umożliwia ruch IPv6 między siecią lokalną a siecią wirtualną koncentratora.
• Przydziel przestrzeń adresową IPv6. Podaj parę podsieci IPv6 /126, które należą do Ciebie, dla podstawowego i pomocniczego łącza ExpressRoute.
• Zweryfikuj propagację trasy. Brama uczy się lokalnych prefiksów IPv6 za pośrednictwem protokołu BGP niezależnie od ustawienia tabeli tras. Propagacja tras określa, czy platforma Azure wstawia te wyuczone prefiksy do tabeli tras podsieci, więc pozostaw ją włączoną w podsieci NVA oraz w podsieciach typu spoke, które wymagają łączności z innymi lokalizacjami lokalnymi.

Te konfiguracje rozszerzają łączność IPv6 na usługi platformy Azure za pośrednictwem obwodu ExpressRoute, dzięki czemu można jednocześnie obsługiwać ruch w trybie podwójnego stosu. Aby zmodyfikować usługę ExpressRoute, zobacz Dodawanie obsługi protokołu IPv6 dla prywatnej komunikacji równorzędnej, która zawiera instrukcje dotyczące korzystania z portalu Azure, programu PowerShell i Azure CLI.

Sprawdź następujące wymagania dotyczące bramy i sieci:

• Przed utworzeniem bramy sieci wirtualnej ExpressRoute dodaj przestrzeń adresową IPv6 do sieci wirtualnej i podsieci bramy.
• Prywatny peering IPv6 obsługuje nowo utworzone bramy sieci wirtualnej usługi ExpressRoute dowolnego typu SKU, które korzystają ze standardowego, statycznego publicznego adresu IP.
• Istniejące bramy obsługują protokół IPv6 tylko wtedy, gdy są strefowo nadmiarowe.
• Prywatny peering IPv6 nie jest obsługiwany w usłudze Virtual WAN, a brama dual-stack nie może połączyć się z obwodem, w którym w prywatnym peeringu włączono tylko protokół IPv4.
• Należy również skonfigurować protokół IPv6 na lokalnym sprzęcie klienta.

Przejście sieci wirtualnych typu spoke na IPv6

Wirtualne sieci typu spoke są połączone z centralnym hubem. Po włączeniu protokołu IPv6 w sieciach wirtualnych szprych każda sieć szprych może komunikować się za pośrednictwem protokołu IPv6, a sieć zyskuje bardziej spójny projekt protokołu IPv6 w całej topologii. Aby włączyć protokół IPv6 w sieciach wirtualnych szprych, wykonaj następujące kroki:

Dodaj przestrzeń adresową IPv6 do wirtualnych sieci typu spoke oraz podsieci typu spoke

Podobnie jak w przypadku centralnej sieci wirtualnej, należy dodać zakresy adresów IPv6 do każdej sieci wirtualnej typu spoke, a następnie do ich podsieci. Użyj bloku adresów /56 dla sieci wirtualnych i /64 bloku adresów dla podsieci. Poniższa tabela przedstawia przykład zakresów adresów IPv6 dla sieci wirtualnych typu spoke i ich podsieci.

W przypadku konfiguracji dostosuj adresy IPv6 zgodnie z alokacją i potrzebami organizacji.

Zmodyfikuj zasoby sieci wirtualnej typu spoke

Każda sieć wirtualna typu spoke zawiera wiele maszyn wirtualnych i wewnętrzny moduł równoważenia obciążenia. Wewnętrzny moduł równoważenia obciążenia umożliwia kierowanie ruchu IPv4 i IPv6 do maszyn wirtualnych. Należy zmodyfikować maszyny wirtualne i wewnętrzne moduły równoważenia obciążenia, aby obsługiwały protokół IPv6.

Dla każdej maszyny wirtualnej dodaj konfigurację adresu IP IPv6 do interfejsu sieciowego, który ma już maszyna wirtualna. Nie twórz oddzielnego interfejsu IPv6. Interfejs zachowuje swoją konfigurację IPv4 i staje się interfejsem dual-stack, ponieważ Azure nie obsługuje interfejsów sieciowych obsługujących wyłącznie protokół IPv6. Aby uzyskać więcej informacji, zobacz Dodawanie konfiguracji protokołu IPv6 do maszyny wirtualnej.

Jeśli w każdej sieci wirtualnej typu spoke nie ma wewnętrznego modułu równoważenia obciążenia, utwórz wewnętrzny moduł równoważenia obciążenia dual-stack. Aby uzyskać więcej informacji, zobacz Tworzenie wewnętrznego modułu równoważenia obciążenia typu dual-stack. Jeśli istnieje wewnętrzny moduł równoważenia obciążenia, możesz użyć programu PowerShell lub Azure CLI, aby dodać obsługę protokołu IPv6.

Skonfiguruj trasy UDR dla każdej podsieci typu spoke

Aby skonfigurować trasy zdefiniowane przez użytkownika (UDR), użyj tej samej konfiguracji dla sieci wirtualnych typu spoke, jak dla sieci wirtualnych typu hub. Po dodaniu obsługi protokołu IPv6 do wirtualnej sieci typu spoke należy:

• Dodaj trasy IPv6. Istniejące trasy IPv4 nie mają zastosowania do ruchu IPv6, ponieważ każda trasa ma jeden prefiks adresu docelowego. Utwórz oddzielne trasy, które określają prefiksy docelowe IPv6 i następne przeskoki, których wymagają.
• Skojarz tabelę tras z podsieciami. Po zdefiniowaniu tras skojarz tabelę tras z odpowiednimi podsieciami w sieci wirtualnej. To skojarzenie określa, które podsieci używają zdefiniowanych tras.

W poniższej tabeli przedstawiono przykładowe trasy IPv6 zdefiniowane przez użytkownika dla każdej podsieci w sieci wirtualnej typu szprycha. Ruch IPv6 kierowany do Internetu trafia do puli NVA IPv6 w koncentratorze, a nie do usługi Azure Firewall, która w tej architekturze obsługuje wyłącznie protokół IPv4. Podobnie jak w centrum, adres następnego przeskoku to adres frontonu IPv6 modułu równoważenia obciążenia, a nie adres pojedynczego urządzenia.

Sieci typu spoke uczą się prefiksów IPv6 ze środowiska lokalnego z bramy usługi ExpressRoute za pośrednictwem protokołu BGP po włączeniu w ramach komunikacji równorzędnej opcji Użyj bramy lub serwera Route Server zdalnej sieci wirtualnej. Dodaj lokalną trasę UDR tylko wtedy, gdy chcesz zastąpić te wyuczone trasy, na przykład gdy kierujesz ruch do urządzenia NVA w celu inspekcji. Podobnie jak w centrum, nie używaj Virtual network gateway typu następnego przeskoku, aby uzyskać dostęp do sieci lokalnych za pośrednictwem usługi ExpressRoute.

W swojej konfiguracji należy dostosować trasy zdefiniowane przez użytkownika (UDR) do zasad sieciowych organizacji oraz architektury wdrożenia na platformie Azure.

Contributors

Microsoft utrzymuje ten artykuł. Następujący współautorzy pierwotnie napisali artykuł.

Główny autor:

• Werner Rall | Starszy architekt rozwiązań w chmurze

Inni współautorzy:

• Sherri Babilon | Starszy menedżer programu technicznego
• Dawn Bedard | Główny menedżer programu technicznego
• Brandon Stephenson | Starszy inżynier klienta

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Utwórz maszynę wirtualną z siecią dwustosową IPv6
• Zarządzanie zakresami adresów IP
• Cloud Adoption Framework: Planowanie adresowania IP
• Protokół IPv6 dla usługi Azure Virtual Network
• Dodaj obsługę protokołu IPv6 dla prywatnej komunikacji równorzędnej ExpressRoute
• Omówienie odwrotnego systemu DNS w usłudze Azure DNS
• Typy SKU usługi Azure NAT Gateway

Powiązane zasoby

• Przejście do protokołu IPv6
• Opcje łączności wirtualnej sieci i komunikacja między węzłami
• Zapora sieciowa i brama aplikacyjna dla sieci wirtualnych
• Wdrażanie usług AD DS w sieci wirtualnej platformy Azure