Azure Stack Hub wprowadzenie do nierównomówionych sieci

Omówienie projektowania sieci

Projekt sieci fizycznej

Rozwiązanie Azure Stack Hub odporne na błędy wymaga odpornej i wysoce dostępnej infrastruktury fizycznej do obsługi jej działania i usług. Linki z tor do przełączników granicznych są ograniczone do nośnika SFP+ lub SFP28 i 1 GB, 10 GB lub 25 GB szybkości. Aby uzyskać informacje o dostępności, skontaktuj się z dostawcą sprzętu OEM.

Na poniższym diagramie przedstawiono zalecany projekt dla Azure Stack Hub nierównomernych.

Azure Stack Hub nierówna sieć fizyczna

Projekt sieci logicznej

Projekt sieci logicznej reprezentuje abstrakcję infrastruktury sieci fizycznej. Służą one do organizowania i upraszczania przypisań sieci dla hostów, maszyn wirtualnych i usług. W ramach tworzenia sieci logicznej lokacje sieciowe są tworzone w celu zdefiniowania:

  • wirtualne sieci lokalne (V LAN)
  • Podsieci IP
  • Pary podsieci IP/sieci VLAN

Wszystkie z nich są skojarzone z siecią logiczną w każdej lokalizacji fizycznej.

W poniższej tabeli przedstawiono sieci logiczne i skojarzone zakresy podsieci IPv4, które należy zaplanować:

Sieć logiczna Opis Rozmiar
Publiczny wirtualny adres IP (VIP) Azure Stack Hub nierównomówiące wykorzystują łącznie 31 adresów z tej sieci. Osiem publicznych adresów IP jest używanych dla małego zestawu Azure Stack Hub nierównomernych usług, a pozostałe są używane przez maszyny wirtualne dzierżawcy. Jeśli planujesz używać App Service i dostawców SQL zasobów, zostanie użytych jeszcze 7 adresów. Pozostałe 15 ip jest zarezerwowanych dla przyszłych usług platformy Azure. /26 (62 hosty)-
/22 (1022 hosty)

Zalecane = /24 (254 hosty)
Przełączanie infrastruktury Adresy IP typu punkt-punkt na potrzeby routingu, dedykowane interfejsy zarządzania przełącznikiem i adresy sprzężenia zwrotnego przypisane do przełącznika. /26
Infrastruktura Służy do Azure Stack Hub się ze wzmocnionymi wewnętrznymi składnikami. /24
Prywatny Służy do sieci magazynowania, prywatnych vip, kontenerów infrastruktury i innych funkcji wewnętrznych. /20
Kontroler zarządzania płytą główną (BMC) Służy do komunikowania się z kontrolerami zarządzania płytą podstawową na hostach fizycznych. /26

Infrastruktura sieci

Infrastruktura sieciowa dla Azure Stack Hub nierównomernych składa się z kilku sieci logicznych skonfigurowanych na przełącznikach. Na poniższym diagramie przedstawiono te sieci logiczne i sposób ich integracji z przełącznikami TOR (top-of-rack), kontrolerem zarządzania płytą podstawową i przełącznikami granicznych (sieć klienta).

Azure Stack Hub nierównomówionych sieci logicznych:

Azure Stack Hub nierówna sieć logiczna

Sieć BMC

Ta sieć jest przeznaczona do łączenia wszystkich kontrolerów zarządzania płytą podstawową (nazywanych również kontrolerami BMC lub procesorami usług) z siecią zarządzania. Przykłady obejmują: iDRAC, iLO, iBMC i tak dalej. Tylko jedno konto kontrolera BMC jest używane do komunikacji z dowolnym węzłem kontrolera BMC. Jeśli istnieje, host cyklu życia sprzętu (HLH) znajduje się w tej sieci i może zapewnić oprogramowanie specyficzne dla producenta OEM do konserwacji lub monitorowania sprzętu.

Serwer HLH hostuje również maszynę wirtualną wdrażania (DVM). DvM jest używany podczas Azure Stack Hub i jest usuwany po zakończeniu wdrażania. Urządzenie DVM wymaga dostępu do Internetu w scenariuszach wdrażania połączonego w celu testowania, weryfikowania i uzyskiwania dostępu do wielu składników. Te składniki mogą być wewnątrz i na zewnątrz sieci firmowej (na przykład NTP, DNS i Azure). Aby uzyskać więcej informacji na temat wymagań dotyczących łączności, zobacz sekcję NAT w te Azure Stack Hub integracji z zaporą o nierównomernych zabezpieczeniach.

Sieć prywatna

Sieć /20 (4096 hostów IP) jest prywatna dla Azure Stack Hub nierównomernych regionu. Nie wykracza poza urządzenia przełączników granicznych Azure Stack Hub nierównomernych regionu. Ta sieć jest podzielona na wiele podsieci, na przykład:

  • Storagesieci: sieć /25 (128 IP) używana do obsługi użycia ruchu magazynu funkcji Bezpośrednie miejsca do magazynowania i bloku komunikatów serwera (SMB) i migracji na żywo maszyny wirtualnej.
  • Wewnętrzna wirtualna sieć IP:sieć /25 przeznaczona tylko dla wewnętrznych adresów VIP dla programowego równoważenia obciążenia.
  • Sieć kontenerów:sieć /23 (512 IP) przeznaczona tylko do ruchu wewnętrznego między kontenerami z uruchomionymi usługami infrastruktury

