Prérequis pour le Microsoft Tunnel dans Intune

Avant de pouvoir installer la passerelle VPN Microsoft Tunnel pour Microsoft Intune, passez en revue et configurez les prérequis. Les conditions préalables comprennent l'utilisation d'un serveur Linux qui exécute des conteneurs pour héberger le logiciel du serveur Tunnel. Prévoyez également de configurer votre réseau, vos pare-feu et vos proxys pour prendre en charge les communications pour Microsoft Tunnel.

À un niveau élevé, Microsoft Tunnel nécessite les éléments suivants :

• Un abonnement Azure.

• Un abonnement Microsoft Intune Plan 1.

  Remarque

  Ce prérequis concerne Microsoft Tunnel et n’inclut pas Microsoft Tunnel pour la gestion des applications mobiles, qui est un module complémentaire Intune qui nécessite un abonnement Microsoft Intune Plan 2.

• Un serveur Linux qui exécute des conteneurs. Le serveur peut être local ou dans le cloud et prend en charge l’un des types de conteneurs suivants :

  • Podman pour Red Hat Enterprise Linux (RHEL). Consultez la configuration requise du serveur Linux .
  • Docker pour toutes les autres distributions Linux.

• Un certificat TLS ( Transport Layer Security ) pour le serveur Linux afin de sécuriser les connexions des appareils au serveur Tunnel Gateway.

• Appareils exécutant Android ou iOS/iPadOS.

Après avoir configuré les prérequis, nous vous recommandons d’exécuter l’outil de préparation pour vérifier que votre environnement est bien configuré pour une installation réussie.

Les sections suivantes détaillent les conditions préalables pour le Microsoft Tunnel et fournissent des conseils sur l'utilisation de l'outil de préparation.

Serveur Linux

Configurez une machine virtuelle Linux ou un serveur physique sur lequel installer la passerelle Microsoft Tunnel.

• Distributions Linux prises en charge : le tableau suivant détaille les versions de Linux prises en charge pour le serveur Tunnel et le conteneur dont elles ont besoin :

  Version de distribution	Exigences relatives aux conteneurs	Considérations
  CentOS 7.4+	Docker CE	Le support se termine en juin 2024. CentOS 8+ n’est pas pris en charge
  Red Hat (RHEL) 7.4+.	Docker CE	Le support se termine en juin 2024
  Red Hat (RHEL) 8.6	La prise en charge se termine en juin 2024 Podman 4.0 (par défaut) Podman 3.0	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.0. Si vous mettez à niveau et modifiez des conteneurs de la version 3 vers la version 4.0, prévoyez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Red Hat (RHEL) 8.7	Podman 4.2 (par défaut)	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Red Hat (RHEL) 8.8	Podman 4.4.1	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Red Hat (RHEL) 8.9	Podman 4.4.1	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Red Hat (RHEL) 8.10	Podman 4.9.4-rhel (par défaut)	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Red Hat (RHEL) 9.0	La prise en charge se termine en juin 2024 Podman 4.4.1 (par défaut)	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel. Le support prend fin en février 2024.
  Red Hat (RHEL) 9.1	Podman 4.4.1 (par défaut)	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Red Hat (RHEL) 9.2	Podman 4.4.1 (par défaut)	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Red Hat (RHEL) 9.3	Podman 4.6.1. (par défaut)	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Red Hat (RHEL) 9.4	Podman 4.9.4-rhel (par défaut)	Cette version de RHEL ne charge pas automatiquement le module ip_tables dans le noyau Linux. Lorsque vous utilisez cette version, prévoyez de charger manuellement le ip_tables avant l’installation de Tunnel. Les conteneurs créés par Podman v3 et versions antérieures ne sont pas utilisables avec Podman v4.2 et versions ultérieures. Si vous mettez à niveau et modifiez des conteneurs, envisagez de créer des conteneurs et de désinstaller, puis de réinstaller Microsoft Tunnel.
  Ubuntu 20.04	Docker CE
  Ubuntu 22.04	Docker CE

  Importante

  En avril 2023, Ubuntu mettra fin à la prise en charge d’Ubuntu 18.04. Avec la fin du support par Ubuntu, Intune mettra également fin à la prise en charge d’Ubuntu 18.04 pour une utilisation avec Microsoft Tunnel. Pour plus d’informations, reportez-vous à l’article https://wiki.ubuntu.com/Releases.

• Dimensionnement du serveur Linux : Utilisez les conseils suivants pour répondre à votre utilisation prévue :

  # Appareils	Nombre de processeurs	Mémoire GB	Nombre de serveurs	Nombre de sites	Espace disque en Go
  1 000	4	4	1	1	30
  2,000	4	4	1	1	30
  5,000	8	8	2	1	30
  10 000	8	8	3	1	30
  20,000	8	8	4	1	30
  40 000	8	8	8	1	30

  La prise en charge évolue de façon linéaire. Bien que chaque tunnel Microsoft prenne en charge jusqu'à 64 000 connexions simultanées, les appareils individuels peuvent ouvrir plusieurs connexions.

