Azure Stack Hub nierównomówiona integracja sieci

W tym temacie o Azure Stack integracji sieci.

Planowanie integracji sieci jest ważnym warunkiem wstępnym dla pomyślnego Azure Stack wdrażania, obsługi i zarządzania zintegrowanymi systemami. Planowanie łączności obramowania rozpoczyna się od wybrania, czy 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 użycia routingu statycznego, w którym statyczna trasa domyślna jest przypisana do urządzeń granicznych.

Przełączniki TOR (top of rack) wymagają linków do warstwy 3 z ip typu punkt-punkt (/30 sieci) skonfigurowanymi w interfejsach fizycznych. Łącza warstwy 2 z przełącznikami TOR obsług Azure Stack nie są obsługiwane.

Routing protokołu BGP

Użycie protokołu routingu dynamicznego, takiego jak BGP, gwarantuje, że system zawsze wie o zmianach sieci i ułatwia administrowanie. W celu zwiększenia bezpieczeństwa można ustawić hasło w komunikacji równorzędnej BGP między torami i obramowaniem.

Jak pokazano na poniższym diagramie, reklamy prywatnej przestrzeni adresów IP w przełączniku TOR są blokowane przy użyciu listy prefiksów. Lista prefiksów nie zezwala na anons sieci prywatnej i jest stosowana jako mapa trasy w połączeniu między torami a obramowaniem.

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

Aby zapewnić natychmiastowe i niewidoczne odzyskiwanie ruchu użytkowników po awarii, sieć VPC lub MLAG skonfigurowana między urządzeniami TOR umożliwia korzystanie z agregacji linków o wielu obudowach do hostów oraz protokołu HSRP lub VRRP, które zapewniają nadmiarowość sieci dla sieci IP.

Routing statyczny

Routing statyczny wymaga dodatkowej konfiguracji urządzeń granicznych. Wymaga to większej ręcznej interwencji i zarządzania, a także dokładnej analizy przed zmianą. W zależności od wprowadzonych zmian wycofywanie problemów spowodowanych błędem konfiguracji może zająć więcej czasu. Ta metoda routingu nie jest zalecana, ale jest obsługiwana.

Aby zintegrować Azure Stack ze środowiskiem sieciowym przy użyciu routingu statycznego, należy podłączyć wszystkie cztery fizyczne połączenia między obramowaniem a urządzeniem TOR. Ze względu na sposób działania routingu statycznego nie można zagwarantować wysokiej dostępności.

Urządzenie obramowania musi być skonfigurowane przy użyciu tras statycznych, które wskazują każdy z czterech adresów IP P2P ustawionych między torami i obramowaniem dla ruchu przeznaczonego do dowolnej sieci wewnątrz usługi Azure Stack, ale tylko zewnętrzna lub publiczna sieć vip jest wymagana do działania. Trasy statyczne do kontrolera BMC i sieci zewnętrznych 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 w celu przełączenia infrastrukturyi sieci zarządzania przełącznikiem jest opcjonalne.

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

Routing statyczny dotyczy tylko łączy między przełącznikami TOR i border. Routing dynamiczny BGP jest używany wewnątrz stojaka, ponieważ jest to podstawowe narzędzie dla usługi 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 zostać uwzględniona w sieci zarządzania przełącznikiem.

Sieć zarządzania przełącznikiem jest wymagana i można ją dodać niezależnie od sieci infrastruktury przełącznika.

Przezroczysty serwer proxy

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

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

Przezroczysty serwer proxy (znany również jako przechwytujące, wbudowane lub wymuszone serwery proxy) przechwytuje normalną komunikację w warstwie sieciowej bez konieczności specjalnej konfiguracji klienta. Klienci nie muszą być świadomi istnienia 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 s przy 3 ponownych próbach.

DNS

Ta sekcja obejmuje konfigurację systemu nazw domen (DNS).

Konfigurowanie warunkowego przekazywania DNS