Rozmiar sieci prywatnej to /20 (4096 adresów IP) prywatnej przestrzeni adresów IP. Ta sieć jest prywatna dla Azure Stack Hub nierównomernych systemu. Nie wykracza poza urządzenia przełączników granicznych systemu Azure Stack Hub i może być ponownie używane w wielu Azure Stack Hub nierównomernych. Sieć jest prywatna, aby Azure Stack Hub nierównomieje, ale nie może pokrywać się z innymi sieciami w centrum danych. Aby uzyskać wskazówki dotyczące prywatnej przestrzeni adresów IP, zalecamy stosowanie się do specyfikacji RFC 1918.

Prywatna przestrzeń adresów IP /20 jest podzielona na wiele sieci, które umożliwiają uruchamianie Azure Stack Hub infrastruktury systemu w kontenerach w przyszłych wersjach. Aby uzyskać szczegółowe informacje, zapoznaj się z informacjami o wersji 1910. Ta nowa prywatna przestrzeń adresów IP umożliwia ciągłe wysiłki w celu zmniejszenia wymaganej routowalnej przestrzeni adresów IP przed wdrożeniem.

Azure Stack Hub nierówna sieć infrastruktury

Sieć /24 jest przeznaczona dla wewnętrznych Azure Stack Hub nierównomernych składników do komunikowania się i wymiany danych między sobą. Ta podsieć może być routowalna zewnętrznie Azure Stack Hub odpornego rozwiązania na centrum danych. Nie zalecamy używania publicznych lub internetowych adresów IP z routowalnymi adresami IP w tej podsieci. Ta sieć jest anonsowana do obramowania, ale większość jej adresów IP jest chronionych przez Access Control list (ACL). Ip dozwolone na dostęp znajdują się w małym zakresie, co odpowiada rozmiarowi sieci /27. Ip hostuje usługi takie jak uprzywilejowany punkt końcowy (PEP) i Azure Stack Hub kopii zapasowej.

Sieć publicznych adresów VIP

Sieć publicznych adresów VIP jest przypisana do kontrolera sieci w Azure Stack Hub nierównomernych. Nie jest to sieć logiczna przełącznika. SLB używa puli adresów i przypisuje /32 sieci dla obciążeń dzierżawy. W tabeli routingu przełącznika te /32 IP są anonsowane jako dostępna trasa za pośrednictwem Border Gateway Protocol (BGP). Ta sieć zawiera adresy publiczne, które są dostępne zewnętrznie. Infrastruktura Azure Stack Hub rezerwuje pierwsze 31 adresów z tej sieci publicznych adresów VIP, a pozostała część jest używana przez maszyny wirtualne dzierżawcy. Rozmiar sieci w tej podsieci może być z zakresu od /26 (64 hosty) do maksymalnie /22 (1022 hosty). Zalecamy zaplanowanie sieci /24.

Przełączanie sieci infrastruktury

Sieć /26 to podsieć zawierająca routowalne adresy IP /30 (dwa adresy IP hosta) i sprzężenia zwrotne. Są to dedykowane podsieci /32 do zarządzania przełącznikiem w pasmie i identyfikator routera BGP. Ten zakres adresów IP musi być routowalny poza Azure Stack Hub rozwiązaniem w centrum danych. Adresy IP mogą być prywatne lub publiczne.

Przełączanie sieci zarządzania

Sieć /29 (sześć hostów IP) jest przeznaczona do łączenia portów zarządzania przełączników. Ta sieć umożliwia dostęp poza pasmem na potrzeby wdrażania, zarządzania i rozwiązywania problemów. Jest on obliczany na podstawie wymienionej powyżej sieci infrastruktury przełączników.

Omówienie projektu DNS

Aby uzyskać dostęp Azure Stack Hub nierównomernych punktów końcowych(portal,adminportal,zarządzanie,adminmanagement) spoza Azure Stack Hub nierównomernych, należy zintegrować Azure Stack Hub nierówne usługi DNS z serwerami DNS, które hostują strefy DNS, które mają być Azure Stack Hub nierówne.

Azure Stack Hub nierówna przestrzeń nazw DNS

Podczas wdrażania systemu dns należy podać ważne informacje, które Azure Stack Hub odporne na błędy.

Pole Opis Przykład
Region (Region) Lokalizacja geograficzna twojego Azure Stack Hub nierówne wdrożenie. wschód
Nazwa domeny zewnętrznej Nazwa strefy, która ma być Azure Stack Hub wdrożenia. cloud.fabrikam.com
Wewnętrzna nazwa domeny Nazwa strefy wewnętrznej, która jest używana dla usług infrastruktury w Azure Stack Hub nierówne. Jest to usługa katalogowa zintegrowana i prywatna (nieozywalna spoza Azure Stack Hub nierównomernego wdrożenia). azurestack.local
Usługi przesyłania dalej DNS Serwery DNS, które są używane do przekazywania zapytań DNS, stref DNS i rekordów, które są hostowane poza Azure Stack Hub odporne, w intranecie firmy lub w publicznym Internecie. Wartość usługi przesyłania dalej DNS można edytować za pomocą polecenia cmdlet Set-AzSDnsForwarder po wdrożeniu.
Prefiks nazewnictwa (opcjonalnie) Prefiks nazewnictwa, który ma być Azure Stack Hub wystąpienia roli infrastruktury o nierównych nazwach maszyn. Jeśli nie zostanie podany, wartość domyślna to "azs". Azs