• CPU : processeur AMD/Intel 64 bits.

• Installer Docker CE ou Podman : en fonction de la version de Linux que vous utilisez pour votre serveur Tunnel, installez l’un des éléments suivants sur le serveur :

  • Docker version 19.03 CE ou ultérieure.
  • Podman version 3.0 ou 4.0 selon la version de RHEL.

  Microsoft Tunnel nécessite Docker ou Podman sur le serveur Linux pour prendre en charge les conteneurs. Les conteneurs fournissent un environnement d'exécution cohérent, une surveillance de l'état de santé et une remédiation proactive, ainsi qu'une expérience de mise à niveau propre.

  Pour des informations sur l'installation et la configuration de Docker ou Podman, voir :

  • Installez le moteur Docker sur CentOS ou Red Hat Enterprise Linux 7.

    Remarque

    Le lien précédent vous dirige vers les instructions de téléchargement et d'installation de CentOS. Utilisez ces mêmes instructions pour RHEL 7.4. La version installée par défaut sur RHEL 7.4 est trop ancienne pour prendre en charge Microsoft Tunnel Gateway.

  • Installez le moteur Docker sur Ubuntu.

  • Installez Podman sur Red Hat Enterprise Linux 8.4 et versions ultérieures (faites défiler jusqu’à RHEL8).

    Ces versions de RHEL ne prennent pas en charge Docker. Au lieu de cela, ces versions utilisent Podman et podman fait partie d’un module appelé « container-tools ». Dans ce contexte, un module est un ensemble de packages RPM qui représentent un composant et qui s’installent généralement ensemble. Un module typique contient des paquets avec une application, des paquets avec les bibliothèques de dépendances spécifiques à l'application, des paquets avec la documentation de l'application et des paquets avec des utilitaires d'aide. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Introduction aux modules dans la documentation Red Hat.

    Remarque

    Podman sans racine : Microsoft Tunnel prend en charge l’utilisation d’un conteneur Podman sans racine.

    L’utilisation de Podman sans racine nécessite des conditions préalables supplémentaires à celles décrites dans cet article et l’utilisation d’une ligne de commande modifiée lorsque vous démarrez le script d’installation de Tunnel. Pour plus d’informations sur les prérequis supplémentaires et la ligne de commande d’installation, consultez Utiliser un conteneur Podman sans racine dans l’article Configurer Microsoft Tunnel pour Intune.

• Certificat TLS (Transport Layer Security) : Le serveur Linux requiert un certificat TLS fiable pour sécuriser la connexion entre les appareils et le serveur Tunnel Gateway. Pendant l’installation de Tunnel Gateway, vous ajoutez au serveur le certificat TLS et la chaîne de certificats approuvée complète.

  • L’autre nom de l’objet du certificat TLS que vous utilisez pour sécuriser le point de terminaison Tunnel Gateway doit correspondre à l’adresse IP ou au nom de domaine complet du serveur Tunnel Gateway.

  • Le certificat TLS ne peut avoir une date d'expiration supérieure à deux ans. Si la date est supérieure à deux ans, elle n’est pas acceptée sur les appareils iOS.

  • La prise en charge des caractères génériques est limitée. Par exemple, *.contoso.com est pris en charge, mais cont*.com n’est pas pris en charge.

  • Pendant l’installation du serveur Tunnel Gateway, vous devez copier l’intégralité de la chaîne de certificats approuvée sur votre serveur Linux. Le script d’installation fournit l’emplacement où vous devez copier les fichiers de certificat, et vous invite à le faire.

  • Si vous utilisez un certificat TLS qui n’est pas approuvé publiquement, vous devez envoyer (push) l’ensemble de la chaîne d’approbation aux appareils à l’aide d’un profil de certificat Intune approuvé.

  • Le certificat TLS peut être au format PEM ou pfx.

  • Pour prendre en charge les case activée d’intégrité de révocation de certificats TLS, vérifiez que le protocole OCSP (Online Certificate Status Protocol) ou l’adresse de liste de révocation de certificats (CRL) telle que définie par le certificat TLS est accessible à partir du serveur.

  • Configurez le certificat des clients Tunnel avec une clé de 2 048 bits ou plus. Nous recommandons des clés plus volumineuses pour que votre déploiement reste pris en charge par différentes solutions de bibliothèque SSL/TLS en constante évolution.

    Conseil

    Passez régulièrement en revue les exigences de votre bibliothèque SSL/TLS choisie pour vous assurer que votre infrastructure et vos certificats restent pris en charge et en conformité avec les modifications récentes pour cette bibliothèque, et réexécutez les certificats clients Tunnel si nécessaire pour rester à jour avec les exigences en constante évolution de vos solutions.

