Compartir por


Ajuste de la configuración de comunicación para la puerta de enlace de datos local

Este artículo describe varias configuraciones de comunicación asociadas con la puerta de enlace de datos local. Esta configuración debe ajustarse para admitir conexiones de origen de datos y acceso de destino de salida.

Habilitar las conexiones salientes de Azure

La puerta de enlace se basa en Azure Relay para la conectividad en la nube. La puerta de enlace establece las conexiones de salida correspondientes a la región de Azure asociada.

Si se registró para un inquilino de Power BI o un inquilino de Office 365, su región de Azure por defecto es la región de ese servicio. De lo contrario, la región de Azure podría ser la más cercana a usted.

Si un firewall bloquea las conexiones salientes, debe configurar el firewall para permitir conexiones salientes desde la puerta de enlace para su región de Azure asociada. Es necesario actualizar las reglas de firewall en el servidor de la puerta de enlace y/o en los servidores proxy del cliente para permitir el tráfico saliente desde el servidor de puerta de enlace a los puntos de conexión indicados a continuación. Si su firewall no admite comodines, utilice las direcciones IP de las Etiquetas de servicio y rangos de IP de Azure. Tenga en cuenta que deben mantenerse sincronizados cada mes.

Puertos

La puerta de enlace se comunica en los siguientes puertos de salida: TCP 443, 5671, 5672 y desde 9350 hasta 9354. La puerta de enlace no requiere puertos de entrada.

Le recomendamos que permita el servicio de nombres de dominio (DNS) "*.servicebus.windows.net". Para obtener orientación sobre cómo configurar el firewall y/o el proxy local usando nombres de dominio completos (FQDN) en lugar de usar direcciones IP que están sujetas a cambios, siga los pasos en Compatibilidad con DNS de Azure WCF Relay.

Otra opción es incluir las direcciones IP de su región de datos en la lista de permitidos del firewall. Utilice los archivos JSON que se enumeran a continuación, que se actualizan semanalmente.

O bien, puede obtener la lista de puertos necesarios realizando la prueba de puertos de red periódicamente en la aplicación de puerta de enlace.

La puerta de enlace se comunica con Azure Relay mediante FQDN. Si fuerza a la puerta de enlace a comunicarse a través de HTTPS, utilizará estrictamente solo los FQDN y no se comunicará utilizando direcciones IP.

Nota:

La lista de IP del centro de datos de Azure muestra las direcciones IP en notación de enrutamiento entre dominios sin clase (CIDR). Un ejemplo de esta notación es 10.0.0.0/24, que no significa desde 10.0.0.0 hasta 10.0.0.24. Más información sobre la notación CIDR.

La siguiente lista describe los FQDN utilizados por la puerta de enlace. Estos puntos de conexión son necesarios para que la puerta de enlace funcione.

Nombres de dominio de nube pública Puertos de salida Descripción
download.Microsoft.com 80 Se utiliza para descargar al instalador. La aplicación de la puerta de enlace también usa este dominio para comprobar la versión y la región de la puerta de enlace.
*.powerbi.com 443 Se usa para identificar el clúster de Power BI correspondiente.
*.analysis.windows.net 443 Se usa para identificar el clúster de Power BI correspondiente.
*.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com 443 Se usa para autenticar la aplicación de puerta de enlace para Microsoft Entra ID y OAuth2. Tenga en cuenta que se podrían requerir direcciones URL adicionales como parte del proceso de inicio de sesión de Microsoft Entra ID que puede ser único para un inquilino.
*.servicebus.windows.net 5671-5672 Se utiliza para el protocolo Advanced Message Queuing Protocol (AMQP).
*.servicebus.windows.net 443 y 9350-9354 Escucha en Azure Relay a través de TCP. Se requiere el puerto 443 para obtener los tokens de Azure Access Control.
*.msftncsi.com 80 Se usa para probar la conectividad a Internet si el servicio Power BI no puede llegar a la puerta de enlace.
*.dc.services.visualstudio.com 443 Usado por AppInsights para recopilar datos de telemetría.
*.frontend.clouddatahub.net 443 Necesario para la ejecución de la canalización de Fabric.

Para GCC, GCC high y DoD, la puerta de enlace utiliza los siguientes FQDN.

