Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 ao destino de saída.
Habilitar as conexões de saída do Azure
O gateway depende do Azure Relay para conexão com a nuvem. O gateway estabelece, respectivamente, conexões de saída com a 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, sua região do Azure pode 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, use 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.
Portas necessárias para a função do gateway
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.
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 via HTTPS, ele usará apenas 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 o funcionamento do gateway.
| Nomes de domínio da nuvem pública | Portas de saída | Descrição |
|---|---|---|
| *.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 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 no Microsoft Entra ID e podem ser exclusivas para um locatário (tenant). |
| *.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 via 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. |
| ecs.office.com | 443 | Usado para a configuração do ECS para habilitar os recursos do Mashup. |
Para o Government Community Cloud (GCC), o Government Community Cloud High (GCC high) e o Departamento de Defesa (DoD), os FQDNs a seguir são usados pelo gateway.
| Portos | 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 | 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 |
| 443 | gccmod.ecs.office.com | config.ecs.gov.teams.microsoft.us | config.ecs.dod.teams.microsoft.us |
Para a Nuvem China (Mooncake), os seguintes FQDNs são usados pelo gateway.
| Portos | 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 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 | Sem equivalente do 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 |
| 443 | clientconfig.passport.net |
| 443 | aadcdn.msftauth.cn |
| 443 | aadcdn.msauth.cn |
| 443 | mooncake.ecs.office.com |
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.
Portas necessárias para executar cargas de trabalho do Fabric
Quando uma carga de trabalho do Fabric (por exemplo, modelos semânticos ou fluxos de dados do Fabric) inclui uma consulta que se conecta a fontes de dados locais (por meio de um gateway de dados local) e fontes de dados de nuvem, toda a consulta é executada no gateway de dados local. Portanto, para executar um item de carga 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 carga de trabalho:
| 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 | 443 | 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 Fluxo de Dados Gen2 para se conectar ao lakehouse de preparo do Fabric. Saiba mais |
| *.datawarehouse.fabric.microsoft.com | 1433 | Novo ponto de extremidade usado pelo Fluxo de Dados Gen2 para conectar-se ao lakehouse de preparo do Fabric. Saiba mais |
| *.frontend.clouddatahub.net | 443 | Obrigatório para a execução do Pipeline do Fabric |
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.
Além disso, quando outras conexões de dados na nuvem (tanto fontes de dados quanto destinos de saída) forem usadas com uma conexão de fonte de dados local em uma consulta de carga de trabalho, você também deverá abrir os pontos de extremidade 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:
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 do teste é "Concluído (Bem-sucedido)" ou "Concluído (Insatisfatório, verifique 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 adicionar o servidor à lista de permissões 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 o Relay do Azure
Você pode obrigar o gateway a se comunicar com o Azure Relay 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 do gateway no aplicativo gateway, acesse 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.
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 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 tem dependências dos seguintes rótulos de serviço:
- PowerBI
- ServiceBus
- AzureActiveDirectory
- AzureCloud
O gateway de dados local usa o Azure Relay para parte da comunicação. No entanto, não há tags de serviço para o Azure Relay. Os rótulos de serviço do ServiceBus ainda são obrigatórios porque ainda se referem 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