W pełni kwalifikowana nazwa domeny (FQDN) Azure Stack Hub wdrożenia i punktów końcowych jest kombinacją parametru Region i parametru Zewnętrzna nazwa domeny. Korzystając z wartości z przykładów z poprzedniej tabeli, w Azure Stack Hub FQDN tego east.cloud.fabrikam.com

W związku z tym przykłady niektórych punktów końcowych dla tego wdrożenia będą wyglądać podobnie do następujących adresów URL:

  • https://portal.east.cloud.fabrikam.com
  • https://adminportal.east.cloud.fabrikam.com

Aby użyć tej przykładowej przestrzeni nazw DNS dla Azure Stack Hub nierównomernych wdrożeń, wymagane są następujące warunki:

  • Strefa jest fabrikam.com u rejestratora domen, wewnętrznego firmowego serwera DNS lub obu tych usług. Rejestracja zależy od wymagań dotyczących rozpoznawania nazw.
  • Domena podrzędna cloud.fabrikam.com istnieje w obszarze strefy fabrikam.com.
  • Serwery DNS, które hostuje strefy fabrikam.com i cloud.fabrikam.com można uzyskać z Azure Stack Hub nierównomernych wdrożenia.

Aby rozpoznać nazwy DNS dla Azure Stack Hub punktami końcowymi i wystąpieniami spoza Azure Stack Hub nierównomówionych, należy zintegrować serwery DNS. W tym serwery, które hostować zewnętrzną strefę DNS dla Azure Stack Hub nierówne, z serwerów DNS, które hostować strefę nadrzędną, której chcesz użyć.

Etykiety nazw DNS

Azure Stack Hub obsługuje dodawanie etykiety nazwy DNS do publicznego adresu IP w celu umożliwienia rozpoznawania nazw dla publicznych adresów IP. Etykiety DNS to wygodny sposób na dostęp użytkowników do aplikacji i usług hostowanych w Azure Stack Hub odporne na nazwy. Etykieta nazwy DNS używa nieco innej przestrzeni nazw niż punkty końcowe infrastruktury. Zgodnie z poprzednim przykładem przestrzeń nazw dla etykiet nazw DNS będzie następująca: *.east.cloudapp.cloud.fabrikam.com.

Jeśli dzierżawa określa Myapp w polu nazwy DNS zasobu publicznego adresu IP, tworzy rekord A dla myapp w strefie east.cloudapp.cloud.fabrikam.com na Azure Stack Hub zewnętrznym serwerze DNS. Wynikowa w pełni kwalifikowana nazwa domeny to: myapp.east.cloudapp.cloud.fabrikam.com.

Jeśli chcesz korzystać z tej funkcji i korzystać z tej przestrzeni nazw, musisz zintegrować serwery DNS. W tym serwery, które hostować zewnętrzną strefę DNS dla Azure Stack Hub nierówne i serwery DNS, które hostować strefę nadrzędną, która ma być również użyć. Ta przestrzeń nazw różni się od tej używanej dla Azure Stack Hub punktami końcowymi usługi odpornej na obciążenia, dlatego należy utworzyć dodatkowe delegowanie lub regułę warunkowego przekazywania dalej.

Aby uzyskać więcej informacji na temat sposobu działania etykiety nazwy DNS, zobacz "Using DNS" in Azure Stack Hub nierównomerne.

Rozpoznawanie i delegowanie

Istnieją dwa typy serwerów DNS:

  • Autorytatywny serwer DNS hostuje strefy DNS. Odpowiada na zapytania DNS dotyczące rekordów tylko w tych strefach.
  • Cykliczny serwer DNS nie hostuje stref DNS. Odpowiada na zapytania DNS, wywołując autorytatywne serwery DNS w celu zebrania danych, których potrzebuje.

Azure Stack Hub odporne na błędy obejmują zarówno autorytatywne, jak i rekursywne serwery DNS. Serwery cykliczne są używane do rozpoznawania nazw wszystkich z wyjątkiem wewnętrznej strefy prywatnej i zewnętrznej publicznej strefy DNS dla Azure Stack Hub wdrożenia nierównomierne.

Rozpoznawanie zewnętrznych nazw DNS z Azure Stack Hub nierównomernych

Aby rozpoznać nazwy DNS dla punktów końcowych poza Azure Stack Hub nierówne (na przykład: www.bing.com),należy podać serwery DNS dla usługi Azure Stack Hub nierówne do przekazywania żądań DNS, dla których Azure Stack Hub nierówne nie jest autorytatywne. Serwery DNS, Azure Stack Hub odrównują żądania przekazywania do są wymagane w arkuszu wdrażania (w polu Usługa przesyłania dalej DNS). Podaj co najmniej dwa serwery w tym polu w celu zapewnienia odporności na uszkodzenia. Bez tych wartości Azure Stack Hub nierównomerne wdrożenie zakończy się niepowodzeniem. Wartości usługi przesyłania dalej DNS można edytować za pomocą polecenia cmdlet Set-AzSDnsForwarder po wdrożeniu.

Omówienie projektu zapory

Zaleca się używanie urządzenia zapory w celu zabezpieczenia Azure Stack Hub nierównomernych. Zapory mogą pomóc w obronie przed atakami typu "rozproszona odmowa usługi" (DDOS, distributed denial of service), wykrywaniem włamań i inspekcją zawartości. Mogą jednak również stać się wąskim gardłem przepływności dla usług Azure Storage, takich jak obiekty blob, tabele i kolejki.

