Integracja sieci

Artykuł
07/12/2023

W tym artykule opisano integrację sieci usługi Azure Stack dla usługi Azure Modular Datacenter.

Łączność obramowania (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, czy chcesz użyć routingu dynamicznego z protokołem BGP (Border Gateway Protocol) lub routingiem statycznym. Routing dynamiczny wymaga przypisania 16-bitowego numeru systemu autonomicznego BGP (publicznego lub prywatnego). Routing statyczny używa statycznej trasy domyślnej przypisanej do urządzeń obramowania.

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

Routing protokołu BGP

Użycie protokołu routingu dynamicznego, takiego jak BGP, gwarantuje, że system jest zawsze świadomy zmian sieci i ułatwia administrowanie. W przypadku zwiększonych zabezpieczeń można ustawić hasło w komunikacji równorzędnej BGP między krawędzią a obramowaniem.

Jak pokazano na poniższym diagramie, reklama prywatnej przestrzeni IP na przełączniku TOR (top-of-rack) jest blokowana przy użyciu listy prefiksów. Lista prefiksów odrzuca anonsowanie sieci prywatnej i jest stosowana jako mapa tras w połączeniu między tor i krawędzią.

Programowy moduł równoważenia obciążenia (SLB) działający wewnątrz komunikacji równorzędnej rozwiązania Usługi Azure Stack z urządzeniami TOR, dzięki czemu może dynamicznie anonsować adresy VIP.

Aby zapewnić natychmiastowe i przezroczyste odzyskiwanie ruchu użytkowników po awarii, wirtualna chmura prywatna lub agregacja łączy z wieloma obudowami (MLAG) skonfigurowana między urządzeniami TOR umożliwia korzystanie z usługi MLAG 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 każdą zmianą. Problemy spowodowane błędem konfiguracji mogą zająć więcej czasu, aby wycofać się w zależności od wprowadzonych zmian. Nie zalecamy tej metody routingu, ale jest ona 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 brzegowym muszą być połączone. Wysoka dostępność nie może być gwarantowana ze względu na sposób działania routingu statycznego.

Urządzenie graniczne musi być skonfigurowane przy użyciu tras statycznych wskazujących każdy z czterech adresów IP punkt-punkt ustawiony między krawędzią a obramowaniem dla ruchu kierowanego do dowolnej sieci wewnątrz usługi Azure Stack. Jednak do operacji wymagana jest tylko zewnętrzna lub publiczna sieć 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 znajdujących się w kontrolerze BMC i sieci infrastruktury. Dodawanie tras statycznych do przełączania infrastruktury i sieci zarządzania przełącznikami jest opcjonalne.

Urządzenia TOR są konfigurowane ze statyczną trasą domyślną wysyłającą cały ruch do urządzeń obramowania. Jednym wyjątkiem ruchu do reguły domyślnej jest przestrzeń prywatna, która jest zablokowana przy użyciu listy kontroli dostępu zastosowanej w połączeniu TOR-to-border.

Routing statyczny ma zastosowanie tylko do pasma między przełącznikami krawędzi 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 całego ruchu do korzystania z serwera proxy, należy skonfigurować przezroczysty serwer proxy, aby przetworzyć cały ruch z stojaka, aby obsłużyć go zgodnie z zasadami. Należy oddzielić ruch między strefami w sieci.

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

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 istnienia serwera proxy.

Przechwytywanie ruchu SSL nie jest obsługiwane i może prowadzić do niepowodzeń 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 wynosi 60 sekund z trzema próbami ponawiania prób.

DNS

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

Konfigurowanie warunkowego przekazywania DNS

Te wskazówki dotyczą tylko wdrożenia Active Directory Federation Services (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ę z podwyższonym poziomem uprawnień Windows PowerShell (uruchom jako administrator). 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 serwery, które przechowują informacje o zewnętrznej strefie DNS i wszystkich strefach utworzonych 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.

Pobieranie 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:

W pełni kwalifikowane nazwy domen serwera DNS (FQDN)
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 wdrożenia. 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 przekazywania warunkowego 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ą. Zalecamy takie podejście, 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 przesyłania warunkowego za pomocą usługi DNS, zobacz artykuł TechNet "Przypisywanie usługi przesyłania dalej warunkowego 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, 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 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 dns rejestratora edytuj 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 publicznej puli 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 dodatkowo zwiększyć bezpieczeństwo 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 do wpisu hosta DNS portalu. <region>.<nazwa 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 udostępnić usługi Azure Stack, takie jak portale, usługi Azure Resource Manager i DNS sieciom zewnętrznym, 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 zapory chroni rozwiązanie, należy zezwolić na określone porty i adresy URL zarówno dla komunikacji przychodzącej, jak i wychodzącej. Przykłady obejmują porty i adresy URL tożsamości, witrynę Azure Stack Hub Marketplace, 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 Azure 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 witryny Azure Stack Hub 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
Stosowanie poprawek i aktualizowanie	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 dostarczony 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 na certyfikacie	HTTP	80	Publiczny adres VIP — /27
LDAP	Las usługi Active Directory udostępniony na potrzeby integracji usługi Azure 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	Azure Blob Storage udostępniony adres URL sygnatury dostępu współdzielonego	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ół. W przypadku punktów końcowych, które wymagają dodatkowych dostawców zasobów, takich jak dostawca zasobów SQL, zobacz dokumentację wdrażania określonego dostawcy zasobów.

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.