Puertos 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 Ir a la documentación Ir a la documentación
5671-5672 *.servicebus.usgovcloudapi.net *.servicebus.usgovcloudapi.net *.servicebus.usgovcloudapi.net
443 y 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 China Cloud (Mooncake), la puerta de enlace utiliza los siguientes FQDN.

Puertos China Cloud (Mooncake)
80 download.Microsoft.com
443 *.powerbi.cn
443 *.asazure.chinacloudapi.cn
443 *.login.chinacloudapi.cn
5671-5672 *.servicebus.chinacloudapi.cn
443 y 9350-9354 *.servicebus.chinacloudapi.cn
443 *. chinacloudapi.cn
443 login.partner.microsoftonline.cn
443 Sin equivalente de Mooncake, no es necesario para ejecutar la puerta de enlace, solo se usa para comprobar la red durante condiciones de error
443 No hay equivalente de Mooncake: se usa durante el inicio de sesión de Microsoft Entra ID. Para más información sobre los puntos de conexión de Microsoft Entra ID, vaya a Comprobación de los puntos de conexión en Azure
443 applicationinsights.azure.cn
433 clientconfig.passport.net
433 aadcdn.msftauth.cn
433 aadcdn.msauth.cn

Nota:

Después de instalar y registrar la puerta de enlace, los únicos puertos y direcciones IP requeridos son los que necesita Azure Relay, como se describe para servicebus.windows.net en la tabla anterior. Puede obtener la lista de puertos necesarios realizando la prueba de puertos de red periódicamente en la aplicación de puerta de enlace. También puede forzar la puerta de enlace a comunicarse mediante HTTPS.

Apertura de puertos para Fabric Dataflow Gen1 y Gen2 mediante la puerta de enlace

Cuando cualquier carga de trabajo basada en mashup (por ejemplo, modelos semánticos, flujos de datos de Fabric, etc.) contiene una consulta que se conecta a orígenes de datos locales (mediante una puerta de enlace de datos local) y orígenes de datos en la nube, toda la consulta se ejecuta en el motor de mashup de la puerta de enlace de datos local. Por lo tanto, los puntos de conexión deben estar abiertos para permitir que la puerta de enlace de datos local en todas las cargas de trabajo basadas en mashup tenga acceso de línea de visión a los orígenes de datos en la nube para el origen de datos y el destino de salida.

Especialmente para Fabric Dataflow Gen1 y Gen2, los siguientes puntos de conexión también deben estar abiertos para permitir el acceso a la puerta de enlace de datos local a Azure Data Lake y a los orígenes de datos en la nube de Fabric Staging Lakehouse.

Nombres de dominio de nube pública Puertos de salida Descripción
*.core.windows.net 443 Usado por Dataflow Gen1 para escribir datos en Azure Data Lake.
*.dfs.fabric.microsoft.com 1433 Punto de conexión usado por Dataflow Gen1 y Gen2 para conectarse a OneLake. Más información
*.datawarehouse.pbidedicated.windows.net 1433 Antiguo punto de conexión usado por Dataflow Gen2 para conectarse al almacenamiento provisional del almacén de lago. Más información
*.datawarehouse.fabric.microsoft.com 1433 Nuevo punto de conexión usado por Dataflow Gen2 para conectarse al almacenamiento provisional del almacén de lago. Más información

Nota:

*.datawarehouse.pbidedicated.windows.net se reemplaza por *.datawarehouse.fabric.microsoft.com. Durante este proceso de transición, asegúrese de que ambos puntos de conexión estén abiertos para garantizar la actualización de Dataflow Gen2.

Prueba de puertos de red

Para probar si la puerta de enlace tiene acceso a todos los puertos requeridos:

  1. En la máquina que ejecuta la puerta de enlace, ingrese "puerta de enlace" en la búsqueda de Windows y luego seleccione la aplicación Puerta de enlace de datos local.

  2. Haga clic en Diagnósticos. Debajo de Prueba de puertos de red, seleccione Iniciar nueva prueba.

    Cómo iniciar una nueva prueba de puertos de red.

Cuando la puerta de enlace ejecuta la prueba de puertos de red, recupera una lista de puertos y servidores de Azure Relay y después intenta conectarse a todos ellos. Cuando vuelve a aparecer el vínculo Iniciar nueva prueba, la prueba de puertos de red ha terminado.

