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

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.

Recomendamos que você habilite o Sistema de Nomes de Domínio (DNS) "*.servicebus.windows.net". 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 80 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.
*.frontend.clouddatahub.net 443 Necessário para a execução do Pipeline de malha.
*.datawarehouse.pbidedicated.windows.net 1433 Ponto de extremidade antigo usado pelo Dataflow Gen2 para se conectar à casa do lago de preparação. Mais informações
*.datawarehouse.fabric.microsoft.com 1433 Novo ponto de extremidade usado pelo Dataflow Gen2 para se conectar ao lago de preparação. Mais informações

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.

Para GCC, GCC high e DoD, os seguintes FQDNs são usados pelo gateway.

Portas 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 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)
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 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.

Abertura de portas para cargas de trabalho baseadas em Mashup de malha conectando-se a fontes de dados locais e na nuvem ao usar o OPDG.

No Fabric, quando uma carga de trabalho baseada em mashup (por exemplo, modelo semântico, fluxo de dados, etc.) contém consulta que se conecta a fontes de dados locais (conectadas por meio de um gateway de dados local) e também se conecta a fontes de dados na nuvem, toda a consulta é executada no mecanismo de mashup do gateway de dados local. Portanto, os endpints a seguir devem estar abertos para permitir o acesso da linha de visão do On-premises Data Gateway às fontes de dados em nuvem.

Nomes de domínio de nuvem pública Portas de saída Description
*.core.windows.net 443 Usado para gravar dados no Azure Data Lake.
*.dfs.fabric.microsoft.com 1433 Ponto de extremidade usado para se conectar ao OneLake.

Teste de portas de rede

Para testar se o gateway tem acesso a todas as portas necessárias:

  1. Na máquina que está executando o gateway, digite "gateway" na pesquisa do Windows e selecione o aplicativo Gateway de dados local.

  2. Selecione Diagnóstico. Em Teste de portas de rede, selecione Iniciar novo teste.

    Como iniciar um novo teste de portas de rede.

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.

Resultados do teste mostrados no Bloco de Notas.

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.

Definindo 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

Próximos passos