Compartir a través de


Configuración de los valores de proxy para la puerta de enlace de datos local

Es posible que el entorno de trabajo requiera que pase por un proxy para acceder a Internet. Este requisito podría impedir que la puerta de enlace de datos local de Microsoft se conecte al servicio.

En la siguiente entrada de superuser.com se describe cómo puede intentar determinar si tiene un proxy en la red: ¿Cómo sé qué servidor proxy estoy usando? (SuperUser.com).

Aunque la mayoría de las opciones de configuración de puerta de enlace se pueden cambiar mediante la aplicación de puerta de enlace de datos local, la información de proxy se configura dentro de un archivo de configuración de .NET. La ubicación y los nombres de archivo son diferentes, en función de la puerta de enlace que use.

Hay cuatro archivos de configuración asociados al uso de un proxy con la puerta de enlace de datos local. Los dos archivos de configuración principales siguientes se aplican a la puerta de enlace y a su proceso de configuración.

  • El primer archivo es para las pantallas de configuración que configuran realmente la puerta de enlace. Si tiene problemas para configurar la puerta de enlace, examine el siguiente archivo: C:\Program Files\On-premises data gateway\enterprisegatewayconfigurator.exe.config. En la puerta de enlace de datos local (modo personal), el archivo correspondiente se %LocalAppData%\Microsoft\On-premises data gateway (personal mode)\PersonalGatewayConfigurator.exe.config.
  • El segundo archivo es para el servicio de Windows real que interactúa con el servicio en la nube mediante la puerta de enlace. Este archivo controla las solicitudes: C:\Program Files\On-premises data gateway\Microsoft.PowerBI.EnterpriseGateway.exe.config. En la puerta de enlace de datos local (modo personal), el archivo correspondiente se %LocalAppData%\Microsoft\On-premises data gateway (personal mode)\Microsoft.PowerBI.DataMovement.PersonalGateway.exe.config.

Si va a realizar cambios en la configuración del proxy, estos archivos se deben editar para que las configuraciones de proxy sean exactamente las mismas en ambos archivos.

El tercer archivo de configuración debe editarse para que la puerta de enlace se conecte a orígenes de datos en la nube a través de un proxy.

  • C:\Program Files\On-premises data gateway\m\Microsoft.Mashup.Container.NetFX45.exe.config

En la puerta de enlace de datos local (modo personal), el archivo correspondiente es %LocalAppData%\Microsoft\On-premises data gateway (personal mode)\m\Microsoft.Mashup.Container.NetFX45.exe.config.

El cuarto archivo de configuración debe editarse para que la puerta de enlace se conecte a los servicios de Fabric Pipelines a través de un proxy. Desde la versión de febrero de 2025 (3000.258), se cambia el nombre del archivo de configuración a:

  • C:\Program Files\On-premises data gateway\FabricIntegrationRuntime\5.0\Shared\FabricPipelineworker.exe.config

Si usa una versión anterior, el archivo de configuración es:

  • C:\Program Files\On-premises data gateway\FabricIntegrationRuntime\5.0\Shared\Fabricworker.exe.config

En la sección siguiente se describe cómo editar estos archivos.

Configurar la configuración del proxy

En el ejemplo siguiente se muestra la configuración de proxy predeterminada que se encuentra en ambos archivos de configuración principales.

<system.net>
    <defaultProxy useDefaultCredentials="true" />
</system.net>

La configuración predeterminada funciona con la autenticación de Windows. Si el proxy usa otra forma de autenticación, debe cambiar la configuración. Si no está seguro, póngase en contacto con el administrador de red.

No se recomienda la autenticación de proxy básica. El uso de la autenticación de proxy básica puede provocar errores de autenticación de proxy que dan lugar a que la puerta de enlace no esté configurada correctamente. Use un mecanismo de autenticación de proxy más seguro para resolverlo.

