Juster kommunikationsindstillinger for datagatewayen i det lokale miljø
I denne artikel beskrives flere kommunikationsindstillinger, der er knyttet til datagatewayen i det lokale miljø. Disse indstillinger skal justeres for at understøtte datakildeforbindelser og outputdestinationsadgang.
Aktivér udgående Azure-forbindelser
Gatewayen er afhængig af Azure Relay til cloudforbindelse. Gatewayen etablerer tilsvarende udgående forbindelser til det tilknyttede Azure-område.
Hvis du har tilmeldt dig enten en Power BI-lejer eller en Office 365-lejer, er dit Azure-område som standard området for den pågældende tjeneste. Ellers kan dit Azure-område være det, der er tættest på dig.
Hvis en firewall blokerer udgående forbindelser, skal du konfigurere firewallen til at tillade udgående forbindelser fra gatewayen til det tilknyttede Azure-område. Firewallreglerne på gatewayserveren og/eller kundens proxyservere skal opdateres for at tillade udgående trafik fra gatewayserveren til nedenstående slutpunkter. Hvis din firewall ikke understøtter jokertegn, skal du bruge IP-adresserne fra Azure IP-intervaller og tjenestekoder. Bemærk, at de skal holdes synkroniseret hver måned.
Porte
Gatewayen kommunikerer på følgende udgående porte: TCP 443, 5671, 5672 og fra 9350 til og med 9354. Gatewayen kræver ikke indgående porte.
Vi anbefaler, at du tillader DNS (Domain Name System) "*.servicebus.windows.net". Hvis du vil have vejledning i, hvordan du konfigurerer din firewall og/eller proxy i det lokale miljø ved hjælp af fuldt kvalificerede domænenavne (FQDN'er) i stedet for at bruge IP-adresser, der kan ændres, skal du følge trinnene i Azure WCF Relay DNS Support.
Du kan også tillade IP-adresserne for dit dataområde i din firewall. Brug de JSON-filer, der er angivet nedenfor, og som opdateres ugentligt.
Du kan også få vist listen over påkrævede porte ved at udføre testen af netværksporte med jævne mellemrum i gatewayappen.
Gatewayen kommunikerer med Azure Relay ved hjælp af FQDN'er. Hvis du tvinger gatewayen til at kommunikere via HTTPS, bruger den kun FQDN'er og kommunikerer ikke ved hjælp af IP-adresser.
Bemærk
Ip-listen for Azure-datacenter viser IP-adresser i CIDR-notation (Classless Inter-Domain Routing). Et eksempel på denne notation er 10.0.0.0/24, hvilket ikke betyder fra 10.0.0.0 til 10.0.0.24. Få mere at vide om CIDR-notation.
På følgende liste beskrives de FQDN'er, der bruges af gatewayen. Disse slutpunkter er påkrævet, for at gatewayen kan fungere.
| Navne på offentlige clouddomæner | Udgående porte | Beskrivelse |
|---|---|---|
| *.download.microsoft.com | 80 | Bruges til at downloade installationsprogrammet. Gatewayappen bruger også dette domæne til at kontrollere versionen og gatewayområdet. |
| *.powerbi.com | 443 | Bruges til at identificere den relevante Power BI-klynge. |
| *.analysis.windows.net | 443 | Bruges til at identificere den relevante Power BI-klynge. |
| *.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com | 443 | Bruges til at godkende gatewayappen til Microsoft Entra ID og OAuth2. Bemærk, at der kan kræves yderligere URL-adresser som en del af logonprocessen for Microsoft Entra-id, som kan være entydig for en lejer. |
| *.servicebus.windows.net | 5671-5672 | Bruges til AMQP (Advanced Message Queuing Protocol). |
| *.servicebus.windows.net | 443 og 9350-9354 | Lytter på Azure Relay via TCP. Port 443 er påkrævet for at hente Azure Access Control-tokens. |
| *.msftncsi.com | 80 | Bruges til at teste internetforbindelsen, hvis Power BI-tjeneste ikke kan få forbindelse til gatewayen. |
| *.dc.services.visualstudio.com | 443 | Bruges af AppInsights til at indsamle telemetri. |
| *.frontend.clouddatahub.net | 443 | Påkrævet til udførelse af Fabric Pipeline. |
For GCC, GCC high og DoD bruges følgende FQDN'er af gatewayen.
| Porte | 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 | Gå til dokumentation | Gå til dokumentationen |
| 5671-5672 | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net |
| 443 og 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 |
For China Cloud (Mooncake) bruges følgende FQDN'er af gatewayen.
| Porte | China Cloud (Mooncake) |
|---|---|
| 80 | *.download.microsoft.com |
| 443 | *.powerbi.cn |
| 443 | *.asazure.chinacloudapi.cn |
| 443 | *.login.chinacloudapi.cn |
| 5671-5672 | *.servicebus.chinacloudapi.cn |
| 443 og 9350-9354 | *.servicebus.chinacloudapi.cn |
| 443 | *.chinacloudapi.cn |
| 443 | login.partner.microsoftonline.cn |
| 443 | Ingen Mooncake-ækvivalent – ikke påkrævet for at køre gatewayen – bruges kun til at kontrollere netværk under fejltilstande |
| 443 | Der bruges ingen mooncake-ækvivalenter under logon til Microsoft Entra-id. Du kan finde flere oplysninger om Microsoft Entra ID-slutpunkter ved at gå til Kontrollér slutpunkterne i Azure |
| 443 | applicationinsights.azure.cn |
| 433 | clientconfig.passport.net |
| 433 | aadcdn.msftauth.cn |
| 433 | aadcdn.msauth.cn |
Bemærk
Når gatewayen er installeret og registreret, er de eneste påkrævede porte og IP-adresser dem, der kræves af Azure Relay, som beskrevet for servicebus.windows.net i den foregående tabel. Du kan få vist listen over påkrævede porte ved at udføre testen Netværksporte med jævne mellemrum i gatewayappen. Du kan også tvinge gatewayen til at kommunikere ved hjælp af HTTPS.
Åbner porte til Fabric Dataflow Gen1 og Gen2 ved hjælp af gatewayen
Når en miksbaseret arbejdsbelastning (f.eks. semantiske modeller, Fabric-dataflow osv.) indeholder en forespørgsel, der opretter forbindelse til både datakilder i det lokale miljø (ved hjælp af en datagateway i det lokale miljø) og clouddatakilder, udføres hele forespørgslen på miksprogrammet for datagatewayen i det lokale miljø. Slutpunkter skal derfor være åbne for at gøre det muligt for datagatewayen i det lokale miljø i alle miksbaserede arbejdsbelastninger at have line of sight-adgang til clouddatakilderne for både datakilden og outputdestinationen.
Specielt til Fabric Dataflow Gen1 og Gen2 skal følgende slutpunkter også være åbne for at give datagatewayen i det lokale miljø adgang til Azure Data Lake og fabric-datakilderne i det midlertidige lakehouse-cloudmiljø.
| Navne på offentlige clouddomæner | Udgående porte | Beskrivelse |
|---|---|---|
| *.core.windows.net | 443 | Bruges af Dataflow Gen1 til at skrive data til Azure Data Lake. |
| *.dfs.fabric.microsoft.com | 1433 | Slutpunkt, der bruges af Dataflow Gen1 og Gen2 til at oprette forbindelse til OneLake. Få mere at vide |
| *.datawarehouse.pbidedicated.windows.net | 1433 | Gammelt slutpunkt, der bruges af Dataflow Gen2 til at oprette forbindelse til det midlertidige lakehouse. Få mere at vide |
| *.datawarehouse.fabric.microsoft.com | 1433 | Nyt slutpunkt, der bruges af Dataflow Gen2 til at oprette forbindelse til det midlertidige lakehouse. Få mere at vide |
Bemærk
*.datawarehouse.pbidedicated.windows.net erstattes af *.datawarehouse.fabric.microsoft.com. Under denne overgangsproces skal du sørge for at have begge slutpunkter åbne for at sikre, at Dataflow Gen2 opdateres.
Test af netværksporte
Sådan tester du, om gatewayen har adgang til alle påkrævede porte:
På den computer, der kører gatewayen, skal du angive "gateway" i Windows Search og derefter vælge appen Datagateway i det lokale miljø.
Vælg Diagnosticering. Under Test af netværksporte skal du vælge Start ny test.
Når din gateway kører testen af netværksporte, henter den en liste over porte og servere fra Azure Relay og forsøger derefter at oprette forbindelse til dem alle. Når linket Start ny test vises igen, er testen af netværksporte fuldført.
Oversigtsresultatet af testen er enten "Completed (Succeeded)" eller "Completed (Failed, see last test results)". Hvis testen lykkedes, oprettede gatewayen forbindelse til alle de påkrævede porte. Hvis testen mislykkedes, kan netværksmiljøet have blokeret de påkrævede porte og servere.
Bemærk
Firewalls tillader ofte med mellemrum trafik på blokerede websteder. Selvom en test lykkes, skal du muligvis stadig angive denne server på firewallen.
Hvis du vil have vist resultaterne af den senest fuldførte test, skal du vælge linket Åbn senest fuldførte testresultater . Testresultaterne åbnes i standardteksteditoren.
Testresultaterne viser alle de servere, porte og IP-adresser, som din gateway kræver. Hvis testresultaterne viser "Lukket" for alle porte som vist på følgende skærmbillede, skal du sørge for, at netværksmiljøet ikke blokerede disse forbindelser. Du skal muligvis kontakte netværksadministratoren for at åbne de nødvendige porte.
Gennemtving HTTPS-kommunikation med Azure Relay
Du kan tvinge gatewayen til at kommunikere med Azure Relay ved hjælp af HTTPS i stedet for direkte TCP.
Bemærk
Fra og med udgivelsen af gatewayen fra juni 2019 og baseret på anbefalinger fra Relay er nye installationer som standard HTTPS i stedet for TCP. Denne standardfunktionsmåde gælder ikke for opdaterede installationer.
Du kan bruge gatewayappen til at tvinge gatewayen til at anvende denne funktionsmåde. I gatewayappen skal du vælge Netværk og derefter aktivere HTTPS-tilstand.
Når du har foretaget denne ændring og derefter vælger Anvend, genstartes gatewaytjenesten i Windows automatisk, så ændringen kan træde i kraft. Knappen Anvend vises kun, når du foretager en ændring.
Hvis du vil genstarte Gateway Windows-tjenesten fra gatewayappen, skal du gå til Genstart en gateway.
Bemærk
Hvis gatewayen ikke kan kommunikere ved hjælp af TCP, bruger den automatisk HTTPS. Valget i gatewayappen afspejler altid den aktuelle protokolværdi.
TLS 1.3 til gatewaytrafik
Gatewayen bruger som standard TLS 1.3 (Transport Layer Security) til at kommunikere med Power BI-tjeneste. Hvis du vil sikre, at al gatewaytrafik bruger TLS 1.3, skal du muligvis tilføje eller ændre følgende registreringsdatabasenøgler på den computer, der kører gatewaytjenesten.
[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
Bemærk
Hvis du tilføjer eller ændrer disse registreringsdatabasenøgler, anvendes ændringen på alle .NET-programmer. Du kan få oplysninger om ændringer i registreringsdatabasen, der påvirker TLS for andre programmer, ved at gå til TLS-indstillinger (Transport Layer Security) i registreringsdatabasen.
Servicemærker
En tjenestekode repræsenterer en gruppe IP-adressepræfikser fra en given Azure-tjeneste. Microsoft administrerer de adressepræfikser, der er omfattet af tjenestekoden, og opdaterer automatisk tjenestekoden, når adresser ændres, så kompleksiteten af hyppige opdateringer af regler for netværkssikkerhed minimeres. Datagatewayen har afhængigheder af følgende tjenestekoder:
- PowerBI
- ServiceBus
- AzureActiveDirectory
- AzureCloud
Datagatewayen i det lokale miljø bruger Azure Relay til noget kommunikation. Der er dog ingen tjenestekoder til Azure Relay-tjenesten. ServiceBus-tjenestekoder er dog stadig påkrævet, fordi de stadig vedrører funktionen tjenestekøer og -emner, selvom de ikke er til Azure Relay.
AzureCloud-tjenestemærket repræsenterer alle globale IP-adresser til Azure Data Center. Da Azure Relay-tjenesten er bygget oven på Azure Compute, er offentlige Azure Relay-IP'er et undersæt af AzureCloud-IP'er. Flere oplysninger: Oversigt over Azure-tjenestetags