Dotyczy to tylko wdrożenia AD FS wdrożenia.

Aby włączyć rozpoznawanie nazw w istniejącej infrastrukturze DNS, skonfiguruj przekazywanie warunkowe.

Aby dodać warunkową usługi przesyłania dalej, 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 Azure Stack.

  1. 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 
    
  2. Po nawiązania 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 Azure Stack NAZW DNS spoza Azure Stack

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

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

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

  • Nazwy FQDN serwera DNS

  • Adresy IP serwera DNS

Nazwy FQDN Azure Stack DNS mają następujący format:

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

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

Przy użyciu przykładowych wartości nazwy FQDN dla serwerów DNS są:

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ń Azure Stack w pliku o nazwie AzureStackStampInformation.json. Ten plik znajduje się w folderze C:\CloudDeployment\logs maszyny wirtualnej wdrażania. Jeśli nie masz pewności, jakie wartości zostały użyte dla wdrożenia Azure Stack, możesz pobrać wartości z tego miejscu.

Jeśli maszyna wirtualna Wdrażanie 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 programu Get-AzureStackStampInformation PowerShell. Aby uzyskać więcej informacji, zobacz privileged endpoint (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 warunkowe przekazywanie strefy z serwera, który hostuje strefę nadrzędną. To podejście jest zalecane, jeśli masz bezpośrednią kontrolę nad serwerami DNS, które hostują strefę nadrzędną dla Azure Stack zewnętrznej przestrzeni nazw DNS.

Jeśli nie wiesz, jak wykonać przekazywanie warunkowe za pomocą usługi DNS, zapoznaj się z następującym artykułem w witrynie TechNet: Przypisywanie usługi warunkowego przesyłania dalej dla nazwy domeny lub dokumentacją specyficzną dla rozwiązania DNS.

W scenariuszach, w których określono zewnętrzną strefę Azure Stack DNS tak, aby wyglądała jak domena podrzędna nazwy domeny firmowej, nie można używać warunkowego przekazywania dalej. Delegowanie DNS musi być skonfigurowane.

Przykład:

  • Nazwa firmowej domeny DNS: contoso.com

  • Azure Stack zewnętrzna nazwa domeny DNS: azurestack.contoso.com

Edytowanie ip usługi przesyłania dalej DNS

Podczas wdrażania usługi przesyłania dalej DNS są ustawiane 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 privileged endpoint (Uprzywilejowany punkt końcowy).

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

Aby nazwy DNS można było rozstrzygić spoza Azure Stack wdrożenia, 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 edytuj rekordy NS i zastąp rekordy NS dla strefy rekordami z Azure Stack.

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

Firewall

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. W celu dalszego wzmacniania rozwiązania są również używane między przełącznikami fizycznymi (tors i BMC). 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 ma przypisany wpis hosta DNS portalu. region > . < fqdn >.

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

architectural diagram shows the different network layers and ACLs

Porty i adresy URL

Aby usługi Azure Stack (takie jak portale, Azure Resource Manager, DNS itp.) 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 rozwiązanie chroni przezroczyste linki proxy do tradycyjnego serwera proxy lub zapory, należy zezwolić na określone porty i adresy URL dla komunikacji przychodzącej i wychodzącej. Obejmują one porty i adresy URL dotyczące tożsamości, platformy handlowej, poprawek i aktualizacji, rejestracji i danych użycia.

Komunikacja wychodząca

Azure Stack obsługuje tylko przezroczyste serwery proxy. We wdrożeniu z przezroczystym linkiem serwera proxy do tradycyjnego serwera proxy należy zezwolić na porty i adresy URL w poniższej tabeli na komunikację wychodzącą podczas wdrażania w trybie połączonym.

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 s.

Uwaga

Azure Stack nie obsługuje korzystania z usługi ExpressRoute w celu dotarcia do usług platformy Azure wymienionych w poniższej tabeli, ponieważ usługa ExpressRoute może nie być w stanie przekierowyć 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 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 do wdrożenia) UDP 123 Publiczny adres VIP — /27
DNS (Adres IP serwera DNS podany 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 zapewniany na Graph integracji TCP
UDP
389 Publiczny adres VIP — /27
LDAP SSL Las usługi Active Directory zapewniany na Graph integracji TCP 636 Publiczny adres VIP — /27
LDAP GC Las usługi Active Directory zapewniany na Graph integracji TCP 3268 Publiczny adres VIP — /27
LDAP GC SSL Las usługi Active Directory zapewniany na Graph integracji TCP 3269 Publiczny adres VIP — /27
AD FS AD FS metadanych na AD FS integracji TCP 443 Publiczny adres VIP — /27
Usługa zbierania dzienników diagnostycznych Adres URL sygnatury dostępu współdzielonego Storage azure Storage blob HTTPS 443 Publiczny adres VIP — /27

Komunikacja przychodzących

Do publikowania punktów końcowych w sieciach zewnętrznych jest wymagany Azure Stack infrastruktury VIP. 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 SQL dostawcy zasobów.

Nie ma na liście wewnętrznych vip infrastruktury, ponieważ nie są one wymagane do publikowania Azure Stack. Vip użytkowników są dynamiczne i zdefiniowane przez samych użytkowników, bez kontroli Azure Stack operatora

Uwaga

IKEv2 VPN to oparte na standardach rozwiązanie sieci VPN IPsec, które używa portów UDP 500 i 4500 oraz TCP 50. Zapory nie zawsze otwierają te porty, więc sieć VPN ZKEv2 może nie być w stanie przechodzić przez serwery proxy i zapory.

Punkt końcowy (VIP) Rekord A hosta DNS Protokół Porty
AD FS Programu adfs. region > . < Fqdn > HTTPS 443
Portal (administrator) Administratorportal. region > . < Fqdn > HTTPS 443
Hostowanie administracyjne *.adminhosting. < region > . < Fqdn> HTTPS 443
Azure Resource Manager (administrator) Administracja. region > . < Fqdn > HTTPS 443
Portal (użytkownik) Portal. region > . < Fqdn > HTTPS 443
Azure Resource Manager (użytkownik) Zarządzania. region > . < Fqdn > HTTPS 443
Graph Graph. region > . < Fqdn > HTTPS 443
Lista odwołania certyfikatów Crl. region > . < Fqdn > HTTP 80
DNS *. region > . < Fqdn > Protokół & UDP protokołu TCP 53
Hosting *.hosting. < region > . < Fqdn> HTTPS 443
Key Vault (użytkownik) *.vault. region > . < Fqdn > HTTPS 443
Key Vault (administrator) *.adminvault. region > . < Fqdn > HTTPS 443
Kolejka magazynu *.queue. region > . < Fqdn > HTTP
HTTPS
80
443
Storage tabeli *.table. region > . < Fqdn > HTTP
HTTPS
80
443
Storage Blob *.blob. region > . < Fqdn > HTTP
HTTPS
80
443
SQL dostawcy zasobów sqladapter.dbadapter. region > . < Fqdn > HTTPS 44300-44304
Dostawca zasobów MySQL mysqladapter.dbadapter. region > . < Fqdn > HTTPS 44300-44304
App Service *.appservice. region > . < Fqdn > TCP 80 (HTTP)
443 (HTTPS)
8172 (MSDeploy)
*.scm.appservice. region > . < Fqdn > TCP 443 (HTTPS)
api.appservice. region > . < Fqdn > TCP 443 (HTTPS)
44300 (Azure Resource Manager)
ftp.appservice. region > . < Fqdn > TCP, UDP 21, 1021, 10001-10100 (FTP)
990 (FTPS)
Bramy sieci VPN Zobacz Brama sieci VPN — często zadawane pytania.