El resultado resumido de la prueba es "Completado (correcto)" o "Completado (error, consulte los resultados de la última prueba)". Si la prueba se ha realizado, la puerta de enlace se ha conectado correctamente con todos los puertos necesarios. Si la prueba ha producido algún error, el entorno de red podría haber bloqueado los servidores y puertos necesarios.

Nota:

Los firewalls a menudo permiten el tráfico de forma intermitente en sitios bloqueados. Incluso si una prueba es correcta, es posible que deba incluir en la lista de permitidos ese servidor en su firewall.

Para ver los resultados de la última prueba completada, haga clic en el vínculo Abrir resultados de la última prueba completada, tal como se muestra a continuación. Los resultados de la prueba se abren en su editor de texto predeterminado.

En los resultados de la prueba aparecen todos los servidores, puertos y direcciones IP que requiere la puerta de enlace. Si los resultados de la prueba muestran "Cerrado" para alguno de los puertos, como se muestra en la siguiente captura de pantalla, asegúrese de que el entorno de red no haya bloqueado esas conexiones. Es posible que deba ponerse en contacto con su administrador de red para abrir los puertos necesarios.

Los resultados de la prueba se muestran en el Bloc de notas.

Forzar la comunicación HTTPS con Azure Relay

Puede obligar a la puerta de enlace a comunicarse con Azure Relay a través de HTTPS en vez de TCP directo.

Nota:

A partir de la versión de junio de 2019 de la puerta de enlace y, a partir de las recomendaciones de Relay, las nuevas instalaciones utilizan de forma predeterminada HTTPS en lugar de TCP. Este comportamiento predeterminado no se aplica a las instalaciones actualizadas.

Puede usar la aplicación de puerta de enlace para hacer que la puerta de enlace adopte este comportamiento. En la aplicación de puerta de enlace, seleccione Red y luego active el Modo HTTPS.

Establecer el modo HTTPS.

Después de hacer este cambio y seleccionar Aplicar, el servicio de puerta de enlace de Windows se reinicia automáticamente para que el cambio surta efecto. El botón Aplicar aparece solo cuando se realiza un cambio.

Para reiniciar el servicio de puerta de enlace de Windows desde la aplicación de puerta de enlace, vaya a Reiniciar una puerta de enlace.

Nota:

Si la puerta de enlace no puede comunicarse usando TCP, automáticamente usa HTTPS. La selección en la aplicación de puerta de enlace siempre refleja el valor del protocolo actual.

TLS 1.3 para el tráfico de puerta de enlace

De forma predeterminada, la puerta de enlace usa la seguridad de capa de transporte (TLS) 1.3 para comunicarse con el servicio Power BI. Para asegurarse de que todo el tráfico de puerta de enlace usa TLS 1.3, es posible que necesite agregar o modificar las siguientes claves del Registro en la máquina que ejecuta el servicio de puerta de enlace.

[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:

Agregar o modificar estas claves de registro permite aplicar el cambio a todas las aplicaciones. NET. Para más información acerca de los cambios del registro que afectan a TLS para otras aplicaciones, consulte Configuración del registro de seguridad de la capa de transporte (TLS).

Etiquetas de servicio

Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio de Azure determinado. Microsoft administra los prefijos de direcciones que la etiqueta de servicio incluye y actualiza automáticamente dicha etiqueta a medida que las direcciones cambian, lo que minimiza la complejidad de las actualizaciones frecuentes en las reglas de seguridad de red. La puerta de enlace de datos depende de las siguientes etiquetas de servicio:

  • PowerBI
  • ServiceBus
  • AzureActiveDirectory
  • AzureCloud

La puerta de enlace de datos local usa Azure Relay para algunas comunicaciones. Sin embargo, no hay etiquetas de servicio para el servicio Azure Relay. Las etiquetas de servicio ServiceBus siguen siendo necesarias, ya que siguen pertenecen a la característica de colas y temas de servicio, aunque no para Azure Relay.

La etiqueta de servicio AzureCloud representa todas las direcciones IP globales de Centro de datos de Azure. Dado que el servicio Azure Relay se basa en Azure Compute, las IP públicas de Azure Relay son un subconjunto de las IP de AzureCloud. Más información: Descripción general de etiuetas de servicio de Azure

Pasos siguientes