Jeśli jest używany tryb wdrożenia bez połączenia, należy opublikować AD FS końcowego. Aby uzyskać więcej informacji, zobacz artykuł datacenter integration identity (Tożsamość integracji centrum danych).

Punkty końcowe Azure Resource Manager (administrator), portal administratora i Key Vault (administrator) nie muszą wymagać publikowania zewnętrznego. Na przykład jako dostawca usług możesz ograniczyć powierzchnię ataku, administrując tylko Azure Stack Hub odporne z wewnątrz sieci, a nie z Internetu.

W przypadku organizacji korporacyjnych sieć zewnętrzna może być istniejącą siecią firmową. W tym scenariuszu należy opublikować punkty końcowe, aby obsługiwać Azure Stack Hub z sieci firmowej.

Translator adresów sieciowych

Zalecaną metodą zezwalania maszynie wirtualnej wdrażania na dostęp do zasobów zewnętrznych podczas wdrażania jest translator adresów sieciowych (NAT). Również w przypadku maszyn wirtualnych konsoli odzyskiwania awaryjnego (ERCS) lub uprzywilejowanego punktu końcowego (PEP) podczas rejestracji i rozwiązywania problemów.

NaT może być również alternatywą dla publicznych adresów IP w sieci zewnętrznej lub publicznych adresów VIP. Nie jest to jednak zalecane, ponieważ ogranicza środowisko użytkownika dzierżawy i zwiększa złożoność. Jedną z opcji jest jeden do jednego nat, który nadal wymaga jednego publicznego adresu IP na adres IP użytkownika w puli. Inną opcją jest nat nat wiele do jednego, który wymaga reguły NAT dla każdego adresu VIP użytkownika dla wszystkich portów, których może używać użytkownik.

Niektóre z minusów używania nat dla publicznych adresów VIP to:

  • Obciążenie związane z zarządzaniem regułami zapory, ponieważ użytkownicy kontrolują własne punkty końcowe i reguły publikowania w stosie sieci zdefiniowanej programowo (SDN). Użytkownicy muszą skontaktować się z Azure Stack Hub, aby opublikować swoje vip-y i zaktualizować listę portów.
  • Użycie nat ogranicza środowisko użytkownika, ale zapewnia pełną kontrolę nad publikowaniem żądań przez operatora.
  • W przypadku scenariuszy chmury hybrydowej z platformą Azure należy wziąć pod uwagę, że platforma Azure nie obsługuje konfigurowania tunelu VPN do punktu końcowego przy użyciu nat.

Przechwycenie protokołu SSL

Obecnie zaleca się wyłączenie dowolnego przechwycenia protokołu SSL (na przykład odciążania odszyfrowywania) we wszystkich Azure Stack Hub nierównomernych. Jeśli będzie ona obsługiwana w przyszłych aktualizacjach, zostaną podane wskazówki dotyczące sposobu włączania przechwycenia protokołu SSL dla Azure Stack Hub nierównomernych.

Scenariusz zapory wdrożenia usługi Edge

W przypadku wdrożenia brzegowego Azure Stack Hub są wdrażane bezpośrednio za routerem krawędzi lub zaporą. W tych scenariuszach zapora może być powyżej obramowania (scenariusz 1), gdzie obsługuje konfiguracje zapory aktywne-aktywne i aktywne/pasywne. Może również działać jako urządzenie obramowania (scenariusz 2), w którym obsługuje tylko konfigurację zapory aktywne-aktywne. Scenariusz 2 opiera się na równych kosztach wielokanałowych (ECMP) z protokołem BGP lub routingiem statycznym w przypadku trybu failover.

Publiczne routowalne adresy IP są określane dla puli publicznych adresów VIP z sieci zewnętrznej w czasie wdrażania. Ze względów bezpieczeństwa publiczne routowalne ip nie są zalecane w żadnej innej sieci w scenariuszu brzegowym. Ten scenariusz umożliwia użytkownikowi korzystanie z pełnego, kontrolowanego samodzielnie środowisko chmury, tak jak w chmurze publicznej, takiej jak Azure.

Azure Stack Hub scenariusz zapory brzegowej z nierównomówionych krawędziami

Enterprise scenariusz zapory sieci intranet lub obwodowej

W przypadku wdrożenia intranetowego lub obwodowego przedsiębiorstwa Azure Stack Hub odporne na nie są wdrażane na zaporze z wieloma strefami lub między zaporą brzegową a wewnętrzną zaporą sieci firmowej. Ruch jest następnie dystrybuowany między bezpieczną siecią obwodową (lub strefą DMZ) i niezabezpieczoną strefą, jak opisano poniżej:

  • Strefa bezpieczna:sieć wewnętrzna, która używa wewnętrznych lub firmowych adresów IP z routowalnymi adresami IP. Bezpieczną sieć można podzielić. Może mieć dostęp wychodzący do Internetu za pośrednictwem nat zapory. Jest on zwykle dostępny z wewnątrz centrum danych za pośrednictwem sieci wewnętrznej. Wszystkie Azure Stack Hub sieci powinny znajdować się w bezpiecznej strefie, z wyjątkiem puli publicznych adresów VIP sieci zewnętrznej.
  • Strefa obwodowa. Sieć obwodowa to miejsce, w którym zwykle wdrażane są zewnętrzne lub internetowe aplikacje, takie jak serwery internetowe. Jest zwykle monitorowany przez zaporę, aby uniknąć ataków, takich jak ataki DDoS i włamania (hakerzy), jednocześnie zezwalając na określony ruch przychodzący z Internetu. Tylko zewnętrzna pula publicznych adresów VIP Azure Stack Hub powinna znajdować się w strefie DMZ.
  • Niezabezpieczone strefy. Sieć zewnętrzna, Internet. Wdrażanie Azure Stack Hub w niezabezpieczonych strefach nie jest zalecane.

