Résoudre les problèmes de passerelle VPN Azure à l’aide des journaux de diagnostic
Cet article décrit les différents journaux disponibles pour les diagnostics de passerelle VPN et explique comment les utiliser pour résoudre efficacement des problèmes de passerelle VPN.
Si le problème que vous rencontrez avec Azure n’est pas traité dans cet article, parcourez les forums Azure sur Microsoft Q&A et Stack Overflow. Vous pouvez publier votre problème sur ces forums ou @AzureSupport sur Twitter. Vous pouvez également envoyer une demande de support Azure. Pour envoyer une demande de support sur la page Prise en charge Azure, sélectionnez Obtenir de l’aide.
Les journaux suivants sont disponibles dans Azure :
- GatewayDiagnosticLog
- TunnelDiagnosticLog
- RouteDiagnosticLog
- IKEDiagnosticLog
- P2SDiagnosticLog
Pour les passerelles basées sur des stratégies, seuls GatewayDiagnosticLog et RouteDiagnosticLog sont disponibles.
Pour tous les journaux de passerelle VPN, consultez informations de référence sur les données de surveillance des passerelles VPN Azure.
Pour configurer des événements de journal de diagnostic provenant de la passerelle VPN Azure en utilisant Azure Log Analytics, consultez Créer des paramètres de diagnostic dans Azure Monitor.
GatewayDiagnosticLog
Les changements de configuration sont audités dans la table GatewayDiagnosticLog. Plusieurs minutes peuvent être nécessaires avant que les modifications que vous exécutez soient reflétées dans les journaux.
Ici, vous disposez d’un exemple de requête pour référence.
AzureDiagnostics
| where Category == "GatewayDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
| sort by TimeGenerated asc
Cette requête sur GatewayDiagnosticLog vous montre plusieurs colonnes.
| Nom | Description |
|---|---|
| TimeGenerated | Horodateur de chaque événement dans le fuseau horaire UTC. |
| OperationName | Événement qui s’est produit. Il peut s’agir de SetGatewayConfiguration, SetConnectionConfiguration, HostMaintenanceEvent, GatewayTenantPrimaryChanged, MigrateCustomerSubscription, GatewayResourceMove, ValidateGatewayConfiguration. |
| Message | Détaille l’opération qui se produit et répertorie les résultats en termes de réussite ou d’échec. |
L’exemple suivant montre l’activité journalisée quand une nouvelle configuration a été appliquée :
Notez qu’une SetGatewayConfiguration est journalisée chaque fois qu’une configuration est modifiée sur une passerelle VPN ou de réseau local.
Comparer les résultats de la table GatewayDiagnosticLog avec ceux de la table TunnelDiagnosticLog peut aider à déterminer si une défaillance de connectivité de tunnel s’est produite lors d’un changement de configuration ou d’une opération de maintenance. Si c’est le cas, cela fournit une indication significative de la cause racine potentielle.
TunnelDiagnosticLog
La table TunnelDiagnosticLog est utile pour inspecter l’historique des états de la connectivité du tunnel.
Ici, vous disposez d’un exemple de requête pour référence.
AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
//| where remoteIP_s == "<REMOTE IP OF TUNNEL>"
| project TimeGenerated, OperationName, remoteIP_s, instance_s, Resource, ResourceGroup
| sort by TimeGenerated asc
Cette requête sur TunnelDiagnosticLog vous montre plusieurs colonnes.
| Nom | Description |
|---|---|
| TimeGenerated | Horodateur de chaque événement dans le fuseau horaire UTC. |
| OperationName | Événement qui s’est produit. Il peut s’agir de TunnelConnected ou de TunnelDisconnected. |
| remoteIP_s | Adresse IP de l’appareil VPN local. Dans des scénarios réels, il est utile de filtrer sur l’adresse IP de l’appareil local concerné s’il y en a plusieurs. |
| Instance_s | instance de rôle de passerelle ayant déclenché l’événement. Il peut s’agir de GatewayTenantWorker_IN_0 ou de GatewayTenantWorker_IN_1, qui sont les noms des deux instances de la passerelle. |
| Ressource | Indique le nom de la passerelle VPN. |
| ResourceGroup | Indique le groupe de ressources dans lequel se trouve la passerelle. |
Exemple de sortie :
La table TunnelDiagnosticLog est utile pour résoudre des problèmes liés à des événements passés concernant des déconnexions inattendues des VPN. Sa nature légère offre la possibilité d’analyser des intervalles de temps importants sur plusieurs jours avec un minimum d’effort. Ce n’est qu’après avoir identifié l’horodateur d’une déconnexion, vous pouvez basculer vers l’analyse plus détaillée de la table IKEdiagnosticLog pour approfondir le raisonnement visant à déterminer si les déconnexions sont liées à IPsec.
Conseils de dépannage :
- Si vous voyez un événement de déconnexion sur une instance de passerelle suivi après quelques secondes d’un événement de connexion sur une autre instance de passerelle, cela indique un basculement de passerelle. Un tel événement se produit généralement en raison d’une maintenance effectuée sur une instance de passerelle. Pour en savoir plus sur ce comportement, consultez À propos de la redondance de passerelle VPN Azure.
- Le même comportement est observé si vous exécutez intentionnellement une réinitialisation de passerelle côté Azure, qui entraîne un redémarrage de l’instance de la passerelle active. Pour en savoir plus sur ce comportement, consultez Réinitialiser une passerelle VPN.
- Si vous voyez un événement de déconnexion sur une instance de passerelle suivi après quelques secondes d’un événement de connexion sur la même instance de passerelle, vous avez peut-être affaire à un problème réseau provoquant une expiration de détection d’homologue mort (DPD) ou une déconnexion envoyée par erreur par l’appareil local.
RouteDiagnosticLog
La table RouteDiagnosticLog trace l’activité pour les itinéraires modifiés de manière statique ou reçus via BGP.
Ici, vous disposez d’un exemple de requête pour référence.
AzureDiagnostics
| where Category == "RouteDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
Cette requête sur RouteDiagnosticLog vous montre plusieurs colonnes.
| Nom | Description |
|---|---|
| TimeGenerated | Horodateur de chaque événement dans le fuseau horaire UTC. |
| OperationName | Événement qui s’est produit. Il peut s’agir de StaticRouteUpdate, BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent. |
| Message | Détails de l’opération qui se produit. |
La sortie montre des informations utiles sur les homologues BGP connectés/déconnectés et sur les routes échangées.
Exemple :
IKEDiagnosticLog
La table IKEDiagnosticLog propose une journalisation de débogage détaillée pour IKE/IPSec. Il est utile de les passer en revue pour résoudre les problèmes de déconnexion ou les scénarios d’échec de connexion au VPN.
Ici, vous disposez d’un exemple de requête pour référence.
AzureDiagnostics
| where Category == "IKEDiagnosticLog"
| extend Message1=Message
| parse Message with * "Remote " RemoteIP ":" * "500: Local " LocalIP ":" * "500: " Message2
| extend Event = iif(Message has "SESSION_ID",Message2,Message1)
| project TimeGenerated, RemoteIP, LocalIP, Event, Level
| sort by TimeGenerated asc
Cette requête sur IKEDiagnosticLog vous montre plusieurs colonnes.
| Nom | Description |
|---|---|
| TimeGenerated | Horodateur de chaque événement dans le fuseau horaire UTC. |
| RemoteIP | Adresse IP de l’appareil VPN local. Dans des scénarios réels, il est utile de filtrer sur l’adresse IP de l’appareil local concerné s’il y en a plusieurs. |
| LocalIP | L’adresse IP de la passerelle VPN pour laquelle nous voulons résoudre les problèmes. Dans des scénarios réels, il est utile de filtrer sur l’adresse IP de la passerelle VPN concernée s’il y en a plusieurs dans votre abonnement. |
| Event | Contient un message de diagnostic utile pour la résolution des problèmes. Il commence généralement par un mot clé et font référence aux actions effectuées par la passerelle Azure. [SEND] indique un événement provoqué par un paquet IPsec envoyé par la passerelle Azure. [RECEIVED] indique un événement résultant de la réception d’un paquet envoyé par un appareil local. [LOCAL] indique une action effectuée localement par la passerelle Azure. |
Notez que les colonnes RemoteIP, LocalIP et Event ne sont pas présentes dans la liste des colonnes d’origine de la base de données AzureDiagnostics, mais qu’elles sont ajoutées à la requête en analysant la sortie de la colonne « Message » pour simplifier l’analyse.
Conseils de dépannage :
Pour identifier le début d’une négociation IPsec, vous devez rechercher le message SA_INIT initial. Ce message peut provenir de chaque côté du tunnel. Le côté envoyant le premier paquet est appelé « initiator » dans la terminologie IPsec, tandis que l’autre côté devient « responder ». Le premier message SA_INIT d’initialisation est toujours celui où rCookie = 0.
Si le tunnel IPsec échoue à établir la connexion, Azure fait de nouvelles tentatives répétées au bout de quelques secondes. C’est pourquoi résoudre les problèmes de « VPN en échec » est pratique sur IKEdiagnosticLog, car vous n’avez pas besoin d’attendre un moment spécifique pour reproduire le problème. En outre, l’échec étant en principe toujours le même à chaque tentative, il suffit d’effectuer un zoom sur un « exemple » de négociation en échec à tout moment.
Le message SA_INIT contient les paramètres IPsec que l’homologue souhaite utiliser pour cette négociation IPsec. Le document officiel
Les paramètres IPSec/IKE par défaut sont les paramètres IPSec que la passerelle Azure prend en charge avec les paramètres par défaut.
P2SDiagnosticLog
Le dernier tableau disponible pour les diagnostics VPN est P2SDiagnosticLog. Ce tableau effectue le suivi de l’activité de point à site (uniquement les protocoles IKEv2 et OpenVPN).
Ici, vous disposez d’un exemple de requête pour référence.
AzureDiagnostics
| where Category == "P2SDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
Cette requête sur P2SDiagnosticLog affiche plusieurs colonnes.
| Nom | Description |
|---|---|
| TimeGenerated | Horodateur de chaque événement dans le fuseau horaire UTC. |
| OperationName | Événement qui s’est produit. Ce sera P2SLogEvent. |
| Message | Détails de l’opération qui se produit. |
La sortie montre tous les paramètres de point à site que la passerelle a appliqués ainsi que les stratégies IPsec en place.
En outre, quand un client établit une connexion de point à site en utilisant OpenVPN et l’authentification Microsoft Entra ID, la table enregistre l’activité des paquets comme suit :
[MSG] [default] [OVPN_XXXXXXXXXXXXXXXXXXXXXXXXXXX] Connect request received. IP=0.X.X.X:XXX
[MSG] [default] [OVPN_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] AAD authentication succeeded. Username=***tosouser@contoso.com
[MSG] [default] [OVPN_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] Connection successful. Username=***tosouser@contoso.com IP=10.0.0.1
Remarque
Dans le journal des connexions point à site, le nom d’utilisateur est partiellement masqué. Le premier octet de l’adresse IP de l’utilisateur client est remplacé par un 0.
Étapes suivantes
Pour configurer des alertes sur les journaux de ressources de tunnel, consultez Configurer des alertes sur les journaux de ressources de la passerelle VPN.