• Version TLS : Par défaut, les connexions entre clients et serveurs Microsoft Tunnel utilisent TLS 1.3. Lorsque TLS 1.3 n’est pas disponible, la connexion peut utiliser TLS 1.2.

Réseau de pont par défaut

Les conteneurs Podman et Docker utilisent tous deux un réseau de pontage pour transmettre le trafic via l'hôte Linux. Lorsque le réseau de pont de conteneurs est en conflit avec un réseau d’entreprise, Tunnel Gateway ne peut pas acheminer le trafic vers ce réseau d’entreprise.

Les réseaux de pont par défaut sont :

• Docker : 172.17.0.0/16
• Podman : 10.88.0.0/16

Pour éviter les conflits, vous pouvez reconfigurer Podman et Docker pour utiliser un réseau de pont que vous spécifiez.

Modifier le réseau de pont par défaut utilisé par Docker

Docker utilise le fichier /etc/docker/daemon.json pour configurer une nouvelle adresse IP de pont par défaut. Dans le fichier, l’adresse IP de pont doit être spécifiée en notation CIDR (routage inter-domaine sans classe), un moyen compact de représenter une adresse IP avec son masque de sous-réseau associé et son préfixe de routage.

1. Utilisez la commande suivante pour arrêter le conteneur MS Tunnel Gateway :sudo mst-cli server stop ; sudo mst-cli agent stop

2. Ensuite, exécutez la commande suivante pour supprimer l’appareil de pont Docker existant : sudo ip link del docker0

3. Si le fichier /etc/docker/daemon.json est présent sur votre serveur, utilisez un éditeur de fichiers comme vi ou nano pour modifier le fichier. Exécutez l’éditeur de fichiers avec des autorisations racine ou sudo :

   • Lorsque l’entrée « bip » : est présente avec une adresse IP, modifiez-la en ajoutant une nouvelle adresse IP en notation CIDR.
   • Lorsque l’entrée « bip » : n’est pas présente, vous devez ajouter la valeur « bip » : et la nouvelle adresse IP en notation CIDR.

   L’exemple suivant illustre la structure d’un fichier daemon.json avec une entrée « bip » : mise à jour qui utilise une adresse IP modifiée « 192.168.128.1/24 ».

   Exemple de daemon.json :

   {
   "bip": "192.168.128.1/24"
   }
   

4. Si le fichier /etc/docker/daemon.json n’est pas présent sur votre serveur, exécutez une commande similaire à l’exemple suivant pour créer le fichier et définir l’adresse IP du pont que vous souhaitez utiliser.

   Exemple : sudo echo '{ "bip":"192.168.128.1/24" }' > /etc/docker/daemon.json

5. Utilisez la commande suivante pour démarrer le conteneur MS Tunnel Gateway :sudo mst-cli agent start ; sudo mst-cli server start

Pour plus d’informations, consultez Utiliser les réseaux pont dans la documentation Docker.

Modifier le réseau de pont par défaut utilisé par Podman

Podman utilise le fichier /etc/cni/net.d comme 87-podman-bridge.conflist pour configurer une nouvelle adresse IP de pont par défaut.

1. Utilisez la commande suivante pour arrêter le conteneur MS Tunnel Gateway :sudo mst-cli server stop ; sudo mst-cli agent stop

2. Ensuite, exécutez la commande suivante pour supprimer le périphérique de pont Podman existant : sudo ip link del cni-podman0

3. À l’aide des autorisations racine et d’un éditeur de fichiers comme vi ou nano, modifiez /etc/cni/net.d en tant que 87-podman-bridge.conflist pour mettre à jour les valeurs par défaut pour « subnet : » et « gateway : » en remplaçant les valeurs par défaut de Podman par les adresses de sous-réseau et de passerelle souhaitées. L’adresse du sous-réseau doit être spécifiée en notation CIDR.

   Les valeurs par défaut de Podman sont :

   • sous-réseau : 10.88.0.0/16
   • passerelle : 10.88.0.1

4. Utilisez la commande suivante pour redémarrer les conteneurs MS Tunnel Gateway :sudo mst-cli agent start ; sudo mst-cli server start

Pour plus d’informations, consultez Configuration de la mise en réseau de conteneur avec Podman dans la documentation Red Hat.

Audit du système Linux

L’audit du système Linux peut aider à identifier les informations relatives à la sécurité ou les violations de sécurité sur un serveur Linux qui héberge Microsoft Tunnel. L’audit du système Linux est recommandé pour Microsoft Tunnel, mais pas obligatoire. Pour utiliser l’audit système, le package audité doit être installé sur /etc/audit/auditd.confun serveur Linux.

