Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Après l’installation de Microsoft Tunnel, vous pouvez afficher la configuration et l’intégrité du serveur dans le Centre d’administration Microsoft Intune.
Utiliser l’interface utilisateur du centre d’administration
Connectez-vous au centre d’administration Microsoft Intune et accédez à Administration des clients> MicrosoftTunnel Gateway>Health status.
Ensuite, sélectionnez un serveur, puis ouvrez l’onglet Health case activée pour afficher les mesures de status d’intégrité des serveurs. Par défaut, chaque métrique utilise des valeurs de seuil prédéfinies qui déterminent l’état. Les métriques suivantes prennent en charge la personnalisation de ces seuils :
- Utilisation du processeur
- Utilisation de la mémoire
- Utilisation de l’espace disque
- Latence
Valeurs par défaut pour les mesures d’intégrité du serveur :
Dernier archivage : date du dernier archivage du serveur Tunnel Gateway avec Intune.
- Sain : le dernier archivage a été effectué au cours des cinq dernières minutes.
- Non sain – La dernière case activée remonte à plus de cinq minutes.
Connexions actives : nombre de connexions uniques actives lors du dernier archivage du serveur.
- Sain : il y avait 4 990 connexions ou moins
- Non sain : il y avait plus de 4 990 connexions actives
Débit : mégabits par seconde du trafic passant par la carte réseau Tunnel Gateway lors du dernier archivage du serveur.
Utilisation du processeur : utilisation moyenne du processeur par le serveur Tunnel Gateway toutes les cinq minutes.
- Sain : 95 % ou moins
- Avertissement :96 % à 99 %
- Non sain : 100 % d’utilisation
Cœurs de processeur : nombre de cœurs de processeur disponibles sur ce serveur.
- Sain - 4 cœurs ou plus
- Avertissement - 1, 2 ou 3 cœurs
- Défectueux -0 cœur
Utilisation de la mémoire : mémoire moyenne utilisée par le serveur Tunnel Gateway toutes les 5 minutes.
- Sain : 95 % ou moins
- Avertissement :96 % à 99 %
- Non sain : 100 % d’utilisation
Utilisation de l’espace disque : quantité d’espace disque utilisée par le serveur Tunnel Gateway.
- Sain - Plus de 5 Go
- Avertissement - 3-5 Go
- Non sain - Inférieur à 3 Go
Latence : durée moyenne nécessaire aux paquets IP pour arriver dans l’interface réseau puis en sortir.
- Sain : moins de 10 millisecondes
- Avertissement : 10 à 20 millisecondes
- Non sain : plus de 20 millisecondes
Certificat d’agent de gestion – Le certificat d’agent de gestion est utilisé par Tunnel Gateway pour s’authentifier auprès d’Intune. Il est donc important de le renouveler avant son expiration. Cependant, il devrait se renouveler automatiquement.
- Sain : l’expiration du certificat est dans plus de 30 jours.
- Avertissement : l’expiration du certificat est dans moins de 30 jours.
- Non sain : le certificat a expiré.
Certificat TLS : nombre de jours avant l’expiration du certificat TLS (Transport Layer Security) qui sécurise le trafic entre les clients et le serveur de passerelle de tunnel.
- Sain : plus de 30 jours
- Avertissement : 30 jours ou moins
- Non sain : le certificat a expiré
Révocation de certificats TLS : Tunnel Gateway tente de case activée le status de révocation du certificat TLS (Transport Layer Security) à l’aide d’une adresse OCSP (Online Certificate Status Protocol) ou de liste de révocation de certificats (CRL) telle que définie par le certificat TLS. Cette case activée exige que le serveur ait accès au point de terminaison OCSP ou à l’adresse de CRL comme défini dans le certificat.
- Sain : le certificat TLS n’est pas révoqué.
- Avertissement - Impossible de vérifier si le certificat TLS est révoqué en case activée. Assurez-vous que les points de terminaison définis dans le certificat sont accessibles à partir du serveur de tunnel.
- Non sain : le certificat TLS est révoqué.
Planifier le remplacement d’un certificat TLS révoqué.
Pour en savoir plus sur le protocole OCSP (Online Certificate Status Protocol), consultez la page wikipedia.org sur le protocole d’état du certificat en ligne .
Accessibilité du réseau interne : état de la vérification la plus récente de l’URL interne. Vous configurez l’URL dans le cadre d’une configuration de site Tunnel.
- Sain : le serveur peut accéder à l’URL spécifiée dans les propriétés du site.
- Non sain : le serveur ne peut pas accéder à l’URL spécifiée dans les propriétés du site.
- Inconnu : cet état s’affiche lorsque vous n’avez pas défini d’URL dans les propriétés du site. Cet état n’affecte pas l’état global du site.
Évolutivité – Capacité du serveur à contacter le référentiel de conteneurs Microsoft, ce qui permet à Tunnel Gateway de se mettre à niveau lorsque les versions sont disponibles.
- Sain : le serveur n’a pas contacté le référentiel de conteneurs Microsoft au cours des 5 dernières minutes.
- Non sain : le serveur n’a pas contacté le référentiel de conteneurs Microsoft pendant plus de 5 minutes.
Version du serveur : état du logiciel du serveur de passerelle Tunnel, par rapport à la dernière version.
- Sain : à jour avec la dernière version logicielle
- Avertissement : une version de retard
- Non sain : au moins deux versions de retard, hors support
Lorsque la Version du serveur n’est pas Sain, prévoyez d’installer des mises à niveau pour Microsoft Tunnel.
Conteneur serveur : détermine si le conteneur hébergeant le serveur Microsoft Tunnel est en cours d’exécution.
- Sain : le status du conteneur Server est sain.
- Non sain : le status du conteneur serveur n’est pas sain.
Configuration du serveur : détermine si la configuration du serveur est appliquée correctement au serveur de tunnel à partir des paramètres du site Microsoft Intune.
- Sain : la configuration du serveur a été appliquée avec succès.
- Non sain : la configuration du serveur n’a pas pu être appliquée.
Journaux du serveur – Détermine si les journaux ont été téléchargés sur le serveur au cours des 60 dernières minutes.
- Sain : les journaux du serveur ont été téléchargés au cours des 60 dernières minutes.
- Non sain : les journaux du serveur n’ont pas été téléchargés au cours des 60 dernières minutes.
Gérer les seuils d’état d’intégrité
Vous pouvez personnaliser les métriques d’état d’intégrité Microsoft Tunnel suivantes pour modifier les seuils utilisés par chacun pour signaler leur état. Les personnalisations sont à l’échelle de l’abonné et s’appliquent à tous les serveurs Tunnel. Les mesures de vérification d’intégrité que vous pouvez personnaliser sont les suivantes :
- Utilisation du processeur
- Utilisation de la mémoire
- Utilisation de l’espace disque
- Latence
Pour modifier une valeur de seuil de mesures :
Connectez-vous au centre d’administration Microsoft Intune et accédez à Administration des clients>Microsoft Tunnel Gateway>Health status.
Sélectionnez Configurer des seuils.
Sur la page Seuils configurés, définissez de nouveaux seuils pour chaque catégorie de case activée de l’intégrité que vous souhaitez personnaliser.
- Les valeurs des seuils s’appliquent à tous les serveurs de tous les sites.
- Sélectionnez Rétablir les valeurs par défaut pour restaurer les valeurs par défaut de tous les seuils.
Sélectionnez Enregistrer.
Dans le volet État d’intégrité, sélectionnez Actualiser pour mettre à jour l’état de tous les serveurs en fonction des valeurs de seuil personnalisées.
Une fois que vous avez modifié les seuils, les valeurs sous l’onglet Vérification de l'intégrité des serveurs sont automatiquement mises à jour pour refléter leur état, en fonction des seuils actuels.
Tendances de l’état d’intégrité pour les serveurs Tunnel
Affichez les tendances de l’état d’intégrité des mesures d’intégrité de la passerelle Microsoft Tunnel sous la forme d’un graphique. La moyenne des données des graphiques est calculée sur un bloc de trois heures et peut être retardée jusqu’à trois heures.
Les graphiques des tendances de l’état d’intégrité sont disponibles pour les mesures suivantes :
- Connexions
- Utilisation du processeur
- Utilisation de l’espace disque
- Utilisation de la mémoire
- Latence moyenne
- Débit
Pour afficher les graphiques de tendances :
Connectez-vous au Centre d’administration Microsoft Intune.
Allez à Administration de l’abonné>Passerelle Microsoft Tunnel>État d’intégrité>Sélectionner un serveur puis sélectionnez Tendances
Utilisez la liste déroulante Métrique pour sélectionner le graphique de métriques que vous souhaitez afficher.
Utiliser l’outil en ligne de commande mst-cli
Utilisez l’outil de ligne de commande mst-cli pour obtenir des informations sur le serveur Microsoft tunnel. Ce fichier est ajouté au serveur Linux lors de l’installation de Microsoft Tunnel. L’outil se trouve à l’emplacement suivant : /usr/sbin/mst-cli.
Pour plus d’informations et pour obtenir des exemples de ligne de commande, consultez outil en ligne de commande mst-cli pour Microsoft Tunnel.
Afficher les journaux Microsoft Tunnel
Microsoft Tunnel enregistre les informations dans les journaux de serveur Linux au format syslog. Pour afficher les entrées de journaux, utilisez la commande journalctl -t suivie d’une ou plusieurs étiquettes propres aux entrées Microsoft Tunnel :
mstunnel-agent: afficher les journaux de l’agent.
mstunnel_monitor: afficher les journaux des tâches de surveillance.
ocserv - Affiche les journaux du serveur.
ocserv-access – Afficher les journaux d’accès.
Par défaut, la journalisation des accès est désactivée. L’activation des journaux d’accès peut réduire les performances, en fonction du nombre de connexions actives et de modèles d’utilisation sur le serveur. La journalisation des connexions DNS augmente la verbosité des journaux, lesquels peuvent devenir bruyants.
Les journaux d’accès présentent le format suivant :
<Server timestamp><Server Name><ProcessID on Server><userId><deviceId><protocol><src IP and port><dst IP and port><bytes sent><bytes received><connection time in seconds>Par exemple :- Feb 25 16:37:56 MSTunnelTest-VM ocserv-access[9528]: ACCESS_LOG,41150dc4-238x-4dwv-9q89-55e987f30c32,f5132455-ef2dd-225a-a693-afbbqed482dce,tcp,169.254.54.149:49462,10.88.0.5:80,112,60,10
Importante
Dans ocserv-access, la valeur deviceId identifie l’instance d’installation unique de Microsoft Defender qui s’exécute sur un appareil et n’identifie pas l’ID d’appareil Intune ou l’ID d’appareil Microsoft Entra. Si Defender est désinstallé puis réinstallé sur un appareil, une nouvelle instance pour le DeviceId* est générée.
Pour activer la journalisation des accès :
- définissez TRACE_SESSIONS=1 dans /etc/mstunnel/env.sh
- définissez TRACE_SESSIONS=2 pour inclure la journalisation pour les connexions DNS
- Exécutez
mst-cli server restartpour redémarrer le serveur.
Si les journaux d’accès sont trop bruyants, vous pouvez désactiver la journalisation des connexions DNS en définissant TRACE_SESSIONS=1 et en redémarrant le serveur.
OCSERV_TELEMETRY : affiche les détails de télémétrie pour les connexions au tunnel.
Les journaux de télémétrie ont le format suivant, les valeurs de bytes_in, bytes_out et durée étant utilisées uniquement pour les opérations de déconnexion :
<operation><client_ip><server_ip><gateway_ip><assigned_ip><user_id><device_id><user_agent><bytes_in><bytes_out><duration>Par exemple :- 20 oct 19:32:15 mstunnel ocserv[4806] : OCSERV_TELEMETRY,connect,31258,73.20.85.75,172.17.0.3,169.254.0.1,169.254.107.209,3780e1fc-3ac2-4268-a1fd-dd910ca8c13c, 5A683ECC-D909-4E5F-9C67-C0F595A4A70E,MobileAccess iOS 1.1.34040102
Importante
En OCSERV_TELEMETRY, la valeur deviceId identifie le instance d’installation unique de Microsoft Defender qui s’exécute sur un appareil, et n’identifie ni l’ID de périphérique Intune ou Microsoft Entra’ID d’appareil. Si Defender est désinstallé puis réinstallé sur un appareil, une nouvelle instance pour le DeviceId* est générée.
Exemples de ligne de commande pour journalctl :
- Pour afficher uniquement les informations relatives au serveur de tunnel, exécutez
journalctl -t ocserv. - Pour afficher le journal de télémétrie, exécutez
journalctl -t ocserv | grep TELEMETRY - Pour afficher les informations relatives aux options de journal, vous pouvez exécuter
journalctl -t ocserv -t ocserv-access -t mstunnel-agent -t mstunnel_monitor. - Ajoutez
-fà la commande pour afficher une vue active et continue du fichier journal. Par exemple, pour superviser activement les processus en cours pour Microsoft Tunnel, exécutezjournalctl -t mstunnel_monitor -f.
Options supplémentaires pour journalctl :
-
journalctl -h: afficher l’aide de la commande pour journalctl. -
man journalctl: afficher des informations supplémentaires. -
man journalctl.conf: afficher des informations sur la configuration. Pour plus d’informations sur journalctl, consultez la documentation de la version de Linux que vous utilisez.
Téléchargement facile des journaux de diagnostic pour les serveurs de tunnel
En guise d’aide au diagnostic, vous pouvez utiliser un simple clic dans le Centre d’administration Intune pour qu’Intune active, collecte et envoie les journaux détaillés à partir d’un serveur de passerelle de tunnel directement à Microsoft. Ces journaux détaillés sont ensuite directement disponibles pour Microsoft lorsque vous travaillez avec Microsoft pour identifier ou résoudre des problèmes avec un serveur de tunnel.
Vous pouvez collecter et télécharger les journaux détaillés à partir d’un événement avant d’ouvrir un incident de support, ou sur demande si vous travaillez déjà avec Microsoft pour examiner une opération de serveurs de tunnel.
Pour utiliser cette fonctionnalité :
Ouvrez le Centre d’administration Microsoft Intune, accédez à Administration> des clients, MicrosoftTunnel Gateway>, sélectionnez un serveur>, puis sélectionnez l’onglet Journaux.
Dans l’onglet Journaux , recherchez la section Envoyer les journaux du serveur détaillé et sélectionnez Envoyer les journaux.
Lorsque vous sélectionnez Envoyer les journaux pour un serveur de tunnel, le processus suivant commence :
- Tout d’abord, Intune capture l’ensemble actuel des journaux du serveur de tunnel et les charge directement dans Microsoft. Ces journaux sont collectés à l’aide du niveau de détail du journal actuel du serveur. Par défaut, le niveau de détail du serveur est zéro (0).
- Ensuite, Intune active un niveau de détail de quatre (4) pour les journaux du serveur de tunnel. Ce niveau de détail est collecté pendant huit heures.
- Pendant les huit heures de collecte des journaux détaillés, le problème ou l’opération faisant l’objet de l’enquête doit être reproduit pour capturer les détails détaillés dans les journaux.
- Au bout de huit heures, Intune recueille un deuxième ensemble de journaux du serveur qui inclut les détails détaillés et les télécharge vers Microsoft. Au moment du téléchargement, Intune réinitialise également les journaux du serveur de tunnel pour utiliser le niveau de détail par défaut de zéro (0). Si vous avez précédemment relevé le niveau de détail du serveur, une fois qu’Intune a réinitialisé le niveau de détail à zéro, vous pouvez restaurer votre niveau de détail personnalisé.
Chaque ensemble de journaux collectés et téléchargés par Intune est identifié en tant qu’ensemble distinct, avec les détails suivants qui apparaissent dans le Centre d’administration sous le bouton Envoyer les journaux :
- Heure de début et de fin de la collecte du journal
- La date de génération du chargement
- Le journal définit le niveau de détail
- Le status de la collecte du journal (terminé, en échec ou en cours)
Une fois que vous avez reproduit un problème pendant la phase de collecte des journaux détaillés, Microsoft peut utiliser les journaux collectés pour l’examiner.
À propos de la collecte de journaux
- Intune n’arrête pas et ne redémarre pas le serveur de tunnel pour activer ou désactiver la journalisation détaillée.
- La période de journalisation détaillée de huit heures ne peut pas être prolongée ou arrêtée prématurément.
- Vous pouvez utiliser le processus Envoyer les journaux aussi souvent que nécessaire pour capturer un problème de journalisation détaillée. Toutefois, l’augmentation du niveau de détail du journal ajoute une contrainte sur le serveur de tunnel et n’est pas recommandée comme configuration régulière.
- Une fois la journalisation détaillée terminée, le niveau de détail par défaut zéro est défini pour les journaux du serveur Tunnel, quels que soient les niveaux de détail précédemment définis.
- Les journaux suivants sont collectés via ce processus :
- mstunnel-agent (journaux de l’agent)
- mstunnel_monitor (surveillance des journaux des tâches)
- ocserv (journaux du serveur)
Les journaux d’accès à ocserv ne sont ni collectés ni téléchargés.
Problèmes détectés
Voici les problèmes connus de Microsoft Tunnel.
Intégrité du serveur
Les clients peuvent utiliser le tunnel lorsque les status d’intégrité du serveur s’affichent comme hors connexion
Problème : sous l’onglet Intégrité du tunnel, le status status d’intégrité d’un serveur est signalé comme étant hors connexion, ce qui indique qu’il est déconnecté, même si les utilisateurs peuvent accéder au serveur de tunnel et se connecter aux ressources du organization.
Solution : pour résoudre ce problème, vous devez réinstaller Microsoft Tunnel, qui réinscrit l’agent du serveur Tunnel auprès d’Intune. Pour éviter ce problème, installez les mises à jour pour l’agent de tunnel et le serveur peu après leur publication. Utilisez les métriques d’intégrité du serveur Tunnel dans le Centre d’administration Microsoft Intune pour surveiller l’intégrité du serveur.
Avec Podman, vous voyez « Erreur lors de l’exécution de la vérification » dans le journal mstunnel_monitor
Problème : Podman ne parvient pas à identifier ou à voir les conteneurs actifs en cours d’exécution et signale une « erreur lors de l’exécution de la vérification » dans le journal mstunnel_monitor du serveur de tunnel. Voici des exemples d’erreurs :
Agent :
Error executing Checkup Error details \tscript: 561 /usr/sbin/mst-cli \t\tcommand: $ctr_cli exec $agent_name mstunnel checkup 2> >(FailLogger) \tstack: \t\t<> Checkup /usr/sbin/mst-cli Message: NA \t\t<> MonitorServices /usr/sbin/mst-cli Message: Failure starting service mstunnel-agent \t\t<> main /usr/sbin/mstunnel_monitor Message: NAServeur :
Error executing Checkup Error details \tscript: 649 /usr/sbin/mst-cli \t\tcommand: $ctr_cli exec $agent_name mstunnel checkup 2> >(FailLogger) \tstack: \t\t<> Checkup /usr/sbin/mst-cli Message: NA \t\t<> MonitorServices /usr/sbin/mst-cli Message: Failure starting service mstunnel-server \t\t<> main /usr/sbin/mstunnel_monitor Message: NA
Solution : Pour résoudre ce problème, redémarrez manuellement les conteneurs Podman. Podman devrait alors être en mesure d’identifier les conteneurs. Si le problème persiste ou se reproduit, envisagez d’utiliser cron pour créer une tâche qui redémarre automatiquement les conteneurs lorsque ce problème se produit.
Avec Podman, vous voyez des erreurs System.DateTime dans le journal mstunnel-agent
Problème : Lorsque vous utilisez Podman, le journal mstunnel-agent peut contenir des erreurs similaires aux entrées suivantes :
Failed to parse version-info.json for version information.System.Text.Json.JsonException: The JSON value could not be converted to System.DateTime
Ce problème se produit en raison de différences de formatage des dates entre Podman et Tunnel Agent. Ces erreurs n’indiquent pas de problème irrécupérable ni n’empêchent la connectivité. À partir des conteneurs publiés après octobre 2022, les problèmes de mise en forme doivent être résolus.
Solution : Pour résoudre ces problèmes, mettez à jour le conteneur de l’agent (Podman ou Docker) vers la dernière version. Au fur et à mesure que de nouvelles sources de ces erreurs seront découvertes, nous continuerons à les corriger dans les mises à jour de versions ultérieures.
Connectivité au tunnel
Les appareils ne parviennent pas à se connecter au serveur Tunnel
Problème : Les appareils ne parviennent pas à se connecter au serveur et le fichier journal OCSERV du serveur de tunnel contient une entrée similaire à l’entrée suivante : main: tun.c:655: Can't open /dev/net/tun: Operation not permitted
Pour obtenir des conseils sur l’affichage des journaux Tunnel, consultez Afficher les journaux Microsoft Tunnel dans cet article.
Solution : Redémarrez le serveur en utilisant mst-cli server restart après le redémarrage du serveur Linux.
Si ce problème persiste, envisagez d’automatiser la commande de redémarrage à l’aide de l’utilitaire de planification cron. Découvrez comment utiliser cron sur Linux sur opensource.com.