Integracja z siecią z chropowatą usługą Azure Stack Hub

Artykuł
07/12/2023

W tym temacie opisano integrację sieci usługi Azure Stack.

Łączność graniczna (pasma)

Planowanie integracji z siecią jest ważnym wymaganiem wstępnym dla pomyślnego wdrożenia, operacji i zarządzania zintegrowanymi systemami usługi Azure Stack. Planowanie łączności obramowania rozpoczyna się od wybrania, jeśli chcesz używać routingu dynamicznego z protokołem BGP (Border Gateway Protocol). Wymaga to przypisania 16-bitowego numeru systemu autonomicznego BGP (publicznego lub prywatnego) lub przy użyciu routingu statycznego, w którym statyczna trasa domyślna jest przypisywana do urządzeń obramowania.

Przełączniki tor (top of rack) wymagają pasma warstwy 3 z adresami IP punkt-punkt (/30 sieci) skonfigurowanymi w interfejsach fizycznych. Pasma warstwy 2 z przełącznikami TOR obsługującymi operacje usługi Azure Stack nie są obsługiwane.

Routing protokołu BGP

Korzystanie z protokołu routingu dynamicznego, takiego jak BGP, gwarantuje, że system zawsze zna zmiany sieci i ułatwia administrowanie. W przypadku zwiększonych zabezpieczeń można ustawić hasło w komunikacji równorzędnej BGP między tor i obramowaniem.

Jak pokazano na poniższym diagramie, reklama prywatnej przestrzeni IP na przełączniku TOR jest blokowana przy użyciu listy prefiksów. Lista prefiksów odrzuca anons sieci prywatnej i jest stosowana jako mapa tras w połączeniu między tor i obramowaniem.

Oprogramowanie Load Balancer (SLB) uruchomione wewnątrz elementu równorzędnego rozwiązania Azure Stack do urządzeń TOR, dzięki czemu może dynamicznie anonsować adresy VIP.

Aby zapewnić natychmiastowe i przezroczyste odzyskiwanie ruchu użytkowników po awarii, VPC lub MLAG skonfigurowane między urządzeniami TOR umożliwia korzystanie z agregacji linków z wieloma obudowami do hostów i HSRP lub VRRP, które zapewniają nadmiarowość sieci dla sieci IP.

Routing statyczny

Routing statyczny wymaga dodatkowej konfiguracji urządzeń obramowania. Wymaga to bardziej ręcznej interwencji i zarządzania, a także dokładnej analizy przed każdą zmianą. Problemy spowodowane błędem konfiguracji mogą zająć więcej czasu na wycofanie w zależności od wprowadzonych zmian. Ta metoda routingu nie jest zalecana, ale jest obsługiwana.

Aby zintegrować usługę Azure Stack ze środowiskiem sieciowym przy użyciu routingu statycznego, wszystkie cztery połączenia fizyczne między obramowaniem a urządzeniem TOR muszą być połączone. Wysoka dostępność nie może być gwarantowana ze względu na sposób działania routingu statycznego.

Urządzenie obramowania musi być skonfigurowane przy użyciu tras statycznych wskazujących każdy z czterech adresów IP P2P ustawionych między tor i obramowaniem dla ruchu kierowanego do dowolnej sieci w usłudze Azure Stack, ale do operacji jest wymagana tylko sieć zewnętrznego lub publicznego adresu VIP. Trasy statyczne do kontrolera BMC i sieci zewnętrzne są wymagane do początkowego wdrożenia. Operatorzy mogą pozostawić trasy statyczne na granicy, aby uzyskać dostęp do zasobów zarządzania, które znajdują się w kontrolerze BMC i sieci infrastruktury . Dodawanie tras statycznych do przełączania infrastruktury i przełączników sieci zarządzania jest opcjonalne.

Urządzenia TOR są konfigurowane przy użyciu statycznej trasy domyślnej wysyłającej cały ruch do urządzeń obramowania. Jednym wyjątkiem ruchu od reguły domyślnej jest przestrzeń prywatna, która jest blokowana przy użyciu listy Access Control zastosowanej na tor do połączenia obramowania.

Routing statyczny ma zastosowanie tylko do pasma między przełącznikami TOR i obramowania. Routing dynamiczny BGP jest używany wewnątrz stojaka, ponieważ jest to podstawowe narzędzie dla SLB i innych składników i nie można go wyłączyć ani usunąć.

* Sieć BMC jest opcjonalna po wdrożeniu.

** Sieć infrastruktury przełącznika jest opcjonalna, ponieważ cała sieć może być uwzględniona w sieci zarządzania przełącznikami.

