Configurazione delle impostazioni di comunicazione per il gateway dati locale

Questo articolo descrive diverse impostazioni di comunicazione associate al gateway dati locale. Queste impostazioni devono essere modificate per supportare le connessioni all'origine dati e l'accesso alla destinazione di output.

Abilitare le connessioni di Azure in uscita

Il gateway si basa su Inoltro di Azure per la connettività cloud. Il gateway stabilisce in modo corrispondente le connessioni in uscita all'area di Azure associata.

Se si è registrati per un tenant di Power BI o per un tenant di Office 365, l'area di Azure per impostazione predefinita corrisponde all'area del servizio. In caso contrario, l'area di Azure potrebbe essere quella più vicina.

Se un firewall blocca le connessioni in uscita, configurare il firewall per consentire le connessioni in uscita dal gateway all'area di Azure associata. Le regole del firewall nel server gateway e/o nei server proxy del cliente devono essere aggiornate per consentire il traffico in uscita dal server gateway agli endpoint seguenti. Se il firewall non supporta i caratteri jolly, usare gli indirizzi IP degli intervalli IP di Azure e i tag di servizio. Si noti che dovranno essere mantenuti sincronizzati ogni mese.

Porti

Il gateway comunica sulle porte in uscita seguenti: TCP 443, 5671, 5672 e da 9350 a 9354. Non sono richieste porte in ingresso.

È consigliabile consentire il dns (Domain Name System) "*.servicebus.windows.net". Per indicazioni su come configurare il firewall locale e/o il proxy usando nomi di dominio completi (FQDN) anziché usare indirizzi IP soggetti a modifiche, seguire la procedura descritta in Supporto DNS di inoltro WCF di Azure.

In alternativa, è possibile consentire gli indirizzi IP per l'area dati nel firewall. Usare i file JSON elencati di seguito, che vengono aggiornati settimanalmente.

In alternativa, è possibile ottenere l'elenco delle porte necessarie eseguendo periodicamente il test delle porte di rete nell'app gateway.

Il gateway comunica con Inoltro di Azure usando FQDN. Se si forza il gateway a comunicare tramite HTTPS, userà esclusivamente FQDN e non comunicherà usando indirizzi IP.

Nota

L'elenco ip del data center di Azure mostra gli indirizzi IP nella notazione CIDR (Classless Inter-Domain Routing). Un esempio di questa notazione è 10.0.0.0/24, che non significa da 10.0.0.0 a 10.0.0.0.24. Altre informazioni sulla notazione CIDR.

L'elenco seguente descrive i nomi di dominio completi usati dal gateway. Questi endpoint sono necessari per il funzionamento del gateway.

Nomi di dominio cloud pubblico Porte in uscita Descrizione
*.download.microsoft.com 80 Usato per scaricare il programma di installazione. L'app gateway usa anche questo dominio per controllare la versione e l'area del gateway.
*.powerbi.com 443 Usato per identificare il cluster di Power BI pertinente.
*.analysis.windows.net 443 Usato per identificare il cluster di Power BI pertinente.
*.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com 443 Usato per autenticare l'app gateway per Microsoft Entra ID e OAuth2. Si noti che potrebbero essere necessari URL aggiuntivi come parte del processo di accesso di Microsoft Entra ID che può essere univoco per un tenant.
*.servicebus.windows.net 5671-5672 Usato per il protocollo AMQP (Advanced Message Queuing Protocol).
*.servicebus.windows.net 443 e 9350-9354 È in ascolto su Inoltro di Azure su TCP. La porta 443 è necessaria per ottenere i token di Controllo di accesso di Azure.
*.msftncsi.com 80 Usato per testare la connettività Internet se il servizio Power BI non riesce a raggiungere il gateway.
*.dc.services.visualstudio.com 443 Usato da AppInsights per raccogliere i dati di telemetria.
*.frontend.clouddatahub.net 443 Obbligatorio per l'esecuzione della pipeline di infrastruttura.