Les détails sur la façon d’implémenter l’audit dépendent de la plateforme Linux que vous utilisez :

• Red Hat : les versions de Red Had Enterprise Linux 7 et ultérieures installent le package audité par défaut. Toutefois, si le package n’est pas installé, vous pouvez utiliser la ligne de commande suivante sur le serveur Linux pour l’installer : sudo dnf install audit audispd-plugins

  En règle générale, le package audité est disponible à partir du dépôt par défaut de chaque version de REHL.

  Pour plus d’informations sur l’utilisation de l’audit système sur RHEL, consultez Configurer l’audit système Linux avec audité dans le blog Red Hat.

• Ubuntu : pour utiliser l’audit système avec Ubuntu, vous devez installer manuellement le package audité . Pour ce faire, utilisez la ligne de commande suivante sur le serveur Linux : sudo apt install auditd audispd-plugins

  En règle générale, le package audité est disponible à partir du référentiel par défaut de chaque version d’Ubuntu.

  Pour plus d’informations sur l’utilisation de l’audit système sur Ubuntu, consultez Guide pratique pour configurer et installer Auditd sur Ubuntu, un article disponible sur le site web dev.to initialement publié à kubefront.com.

Réseau

• Activez le transfert de paquets pour IPv4: chaque serveur Linux hébergeant le logiciel serveur Tunnel doit avoir le transfert IP pour IPv4 activé. Pour vérifier l’état du transfert IP, sur le serveur, exécutez l’une des commandes génériques suivantes en tant que root ou sudo. Les deux commandes retournent la valeur 0 pour désactivé et la valeur 1 pour activé :

  • sysctl net.ipv4.ip_forward
  • cat /proc/sys/net/ipv4/ip_forward

  Si cette option n’est pas activée, vous pouvez activer temporairement le transfert IP en exécutant l’une des commandes génériques suivantes en tant que root ou sudo sur le serveur. Ces commandes peuvent modifier la configuration de transfert IP jusqu’au redémarrage du serveur. Après un redémarrage, le serveur renvoie le comportement de transfert IP à son état précédent. Pour les deux commandes, utilisez la valeur 1 pour activer le transfert. La valeur 0 désactive le transfert. Les exemples de commandes suivants utilisent la valeur 1 pour activer le transfert :

  • sysctl -w net.ipv4.ip_forward=1
  • echo 1 > /proc/sys/net/ipv4/ip_forward

  Pour rendre le transfert IP permanent, sur chaque serveur Linux, modifiez le fichier /etc/sysctl.conf et supprimez le dièse (#) de début de #net.ipv4.ip_forward=1 pour activer le transfert de paquets. Après votre modification, l'entrée devrait apparaître comme suit :

  # Uncomment the next line to enable packet forwarding for IPv4
  net.ipv4.ip_forward=1
  

  Pour que cette modification prenne effet, vous devez soit redémarrer le serveur, soit exécutersysctl -p.

  Si l’entrée attendue n’est pas présente dans le fichier sysctl.conf, consultez la documentation relative à la distribution que vous utilisez pour savoir comment activer le transfert IP. En règle générale, vous pouvez modifier sysctl.conf pour ajouter la ligne manquante à la fin du fichier afin d’activer le transfert IP de façon permanente.

• Configurer plusieurs cartes réseau par serveur(facultatif) : nous vous recommandons d’utiliser deux contrôleurs d’interface réseau (NIC) par serveur Linux pour améliorer les performances, bien que l’utilisation de deux soit facultative.

  • NIC 1 : ce contrôleur réseau gère le trafic provenant de vos appareils gérés, et doit se trouver sur un réseau public avec une adresse IP publique.  Cette adresse IP est l’adresse que vous configurez dans la configuration de site. Elle peut représenter un serveur unique ou un équilibreur de charge.

  • NIC 2 : ce contrôleur réseau gère le trafic vers vos ressources locales, et doit se trouver sur votre réseau interne privé sans segmentation de réseau.

• Veiller à ce que les machines virtuelles cloud Linux puissent accéder à votre réseau local : si vous exécutez Linux en tant que machine virtuelle sur un cloud, veillez à ce que le serveur puisse accéder à votre réseau local. Par exemple, pour une machine virtuelle dans Azure, vous pouvez utiliser Azure ExpressRoute ou un produit similaire pour fournir l’accès. Azure ExpressRoute n’est pas nécessaire quand vous exécutez le serveur sur une machine virtuelle locale.

• Équilibreurs de charge(facultatif) : si vous choisissez d’ajouter un équilibreur de charge, consultez la documentation de vos fournisseurs pour plus d’informations sur la configuration. Prenez en compte le trafic réseau et les ports de pare-feu spécifiques à Intune et au tunnel Microsoft.

  Le serveur Tunnel répond aux requêtes GET avec une page statique. La réponse est utilisée comme sonde par les équilibreurs de charge pour case activée de l’activité du serveur Tunnel. La réponse est statique et ne contient pas d’informations sensibles.

• Prise en charge du VPN par application et du domaine de niveau supérieur : l’utilisation du VPN par application avec une utilisation interne de domaines de niveau supérieur locaux n’est pas prise en charge par Microsoft Tunnel.

Pare-feu

Par défaut, Microsoft Tunnel et le serveur utilisent les ports suivants :

Ports d’entrée :

• TCP 443 : requis par Microsoft Tunnel.
• UDP 443 : requis par Microsoft Tunnel.
• TCP 22 : facultatif. Utilisé pour la communication SSH/SCP avec le serveur Linux.

Ports de sortie :

• TCP 443 – Requis pour accéder aux services Intune. Requis par Docker ou Podman pour tirer des images.

Lorsque vous créez la configuration de serveur pour le tunnel, vous pouvez spécifier un port autre que le port par défaut 443. Si vous spécifiez un port différent, configurez les pare-feu pour qu'ils prennent en charge votre configuration.

Autres exigences :

Pour accéder au service de jeton de sécurité et au stockage Azure pour les journaux, fournissez l’accès aux noms de domaine complets suivants :

• Service d'émission de jeton de sécurité*.sts.windows.net
• Stockage Azure pour les journaux de tunnel : *.blob.core.windows.net
• Autres URL de point de terminaison de stockage : *.blob.storage.azure.net
• Microsoft Intune :*.manage.microsoft.com
• Authentification Microsoft : login.microsoftonline.com
• Microsoft Graph : graph.microsoft.com
• Configurez des règles de pare-feu pour prendre en charge les configurations détaillées dans configuration des règles de pare-feu du client Registre des artefacts Microsoft (MAR).

Proxy

Vous pouvez utiliser un serveur proxy avec Microsoft Tunnel.

Les considérations suivantes peuvent vous aider à configurer le serveur Linux et votre environnement pour réussir :

Configurer un proxy sortant pour Docker

• Si vous utilisez un proxy interne, vous devrez peut-être configurer l'hôte Linux pour qu'il utilise votre serveur proxy en utilisant des variables d'environnement. Pour utiliser les variables, modifiez le fichier /etc/environnementsur le serveur Linux, et ajoutez les lignes suivantes :

  http_proxy=[address]
https_proxy=[address]

• Les proxies authentifiés ne sont pas supportés.

• Le proxy ne peut pas effectuer d’arrêt et d’inspection, car le serveur Linux utilise l’authentification mutuelle TLS lors de la connexion à Intune.

• Configurez Docker pour qu'il utilise le proxy pour tirer des images. Pour ce faire, modifiez le fichier /etc/systemd/system/docker.service.d/http-proxy.conf sur le serveur Linux en ajoutant les lignes suivantes :

  [Service]
  Environment="HTTP_PROXY=http://your.proxy:8080/"
  Environment="HTTPS_PROXY=https://your.proxy:8080/"
  Environment="NO_PROXY=127.0.0.1,localhost"
  

  Remarque

  Microsoft Tunnel ne prend pas en charge Microsoft Entra proxy d’application ou des solutions de proxy similaires.

Configurer un proxy sortant pour Podman

Les informations suivantes peuvent vous aider à configurer un proxy interne lors de l’utilisation de Podman :

• Les proxies authentifiés ne sont pas supportés.

• Le proxy ne peut pas effectuer d’arrêt et d’inspection, car le serveur Linux utilise l’authentification mutuelle TLS lors de la connexion à Intune.

• Podman lit les informations du proxy HTTP stockées dans /etc/profile.d/http_proxy.sh . Si ce fichier n'existe pas sur votre serveur, créez-le. Modifiez http_proxy.sh pour ajouter les deux lignes suivantes. Dans les lignes suivantes, 10.10.10.1:3128 est un exemple d'entrée adresse:port. Lorsque vous ajoutez ces lignes, remplacez 10.10.10.1:3128 par les valeurs pour l'adresse IP de votre proxy:port :

  export HTTP_PROXY=http://10.10.10.1:3128
export HTTPS_PROXY=http://10.10.10.1:3128

  Si vous avez accès au Red Hat Customer Portal, vous pouvez consulter l'article de la base de connaissances associé à cette solution. Voir Configuration des variables de proxy HTTP pour Podman – Portail clients de Red Hat.

• Lorsque vous ajoutez ces deux lignes à http_proxy.sh avant d’installer Microsoft Tunnel Gateway en exécutant mstunnel-setup, le script configure automatiquement les variables d’environnement du proxy Tunnel Gateway dans /etc/mstunnel/env.sh.

  Pour configurer un proxy une fois l’installation de Microsoft Tunnel Gateway terminée, effectuez les actions suivantes :

  1. Modifiez ou créez le fichier /etc/profile.d/http_proxy.sh et ajoutez les deux lignes du point précédent.

  2. Modifiez /etc/mstunnel/env.sh et ajoutez les deux lignes suivantes à la fin du fichier. Comme les lignes précédentes, remplacez l’exemple de valeur address :port de 10.10.10.1:3128 par les valeurs de votre proxy IP address :port :

     HTTP_PROXY=http://10.10.10.1:3128
HTTPS_PROXY=http://10.10.10.1:3128

  3. Redémarrez le serveur Tunnel Gateway : Exécuter mst-cli server restart

  Sachez que RHEL utilise SELinux. Étant donné qu’un proxy qui ne s’exécute pas sur un port SELinux pour http_port_t peut nécessiter une configuration supplémentaire, vérifiez l’utilisation des ports managés SELinux pour http. Pour afficher les configurations, exécutez la commande suivante : sudo semanage port -l | grep "http_port_t"

  Exemple des résultats de la commande de vérification du port. Dans cet exemple, le proxy utilise 3128 et n'est pas listé :

  

  • Si votre proxy s’exécute sur l’un des ports SELinux pour http_port_t, vous pouvez poursuivre le processus d’installation de Tunnel Gateway.

  • Si votre proxy ne s’exécute pas sur un port SELinux pour http_port_t comme dans l’exemple précédent, vous devez effectuer des configurations supplémentaires.

    Si votre port proxy n’est pas répertorié pourhttp_port_t, case activée si le port proxy est utilisé par un autre service. Utilisez la commande semanage pour d’abord case activée le port utilisé par votre proxy, puis ultérieurement si nécessaire, pour le modifier. Pour vérifier le port utilisé par votre proxy, exécutez : sudo semanage port -l | grep "your proxy port"

    Exemple des résultats de la vérification d'un service qui pourrait utiliser le port :

    

    • Dans l'exemple, le port attendu (3128) est utilisé par squid , qui se trouve être un service proxy OSS. Les stratégies SELinux du proxy Squid font partie de nombreuses distributions courantes. Comme squid utilise le port 3128 (notre port d'exemple), nous devons modifier les ports http_port_t et ajouter le port 3128 pour qu'il soit autorisé via SELinux pour le proxy utilisé par Tunnel. Pour modifier l'utilisation du port, exécutez la commande suivante :sudo semanage port -m -t http_port_t -p tcp "your proxy port"

      Exemple de la commande pour modifier le port :

      

      Après avoir exécuté la commande pour changer le port, exécutez la commande suivante pour vérifier si le port est utilisé par un autre service : sudo semanage port -l | grep "your proxy port"

      Exemple de la commande permettant de vérifier le port après sa modification :

      

      Dans cet exemple, le port 3128 est maintenant associé à la fois à http_port-t et à squid_port_t. Ce résultat est attendu. Si le port de votre proxy n'est pas listé lors de l'exécution de la commande sudo semanage port -l | grep « your_proxy_port», exécutez à nouveau la commande pour modifier le port, mais le -m de la commande semanage avec -a : sudo semanage port -a -t http_port_t -p tcp "your proxy port"

