Où sont les journaux Azure Point-to-Site VPN ? Regardez dans Monitor

Un utilisateur ne peut pas se connecter à la passerelle point à site, vous ouvrez le panneau de la passerelle, et il n’y a nulle part d’historique des connexions sur la page. Configuration, certificats, état : tout est présent, aucun enregistrement. Les journaux existent, mais ils ne sont pas du tout produits par les pages réseau. Ils proviennent d’un paramètre de diagnostic attaché à la ressource de passerelle, et ce paramètre vit sous Monitor ; c’est pourquoi la première recherche à l’endroit évident ne renvoie rien et les gens concluent que le service ne conserve aucune trace d’audit.

Pourquoi la recherche évidente échoue

Les anciens guides affirment qu’Azure Point-to-Site VPN n’a pas d’audit, et c’était vrai lorsque le service n’exposait aucun enregistrement par connexion. Les passerelles actuelles publient des enregistrements de diagnostic du tunnel, aussi la question utile a changé : non pas s’il existe des journaux, mais quelle ressource les émet et quelle catégorie vous avez activée. Le panneau de la passerelle est une surface de configuration, et les surfaces de configuration servent rarement aussi de visionneuses de journaux. Un paramètre de diagnostic est un objet par ressource, donc la ressource que vous choisissez détermine tout ce qui suit.

L’autre moitié de la confusion est l’authentification. Les connexions point à site basées sur certificat ne génèrent pas d’événement de connexion par utilisateur comme le fait un fournisseur d’identité, donc il n’existe aucun enregistrement d’une personne nommée tapant un mot de passe.

Attachez le paramètre de diagnostic à la ressource de passerelle

Ouvrez Monitor, puis Diagnostic settings, et ajoutez un nouveau paramètre dont la cible est la passerelle de réseau virtuel elle-même et non le réseau virtuel qui la contient. Sélectionnez la catégorie de diagnostic point à site, celle nommée P2SDiagnosticLog, car c’est elle qui porte les enregistrements de connexion par client ; n’ajoutez les catégories tunnel, route ou IKE que pour les erreurs site à site qu’elles couvrent. Envoyez ensuite les données vers un espace de travail Log Analytics que vous contrôlez, avec une période de rétention que vous avez choisie exprès. La plupart des recherches infructueuses sont un paramètre attaché à la mauvaise ressource, et non une fonctionnalité manquante.

Les listes de catégories varient selon le type et la génération de la passerelle. Si la catégorie point à site est absente, la passerelle est peut-être antérieure à la fonctionnalité ou exécute une SKU qui ne l’émet jamais, alors vérifiez les catégories prises en charge avant de chercher un problème d’autorisations. Une passerelle sans catégorie point à site n’est pas cassée ; elle ne peut simplement pas être la source de cet enregistrement, et le substitut le plus proche est la catégorie tunnel ou IKE, qui enregistre l’adresse du client même si elle ne décrit pas une session point à site. Confirmez la liste des catégories avant d’ouvrir un cas de support au sujet de journaux manquants.

Lisez les enregistrements dans la table qu’utilise votre mode

Avec l’ancien mode de collecte, les entrées atterrissent dans la table AzureDiagnostics et la catégorie apparaît comme valeur de colonne ; avec les tables propres à la ressource, la passerelle a sa propre table. Dans tous les cas, interrogez par ressource de passerelle et par une fenêtre autour de la tentative échouée, puis lisez la corrélation plutôt que les lignes individuelles :

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

L’ensemble des colonnes suit votre mode de collecte, alors traitez la requête comme une forme et non comme un script. Ce que vous cherchez, c’est une adresse de client qui apparaît puis disparaît, avec un type de résultat qui n’est pas un succès.

Associez l’enregistrement de la passerelle au point de vue du client

Les journaux de la passerelle décrivent le tunnel, pas pourquoi un ordinateur portable n’a pas réussi à en établir un. Collectez le côté client au même horodatage : le journal des événements Windows pour le client RAS, le journal de connexion macOS ou le texte d’erreur affiché par l’application cliente. Un enregistrement de passerelle sans tentative client correspondante pointe vers le client ; un client qui signale un succès alors que la passerelle n’enregistre rien signifie généralement que le profil vise une autre passerelle.

Gardez les deux moitiés dans le même ticket. Un journal de passerelle seul invite à la mauvaise conclusion, et un journal client seul ne peut pas montrer si le paquet est jamais arrivé.

Si rien n’apparaît à l’un ou l’autre endroit, vérifiez l’horloge du client avant de douter de la plateforme. Des horodatages faussés font échouer la corrélation d’une manière qui ressemble exactement à des données manquantes.

Rétention, portée et l’entrée du runbook

Les enregistrements de tunnel portent des adresses de client et des horodatages de connexion, alors traitez-les comme des données personnelles avec un calendrier de suppression au lieu de laisser la valeur par défaut de la plateforme. Vérifiez aussi que l’espace de travail n’ingère pas toutes les catégories de toutes les ressources de l’abonnement, car un espace de travail bruyant rend la corrélation plus lente que la lecture directe du journal client.

Enfin, écrivez le nom du paramètre, l’espace de travail et les catégories choisies dans le runbook de la passerelle. La prochaine personne qui déboguer un client regardera d’abord le panneau de la passerelle, ne trouvera rien et conclura que les journaux n’existent pas.