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

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

Łączność graniczna (pasma)

Planowanie integracji 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 jest przypisana statyczna trasa domyślna do urządzeń obramowania.

Przełączniki w górnej części stojaka (TOR) 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 protokół 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.

Programowy moduł równoważenia obciążenia (SLB) uruchomiony w ramach komunikacji równorzędnej rozwiązania Azure Stack z urządzeniami TOR, dzięki czemu może dynamicznie anonsować adresy VIP.

Aby zapewnić natychmiastowe i przejrzyste 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óra zapewnia 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 wszelkimi zmianami. Problemy spowodowane błędem konfiguracji mogą zająć więcej czasu, aby wycofać się 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 fizyczne połączenia 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 sieci zarządzania infrastrukturą i przełącznikiem 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 do reguły domyślnej jest przestrzeń prywatna, która jest blokowana przy użyciu listy kontroli dostępu 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ą wiedzieć 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-tych z 3 ponownymi próbami.

System Nazw Domenowych (DNS)

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

Konfigurowanie warunkowego przekazywania DNS

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

Aby włączyć rozpoznawanie nazw przy użyciu istniejącej infrastruktury 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ę programu 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

Serwery autorytatywne 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 to:

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 polecenie cmdlet Get-AzureStackStampInformation 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ą. To podejście jest zalecane, 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 znasz sposobu przekazywania warunkowego z usługą DNS, zobacz następujący artykuł w witrynie TechNet: Przypisywanie warunkowego usługi przesyłania dalej dla nazwy domeny lub dokumentację specyficzną dla rozwiązania DNS.

W scenariuszach, w których określono zewnętrzną strefę DNS usługi Azure Stack tak, 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:

Nazwa domeny DNS firmy: 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 polecenia cmdlet programu PowerShell Get-AzSDnsForwarder i Set-AzSDnsForwarder [[-IPAddress] <IPAddress[]>]. 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 rozpoznać 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.

Zapora sieciowa

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 sieciowej zdefiniowanej programowo. Listy ACL są również używane w przełącznikach fizycznych (TORs i BMC), aby jeszcze bardziej wzmocnić rozwiązanie. 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 architektonicznym 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 przezroczysty serwer proxy łączy się z tradycyjnym serwerem proxy lub zaporą 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. We wdrożeniu z przezroczystym połączeniem serwera proxy z tradycyjnym serwerem proxy należy zezwolić na porty i adresy URL w poniższej tabeli na potrzeby 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ść	Błękit 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 od 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	Błękit 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 od 21Vianet* https://management.chinacloudapi.cn/ http://*.blob.core.chinacloudapi.cn	HTTPS	443	Publiczny adres VIP — /27
Poprawianie i aktualizowanie	https://*.azureedge.net https://aka.ms/azurestackautomaticupdate	HTTPS	443	Publiczny adres VIP — /27
Rejestracja	Błękit https://management.azure.com Azure Government https://management.usgovcloudapi.net/ Azure w Chinach od 21Vianet https://management.chinacloudapi.cn	HTTPS	443	Publiczny adres VIP — /27
Użycie	Błękit https://.trafficmanager.net Azure Government* https://.usgovtrafficmanager.net Azure w Chinach od 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
Protokół czasu sieciowego (NTP)	(Adres IP serwera NTP udostępnionego do wdrożenia)	protokół UDP	123	Publiczny adres VIP — /27
System Nazw Domenowych (DNS)	(Adres IP serwera DNS dostarczonego do wdrożenia)	TCP protokół UDP	53	Publiczny adres VIP — /27
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 protokół UDP	389	Publiczny adres VIP — /27
LDAP SSL (Protokół LDAP z 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	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