Anpassen von Kommunikationseinstellungen für das lokale Datengateway
In diesem Artikel werden verschiedene Kommunikationseinstellungen, die dem lokalen Datengateway zugeordnet sind, beschrieben. Diese Einstellungen müssen angepasst werden, um Datenquellenverbindungen und Ausgabezielzugriff zu unterstützen.
Aktivieren von ausgehenden Azure-Verbindungen
Das Gateway stützt sich für die Cloudkonnektivität auf Azure Relay. Das Gateway stellt entsprechend ausgehende Verbindungen mit seiner zugeordneten Azure-Region her.
Wenn Sie entweder für einen Power BI-Mandanten oder einen Office 365-Mandanten registriert sind, wird Ihre Azure-Region standardmäßig auf die Region dieses Diensts festgelegt. Andernfalls ist Ihre Azure-Region möglicherweise diejenige, die Ihnen am nächsten liegt.
Wenn eine Firewall ausgehende Verbindungen blockiert, konfigurieren Sie die Firewall so, dass ausgehende Verbindungen vom Gateway mit der zugeordneten Azure-Region zugelassen werden. Die Firewallregeln auf dem Gatewayserver und/oder den Proxyservern des Kunden müssen aktualisiert werden, um ausgehenden Datenverkehr vom Gatewayserver zu den folgenden Endpunkten zuzulassen. Wenn Ihre Firewall keine Wildcards unterstützt, verwenden Sie die IP-Adressen aus Azure-IP-Bereiche und -Diensttags. Beachten Sie, dass sie jeden Monat synchronisiert werden müssen.
Ports
Das Gateway kommuniziert über die folgenden ausgehenden Ports: TCP 443, 5671, 5672 und über 9350 bis 9354. Das Gateway benötigt keine eingehenden Ports.
Wir empfehlen Ihnen, das DNS (Domain Name System) „*.servicebus.windows.net“ zuzulassen. Eine Anleitung zum Einrichten Ihrer lokalen Firewall und/oder Ihres Proxys unter Verwendung von vollqualifizierten Domänennamen (FQDNs) statt IP-Adressen, die sich ändern können, finden Sie in den Schritten unter Azure WCF Relay-DNS-Unterstützung.
Es wird alternativ empfohlen, in der Firewall die IP-Adressen für Ihre Datenregion zuzulassen. Verwenden Sie die unten aufgeführten JSON-Dateien, die wöchentlich aktualisiert werden.
Oder Sie können die Liste der erforderlichen Ports abrufen, indem Sie den Test der Netzwerkports regelmäßig in der Gateway-App durchführen.
Das Gateway kommuniziert mithilfe von FQDN mit Azure Relay. Wenn Sie das Gateway zur Kommunikation über HTTPS zwingen, werden ausschließlich FQDN und keine IP-Adressen verwendet.
Hinweis
In der Azure-Rechenzentrum-IP-Liste werden IP-Adressen in der CIDR-Notation (Classless Inter-Domain Routing) angezeigt. Ein Beispiel für diese Notation ist 10.0.0.0/24, was nicht von 10.0.0.0 bis 10.0.0.24 bedeutet. Weitere Informationen: CIDR-Notation.
In der folgenden Liste werden die vom Gateway verwendeten vollqualifizierten Domänennamen (FQDN) beschrieben. Diese Endpunkte sind erforderlich, damit das Gateway funktioniert.
| Domänennamen der öffentlichen Cloud | Ausgehende Ports | Beschreibung |
|---|---|---|
| *.download.microsoft.com | 80 | Wird zum Herunterladen des Installationsprogramms verwendet. Die Gateway-App verwendet diese Domäne auch, um die Version und die Gatewayregion zu überprüfen. |
| *.powerbi.com | 443 | Wird zum Identifizieren des relevanten Power BI-Clusters verwendet. |
| *.analysis.windows.net | 443 | Wird zum Identifizieren des relevanten Power BI-Clusters verwendet. |
| *.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com | 443 | Wird verwendet, um die Gateway-App bei Microsoft Entra ID und OAuth2 zu authentifizieren. Beachten Sie, dass zusätzliche URLs im Rahmen des Microsoft Entra ID-Anmeldevorgangs erforderlich sein können, die für einen Mandanten eindeutig sein können. |
| *.servicebus.windows.net | 5671-5672 | Wird für das Advance Message Queueing Protocol (AMQP) verwendet. |
| *.servicebus.windows.net | 443 und 9350-9354 | Lauscht über TCP an Azure Relay. Port 443 ist erforderlich, um Azure-Zugriffssteuerungstoken abzurufen. |
| *.msftncsi.com | 80 | Wird zum Testen der Internetverbindung verwendet, wenn der Power BI-Dienst das Gateway nicht erreichen kann. |
| *.dc.services.visualstudio.com | 443 | Werden von AppInsights zur Erfassung von Telemetrie verwendet. |
| *.frontend.clouddatahub.net | 443 | Erforderlich für die Ausführung der Fabric-Pipeline. |
Für GCC, GCC High und DoD werden die folgenden FQDN vom Gateway verwendet.
| Ports | 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 | Zur Dokumentation wechseln | Zur Dokumentation wechseln |
| 5671-5672 | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net |
| 443 und 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 |
Für China Cloud (Mooncake) werden die folgenden FQDN vom Gateway verwendet.
| Ports | China Cloud (Mooncake) |
|---|---|
| 80 | *.download.microsoft.com |
| 443 | *.powerbi.cn |
| 443 | *.asazure.chinacloudapi.cn |
| 443 | *.login.chinacloudapi.cn |
| 5671-5672 | *.servicebus.chinacloudapi.cn |
| 443 und 9350-9354 | *.servicebus.chinacloudapi.cn |
| 443 | *.chinacloudapi.cn |
| 443 | login.partner.microsoftonline.cn |
| 443 | Kein Mooncake-Äquivalent – nicht erforderlich, um das Gateway auszuführen – wird nur verwendet, um das Netzwerk unter Fehlerbedingungen zu überprüfen |
| 443 | Kein Mooncake-Äquivalent – wird während der Microsoft Entra-ID-Anmeldung verwendet. Weitere Informationen über Microsoft Entra ID-Endpunkte finden Sie unter Überprüfen der Endpunkte in Azure. |
| 443 | applicationinsights.azure.cn |
| 433 | clientconfig.passport.net |
| 433 | aadcdn.msftauth.cn |
| 433 | aadcdn.msauth.cn |
Hinweis
Nach der Installation und Registrierung des Gateways sind nur die von Azure Relay benötigten Ports und IP-Adressen erforderlich, wie in der vorhergehenden Tabelle für servicebus.windows.net beschrieben. Sie können die Liste der erforderlichen Ports abrufen, indem Sie den Test der Netzwerkports regelmäßig in der Gateway-App durchführen. Sie können das Gateway auch zur Kommunikation über HTTPS erzwingen.
Öffnen von Ports für Fabric Dataflow Gen1 und Gen2 mithilfe des Gateways
Wenn eine Mashup-basierte Workload (z. B. Semantikmodelle, Fabric-Datenflüsse usw.) eine Abfrage enthält, die eine Verbindung mit lokalen Datenquellen (mithilfe eines lokalen Datengateways) und Clouddatenquellen herstellt, wird die gesamte Abfrage im Mashup-Modul des lokalen Datengateways ausgeführt. Daher müssen Endpunkte geöffnet sein, damit das lokale Datengateway in allen Mashup-basierten Workloads zugriff auf die Clouddatenquellen sowohl für Datenquellen als auch für das Ausgabeziel ermöglicht werden kann.
Speziell für Fabric Dataflow Gen1 und Gen2 müssen die folgenden Endpunkte ebenfalls geöffnet sein, um den lokalen Datengatewayzugriff auf Azure Data Lake und die Fabric Staging Lakehouse-Clouddatenquellen zu ermöglichen.
| Namen öffentlicher Clouddomänen | Ausgehende Ports | Beschreibung |
|---|---|---|
| *.core.windows.net | 443 | Wird von Dataflow Gen1 verwendet, um Daten in Azure Data Lake zu schreiben |
| *.dfs.fabric.microsoft.com | 1433 | Endpunkt, der von Dataflow Gen1 und Gen2 zum Herstellen einer Verbindung mit OneLake verwendet wird. Weitere Informationen |
| *.datawarehouse.pbidedicated.windows.net | 1433 | Alter Endpunkt, der von Dataflow Gen2 zum Herstellen einer Verbindung mit dem Staging Lakehouse verwendet wird. Weitere Informationen |
| *.datawarehouse.fabric.microsoft.com | 1433 | Neuer Endpunkt, der von Dataflow Gen2 zum Herstellen einer Verbindung mit dem Staging Lakehouse verwendet wird. Weitere Informationen |
Hinweis
*.datawarehouse.pbidedicated.windows.net wird durch *.datawarehouse.fabric.microsoft.com ersetzt. Stellen Sie während dieses Übergangsvorgangs sicher, dass beide Endpunkte geöffnet sind, damit Dataflow Gen2 aktualisiert wird.
Test der Netzwerkports
So testen Sie, ob das Gateway Zugriff auf alle erforderlichen Ports hat:
Geben Sie auf dem Computer, auf dem das Gateway ausgeführt wird, in das Windows-Suchfeld „Gateway“ ein und wählen Sie dann die App Lokales Datengateway aus.
Wählen Sie Diagnose. Wählen Sie unter Test der Netzwerkports die Option Neuen Test starten aus.
Wenn Ihr Gateway den Test der Netzwerkports ausführt, ruft es eine Liste der Ports und Server von Azure Relay ab und versucht dann, sich mit allen zu verbinden. Wenn der Link Neuen Test starten erneut angezeigt wird, wurde der Test der Netzwerkports abgeschlossen.
Das zusammenfassende Ergebnis des Tests lautet entweder „Abgeschlossen (erfolgreich)“ oder „Abgeschlossen (fehlgeschlagen, siehe letzte Testergebnisse)“. Wenn der Test erfolgreich war, hat Ihr Gateway eine Verbindung zu allen erforderlichen Ports hergestellt. Wenn der Test fehlgeschlagen ist, hat Ihre Netzwerkumgebung möglicherweise die erforderlichen Ports und Server blockiert.
Hinweis
Firewalls lassen den Verkehr auf gesperrten Websites oft zeitweise zu. Selbst wenn ein Test erfolgreich ist, müssen Sie diesen Server möglicherweise noch auf Ihrer Firewall zulassen.
Um die Ergebnisse des letzten abgeschlossenen Tests anzuzeigen, wählen Sie den Link Ergebnisse des letzten abgeschlossenen Tests öffnen. Die Testergebnisse werden im Standardtexteditor geöffnet.
In den Testergebnissen sind alle Server, Ports und IP-Adressen aufgeführt, die Ihr Gateway benötigt. Wenn in den Testergebnissen für Ports „Geschlossen“ angezeigt wird, wie im folgenden Screenshot zu sehen ist, stellen Sie sicher, dass Ihre Netzwerkumgebung diese Verbindungen nicht blockiert hat. Möglicherweise müssen Sie sich an Ihren Netzwerkadministrator wenden, um die erforderlichen Ports zu öffnen.
Erzwingen der HTTPS-Kommunikation mit Azure Relay
Sie können das Gateway zwingen, mit Azure Relay über HTTPS und nicht über direktes TCP zu kommunizieren.
Hinweis
Ab der Gatewayversion vom Juni 2019 und basierend auf den Empfehlungen von Relay wird bei Neuinstallationen standardmäßig HTTPS anstelle von TCP verwendet. Dieses Standardverhalten gilt nicht für aktualisierte Installationen.
Sie können die Gateway-App verwenden, um das Gateway zu zwingen, dieses Verhalten zu übernehmen. Wählen Sie in der Gateway-App die Option Netzwerk aus und aktivieren Sie dann den HTTPS-Modus.
Nachdem Sie diese Änderung vorgenommen und dann Anwenden ausgewählt haben, wird der Windows-Dienst auf dem Gateway automatisch neu gestartet, damit die Änderung wirksam wird. Die Schaltfläche Anwenden wird nur angezeigt, wenn Sie eine Änderung vornehmen.
Informationen zum Neustarten des Windows-Diensts für das Gateway über die Gateway-App finden Sie unter Neustarten eines Gateways.
Hinweis
Wenn das Gateway nicht über TCP kommunizieren kann, verwendet es automatisch HTTPS. Die Auswahl in der Gateway-App spiegelt immer den aktuellen Protokollwert wider.
TLS 1.3 für Gatewaydatenverkehr
Standardmäßig verwendet das lokale Datengateway TLS (Transport Layer Security) 1.3 für die Kommunikation mit dem Power BI-Dienst. Um sicherzustellen, dass der gesamte Gatewaydatenverkehr TLS 1.3 verwendet, müssen Sie möglicherweise die folgenden Registrierungsschlüssel auf dem Computer, auf dem der Gatewaydienst ausgeführt wird, hinzufügen oder ändern.
[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
Hinweis
Durch Hinzufügen bzw. Ändern dieser Registrierungsschlüssel wird die Änderung auf alle .NET-Anwendungen angewendet. Weitere Informationen zu den Registrierungsänderungen mit Auswirkungen auf TLS für andere Anwendungen finden Sie unter TLS-Registrierungseinstellungen (Transport Layer Security).
Diensttags
Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen aus einem bestimmten Azure-Dienst. Microsoft verwaltet die Adresspräfixe, für die das Diensttag gilt, und aktualisiert das Tag automatisch, wenn sich die Adressen ändern. Auf diese Weise wird die Komplexität häufiger Updates an Netzwerksicherheitsregeln minimiert. Das Datengateway weist Abhängigkeiten von den folgenden Diensttags auf:
- PowerBI
- ServiceBus
- AzureActiveDirectory
- AzureCloud
Das lokale Datengateway verwendet für einen Teil der Kommunikation Azure Relay. Es gibt jedoch keine Diensttags für den Azure Relay-Dienst. ServiceBus-Diensttags sind jedoch weiterhin erforderlich, da sie weiterhin für die Dienstwarteschlangen- und Themenfunktion relevant sind, wenn auch nicht bei Azure Relay.
Das AzureCloud-Diensttag stellt alle globalen IP-Adressen von Azure-Rechenzentren dar. Da der Azure Relay-Dienst auf Azure Compute aufbaut, sind die öffentlichen IP-Adressen von Azure Relay eine Teilmenge der AzureCloud-IP-Adressen. Weitere Informationen: Übersicht über Azure-Diensttags