Configurer Podman pour utiliser le proxy pour télécharger les mises à jour d’images

Vous pouvez configurer Podman pour qu’il utilise le proxy pour télécharger (extraire) des images mises à jour pour Podman :

1. Sur le serveur tunnel, utilisez une invite de commandes pour exécuter la commande suivante afin d’ouvrir un éditeur pour le fichier de remplacement pour le service Microsoft Tunnel :

   systemctl edit --force mstunnel_monitor

2. Ajoutez les trois lignes suivantes au fichier. Remplacez chaque instance de [address] par votre nom de domaine ou adresse de proxy, puis enregistrez le fichier :

   [Service]
   Environment="http_proxy=[address]"
   Environment="https_proxy=[address]"
   

3. Ensuite, exécutez la commande suivante à l’invite de commandes :

   systemctl restart mstunnel_monitor

4. Enfin, exécutez la commande suivante à l’invite de commandes pour confirmer que la configuration a réussi :

   systemctl show mstunnel_monitor | grep http_proxy

   Si la configuration réussit, les résultats ressemblent aux informations suivantes :

   Environment="http_proxy=address:port"
   Environment="https_proxy=address:port"
   

Mettre à jour le serveur proxy utilisé par le serveur de tunnel

Pour modifier la configuration du serveur proxy qui est en cours d’utilisation par l’hôte Linux du serveur de tunnel, suivez la procédure suivante :