Además de usar las credenciales predeterminadas, puede agregar un <proxy> elemento para definir la configuración del servidor proxy con más detalle. Por ejemplo, puede especificar que la puerta de enlace de datos local siempre debe usar el proxy, incluso para los recursos locales, estableciendo el parámetro bypassonlocal en false. Esta configuración puede ayudar en situaciones de solución de problemas con el fin de realizar un seguimiento de todas las solicitudes HTTPS que se originan en una puerta de enlace en los archivos de registro del proxy. La siguiente configuración de ejemplo especifica que todas las solicitudes deben pasar por un proxy específico con la dirección IP 192.168.1.10.

<system.net>
    <defaultProxy useDefaultCredentials="true">
        <proxy  
            autoDetect="false"  
            proxyaddress="http://192.168.1.10:3128"  
            bypassonlocal="false"  
            usesystemdefault="false"
        />  
    </defaultProxy>
</system.net>

También debe editar el archivo Microsoft.Mashup.Container.NetFX45.exe.config si desea que la puerta de enlace se conecte a orígenes de datos en la nube a través de una puerta de enlace.

En el archivo, expanda la sección <configurations> para incluir el contenido siguiente y actualice el atributo proxyaddress con su información de proxy. En el ejemplo siguiente se enrutan todas las solicitudes en la nube a través de un proxy específico con la dirección IP 192.168.1.10.

<configuration>
    <system.net>
        <defaultProxy useDefaultCredentials="true" enabled="true">
        <proxy proxyaddress="http://192.168.1.10:3128" bypassonlocal="true" />
        </defaultProxy>
    </system.net>
</configuration>

La configuración de este tercer archivo puede ser necesaria si el proxy es un requisito para toda la comunicación de Internet, especialmente para el uso corporativo en el que las redes están seguras y bloqueadas. Si se requiere un proxy para la comunicación de puerta de enlace, es probable que también sea necesario para cualquier tráfico de Internet desde contenedores. En este caso, puede parecer que la puerta de enlace funciona correctamente hasta que cualquier contenedor realice cualquier consulta externa (Internet). Este problema es especialmente aplicable a los flujos de datos, que intentan insertar la consulta resultante de datos locales en Azure Data Lake Storage. Pero también se aplica cuando una consulta de puerta de enlace combina un modelo semántico local con un modelo semántico enlazado a Internet.

Para obtener más información sobre la configuración de los elementos proxy para los archivos de configuración de .NET, vaya a defaultProxy Element (Network settings).

Configuración de la puerta de enlace para destinos de salida

Además, para usar la puerta de enlace con destinos de salida, es posible que sea necesario configurar la puerta de enlace para poder pasar a través de un firewall o proxy para llegar al origen de datos de destino. Si usa un servidor proxy, este paso podría requerir habilitar listas de URLs para los destinos apropiados, por ejemplo, *.datawarehouse.pbidedicated.windows.net para LakeHouse, *.dfs.core.windows.net para Data Lake, y así sucesivamente.

Nota:

Si está utilizando destinos de LakeHouse, debe estar ejecutando al menos la versión de mayo de 2023 del gateway. El conector Lakehouse no está disponible en las versiones de gateway anteriores a esta versión.

Cambio de la cuenta de servicio de puerta de enlace a un usuario de dominio

Como se explicó anteriormente, al configurar la configuración del proxy para usar las credenciales predeterminadas, es posible que se produzcan problemas de autenticación con el proxy. Esta situación se produce cuando la cuenta de servicio predeterminada es el SID de servicio y no un usuario de dominio autenticado. Si el proxy de la organización requiere una cuenta de dominio para autenticar la solicitud, puede cambiar la cuenta de servicio de la puerta de enlace a una cuenta de servicio de dominio. Este cambio permite la autenticación adecuada con el proxy. Para obtener más información sobre cómo cambiar la cuenta de servicio de puerta de enlace, vaya a Cambiar la cuenta de servicio de puerta de enlace de datos local.

Nota:

Se recomienda usar una cuenta de servicio administrada para evitar tener que restablecer contraseñas. Aprenda a crear una cuenta de servicio administrada en Active Directory.