Ajustar as definições de comunicação do gateway de dados no local
Este artigo descreve várias configurações de comunicação associadas ao gateway de dados local. Essas configurações precisam ser ajustadas para oferecer suporte a conexões de fonte de dados e acesso de destino de saída.
Habilitar conexões de saída do Azure
O gateway depende do Azure Relay para conectividade na nuvem. O gateway estabelece conexões de saída correspondentemente para sua região do Azure associada.
Se você se registrou para um locatário do Power BI ou um locatário do Office 365, sua região do Azure assume como padrão a região desse serviço. Caso contrário, sua região do Azure pode ser a mais próxima de você.
Se um firewall bloquear conexões de saída, configure o firewall para permitir conexões de saída do gateway para sua região do Azure associada. As regras de firewall no servidor gateway e/ou nos servidores proxy do cliente precisam ser atualizadas para permitir o tráfego de saída do servidor gateway para os pontos de extremidade abaixo. Se o firewall não oferecer suporte a curingas, use os endereços IP dos Intervalos de IP e Tags de Serviço do Azure. Observe que eles precisarão ser mantidos em sincronia a cada mês.
Portas necessárias para que o gateway funcione
O gateway se comunica nas seguintes portas de saída: TCP 443, 5671, 5672 e de 9350 a 9354. O gateway não requer portas de entrada.
Para obter orientação sobre como configurar seu firewall e/ou proxy local usando FQDNs (nomes de domínio totalmente qualificados) em vez de usar endereços IP sujeitos a alterações, siga as etapas em Suporte a DNS de Retransmissão WCF do Azure.
Como alternativa, você permite os endereços IP da região de dados no firewall. Use os arquivos JSON listados abaixo, que são atualizados semanalmente.
Ou, você pode obter a lista de portas necessárias executando o teste de portas de rede periodicamente no aplicativo de gateway.
O gateway se comunica com o Azure Relay usando FQDNs. Se você forçar o gateway a se comunicar via HTTPS, ele usará estritamente apenas FQDNs e não se comunicará usando endereços IP.
Nota
A lista de IP do datacenter do Azure mostra endereços IP na notação CIDR (Roteamento entre Domínios sem Classe). Um exemplo dessa notação é 10.0.0.0/24, que não significa de 10.0.0.0 a 10.0.0.24. Saiba mais sobre a notação CIDR.
A lista a seguir descreve os FQDNs usados pelo gateway. Esses pontos de extremidade são necessários para que o gateway funcione.
| Nomes de domínio de nuvem pública | Portas de saída | Description |
|---|---|---|
| *.download.microsoft.com | 443 | Usado para baixar o instalador. O aplicativo de gateway também usa esse domínio para verificar a versão e a região do gateway. |
| *.powerbi.com | 443 | Usado para identificar o cluster relevante do Power BI. |
| *.analysis.windows.net | 443 | Usado para identificar o cluster relevante do Power BI. |
| *.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com | 443 | Usado para autenticar o aplicativo de gateway para Microsoft Entra ID e OAuth2. Observe que URLs adicionais podem ser necessárias como parte do processo de entrada do Microsoft Entra ID que pode ser exclusivo para um locatário. |
| *.servicebus.windows.net | 5671-5672 | Usado para AMQP (Advanced Message Queuing Protocol). |
| *.servicebus.windows.net | 443 e 9350-9354 | Escuta no Azure Relay sobre TCP. A porta 443 é necessária para obter tokens do Controle de Acesso do Azure. |
| *.msftncsi.com | 80 | Usado para testar a conectividade com a Internet se o serviço do Power BI não puder acessar o gateway. |
| *.dc.services.visualstudio.com | 443 | Usado pelo AppInsights para coletar telemetria. |
Para GCC, GCC high e DoD, os seguintes FQDNs são usados pelo gateway.
| Portas | GCC | GCC High | DoD |
|---|---|---|---|
| 443 | *.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 | Documentação Go Go | Ir para a documentação |
| 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 |
Para o China Cloud (Mooncake), os seguintes FQDNs são usados pelo gateway.
| Portas | Nuvem da China (Mooncake) |
|---|---|
| 443 | *.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 | Nenhum equivalente Mooncake — não necessário para executar o gateway — usado apenas para verificar a rede durante condições de falha |
| 443 | Nenhum equivalente do Mooncake — usado durante o login do Microsoft Entra ID. Para obter mais informações sobre os pontos de extremidade do Microsoft Entra ID, vá para Verificar os pontos de extremidade no Azure |
| 443 | applicationinsights.azure.cn |
| 433 | clientconfig.passport.net |
| 433 | aadcdn.msftauth.cn |
| 433 | aadcdn.msauth.cn |
Nota
Depois que o gateway é instalado e registrado, as únicas portas e endereços IP necessários são aqueles necessários para o Azure Relay, conforme descrito para servicebus.windows.net na tabela anterior. Você pode obter a lista de portas necessárias executando o teste de portas de rede periodicamente no aplicativo de gateway. Você também pode forçar o gateway a se comunicar usando HTTPS.
Portas necessárias para a execução de cargas de trabalho do Fabric
Quando uma carga de trabalho de malha (por exemplo, modelos semânticos ou fluxos de dados de malha) inclui uma consulta que se conecta a fontes de dados locais (por meio de um gateway de dados local) e fontes de dados em nuvem, toda a consulta é executada no gateway de dados local. Portanto, para executar um item de tarefa de trabalho do Fabric, os seguintes pontos de extremidade devem estar abertos para que o gateway de dados local tenha acesso direto às fontes de dados necessárias para a tarefa de trabalho.
| Nomes de domínio de nuvem pública | Portas de saída | Description |
|---|---|---|
| *.core.windows.net | 443 | Usado pelo Dataflow Gen1 para gravar dados no Azure Data Lake. |
| *.dfs.fabric.microsoft.com | 1433 | Ponto de extremidade usado pelo Dataflow Gen1 e Gen2 para se conectar ao OneLake. Mais informações |
| *.datawarehouse.pbidedicated.windows.net | 1433 | Endpoint antigo usado pelo Dataflow Gen2 para se conectar ao lago intermédio do Fabric. Mais informações |
| *.datawarehouse.fabric.microsoft.com | 1433 | Novo endpoint usado pelo Dataflow Gen2 para se conectar ao lakehouse de preparação do Fabric. Mais informações |
| *.frontend.clouddatahub.net | 443 | Necessário para a execução do pipeline do Fabric |
Nota
*.datawarehouse.pbidedicated.windows.net está a ser substituído por *.datawarehouse.fabric.microsoft.com. Durante esse processo de transição, certifique-se de ter ambos os pontos de extremidade abertos para garantir a atualização do Dataflow Gen2.
Além disso, quando quaisquer outras ligações de dados na nuvem (fontes de dados e destinos de saída) são utilizadas com uma ligação de fonte de dados local numa consulta de carga de trabalho, deve-se também abrir os pontos finais necessários para garantir que o gateway de dados local tenha acesso direto a essas fontes de dados na nuvem.
Teste de portas de rede
Para testar se o gateway tem acesso a todas as portas necessárias:
Na máquina que está executando o gateway, digite "gateway" na pesquisa do Windows e selecione o aplicativo Gateway de dados local.
Selecione Diagnóstico. Em Teste de portas de rede, selecione Iniciar novo teste.
Quando seu gateway executa o teste de portas de rede, ele recupera uma lista de portas e servidores do Azure Relay e, em seguida, tenta se conectar a todos eles. Quando o link Iniciar novo teste reaparecer, o teste de portas de rede foi concluído.
O resultado resumido do teste é "Concluído (Aprovado)" ou "Concluído (Reprovado, consulte os últimos resultados do teste)". Se o teste for bem-sucedido, seu gateway será conectado a todas as portas necessárias. Se o teste falhar, seu ambiente de rede pode ter bloqueado as portas e os servidores necessários.
Nota
Os firewalls geralmente permitem o tráfego intermitentemente em sites bloqueados. Mesmo que um teste seja bem-sucedido, talvez ainda seja necessário permitir esse servidor no firewall.
Para visualizar os resultados do último teste concluído, selecione o link Abrir os resultados do último teste concluído. Os resultados do teste são abertos no editor de texto padrão.
Os resultados do teste listam todos os servidores, portas e endereços IP que seu gateway exige. Se os resultados do teste exibirem "Fechado" para quaisquer portas, conforme mostrado na captura de tela a seguir, verifique se o ambiente de rede não bloqueou essas conexões. Talvez seja necessário entrar em contato com o administrador da rede para abrir as portas necessárias.
Forçar a comunicação HTTPS com o Azure Relay
Você pode forçar o gateway a se comunicar com o Azure Relay usando HTTPS em vez de TCP direto.
Nota
A partir da versão do gateway de junho de 2019 e com base nas recomendações do Relay, as novas instalações têm como padrão HTTPS em vez de TCP. Esse comportamento padrão não se aplica a instalações atualizadas.
Você pode usar o aplicativo de gateway para forçar o gateway a adotar esse comportamento. No aplicativo de gateway, selecione Rede e ative o modo HTTPS.
Depois de fazer essa alteração e selecionar Aplicar, o serviço de gateway do Windows é reiniciado automaticamente para que a alteração possa entrar em vigor. O botão Aplicar aparece somente quando você faz uma alteração.
Para reiniciar o serviço de gateway do Windows a partir do aplicativo de gateway, vá para Reiniciar um gateway.
Nota
Se o gateway não puder se comunicar usando TCP, ele usará automaticamente HTTPS. A seleção no aplicativo de gateway sempre reflete o valor do protocolo atual.
TLS 1.3 para tráfego de gateway
Por padrão, o gateway usa o Transport Layer Security (TLS) 1.3 para se comunicar com o serviço do Power BI. Para garantir que todo o tráfego de gateway use TLS 1.3, talvez seja necessário adicionar ou modificar as seguintes chaves do Registro na máquina que executa o serviço de 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
Adicionar ou modificar essas chaves do Registro aplica a alteração a todos os aplicativos .NET. Para obter informações sobre alterações no Registro que afetam o TLS para outros aplicativos, vá para Configurações do Registro TLS (Transport Layer Security).
Etiquetas de serviço
Uma marca de serviço representa um grupo de prefixos de endereço IP de um determinado serviço do Azure. A Microsoft gerencia os prefixos de endereço incluídos pela etiqueta de serviço e atualiza automaticamente a etiqueta de serviço à medida que os endereços mudam, minimizando a complexidade das atualizações frequentes das regras de segurança de rede. O gateway de dados tem dependências nas seguintes tags de serviço:
- Power BI
- ServiceBus
- AzureActiveDirectory
- AzureCloud
O gateway de dados local usa o Azure Relay para alguma comunicação. No entanto, não há marcas de serviço para o serviço Azure Relay. No entanto, as tags de serviço do ServiceBus ainda são necessárias porque ainda pertencem ao recurso de tópicos e filas de serviço, mesmo que não para o Azure Relay.
A marca de serviço AzureCloud representa todos os endereços IP globais do Data Center do Azure. Como o serviço Azure Relay é criado sobre o Azure Compute, os IPs públicos do Azure Relay são um subconjunto dos IPs do AzureCloud. Para obter mais informações: Visão geral das tags de serviço do Azure