Sieć zarządzania przełącznikami jest wymagana i można dodać oddzielnie od sieci infrastruktury przełącznika.

Przezroczysty serwer proxy

Jeśli centrum danych wymaga, aby cały ruch używał serwera proxy, należy skonfigurować przezroczysty serwer proxy do przetwarzania całego ruchu z stojaka w celu obsługi go zgodnie z zasadami, oddzielając ruch między strefami w sieci.

Rozwiązanie usługi Azure Stack nie obsługuje normalnych internetowych serwerów proxy

Przezroczysty serwer proxy (nazywany również przechwytywaniem, wbudowanym lub wymuszonym serwerem proxy) przechwytuje normalną komunikację w warstwie sieciowej bez konieczności specjalnej konfiguracji klienta. Klienci nie muszą mieć świadomości o istnieniu serwera proxy.

Przechwytywanie ruchu SSL nie jest obsługiwane i może prowadzić do błędów usługi podczas uzyskiwania dostępu do punktów końcowych. Maksymalny obsługiwany limit czasu komunikacji z punktami końcowymi wymaganymi dla tożsamości to 60-te z 3 próbami ponawiania prób.

DNS

W tej sekcji opisano konfigurację systemu nazw domen (DNS).

Konfigurowanie warunkowego przesyłania dalej DNS

Dotyczy to tylko wdrożenia usług AD FS.

Aby włączyć rozpoznawanie nazw z istniejącą infrastrukturą DNS, skonfiguruj przekazywanie warunkowe.

Aby dodać usługę przesyłania dalej warunkowego, należy użyć uprzywilejowanego punktu końcowego.

W tej procedurze należy użyć komputera w sieci centrum danych, który może komunikować się z uprzywilejowanym punktem końcowym w usłudze Azure Stack.

Otwórz sesję Windows PowerShell z podwyższonym poziomem uprawnień (uruchom jako administrator) i połącz się z adresem IP uprzywilejowanego punktu końcowego. Użyj poświadczeń do uwierzytelniania CloudAdmin.
```
\$cred=Get-Credential Enter-PSSession -ComputerName \<IP Address of ERCS\> -ConfigurationName PrivilegedEndpoint -Credential \$cred 
```
Po nawiązaniu połączenia z uprzywilejowanym punktem końcowym uruchom następujące polecenie programu PowerShell. Zastąp przykładowe wartości podane nazwą domeny i adresami IP serwerów DNS, których chcesz użyć.
```
Register-CustomDnsServer -CustomDomainName "contoso.com" -CustomDnsIPAddresses "192.168.1.1","192.168.1.2" 
```

Rozpoznawanie nazw DNS usługi Azure Stack spoza usługi Azure Stack

Autorytatywne serwery to te, które przechowują informacje o zewnętrznej strefie DNS i wszystkie strefy utworzone przez użytkownika. Zintegruj się z tymi serwerami, aby włączyć delegowanie strefy lub przekazywanie warunkowe w celu rozpoznawania nazw DNS usługi Azure Stack spoza usługi Azure Stack.

Uzyskiwanie informacji o zewnętrznym punkcie końcowym serwera DNS

Aby zintegrować wdrożenie usługi Azure Stack z infrastrukturą DNS, potrzebne są następujące informacje:

Nazwy FQDN serwera DNS
Adresy IP serwera DNS

Nazwy FQDN dla serwerów DNS usługi Azure Stack mają następujący format:

<NAMINGPREFIX-ns01>.<REGION>.<EXTERNALDOMAINNAME>

<NAMINGPREFIX-ns02>.<REGION>.<EXTERNALDOMAINNAME>

Korzystając z przykładowych wartości, nazwy FQDN dla serwerów DNS są następujące:

azs-ns01.east.cloud.fabrikam.com

azs-ns02.east.cloud.fabrikam.com

Te informacje są dostępne w portalu administracyjnym, ale także tworzone na końcu wszystkich wdrożeń usługi Azure Stack w pliku o nazwie AzureStackStampInformation.json. Ten plik znajduje się w folderze C:\CloudDeployment\logs maszyny wirtualnej Wdrażanie. Jeśli nie masz pewności, jakie wartości zostały użyte do wdrożenia usługi Azure Stack, możesz uzyskać wartości z tego miejsca.

Jeśli maszyna wirtualna wdrożenia nie jest już dostępna lub jest niedostępna, możesz uzyskać wartości, łącząc się z uprzywilejowanym punktem końcowym i uruchamiając Get-AzureStackStampInformation polecenia cmdlet programu PowerShell. Aby uzyskać więcej informacji, zobacz uprzywilejowany punkt końcowy.