Per GCC, GCC high e DoD, i nomi di dominio completi seguenti vengono usati dal gateway.

Porti 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 Documentazione di Go Go Passare alla documentazione
5671-5672 *.servicebus.usgovcloudapi.net *.servicebus.usgovcloudapi.net *.servicebus.usgovcloudapi.net
443 e 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

Per Cloud Cina (Mooncake), i nomi di dominio completi seguenti vengono usati dal gateway.

Porti Cloud Cina (Mooncake)
80 *.download.microsoft.com
443 *.powerbi.cn
443 *.asazure.chinacloudapi.cn
443 *.login.chinacloudapi.cn
5671-5672 *.servicebus.chinacloudapi.cn
443 e 9350-9354 *.servicebus.chinacloudapi.cn
443 *.chinacloudapi.cn
443 login.partner.microsoftonline.cn
443 Nessun equivalente mooncake, non necessario per eseguire il gateway, usato solo per controllare la rete durante le condizioni di errore
443 Nessun equivalente Mooncake: usato durante l'accesso con l'ID Entra di Microsoft. Per altre informazioni sugli endpoint di Microsoft Entra ID, vedere Controllare gli endpoint in Azure
443 applicationinsights.azure.cn
433 clientconfig.passport.net
433 aadcdn.msftauth.cn
433 aadcdn.msauth.cn

Nota

Dopo l'installazione e la registrazione del gateway, le uniche porte e indirizzi IP necessari sono quelle necessarie per Inoltro di Azure, come descritto per servicebus.windows.net nella tabella precedente. È possibile ottenere l'elenco delle porte necessarie eseguendo periodicamente il test delle porte di rete nell'app gateway. È anche possibile forzare il gateway a comunicare tramite HTTPS.

Apertura di porte aggiuntive per Dataflow Gen1 e Gen2 tramite OPDG

In Dataflow Gen1 e Gen2 all'interno di Fabric Data Factory, quando una query Mashup combina un'origine dati locale (connessa tramite un gateway dati locale) con un'origine dati cloud, l'intera query viene eseguita nel gateway dati locale. Di conseguenza, i puntini di chiusura seguenti devono essere aperti per consentire l'accesso line-of-sight del gateway dati locale alle origini dati cloud.

Nomi di dominio cloud pubblico Porte in uscita Descrizione
*.core.windows.net 443 Usato da Dataflow Gen1 per scrivere dati in Azure Data Lake.
*.datawarehouse.pbidedicated.windows.net 1433 Endpoint precedente di Dataflow Gen2 per connettersi al lakehouse di staging. Ulteriori informazioni
*.datawarehouse.fabric.microsoft.com 1433 Nuovo endpoint usato da Dataflow Gen2 per connettersi al lakehouse di staging. Ulteriori informazioni
*.dfs.fabric.microsoft.com 1433 Endpoint usato da Dataflow Gen2 per connettersi a OneLake.

Nota

*.datawarehouse.pbidedicated.windows.net viene sostituito da *.datawarehouse.fabric.microsoft.com. Durante questo processo di transizione assicurarsi che entrambi gli endpoint siano aperti per garantire l'aggiornamento di Dataflow Gen2.

Test delle porte di rete

Per verificare se il gateway ha accesso a tutte le porte necessarie:

  1. Nel computer che esegue il gateway immettere "gateway" in Ricerca di Windows e quindi selezionare l'app gateway dati locale.

  2. Selezionare Diagnostica. In Test porte di rete selezionare Avvia nuovo test.

    Come avviare un nuovo test delle porte di rete.

Quando il gateway esegue il test delle porte di rete, recupera un elenco di porte e server da Inoltro di Azure e quindi tenta di connettersi a tutti. Quando viene visualizzato nuovamente il collegamento Avvia nuovo test , il test delle porte di rete è terminato.

Il risultato di riepilogo del test è "Completed (Succeeded)" o "Completed (Failed, see last test results)". Se il test ha avuto esito positivo, il gateway è connesso a tutte le porte necessarie. Se il test non è riuscito, l'ambiente di rete potrebbe aver bloccato le porte e i server necessari.