1. Sur le serveur de tunnel, modifiez /etc/mstunnel/env.sh et spécifiez le nouveau serveur proxy.

2. Exécutez mst-cli install.

   Cette commande reconstruit les conteneurs avec les détails du nouveau serveur proxy. Au cours de ce processus, vous êtes invité à vérifier le contenu de /etc/mstunnel/env.sh et à vous assurer que le certificat est installé. Le certificat doit déjà être présent à partir de la configuration précédente du serveur proxy.

   Pour confirmer les deux et terminer la configuration, entrez oui.

Plateformes

Les appareils doivent être inscrits auprès d’Intune pour être pris en charge avec Microsoft Tunnel. Seules les plateformes d’appareil suivantes sont prises en charge :

• iOS/iPadOS

• Android Enterprise :

  • Entièrement géré
  • Profil professionnel appartenant à l’entreprise
  • Profil de travail personnel

  Remarque

  Les appareils Android Enterprise dédiés ne sont pas pris en charge par Microsoft Tunnel.

Toutes les plateformes prennent en charge les fonctionnalités suivantes :

• Microsoft Entra l’authentification auprès du tunnel à l’aide du nom d’utilisateur et du mot de passe.
• Activer l’authentification des services de fédération Active Directory (AD FS) à Tunnel à l’aide du nom d’utilisateur et du mot de passe.
• Prise en charge par application.
• Tunnel d’appareil complet manuel par le biais d’une application tunnel, où l’utilisateur lance le VPN et sélectionne Se connecter.
• Tunneling fractionné. Toutefois, sur iOS, les règles de tunneling fractionné sont ignorées lorsque votre profil VPN utilise VPN par application.

