Partager via

Configurer les paramètres de proxy pour la passerelle de données locale

Votre environnement de travail peut nécessiter que vous passez par un proxy pour accéder à Internet. Cette exigence peut empêcher la passerelle de données locale Microsoft de se connecter au service.

Le billet suivant sur superuser.com explique comment vous pouvez essayer de déterminer si vous avez un proxy sur votre réseau : Comment savoir quel serveur proxy j’utilise ? (SuperUser.com).

Bien que la plupart des paramètres de configuration de passerelle puissent être modifiés à l’aide de l’application de passerelle de données locale, les informations de proxy sont configurées dans un fichier de configuration .NET. L’emplacement et les noms de fichiers sont différents, selon la passerelle que vous utilisez.

Il existe quatre fichiers de configuration associés à l’utilisation d’un proxy avec la passerelle de données locale. Les deux fichiers de configuration principaux suivants s’appliquent à la passerelle et à son processus de configuration.

  • Le premier fichier concerne les écrans de configuration qui configurent réellement la passerelle. Si vous rencontrez des problèmes lors de la configuration de la passerelle, consultez le fichier suivant : C:\Program Files\On-premises data gateway\enterprisegatewayconfigurator.exe.config. Sur la passerelle de données locale (mode personnel), le fichier correspondant est %LocalAppData%\Microsoft\On-premises data gateway (personal mode)\PersonalGatewayConfigurator.exe.config.
  • Le deuxième fichier concerne le service Windows réel qui interagit avec le service cloud à l’aide de la passerelle. Ce fichier gère les requêtes : C:\Program Files\On-premises data gateway\Microsoft.PowerBI.EnterpriseGateway.exe.config. Sur la passerelle de données locale (mode personnel), le fichier correspondant est %LocalAppData%\Microsoft\On-premises data gateway (personal mode)\Microsoft.PowerBI.DataMovement.PersonalGateway.exe.config.

Si vous allez apporter des modifications à la configuration du proxy, ces fichiers doivent être modifiés afin que les configurations de proxy soient exactement les mêmes dans les deux fichiers.

Le troisième fichier de configuration doit être modifié pour que la passerelle se connecte à des sources de données cloud via un proxy.

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

Sur la passerelle de données locale (mode personnel), le fichier correspondant est %LocalAppData%\Microsoft\On-premises data gateway (personal mode)\m\Microsoft.Mashup.Container.NetFX45.exe.config.

Le quatrième fichier de configuration doit être modifié pour que la passerelle se connecte aux services Fabric Pipelines via un proxy. Depuis la version de février 2025 (3000.258), le fichier de configuration est renommé en :

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

Si vous utilisez une version antérieure, le fichier de configuration est :

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

La section suivante décrit comment modifier ces fichiers.

Configuration des paramètres de proxy

L’exemple suivant montre la configuration de proxy par défaut trouvée dans les deux fichiers de configuration principaux.

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

La configuration par défaut fonctionne avec l’authentification Windows. Si votre proxy utilise une autre forme d’authentification, vous devez modifier les paramètres. Si vous n’êtes pas sûr, contactez votre administrateur réseau.

Nous vous déconseillons d’utiliser l’authentification proxy de base. L’utilisation de l’authentification proxy de base peut entraîner des erreurs d’authentification proxy qui entraînent la configuration incorrecte de la passerelle. Utilisez un mécanisme d’authentification proxy plus fort pour résoudre.

Outre l’utilisation des informations d’identification par défaut, vous pouvez ajouter un <proxy> élément pour définir les paramètres du serveur proxy plus en détail. Par exemple, vous pouvez spécifier que votre passerelle de données locale doit toujours utiliser le proxy, même pour les ressources locales, en définissant le paramètre bypassonlocal sur false. Ce paramètre peut aider à résoudre des problèmes en permettant de suivre toutes les requêtes HTTPS provenant d’une passerelle dans les fichiers journaux du proxy. L’exemple de configuration suivant spécifie que toutes les requêtes doivent passer par un proxy spécifique avec l’adresse 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>

Vous devez également modifier le fichier Microsoft.Mashup.Container.NetFX45.exe.config si vous souhaitez que la passerelle se connecte à des sources de données cloud via une passerelle.

Dans le fichier, développez la <configurations> section pour inclure le contenu suivant et mettez à jour l’attribut proxyaddress avec vos informations de proxy. L’exemple suivant route toutes les requêtes cloud via un proxy spécifique avec l’adresse 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 configuration de ce troisième fichier peut être nécessaire si votre proxy est requis pour toutes les communications Internet, en particulier pour l’utilisation de l’entreprise où les réseaux sont sécurisés et verrouillés. Si un proxy est requis pour la communication de passerelle, il est probable qu’il soit également nécessaire pour tout trafic Internet provenant de conteneurs. Dans ce cas, la passerelle peut sembler fonctionner correctement jusqu’à ce que n’importe quel conteneur effectue une requête externe (Internet). Ce problème s’applique particulièrement aux dataflows, qui tentent d’envoyer (push) la requête résultante de données locales vers Azure Data Lake Storage. Mais elle s’applique également lorsqu’une requête de passerelle fusionne un modèle sémantique local avec un modèle sémantique lié à Internet.

Pour en savoir plus sur la configuration des éléments proxy pour les fichiers de configuration .NET, accédez à defaultProxy, élément (paramètres réseau).

Configurer la passerelle pour les destinations de sortie

En outre, pour utiliser la passerelle avec des destinations de sortie, la passerelle peut être configurée pour pouvoir passer par un pare-feu ou un proxy pour atteindre la source de données de destination. Si vous utilisez un serveur proxy, cette procédure pas à pas peut nécessiter l’activation des URL vers des destinations appropriées, par exemple *.datawarehouse.pbidedicated.windows.net pour LakeHouse, *.dfs.core.windows.net pour Data Lake Lake, et ainsi de suite.

Remarque

Si vous utilisez des destinations LakeHouse, vous devez exécuter au moins la version de mai 2023 de la passerelle. Le connecteur Lakehouse n’est pas disponible dans les versions de passerelle antérieures à cette version.

Modifier le compte de service de passerelle en un utilisateur de domaine

Comme expliqué précédemment, lorsque vous configurez les paramètres de proxy pour utiliser les informations d’identification par défaut, vous pouvez rencontrer des problèmes d’authentification avec votre proxy. Cette situation se produit lorsque le compte de service par défaut est le SID de service et non un utilisateur de domaine authentifié. Si le proxy de votre organisation nécessite un compte de domaine pour authentifier la demande, vous pouvez modifier le compte de service de la passerelle en un compte de service de domaine. Cette modification permet l’authentification appropriée avec votre proxy. Pour plus d’informations sur la modification du compte de service de passerelle, accédez à Modifier le compte de service de passerelle de données local.

Remarque

Nous vous recommandons d’utiliser un compte de service géré pour éviter d’avoir à réinitialiser les mots de passe. Découvrez comment créer un compte de service managé dans Active Directory.

Contenu connexe