Scenariusz zapory sieci obwodowej

Omówienie projektowania sieci VPN

Mimo że sieć VPN jest pojęciem użytkownika, istnieją pewne ważne kwestie, które właściciel i operator rozwiązania muszą znać.

Aby można było wysyłać ruch sieciowy między siecią wirtualną platformy Azure i lokacją lokalną, należy utworzyć bramę sieci wirtualnej (VPN) dla sieci wirtualnej.

Brama sieci VPN jest typem bramy sieci wirtualnej, który wysyła zaszyfrowany ruch sieciowy przez połączenie publiczne. Bram sieci VPN można używać do bezpiecznego wysyłania ruchu między siecią wirtualną na platformie Azure Stack Hub a siecią wirtualną na platformie Azure. Możesz również bezpiecznie wysyłać ruch między siecią wirtualną a inną siecią, która jest połączona z urządzeniem sieci VPN.

Podczas tworzenia bramy sieci wirtualnej musisz wybrać typ bramy do utworzenia. Azure Stack Hub nierównomówiące obsługują jeden typ bramy sieci wirtualnej: typ sieci VPN.

Każda sieć wirtualna może mieć tylko dwie bramy sieci wirtualnych, ale może istnieć tylko jedna brama danego typu. W zależności od wybranych ustawień można utworzyć wiele połączeń z jedną bramą sieci VPN. Przykładem takiej konfiguracji jest konfiguracja połączenia z wieloma lokacjami.

Przed utworzeniem i skonfigurowaniem bram sieci VPN pod Azure Stack Hub, zapoznaj się z zagadnieniami Azure Stack Hub sieci. Dowiesz się, jak konfiguracje Azure Stack Hub różnią się od konfiguracji platformy Azure.

Na platformie Azure przepływność przepustowości dla jednostki SKU bramy sieci VPN musi być podzielona na wszystkie połączenia połączone z bramą. W Azure Stack Hub jednak nierówna wartość przepustowości dla sku bramy sieci VPN jest stosowana do każdego zasobu połączenia połączonego z bramą. Na przykład:

  • Na platformie Azure podstawowa jednostka SKU bramy sieci VPN może obsłużyć około 100 Mb/s zagregowanej przepływności. Jeśli utworzysz dwa połączenia z bramą sieci VPN, a jedno połączenie będzie korzystać z przepustowości 50 Mb/s, to drugie połączenie będzie dostępne o przepustowości 50 Mb/s.
  • W Azure Stack Hub nierównomówionych każde połączenie z podstawową jednostką SKU bramy sieci VPN ma przydzieloną przepływność 100 Mb/s.

Typy sieci VPN

Podczas tworzenia bramy sieci wirtualnej dla konfiguracji bramy sieci VPN należy określić typ sieci VPN. Wybór typu sieci VPN zależy od topologii połączenia, którą chcesz utworzyć. Typ sieci VPN może również zależeć od sprzętu, z których korzystasz. Konfiguracje S2S wymagają urządzenia sieci VPN. Niektóre urządzenia sieci VPN obsługują tylko określony typ sieci VPN.

Ważne

Obecnie Azure Stack Hub obsługuje tylko typ sieci VPN oparty na trasach. Jeśli urządzenie obsługuje tylko sieci VPN oparte na zasadach, połączenia z tymi urządzeniami z sieci Azure Stack Hub nie są obsługiwane. Ponadto obecnie Azure Stack Hub nie obsługuje selektorów ruchu opartych na zasadach dla bram opartych na trasach, ponieważ niestandardowe konfiguracje zasad protokołu IPSec/IKE nie są obsługiwane.

  • PolicyBased:sieci VPN oparte na zasadach szyfrują i kierują pakiety za pośrednictwem tuneli IPsec na podstawie zasad protokołu IPsec. Zasady są konfigurowane przy użyciu kombinacji prefiksów adresów między siecią lokalną i Azure Stack Hub siecią wirtualną. Zasady lub selektor ruchu są zwykle listą dostępu w konfiguracji urządzenia sieci VPN. PolicyBased jest obsługiwany na platformie Azure, ale nie w Azure Stack Hub nierównomernych.
  • RouteBased:sieci VPN oparte na trasach używają tras skonfigurowanych w tabeli przekazywania lub routingu IP. Trasy kierują pakiety do odpowiednich interfejsów tunelu. W dalszej kolejności interfejsy tuneli szyfrują lub odszyfrowują pakiety wchodzące do tuneli lub wychodzące z nich. Zasady lub selektor ruchu dla sieci VPN typu RouteBased są skonfigurowane jako dowolne-dowolne (lub używają symboli wieloznaczych). Domyślnie nie można ich zmienić. Wartość typu sieci VPN RouteBased to RouteBased.

Konfigurowanie bramy sieci VPN

Połączenie bramy sieci VPN opiera się na kilku zasobach skonfigurowanych przy użyciu określonych ustawień. Większość tych zasobów można skonfigurować oddzielnie, ale w niektórych przypadkach muszą one być skonfigurowane w określonej kolejności.