La prise en charge d’un proxy est limitée aux plateformes suivantes :

• Android 10 et versions ultérieures
• iOS/iPadOS

Autorisations

Pour gérer Microsoft Tunnel, les utilisateurs doivent disposer des autorisations incluses dans le groupe d’autorisations Microsoft Tunnel Gateway dans Intune. Par défaut, les administrateurs Intune et les administrateurs Microsoft Entra disposent de ces autorisations. Vous pouvez également les ajouter aux rôles personnalisés que vous créez pour votre locataire Intune.

Lors de la configuration d’un rôle, dans la page Autorisations, développez Microsoft Tunnel Gateway, puis sélectionnez les autorisations que vous souhaitez accorder.

Le groupe d’autorisations Microsoft Tunnel Gateway accorde les autorisations suivantes :

• Créer : configurer des sites et des serveurs Microsoft Tunnel Gateway. Les configurations de serveur incluent des paramètres pour les plages d’adresses IP, les serveurs DNS, les ports et les règles de segmentation de tunnel. Les sites sont des regroupements logiques de plusieurs serveurs qui prennent en charge Microsoft Tunnel.

• Mettre à jour (modifier) – Mettre à jour les configurations et les sites du serveur Microsoft Tunnel Gateway. La configuration des serveurs comprend des paramètres pour les plages d'adresses IP, les serveurs DNS, les ports et les règles de tunnellisation. Les sites sont des regroupements logiques de plusieurs serveurs qui prennent en charge Microsoft Tunnel.

• Supprimer : supprimer des sites et des configurations de serveur Microsoft Tunnel Gateway. Les configurations de serveur incluent des paramètres pour les plages d’adresses IP, les serveurs DNS, les ports et les règles de segmentation de tunnel. Les sites sont des regroupements logiques de plusieurs serveurs qui prennent en charge Microsoft Tunnel.

• Lire : afficher les sites et les configurations de serveur Microsoft Tunnel Gateway. La configuration des serveurs comprend des paramètres pour les plages d'adresses IP, les serveurs DNS, les ports et les règles de tunnellisation. Les sites sont des regroupements logiques de plusieurs serveurs qui prennent en charge Microsoft Tunnel.

Exécuter l’outil de préparation

Avant de démarrer une installation de serveur, nous vous recommandons de télécharger et d’exécuter la version la plus récente de l’outil mst-readiness . Il s’agit d’un script qui s’exécute sur votre serveur Linux et effectue les actions suivantes :

• Vérifie que le compte Microsoft Entra que vous utilisez pour installer Microsoft Tunnel dispose des rôles requis pour terminer l’inscription.

• Confirme que votre configuration réseau permet à Microsoft Tunnel d'accéder aux points d'extrémité Microsoft requis.

• Vérifie la présence du module ip_tables sur le serveur Linux. Cette vérification a été ajoutée au script le 11 février 2022, lorsque la prise en charge de RHEL 8.5 a été ajoutée. RHEL 8.5 ultérieurement ne charge pas le module ip_tables par défaut. S’ils sont manquants après l’installation du serveur Linux, vous devez charger manuellement le module ip_tables.

L’outil mst-readiness a une dépendance envers jq, un processeur JSON en ligne de commande. Avant d’exécuter l’outil de préparation, vérifiez que jq est installé. Pour plus d’informations sur la façon d’obtenir et d’installerjq, consultez la documentation de la version de Linux que vous utilisez.