Konfigurowanie warunkowego przesyłania dalej do usługi Azure Stack

Najprostszym i najbezpieczniejszym sposobem integracji usługi Azure Stack z infrastrukturą DNS jest wykonywanie warunkowego przekazywania strefy z serwera, który hostuje strefę nadrzędną. Ta metoda jest zalecana, jeśli masz bezpośrednią kontrolę nad serwerami DNS hostujących strefę nadrzędną dla zewnętrznej przestrzeni nazw DNS usługi Azure Stack.

Jeśli nie wiesz, jak wykonywać przekazywanie warunkowe za pomocą usługi DNS, zobacz następujący artykuł w witrynie TechNet: Przypisywanie warunkowego przesyłania dalej dla nazwy domeny lub dokumentacja specyficzna dla rozwiązania DNS.

W scenariuszach, w których określono zewnętrzną strefę DNS usługi Azure Stack, aby wyglądała jak domena podrzędna nazwy domeny firmowej, nie można używać przekazywania warunkowego. Należy skonfigurować delegowanie DNS.

Przykład:

Firmowa nazwa domeny DNS: contoso.com
Zewnętrzna nazwa domeny DNS usługi Azure Stack: azurestack.contoso.com

Edytowanie adresów IP usługi przesyłania dalej DNS

Adresy IP usługi przesyłania dalej DNS są ustawiane podczas wdrażania usługi Azure Stack. Jeśli jednak adresy IP usługi przesyłania dalej muszą zostać zaktualizowane z jakiegokolwiek powodu, możesz edytować wartości, łącząc się z uprzywilejowanym punktem końcowym i uruchamiając Get-AzSDnsForwarder i Set-AzSDnsForwarder [[-IPAddress>] <polecenia cmdlet programu PowerShell. Aby uzyskać więcej informacji, zobacz uprzywilejowany punkt końcowy.

Delegowanie zewnętrznej strefy DNS do usługi Azure Stack

Aby nazwy DNS można było rozpoznawać spoza wdrożenia usługi Azure Stack, należy skonfigurować delegowanie DNS.

Każdy rejestrator ma swoje własne narzędzia do zarządzania systemem DNS służące do zmiany rekordów serwerów nazw dla domeny. Na stronie zarządzania systemem DNS rejestratora zmodyfikuj rekordy NS i zastąp rekordy NS dla strefy tymi w usłudze Azure Stack.

Większość rejestratorów DNS wymaga podania co najmniej dwóch serwerów DNS do ukończenia delegowania.

Firewall

Usługa Azure Stack konfiguruje wirtualne adresy IP (VIP) dla ról infrastruktury. Te adresy VIP są przydzielane z puli publicznych adresów IP. Każdy adres VIP jest zabezpieczony za pomocą listy kontroli dostępu (ACL) w warstwie sieci zdefiniowanej programowo. Listy ACL są również używane w przełącznikach fizycznych (TORs i BMC) w celu dalszego wzmacniania funkcjonalności rozwiązania. Wpis DNS jest tworzony dla każdego punktu końcowego w zewnętrznej strefie DNS określonej w czasie wdrażania. Na przykład portal użytkowników jest przypisany wpis hosta DNS portalu. <region>.<fqdn>.

Na poniższym diagramie architektury przedstawiono różne warstwy sieciowe i listy ACL:

diagram architektury przedstawia różne warstwy sieciowe i listy ACL

Porty i adresy URL

Aby usługi Azure Stack (takie jak portale, azure Resource Manager, DNS itd.) były dostępne dla sieci zewnętrznych, należy zezwolić na ruch przychodzący do tych punktów końcowych dla określonych adresów URL, portów i protokołów.

W przypadku wdrożenia, w którym przezroczyste pasma serwera proxy do tradycyjnego serwera proxy lub zapora chroni rozwiązanie, należy zezwolić na określone porty i adresy URL zarówno dla komunikacji przychodzącej, jak i wychodzącej. Obejmują one porty i adresy URL tożsamości, platformę handlową, poprawkę i aktualizację, rejestrację i dane użycia.

Komunikacja wychodząca

Usługa Azure Stack obsługuje tylko przezroczyste serwery proxy. W przypadku wdrożenia z przezroczystym łączem serwera proxy do tradycyjnego serwera proxy należy zezwolić na porty i adresy URL w poniższej tabeli dla komunikacji wychodzącej podczas wdrażania w trybie połączonym.

Uwaga

Usługa Azure Stack nie obsługuje korzystania z usługi ExpressRoute w celu uzyskania dostępu do usług platformy Azure wymienionych w poniższej tabeli, ponieważ usługa ExpressRoute może nie być w stanie kierować ruchu do wszystkich punktów końcowych.

Przeznaczenie	Docelowy adres URL	Protokół	Porty	Sieć źródłowa
Tożsamość	Azure login.windows.net login.microsoftonline.com graph.windows.net https://secure.aadcdn.microsoftonline-p.com www.office.com ManagementServiceUri = https://management.core.windows.net ARMUri = https://management.azure.com https://.msftauth.net https://.msauth.net https://.msocdn.com Azure Government* https://login.microsoftonline.us/ https://graph.windows.net/ Azure w Chinach — 21Vianet https://login.chinacloudapi.cn/ https://graph.chinacloudapi.cn/ Azure (Niemcy) https://login.microsoftonline.de/ https://graph.cloudapi.de/	HTTP HTTPS	80 443	Publiczny adres VIP — /27 Sieć infrastruktury publicznej
Syndykacja w witrynie Marketplace	Azure https://management.azure.com https://.blob.core.windows.net https://.azureedge.net Azure Government https://management.usgovcloudapi.net/ https://.blob.core.usgovcloudapi.net/ Azure w Chinach — 21Vianet* https://management.chinacloudapi.cn/ http://*.blob.core.chinacloudapi.cn	HTTPS	443	Publiczny adres VIP — /27
Aktualizacja & poprawek	https://*.azureedge.net https://aka.ms/azurestackautomaticupdate	HTTPS	443	Publiczny adres VIP — /27
Rejestracja	Azure https://management.azure.com Azure Government https://management.usgovcloudapi.net/ Azure w Chinach — 21Vianet https://management.chinacloudapi.cn	HTTPS	443	Publiczny adres VIP — /27
Użycie	Azure https://.trafficmanager.net Azure Government* https://.usgovtrafficmanager.net Azure w Chinach — 21Vianet* https://*.trafficmanager.cn	HTTPS	443	Publiczny adres VIP — /27
Windows Defender	.wdcp.microsoft.com .wdcpalt.microsoft.com .wd.microsoft.com .update.microsoft.com *.download.microsoft.com https://www.microsoft.com/pkiops/crl https://www.microsoft.com/pkiops/certs https://crl.microsoft.com/pki/crl/products https://www.microsoft.com/pki/certs https://secure.aadcdn.microsoftonline-p.com	HTTPS	80 443	Publiczny adres VIP — /27 Sieć infrastruktury publicznej
NTP	(Adres IP serwera NTP dostarczonego do wdrożenia)	UDP	123	Publiczny adres VIP — /27
DNS	(Adres IP serwera DNS dostarczonego do wdrożenia)	TCP UDP	53	Publiczny adres VIP — /27
Listy crl	(Adres URL w obszarze Punkty dystrybucji listy CRL w certyfikacie)	HTTP	80	Publiczny adres VIP — /27
LDAP	Las usługi Active Directory udostępniony na potrzeby integracji z programem Graph	TCP UDP	389	Publiczny adres VIP — /27
LDAP SSL	Las usługi Active Directory udostępniony na potrzeby integracji z programem Graph	TCP	636	Publiczny adres VIP — /27
LDAP GC	Las usługi Active Directory udostępniony na potrzeby integracji z programem Graph	TCP	3268	Publiczny adres VIP — /27
LDAP GC SSL	Las usługi Active Directory udostępniony na potrzeby integracji z programem Graph	TCP	3269	Publiczny adres VIP — /27
AD FS	Punkt końcowy metadanych usług AD FS udostępniony na potrzeby integracji z usługami AD FS	TCP	443	Publiczny adres VIP — /27
Usługa zbierania dzienników diagnostycznych	Podany adres URL sygnatury dostępu współdzielonego obiektu blob w usłudze Azure Storage	HTTPS	443	Publiczny adres VIP — /27

Komunikacja przychodząca

Zestaw adresów VIP infrastruktury jest wymagany do publikowania punktów końcowych usługi Azure Stack w sieciach zewnętrznych. Tabela Punkt końcowy (VIP) zawiera każdy punkt końcowy, wymagany port i protokół. Zapoznaj się z dokumentacją wdrażania określonego dostawcy zasobów dla punktów końcowych, które wymagają dodatkowych dostawców zasobów, takich jak dostawca zasobów SQL.

Adresy VIP infrastruktury wewnętrznej nie są wyświetlane, ponieważ nie są wymagane do publikowania usługi Azure Stack. Adresy VIP użytkownika są dynamiczne i definiowane przez samych użytkowników bez kontroli operatora usługi Azure Stack