Ustawienia

Ustawienia wybierane dla każdego zasobu mają kluczowe znaczenie dla utworzenia pomyślnego połączenia.

Ten artykuł ułatwia zrozumienie:

  • Typy bram, typy sieci VPN i typy połączeń.
  • Podsieci bramy, bramy sieci lokalnej i inne ustawienia zasobów, które warto wziąć pod uwagę.

Diagramy topologii połączeń

Istnieją różne konfiguracje dostępne dla połączeń bramy sieci VPN. Określ, która konfiguracja najlepiej odpowiada Twoim potrzebom. W poniższych sekcjach można wyświetlić informacje i diagramy topologii dotyczące następujących połączeń bramy sieci VPN:

  • Dostępny model wdrażania
  • Dostępne narzędzia konfiguracji
  • Linki prowadzące bezpośrednio do artykułu, jeśli jest dostępny

Diagramy i opisy w poniższych sekcjach mogą ułatwić wybranie topologii połączenia zgodnej z wymaganiami. Diagramy pokazują główne topologie punktów odniesienia, ale można utworzyć bardziej złożone konfiguracje, korzystając z diagramów jako przewodnika.

Połączenia typu lokacja-lokacja i wiele lokacji (tunel VPN protokołu IPsec/IKE)

Lokacja-lokacja

Połączenie bramy sieci VPN typu lokacja-lokacja (S2S) to połączenie za pośrednictwem tunelu sieci VPN protokołu IPsec/IKE (IKEv2). Ten typ połączenia wymaga urządzenia sieci VPN, które znajduje się lokalnie i ma przypisany publiczny adres IP. To urządzenie nie może być umieszczone za nat. Z połączeń typu lokacja-lokacja (S2S) można korzystać w ramach konfiguracji hybrydowych i obejmujących wiele lokalizacji.

Wiele lokacji

Połączenie wielu lokacji jest odmianą połączenia lokacja-lokacja. W tym przypadku tworzysz więcej niż jedno połączenie VPN z bramy sieci wirtualnej — zwykle do nawiązywania połączenia z wieloma lokacjami lokalnymi. Podczas pracy z wieloma połączeniami należy użyć typu sieci VPN opartego na trasach (nazywanego bramą dynamiczną podczas pracy z klasycznymi sieciami wirtualnmi). Ze względu na to, że każda sieć wirtualna może mieć tylko jedną bramę sieci VPN, wszystkie połączenia za pośrednictwem bramy współużytkują dostępną przepustowość.

Jednostki SKU bramy

Podczas tworzenia bramy sieci wirtualnej dla Azure Stack Hub należy określić używaną przez Ciebie sku bramy. Obsługiwane są następujące jednostki SKU bramy sieci VPN:

  • Podstawowa
  • Standardowa (Standard)
  • Wysoka wydajność

Wybranie wyższej liczby sku bramy przydziela bramie więcej procesorów CPU i przepustowości sieci. W związku z tym brama może obsługiwać wyższą przepływność sieci do sieci wirtualnej.

Azure Stack Hub nierównomieniowa nie obsługuje ultrawydajnych sku bramy, która jest używana wyłącznie z usługą Express Route.

Po wybraniu sku SKU należy wziąć pod uwagę następujące kwestie:

  • Azure Stack Hub nierównomówiące nie obsługują bram opartych na zasadach.
  • W przypadku podstawowej wersji SKU nie jest obsługiwany protokołu BGP.
  • Współistniejące konfiguracje bramy usługi ExpressRoute-VPN nie są obsługiwane Azure Stack Hub nierównomernych.

Dostępność bramy

Scenariusze wysokiej dostępności można skonfigurować tylko w przypadku sku połączenia bramy o wysokiej wydajności. W przeciwieństwie do platformy Azure, która zapewnia dostępność za pośrednictwem konfiguracji zarówno aktywny/aktywny, jak i aktywny/pasywny, Azure Stack Hub nierównomówiona obsługuje tylko konfigurację aktywny/pasywny.

Tryb failover

Istnieją trzy wielodostępne maszyny wirtualne infrastruktury bramy w Azure Stack Hub nierównomernych. Dwie z tych maszyn wirtualnych są w trybie aktywnym, a trzecia jest w trybie nadmiarowym. Aktywne maszyny wirtualne umożliwiają tworzenie na nich połączeń sieci VPN, a nadmiarowa maszyna wirtualna akceptuje połączenia sieci VPN tylko wtedy, gdy nastąpi tryb failover. Jeśli aktywna maszyna wirtualna bramy stanie się niedostępna, połączenie sieci VPN zostanie przejściowe do nadmiarowej maszyny wirtualnej po krótkiej (kilkuseksowej) utracie połączenia.

Szacowana agregowana przepływność według jednostki SKU

W poniższej tabeli przedstawiono typy bram i szacowaną zagregowaną przepływność według jednostki SKU bramy:

Przepływność usługi VPN Gateway (1) Maksymalna liczba tuneli protokołu IPsec bramy sieci VPN (2)
Podstawowa sku(3) 100 Mb/s 20
Standardowy SKU 100 Mb/s 20
SKU o wysokiej wydajności 200 Mb/s 10

Uwagi dotyczące tabeli

(1) — przepływność sieci VPN nie jest gwarantowaną przepływnością dla połączeń między lokalizacjami przez Internet. Jest to maksymalna możliwa miara przepływności.
(2) — Maksymalna liczba tuneli to łączna liczba Azure Stack Hub wdrożenia dla wszystkich subskrypcji.
(3) — routing BGP nie jest obsługiwany w przypadku podstawowej wersji SKU.