Nota

I firewall spesso consentono il traffico su siti bloccati. Anche se un test ha esito positivo, potrebbe essere comunque necessario consentire tale server nel firewall.

Per visualizzare i risultati dell'ultimo test completato, selezionare il collegamento Apri i risultati dell'ultimo test completato. I risultati del test si aprono nell'editor di testo predefinito.

I risultati del test elencano tutti i server, le porte e gli indirizzi IP richiesti dal gateway. Se i risultati del test visualizzano "Chiuso" per qualsiasi porta, come illustrato nello screenshot seguente, assicurarsi che l'ambiente di rete non blocchi tali connessioni. Potrebbe essere necessario contattare l'amministratore di rete per aprire le porte necessarie.

Risultati dei test visualizzati in Blocco note.

Forzare la comunicazione HTTPS con Inoltro di Azure

È possibile forzare il gateway a comunicare con Inoltro di Azure usando HTTPS anziché TCP diretto.

Nota

A partire dalla versione del gateway di giugno 2019 e in base alle raccomandazioni di Inoltro, le nuove installazioni predefinite sono HTTPS anziché TCP. Questo comportamento predefinito non si applica alle installazioni aggiornate.

È possibile usare l'app gateway per imporre al gateway di adottare questo comportamento. Nell'app gateway selezionare Rete e quindi attivare la modalità HTTPS.

Impostazione della modalità HTTPS.

Dopo aver apportato questa modifica e quindi selezionare Applica, il servizio Windows gateway viene riavviato automaticamente in modo che la modifica possa essere applicata. Il pulsante Applica viene visualizzato solo quando si apporta una modifica.

Per riavviare il servizio Windows gateway dall'app gateway, passare a Riavvia un gateway.

Nota

Se il gateway non riesce a comunicare tramite TCP, usa automaticamente HTTPS. La selezione nell'app gateway riflette sempre il valore del protocollo corrente.

TLS 1.3 per il traffico del gateway

Per impostazione predefinita, il gateway usa Transport Layer Security (TLS) 1.3 per comunicare con il servizio Power BI. Per garantire che tutto il traffico del gateway usi TLS 1.3, potrebbe essere necessario aggiungere o modificare le chiavi del Registro di sistema seguenti nel computer che esegue il servizio gateway.

[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

Nota

L'aggiunta o la modifica di queste chiavi del Registro di sistema applica la modifica a tutte le applicazioni .NET. Per informazioni sulle modifiche del Registro di sistema che influiscono su TLS per altre applicazioni, vedere Impostazioni del Registro di sistema tls (Transport Layer Security).

Tag di servizio

Un tag del servizio rappresenta un gruppo di prefissi di indirizzi IP di un determinato servizio di Azure. Microsoft gestisce i prefissi di indirizzo inclusi nel tag del servizio e aggiorna automaticamente il tag in base alla modifica degli indirizzi, riducendo la complessità degli aggiornamenti frequenti alle regole di sicurezza di rete. Il gateway dati presenta dipendenze dai tag di servizio seguenti:

  • PowerBI
  • Bus di servizio
  • AzureActiveDirectory
  • AzureCloud

Il gateway dati locale usa Inoltro di Azure per alcune comunicazioni. Tuttavia, non sono presenti tag di servizio per il servizio inoltro di Azure. I tag del servizio ServiceBus sono comunque necessari perché riguardano ancora la funzionalità code e argomenti del servizio, anche se non per Inoltro di Azure.

Il tag del servizio AzureCloud rappresenta tutti gli indirizzi IP globali del data center di Azure. Poiché il servizio di inoltro di Azure si basa su Calcolo di Azure, gli indirizzi IP pubblici di Inoltro di Azure sono un subset degli indirizzi IP di AzureCloud. Altre informazioni: Panoramica dei tag del servizio di Azure

Passaggi successivi