Dostosowywanie ustawień komunikacji dla lokalnej bramy danych
W tym artykule opisano kilka ustawień komunikacji skojarzonych z lokalną bramą danych. Te ustawienia należy dostosować, aby obsługiwać połączenia ze źródłem danych i dostęp do miejsca docelowego danych wyjściowych.
Włączanie wychodzących połączeń platformy Azure
Brama opiera się na usłudze Azure Relay na potrzeby łączności w chmurze. Brama odpowiednio ustanawia połączenia wychodzące ze skojarzonym z nim regionem świadczenia usługi Azure.
Jeśli zarejestrowano się w dzierżawie usługi Power BI lub dzierżawie usługi Office 365, region świadczenia usługi Azure domyślnie jest regionem tej usługi. W przeciwnym razie region świadczenia usługi Azure może być najbliżej Ciebie.
Jeśli zapora blokuje połączenia wychodzące, skonfiguruj zaporę tak, aby zezwalała na połączenia wychodzące z bramy do skojarzonego z nią regionu świadczenia usługi Azure. Reguły zapory na serwerze bramy i/lub serwerach proxy klienta muszą zostać zaktualizowane, aby zezwolić na ruch wychodzący z serwera bramy do poniższych punktów końcowych. Jeśli zapora nie obsługuje symboli wieloznacznych, użyj adresów IP z zakresów adresów IP platformy Azure i tagów usługi. Należy pamiętać, że będą one synchronizowane co miesiąc.
Porty
Brama komunikuje się na następujących portach wychodzących: TCP 443, 5671, 5672 i od 9350 do 9354. Brama nie wymaga portów przychodzących.
Zalecamy zezwolenie na system nazw domen "*.servicebus.windows.net" (DNS). Aby uzyskać wskazówki dotyczące konfigurowania lokalnej zapory i/lub serwera proxy przy użyciu w pełni kwalifikowanych nazw domen (FQDN) zamiast używania adresów IP, które podlegają zmianie, wykonaj kroki opisane w temacie Obsługa dns usługi Azure WCF Relay.
Możesz też zezwolić na adresy IP dla regionu danych w zaporze. Użyj plików JSON wymienionych poniżej, które są aktualizowane co tydzień.
Możesz też uzyskać listę wymaganych portów, wykonując test portów sieciowych okresowo w aplikacji bramy.
Brama komunikuje się z usługą Azure Relay przy użyciu nazw FQDN. Jeśli wymusisz komunikację bramy za pośrednictwem protokołu HTTPS, będzie ona ściśle używać nazw FQDN i nie będzie komunikować się przy użyciu adresów IP.
Uwaga
Lista adresów IP centrum danych platformy Azure zawiera adresy IP w notacji CiDR (Classless Inter-Domain Routing). Przykładem tej notacji jest 10.0.0.0/24, co nie oznacza od 10.0.0.0 do 10.0.0.0.24. Dowiedz się więcej o notacji CIDR.
Poniższa lista zawiera opis nazw FQDN używanych przez bramę. Te punkty końcowe są wymagane do działania bramy.
| Nazwy domen chmury publicznej | Porty wychodzące | opis |
|---|---|---|
| *.download.microsoft.com | 80 | Służy do pobierania instalatora. Aplikacja bramy używa również tej domeny do sprawdzania wersji i regionu bramy. |
| *.powerbi.com | 443 | Służy do identyfikowania odpowiedniego klastra usługi Power BI. |
| *.analysis.windows.net | 443 | Służy do identyfikowania odpowiedniego klastra usługi Power BI. |
| *.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com | 443 | Służy do uwierzytelniania aplikacji bramy dla identyfikatora Entra firmy Microsoft i protokołu OAuth2. Należy pamiętać, że dodatkowe adresy URL mogą być wymagane w ramach procesu logowania identyfikatora Entra firmy Microsoft, który może być unikatowy dla dzierżawy. |
| *.servicebus.windows.net | 5671-5672 | Służy do zaawansowanego protokołu kolejkowania komunikatów (AMQP). |
| *.servicebus.windows.net | 443 i 9350-9354 | Nasłuchuje w usłudze Azure Relay za pośrednictwem protokołu TCP. Port 443 jest wymagany do uzyskania tokenów kontroli dostępu platformy Azure. |
| *.msftncsi.com | 80 | Służy do testowania łączności z Internetem, jeśli usługa Power BI nie może nawiązać połączenia z bramą. |
| *.dc.services.visualstudio.com | 443 | Używane przez usługę AppInsights do zbierania danych telemetrycznych. |
| *.frontend.clouddatahub.net | 443 | Wymagane do wykonania potoku sieci szkieletowej. |
W przypadku GCC, GCC high i DoD następujące nazwy FQDN są używane przez bramę.
| Porty | GCC | GCC High | DoD |
|---|---|---|---|
| 80 | *.download.microsoft.com | *.download.microsoft.com | *.download.microsoft.com |
| 443 | *.powerbigov.us, *.powerbi.com | *.high.powerbigov.us | *.mil.powerbigov.us |
| 443 | *.analysis.usgovcloudapi.net | *.high.analysis.usgovcloudapi.net | *.mil.analysis.usgovcloudapi.net |
| 443 | *.login.windows.net, *.login.live.com, *.aadcdn.msauth.net | Przejdź do dokumentacji | Przejdź do dokumentacji |
| 5671-5672 | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net |
| 443 i 9350-9354 | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net |
| 443 | *.core.usgovcloudapi.net | *.core.usgovcloudapi.net | *.core.usgovcloudapi.net |
| 443 | *.login.microsoftonline.com | *.login.microsoftonline.us | *.login.microsoftonline.us |
| 443 | *.msftncsi.com | *.msftncsi.com | *.msftncsi.com |
| 443 | *.microsoftonline-p.com | *.microsoftonline-p.com | *.microsoftonline-p.com |
| 443 | *.dc.applicationinsights.us | *.dc.applicationinsights.us | *.dc.applicationinsights.us |
W przypadku chmury Chińskiej (Mooncake) następujące nazwy FQDN są używane przez bramę.
| Porty | Chmura w Chinach (Mooncake) |
|---|---|
| 80 | *.download.microsoft.com |
| 443 | *.powerbi.cn |
| 443 | *.asazure.chinacloudapi.cn |
| 443 | *.login.chinacloudapi.cn |
| 5671-5672 | *.servicebus.chinacloudapi.cn |
| 443 i 9350-9354 | *.servicebus.chinacloudapi.cn |
| 443 | *.chinacloudapi.cn |
| 443 | login.partner.microsoftonline.cn |
| 443 | Brak odpowiednika mooncake — nie jest wymagany do uruchomienia bramy — używany tylko do sprawdzania sieci podczas warunków awarii |
| 443 | Brak odpowiednika aplikacji Mooncake — używane podczas logowania do identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji na temat punktów końcowych identyfikatora entra firmy Microsoft, zobacz Sprawdzanie punktów końcowych na platformie Azure |
| 443 | applicationinsights.azure.cn |
| 433 | clientconfig.passport.net |
| 433 | aadcdn.msftauth.cn |
| 433 | aadcdn.msauth.cn |
Uwaga
Po zainstalowaniu i zarejestrowaniu bramy jedyne wymagane porty i adresy IP są wymagane przez usługę Azure Relay zgodnie z opisem servicebus.windows.net w poprzedniej tabeli. Listę wymaganych portów można uzyskać, wykonując test porty sieciowe okresowo w aplikacji bramy. Możesz również wymusić komunikację bramy przy użyciu protokołu HTTPS.
Otwieranie portów dla sieci szkieletowej Dataflow Gen1 i Gen2 przy użyciu bramy
Gdy dowolne obciążenie oparte na mashupie (na przykład modele semantyczne, przepływy danych sieci szkieletowej itd.) zawiera zapytanie łączące się zarówno z lokalnymi źródłami danych (przy użyciu lokalnej bramy danych) jak i źródłami danych w chmurze, całe zapytanie jest wykonywane w amencie mashup lokalnej bramy danych. W związku z tym punkty końcowe muszą być otwarte, aby umożliwić lokalnej bramie danych we wszystkich obciążeniach opartych na mashupach dostęp do źródeł danych w chmurze zarówno dla źródła danych, jak i miejsca docelowego danych wyjściowych.
Specjalnie w przypadku przepływów danych sieci szkieletowej Gen1 i Gen2 następujące punkty końcowe muszą być otwarte, aby umożliwić lokalnym bramie danych dostęp do usługi Azure Data Lake i przejściowe źródła danych chmury lakehouse w sieci szkieletowej.
| Nazwy domen w chmurze publicznej | Porty wychodzące | opis |
|---|---|---|
| *.core.windows.net | 443 | Używany przez usługę Dataflow Gen1 do zapisywania danych w usłudze Azure Data Lake. |
| *.dfs.fabric.microsoft.com | 1433 | Punkt końcowy używany przez usługę Dataflow Gen1 i Gen2 do nawiązania połączenia z usługą OneLake. Dowiedz się więcej |
| *.datawarehouse.pbidedicated.windows.net | 1433 | Stary punkt końcowy używany przez usługę Dataflow Gen2 do nawiązywania połączenia z przejściowym magazynem lakehouse. Dowiedz się więcej |
| *.datawarehouse.fabric.microsoft.com | 1433 | Nowy punkt końcowy używany przez usługę Dataflow Gen2 do nawiązywania połączenia z przejściowym magazynem lakehouse. Dowiedz się więcej |
Uwaga
*.datawarehouse.pbidedicated.windows.net jest zastępowany przez *.datawarehouse.fabric.microsoft.com. Podczas tego procesu przejścia upewnij się, że oba punkty końcowe są otwarte, aby upewnić się, że odświeżanie usługi Dataflow Gen2.
Test portów sieciowych
Aby sprawdzić, czy brama ma dostęp do wszystkich wymaganych portów:
Na maszynie, na którym jest uruchomiona brama, wprowadź ciąg "gateway" w wyszukiwaniu systemu Windows, a następnie wybierz aplikację lokalnej bramy danych.
Wybierz pozycję Diagnostyka. W obszarze Test portów sieciowych wybierz pozycję Rozpocznij nowy test.
Gdy brama uruchamia test portów sieciowych, pobiera listę portów i serwerów z usługi Azure Relay, a następnie próbuje nawiązać połączenie ze wszystkimi z nich. Po ponownym uruchomieniu linku Rozpocznij nowy test testowy portów sieciowych zakończył się.
Podsumowanie wyniku testu to "Ukończono (powodzenie)" lub "Ukończono (niepowodzenie, zobacz ostatnie wyniki testu)". Jeśli test zakończył się pomyślnie, brama połączona ze wszystkimi wymaganymi portami. Jeśli test nie powiedzie się, środowisko sieciowe mogło zablokować wymagane porty i serwery.
Uwaga
Zapory często sporadycznie zezwalają na ruch w zablokowanych witrynach. Nawet jeśli test zakończy się pomyślnie, może być konieczne dodanie tego serwera do listy dozwolonych na zaporze.
Aby wyświetlić wyniki ostatniego ukończonego testu, wybierz link Otwórz wyniki ostatniego ukończonego testu . Wyniki testu są otwierane w domyślnym edytorze tekstów.
Wyniki testu zawierają listę wszystkich serwerów, portów i adresów IP, których wymaga brama. Jeśli wyniki testu są wyświetlane jako "Zamknięte" dla jakichkolwiek portów, jak pokazano na poniższym zrzucie ekranu, upewnij się, że środowisko sieciowe nie zablokowało tych połączeń. Może być konieczne skontaktowanie się z administratorem sieci w celu otwarcia wymaganych portów.
Wymuszanie komunikacji HTTPS z usługą Azure Relay
Brama może wymusić komunikację z usługą Azure Relay przy użyciu protokołu HTTPS zamiast bezpośredniego protokołu TCP.
Uwaga
Począwszy od wersji bramy z czerwca 2019 r. i na podstawie zaleceń z usługi Relay, nowe instalacje są domyślnie https zamiast TCP. To domyślne zachowanie nie ma zastosowania do zaktualizowanych instalacji.
Możesz użyć aplikacji bramy, aby wymusić zastosowanie tego zachowania przez bramę. W aplikacji bramy wybierz pozycję Sieć, a następnie włącz tryb HTTPS.
Po wprowadzeniu tej zmiany, a następnie wybraniu pozycji Zastosuj usługa bramy systemu Windows zostanie automatycznie uruchomiona ponownie, aby zmiana mogła obowiązywać. Przycisk Zastosuj jest wyświetlany tylko wtedy, gdy wprowadzisz zmianę.
Aby ponownie uruchomić usługę bramy systemu Windows z poziomu aplikacji bramy, przejdź do pozycji Uruchom ponownie bramę.
Uwaga
Jeśli brama nie może komunikować się przy użyciu protokołu TCP, automatycznie używa protokołu HTTPS. Wybór w aplikacji bramy zawsze odzwierciedla bieżącą wartość protokołu.
Protokół TLS 1.3 dla ruchu bramy
Domyślnie brama używa protokołu Transport Layer Security (TLS) 1.3 do komunikowania się z usługa Power BI. Aby upewnić się, że cały ruch bramy korzysta z protokołu TLS 1.3, może być konieczne dodanie lub zmodyfikowanie następujących kluczy rejestru na maszynie, na której jest uruchomiona usługa bramy.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001
Uwaga
Dodanie lub zmodyfikowanie tych kluczy rejestru spowoduje zastosowanie zmiany do wszystkich aplikacji platformy .NET. Aby uzyskać informacje na temat zmian rejestru, które mają wpływ na protokół TLS dla innych aplikacji, zobacz Ustawienia rejestru protokołu Transport Layer Security (TLS).
Tagi usługi
Tag usługi reprezentuje grupę prefiksów adresów IP z danej usługi platformy Azure. Firma Microsoft zarządza prefiksami adresów uwzględnionych przez tag usługi i automatycznie aktualizuje tag usługi w miarę zmiany adresów, minimalizując złożoność częstych aktualizacji reguł zabezpieczeń sieci. Brama danych ma zależności od następujących tagów usługi:
- PowerBI
- ServiceBus
- AzureActiveDirectory
- AzureCloud
Lokalna brama danych używa usługi Azure Relay do komunikacji. Nie ma jednak żadnych tagów usługi dla usługi Azure Relay. Tagi usługi ServiceBus są jednak nadal wymagane, ponieważ nadal odnoszą się one do kolejek i tematów usługi, mimo że nie dla usługi Azure Relay.
Tag usługi AzureCloud reprezentuje wszystkie globalne adresy IP centrum danych platformy Azure. Ponieważ usługa Azure Relay jest oparta na usłudze Azure Compute, publiczne adresy IP usługi Azure Relay są podzbiorem adresów IP usługi AzureCloud. Więcej informacji: Omówienie tagów usługi platformy Azure