Ważne

Można utworzyć tylko jedno połączenie sieci VPN typu lokacja-lokacja między dwoma Azure Stack Hub nierównomówionych wdrożeń. Wynika to z ograniczenia platformy, które zezwala tylko na pojedyncze połączenie sieci VPN z tym samym adresem IP. Ponieważ Azure Stack Hub korzysta z wielodostępnych bram, które wykorzystują jeden publiczny adres IP dla wszystkich bram sieci VPN w systemie Azure Stack Hub z nierównomówieńcami, między dwoma systemami Azure Stack Hub może być tylko jedno połączenie SIECI VPN.

To ograniczenie dotyczy również łączenia więcej niż jednego połączenia sieci VPN typu lokacja-lokacja z dowolną bramą sieci VPN, która używa jednego adresu IP. Azure Stack Hub nierównomówiące nie zezwala na więcej niż jeden zasób bramy sieci lokalnej przy użyciu tego samego adresu IP.**

Parametry protokołu IPsec/IKE

Podczas konfigurowania połączenia sieci VPN w Azure Stack Hub, należy skonfigurować połączenie po obu stronach. Jeśli konfigurujesz połączenie sieci VPN między urządzeniem Azure Stack Hub i urządzeniem sprzętowym, to urządzenie może poprosić o dodatkowe ustawienia. Na przykład przełącznik lub router, który działa jako brama sieci VPN.

W przeciwieństwie do platformy Azure, która obsługuje wiele ofert zarówno jako inicjator, jak i responder, Azure Stack Hub nierównomówiona domyślnie obsługuje tylko jedną ofertę. Jeśli do pracy z urządzeniem sieci VPN konieczne jest użycie różnych ustawień protokołu IPSec/IKE, dostępnych jest więcej ustawień do ręcznego konfigurowania połączenia.

Parametry protokołu IKE — faza 1 (tryb główny)

Właściwość Wartość
Wersja IKE IKEv2
Grupa Diffie’ego-Hellmana ECP384
Metoda uwierzytelniania Klucz wstępny
Algorytmy & wyznaczania wartości skrótu szyfrowania AES256, SHA384
Okres istnienia skojarzeń zabezpieczeń (czas) 28 800 sekund

Parametry protokołu IKE — faza 2 (tryb szybki)

Właściwość Wartość
Wersja IKE IKEv2
Algorytmy & wyznaczania wartości skrótu szyfrowania (szyfrowanie) GCMAES256
Algorytmy & wyznaczania wartości skrótu szyfrowania (uwierzytelnianie) GCMAES256
Okres istnienia skojarzeń zabezpieczeń (czas) 27 000 sekund
Okres istnienia skojańcy zabezpieczeń (kilobajty) 33,553,408
Doskonałe utajnienie przekazywania (PFS) ECP384
Wykrywanie nieaktywnych elementów równorzędnych Obsługiwane

Konfigurowanie niestandardowych zasad połączeń protokołu IPSec/IKE

Standard protokołu IPsec i IKE obsługuje szeroką gamę algorytmów kryptograficznych w różnych kombinacjach. Aby sprawdzić, które parametry są obsługiwane w Azure Stack Hub, aby spełnić wymagania dotyczące zgodności lub zabezpieczeń, zobacz Parametry protokołu IPsec/IKE.

Ten artykuł zawiera instrukcje dotyczące tworzenia i konfigurowania zasad protokołu IPsec/IKE oraz stosowania ich do nowego lub istniejącego połączenia.

Zagadnienia do rozważenia

Podczas korzystania z tych zasad należy zwrócić uwagę na następujące ważne kwestie:

  • Zasady protokołu IPsec/IKE są dostępne tylko w przypadku standardowych i wysokowydajnych (opartych na trasach) jednostki SKU bramy.
  • Można określić tylko jedną kombinację zasad dla danego połączenia.
  • Należy określić wszystkie algorytmy i parametry zarówno dla protokołu IKE (tryb główny), jak i protokołu IPsec (tryb szybki). Częściowa specyfikacja zasad nie jest dozwolona.
  • Skonsultuj się ze specyfikacjami dostawcy urządzeń sieci VPN, aby upewnić się, że zasady są obsługiwane na lokalnych urządzeniach sieci VPN. Nie można nawiązyć połączeń typu lokacja-lokacja, jeśli zasady są niezgodne.

Przepływ pracy tworzenia i ustawienia zasad protokołu IPsec/IKE

W tej sekcji przedstawiono przepływ pracy wymagany do utworzenia i zaktualizowania zasad protokołu IPsec/IKE w połączeniu sieci VPN typu lokacja-lokacja:

  1. Utwórz sieć wirtualną i bramę sieci VPN.
  2. Utwórz bramę sieci lokalnej dla połączenia między środowiskami lokalnymi.
  3. Utwórz zasady protokołu IPsec/IKE z wybranymi algorytmami i parametrami.
  4. Utwórz połączenie protokołu IPSec przy użyciu zasad protokołu IPsec/IKE.
  5. Dodawanie/aktualizowanie/usuwanie zasad protokołu IPsec/IKE dla istniejącego połączenia.

Obsługiwane algorytmy kryptograficzne i silne strony klucza

W poniższej tabeli wymieniono obsługiwane algorytmy kryptograficzne i siły klucza konfigurowalne przez Azure Stack Hub nierównomówionych klientów:

