Ajustar configurações de comunicação para gateway de dados local
Este artigo descreve várias configurações de comunicação associadas ao gateway de dados local. Essas configurações precisam ser ajustadas para dar suporte a conexões de fonte de dados e acesso de destino de saída.
Habilitar as conexões de saída do Azure
O gateway depende da Retransmissão do Azure para conectividade de nuvem. O gateway estabelece conexões de saída fazendo a correspondência com sua região do Azure associada.
Se você se registrou para um locatário do Power BI ou um locatário do Office 365, a região do Azure usará a região desse serviço como padrão. Caso contrário, a região do Azure será a mais próxima de você.
Se um firewall bloquear as conexões de saída, será necessário configurá-lo para permitir conexões de saída do gateway com a região do Azure associada. As regras de firewall no servidor de gateway e/ou nos servidores proxy do cliente precisam ser atualizadas para permitir o tráfego de saída do servidor de gateway para os pontos de extremidade abaixo. Se o firewall não der suporte a curingas, utilize os endereços IP de Intervalos de IP e marcas de Serviço do Azure. Observe que eles precisarão ser mantidos em sincronia todos os meses.
Portos
O gateway se comunica nas seguintes portas de saída: TCP 443, 5671, 5672 e de 9350 a 9354. O gateway não exige portas de entrada.
Recomendamos que você permita o DNS (Sistema de Nomes de Domínio) "*.servicebus.windows.net". Para obter diretrizes de como configurar o firewall e/ou o proxy local usando FQDNs (nomes de domínio totalmente qualificados) em vez de usar endereços IP que estão sujeitos a alterações, siga as etapas em Suporte ao DNS da Retransmissão do WCF do Azure.
Como alternativa, permita os endereços IP para sua região de dados no seu firewall. Use os arquivos JSON indicados abaixo, que são atualizados semanalmente.
Ou, obtenha lista de portas necessárias executando o teste de portas de rede periodicamente no aplicativo de gateway.
O gateway se comunica com a Retransmissão do Azure usando FQDNs. Se você forçar o gateway a se comunicar por HTTPS, ele usará somente FQDNs e não se comunicará usando endereços IP.
Observação
A lista de IPs do datacenter do Azure mostra os endereços IP na notação CIDR (Roteamento entre Domínios sem Classificação). Um exemplo dessa notação é 10.0.0.0/24, o 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 da nuvem pública | Portas de saída | Descrição |
|---|---|---|
| *.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 do Power BI relevante. |
| *.analysis.windows.net | 443 | Usado para identificar o cluster do Power BI relevante. |
| *.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com | 443 | Usado para autenticar o aplicativo de gateway para o 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 pelo AMQP (Advanced Message Queuing Protocol). |
| *.servicebus.windows.net | 443 e de 9350 a 9354 | Escuta na Retransmissão do Azure por TCP. A porta 443 é necessária para obter tokens de Controle de Acesso do Azure. |
| *.msftncsi.com | 80 | Usado para testar a conectividade da Internet quando o serviço do Power BI não consegue acessar o gateway. |
| *.dc.services.visualstudio.com | 443 | Usado pelo AppInsights para coletar a telemetria. |
| *.frontend.clouddatahub.net | 443 | Necessário para a execução do Pipeline do Fabric. |
Para GCC, GCC High e DoD, os FQDNs a seguir 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 | Acessar a documentação | Acessar a documentação |
| 5671-5672 | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net | *.servicebus.usgovcloudapi.net |
| 443 e de 9350 a 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 a nuvem da China (Mooncake), os FQDNs a seguir 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 de 9350 a 9354 | *.servicebus.chinacloudapi.cn |
| 443 | *.chinacloudapi.cn |
| 443 | login.partner.microsoftonline.cn |
| 443 | Sem equivalente ao Mooncake. Não é necessário para executar o gateway e é usado apenas para verificar a rede durante condições de falha |
| 443 | Nenhum equivalente ao Mooncake — usado durante a entrada do Microsoft Entra ID. Para obter mais informações sobre os pontos de extremidade do Microsoft Entra ID, acesse Verificar os pontos de extremidade no Azure |
| 443 | applicationinsights.azure.cn |
| 433 | clientconfig.passport.net |
| 433 | aadcdn.msftauth.cn |
| 433 | aadcdn.msauth.cn |
Observação
Depois que o gateway é instalado e registrado, as únicas portas e endereços IP necessários são os necessários para a Retransmissão do Azure, conforme a descrição de 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.
Abrindo portas para o Fabric Dataflow Gen1 e Gen2 usando o gateway
Quando qualquer carga de trabalho baseada em mashup (por exemplo, modelos semânticos, fluxos de dados de malha e assim por diante) contém uma consulta que se conecta a fontes de dados locais (usando um gateway de dados local) e fontes de dados na nuvem, toda a consulta é executada no mecanismo de mashup do gateway de dados local. Portanto, os pontos de extremidade devem ser abertos para permitir que o gateway de dados local em todas as cargas de trabalho baseadas em mashup tenha acesso de linha de visão às fontes de dados na nuvem para a fonte de dados e o destino de saída.
Especialmente para o Fabric Dataflow Gen1 e Gen2, os pontos de extremidade a seguir também devem estar abertos para permitir o acesso do gateway de dados local ao Azure Data Lake e às fontes de dados de nuvem do lakehouse de preparo do Fabric.
| Nomes de domínio de nuvem pública | Portas de saída | Descrição |
|---|---|---|
| *.core.windows.net | 443 | Usado pelo Dataflow Gen1 para gravar dados no Azure Data Lake. |
| *.dfs.fabric.microsoft.com | 1433 | Endpoint usado pelo Dataflow Gen1 e Gen2 para se conectar ao OneLake. Saiba mais |
| *.datawarehouse.pbidedicated.windows.net | 1433 | Ponto de extremidade antigo usado pelo Dataflow Gen2 para se conectar ao lakehouse de preparo. Saiba mais |
| *.datawarehouse.fabric.microsoft.com | 1433 | Novo ponto de extremidade usado pelo Dataflow Gen2 para se conectar ao lakehouse de preparo. Saiba mais |
Observação
*.datawarehouse.pbidedicated.windows.net será substituído por *.datawarehouse.fabric.microsoft.com. Durante esse processo de transição, certifique-se de que ambos os pontos de extremidade estejam abertos para garantir a atualização do Dataflow Gen2.
Teste de portas de rede
Para testar se o gateway tem acesso a todas as portas necessárias:
No computador que está executando o gateway, insira "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 o gateway executa o teste de portas de rede, ele recupera uma lista de portas e servidores da Retransmissão do Azure e tenta se conectar a todos eles. Quando o link Iniciar novo teste for exibido novamente, o teste de portas de rede terá sido concluído.
O resultado de resumo do teste é "Concluído (Bem-sucedido)" ou "Concluído (Com falha, confira os últimos resultados do teste)". Se o teste for bem-sucedido, o gateway terá se conectado a todas as portas necessárias. Se o teste falhar, o ambiente de rede poderá ter bloqueado as portas e os servidores necessários.
Observação
Com frequência, os firewalls permitem tráfego em sites bloqueados de maneira intermitente. Mesmo se um teste for bem-sucedido, ainda poderá ser necessário incluir o servidor na lista de permitidos no firewall.
Para ver os resultados do último teste concluído, selecione o link Abrir 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, as portas e os endereços IP que o gateway exige. Se os resultados do teste exibirem "Fechado" para qualquer porta, 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 comunicação HTTPS com a Retransmissão do Azure
Você pode forçar o gateway a se comunicar com a Retransmissão do Azure usando HTTPS em vez de TCP direto.
Observação
Começando com a versão do gateway de junho de 2019 e com base nas recomendações da Retransmissão, as novas instalações usam HTTPS como padrão 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 que você fizer essa alteração e selecionar Aplicar, o serviço Windows de gateway será reiniciado automaticamente para que a alteração entre em vigor. O botão Aplicar aparece somente quando você faz uma alteração.
Para reiniciar o serviço Windows de gateway por meio do aplicativo de gateway, confira Reiniciar um gateway.
Observação
Se o gateway não puder se comunicar usando TCP, ele usará HTTPS automaticamente. 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 TLS (Transport Layer Security) 1.3 para se comunicar com o serviço do Power BI. Para garantir que todo o tráfego de gateway use o TLS 1.3, talvez seja necessário adicionar ou modificar as seguintes chaves do Registro no computador 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
Observação
A adição ou modificação dessas chaves do Registro aplica a alteração a todos os aplicativos .NET. Para obter informações sobre as alterações no registro que afetam o TLS em outros aplicativos, consulte Configurações do Registro do protocolo TLS.
Marcas 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 englobados pela marca de serviço e atualiza automaticamente a marca de serviço em caso de alteração de endereços, minimizando a complexidade de atualizações frequentes das regras de segurança de rede. O gateway de dados depende das seguintes marcas de serviço:
- PowerBI
- ServiceBus
- AzureActiveDirectory
- AzureCloud
O gateway de dados local usa a Retransmissão do Azure para comunicação. No entanto, não há marcas de serviço para o serviço Retransmissão do Azure. As marcas de serviço do ServiceBus ainda são necessárias, embora se apliquem ao recurso de filas e tópicos do serviço, mesmo que não para a Retransmissão do Azure.
A marca de serviço AzureCloud representa todos os endereços IP globais do datacenter do Azure. Como o serviço Retransmissão do Azure é criado com base na Computação do Azure, os IPs públicos da Retransmissão do Azure são um subconjunto dos IPs do AzureCloud. Mais informações: Visão geral das marcas de serviço do Azure