Pour utiliser l’outil de préparation

1. Obtenez la version la plus récente de l’outil de préparation à l’aide de l’une des méthodes suivantes :

   • Téléchargez l’outil directement à l’aide d’un navigateur web. Accédez à https://aka.ms/microsofttunnelready pour télécharger un fichier nommé mst-readiness.

   • Connectez-vous à Microsoft Intune centre> d’administrationAdministration> du locataireMicrosoft Tunnel Gateway, sélectionnez l’onglet Serveurs, sélectionnez Créer pour ouvrir le volet Créer un serveur, puis sélectionnez Télécharger l’outil de préparation.

   • Utilisez une commande Linux pour obtenir directement l’outil de préparation. Par exemple, vous pouvez utiliser wget ou curl pour ouvrir le lien https://aka.ms/microsofttunnelready.

     Par exemple, pour utiliser wget et enregistrer les détails pour la préparation mst pendant le téléchargement, exécutez wget --output-document=mst-readiness https://aka.ms/microsofttunnelready

   Le script peut être exécuté à partir de n’importe quel serveur Linux qui se trouve sur le même réseau que le serveur que vous envisagez d’installer, ce qui permet aux administrateurs réseau d’utiliser le script pour résoudre les problèmes réseau indépendamment.

2. Pour valider votre configuration réseau et Linux, exécutez le script avec les commandes suivantes. Ces commandes définissent les autorisations d’exécution pour le script, valident que tunnel peut se connecter aux points de terminaison appropriés, puis case activée la présence d’utilitaires que Tunnel utilise :

   • sudo ./mst-readiness

   • sudo ./mst-readiness network - Cette commande exécute les actions suivantes, puis signale la réussite ou l’erreur pour les deux :

     • Tente de se connecter à chaque point de terminaison Microsoft que le tunnel utilisera.
     • Il vérifie que les ports requis sont ouverts dans votre pare-feu.

   • sudo ./mst-readiness utils - Cette commande vérifie que les utilitaires utilisés par Tunnel comme Docker ou Podman et ip_tables sont disponibles.

3. Pour vérifier que le compte que vous utiliserez pour installer Microsoft Tunnel dispose des rôles et des autorisations nécessaires pour terminer l’inscription, exécutez le script avec la ligne de commande suivante : ./mst-readiness account

   Le script vous invite à utiliser un autre ordinateur avec un navigateur web, que vous utilisez pour vous authentifier pour Microsoft Entra ID et pour Intune. L’outil signale une réussite ou une erreur.

Pour plus d'informations sur cet outil, voir Référence pour mst-cli dans l'article de référence pour Microsoft Tunnel.

Charger manuellement les ip_tables

Bien que la plupart des distributions Linux chargent automatiquement ip_tables module, certaines distributions peuvent ne pas le faire. Par exemple, RHEL 8.5 ne charge pas le ip_tables par défaut.

Pour vérifier la présence de ce module, exécutez la version la plus récente de l’outil mst-readiness sur le serveur Linux. La vérification de ip_tables a été ajoutée au script des outils de préparation le 11 février 2022.

Si le module n’est pas présent, l’outil s’arrête sur le ip_tables module case activée. Dans ce scénario, vous pouvez exécuter les commandes suivantes pour charger manuellement le module.

Charger manuellement le module ip_tables

Dans le contexte de sudo, exécutez les commandes suivantes sur votre serveur Linux :

1. Valider la présence de ip_tables sur le serveur : lsmod |grep ip_tables

2. Si ip_tables n’est pas présent, exécutez la commande suivante pour charger immédiatement le module dans le noyau, sans redémarrage : /sbin/modprobe ip_tables

3. Réexécutez la validation pour confirmer que les tables sont maintenant chargées : lsmod |grep ip_tables

Configurer Linux pour charger ip_tables au démarrage

Dans le contexte de sudo, exécutez la commande suivante sur votre serveur Linux pour créer un fichier de configuration qui charge le ip_tables dans le noyau au moment du démarrage : echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Charger manuellement le module tun

Microsoft Tunnel nécessite le module tun , mais certaines distributions Linux ne chargent pas le module tun par défaut.

Pour valider la présence du module tun sur le serveur, exécutez : lsmod |grep tun

1. Si tun n’est pas présent, exécutez la commande suivante pour charger immédiatement le module dans le noyau, sans redémarrage : /sbin/modprobe tun

2. Réexécutez la validation pour confirmer que le module tun est maintenant chargé : lsmod |grep tun

Configurer Linux pour charger tun au démarrage

Dans le contexte de sudo, exécutez la commande suivante sur votre serveur Linux pour créer un fichier de configuration qui charge tun dans le noyau au moment du démarrage : echo tun > /etc/modules-load.d/mstunnel_tun.conf

Prochaines étapes

Configurer Microsoft Tunnel