IPsec/IKEv2 Opcje
Szyfrowanie IKEv2 AES256, AES192, AES128, DES3, DES
Integralność IKEv2 SHA384, SHA256, SHA1, MD5
Grupa DH ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, None
Szyfrowanie IPsec GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, Brak
Integralność IPsec GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Grupa PFS PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, Brak
Okres istnienia skojarzeń zabezpieczeń QM (Opcjonalnie: wartości domyślne są używane, jeśli nie zostaną określone)
Sekundy (liczba całkowita; min. 300/domyślna 27 000 sekund)
KB (liczba całkowita; min. 1024/wartość domyślna 102 400 000 KB)
Selektor ruchu Selektory ruchu oparte na zasadach nie są obsługiwane w przypadku Azure Stack Hub nierównomernych.

Konfiguracja lokalnego urządzenia sieci VPN musi być zgodna z następującymi algorytmami (lub je zawierać) oraz z następującymi parametrami określonymi w zasadach protokołu IPsec/IKE platformy Azure (lub je zawierać):

  • Algorytm szyfrowania IKE (tryb główny/faza 1).
  • Algorytm integralności IKE (tryb główny/faza 1).
  • Grupa DH (tryb główny / faza 1).
  • Algorytm szyfrowania IPsec (tryb szybki/faza 2).
  • Algorytm integralności IPsec (tryb szybki/faza 2).
  • Grupa PFS (tryb szybki/faza 2).
  • Okresy istnienia skojarów zabezpieczeń są tylko specyfikacjami lokalnymi i nie muszą być zgodne.

Jeśli szyfrowanie GCMAES jest używane jako dla algorytmu szyfrowania IPsec, należy wybrać ten sam algorytm GCMAES i długość klucza dla integralności protokołu IPsec. Na przykład: przy użyciu GCMAES128 dla obu.

W powyższej tabeli:

  • IKEv2 odpowiada trybowi głównemu lub fazie 1.
  • IPsec odpowiada trybowi szybkiemu lub fazie 2.
  • Grupa DH określa grupę Diffie-Hellmen używaną w trybie głównym lub fazie 1.
  • Grupa PFS określa grupę Diffie-Hellmen używaną w trybie szybkim lub fazie 2.
  • Okres istnienia skojaźnień zabezpieczeń trybu głównego IKEv2 jest ustalony na 28 800 sekund na Azure Stack Hub nierównomówionych bram sieci VPN.

W poniższej tabeli wymieniono odpowiednie grupy Diffie-Hellman obsługiwane przez zasady niestandardowe:

Grupa Diffie’ego-Hellmana DHGroup PFSGroup Długość klucza
1 DHGroup1 PFS1 MODP, 768-bitowy
2 DHGroup2 PFS2 MODP, 1024-bitowy
14 DHGroup14 PFS2048 MODP, 2048-bitowy
DHGroup2048
19 ECP256 ECP256 ECP, 256-bitowy
20 ECP384 ECP384 ECP, 384-bitowy
24 DHGroup24 PFS24 MODP, 2048-bitowy

Połączenie Azure Stack Hub na platformie Azure przy użyciu Azure ExpressRoute

Omówienie, założenia i wymagania wstępne

Azure ExpressRoute umożliwia rozszerzenie sieci lokalnych na chmurę firmy Microsoft. Używasz połączenia prywatnego dostarczonego przez dostawcę połączenia. Usługa ExpressRoute nie jest połączeniem sieci VPN za pośrednictwem publicznego Internetu.

Aby uzyskać więcej informacji na Azure ExpressRoute, zobacz ExpressRoute overview (Omówienie expressRoute).

Założenia

W tym artykule przyjęto założenie, że:

  • Masz wiedzę na temat platformy Azure.
  • Masz podstawową wiedzę na temat Azure Stack Hub nierównomernych.
  • Masz podstawową wiedzę na temat sieci.

Wymagania wstępne

Aby połączyć Azure Stack Hub z platformą Azure przy użyciu usługi ExpressRoute, musisz spełnić następujące wymagania:

  • Aprowizowany obwód usługi ExpressRoute za pośrednictwem dostawcy łączności.
  • Subskrypcja platformy Azure do tworzenia obwodu usługi ExpressRoute i sieci wirtualnych na platformie Azure.
  • Router obsługujący:
    • Połączenia sieci VPN typu lokacja-lokacja między interfejsem sieci LAN a Azure Stack Hub wielodostępną bramą.
    • tworzenie wielu wirtualnych funkcji przesyłania dalej (VIRTUAL Routing and Forwarding), jeśli w twojej Azure Stack Hub wdrożenia znajduje się więcej niż jedna dzierżawa.
  • Router, który ma:
    • Port sieci WAN podłączony do obwodu usługi ExpressRoute.
    • Port sieci LAN podłączony do Azure Stack Hub wielodostępną bramą.

Architektura sieci usługi ExpressRoute

Na poniższej ilustracji przedstawiono Azure Stack Hub i środowiska platformy Azure po zakończeniu konfigurowania usługi ExpressRoute, korzystając z przykładów w tym artykule:

Architektura sieci usługi ExpressRoute

Na poniższej ilustracji pokazano, jak wiele dzierżawców łączy się z Azure Stack Hub przez router usługi ExpressRoute z platformą Azure:

Architektura sieci usługi ExpressRoute z wieloma dzierżawcami