Supervision VPN d’Azure Site : associer l’état du tunnel à une sonde réelle

Tous les tableaux de bord sont verts, le tunnel est monté depuis onze jours, et la succursale ne peut pas charger l’application interne. C’est le symptôme pour lequel ce design existe, et ce n’est pas un bug de supervision. L’état du tunnel répond à une question sur la négociation, alors que l’utilisateur pose une question sur une requête qui traverse quatre décisions de routage et une couche de politiques. Il faut les deux signaux, tenus séparés, et un moyen de les distinguer au milieu de la nuit.

Partez du symptôme défaillant, pas du tunnel

Une association de sécurité établie signifie que les pairs se sont mis d’accord sur une proposition et ont installé des clés. Cela ne signifie pas que les sélecteurs couvrent le sous-réseau dont l’utilisateur a besoin, que le côté distant a une route de retour, ou qu’un pare-feu accepte le port après déchiffrement. Le trafic peut aussi échouer du côté succursale du tunnel, et Azure ne voit alors rien et rapporte une santé parfaite. La métrique du tunnel est nécessaire et jamais suffisante.

Trois états doivent être distinguables : le tunnel est en panne, le tunnel est monté et le service échoue, et la source de supervision elle-même est indisponible.

Placez la sonde là où sont les utilisateurs

Pour une application de succursale vers Azure, exécutez le test synthétique depuis un hôte du réseau de charge de travail de la succursale et pointez-le vers le point d’entrée HTTPS privé que les utilisateurs atteignent réellement. Une sonde lancée depuis la passerelle utilise une autre adresse source et souvent un autre chemin de politique, elle peut donc réussir alors que tous les utilisateurs échouent. Azure Connection Monitor prend en charge les contrôles TCP, ICMP et HTTP avec des groupes de test et des seuils, et ses sources locales ont des exigences d’agent différentes de celles du côté Azure. Vérifiez la disposition actuellement prise en charge au lieu de copier une recette classique de supervision retirée d’un blog.

Gardez la sonde étroite et ennuyeuse : une destination, un port, une fréquence conforme à l’exigence d’exploitation, et une règle d’autorisation explicite pour cette source.

Choisissez un contrôle qui correspond au service

Une connexion TCP au port du service prouve l’accessibilité du transport à travers le tunnel et ne dit rien de TLS ni de l’application. Un contrôle HTTP ajoute une attente de statut et attrape un écouteur qui accepte les connexions mais ne peut pas servir, ce qui est la défaillance la plus courante après un changement de certificat ou de backend. Aucun des deux n’est une transaction métier authentifiée si le test n’authentifie pas réellement, donc ne l’étiquetez pas comme telle sur le tableau de bord. Choisissez le contrôle qui échoue lorsque la plainte de l’utilisateur survient.

ICMP est la plus faible des trois options, car beaucoup de piles le rejettent par politique et un ping échoué prouve très peu.

Amenez les deux signaux dans Elastic sans les inventer

La passerelle VPN émet des métriques de plateforme comme les octets sortants et entrants du tunnel et les compteurs de paquets perdus, et elle peut envoyer des journaux de diagnostic dans des catégories incluant les événements de tunnel et IKE. Les résultats de Connection Monitor arrivent via Azure Monitor comme métriques et via un espace de travail Log Analytics comme enregistrements de journal. Rien de tout cela n’apparaît de lui-même dans un index Elastic. Choisissez un pipeline pris en charge pour les métriques et un autre pour les journaux, généralement l’entrée Azure Event Hub ou l’intégration Azure Monitor, et vérifiez ce que l’intégration installée ingère réellement avant de faire confiance au modèle d’index.

Conservez les étiquettes qui permettent à un opérateur de joindre les deux jeux de données : point de terminaison source, destination, protocole et port pour la sonde, et identité du tunnel plus adresse du pair pour la passerelle.

Validez le pipeline avec un événement contrôlé, puis recherchez-le dans Elastic et vérifiez son horodatage et ses étiquettes de ressources. Un document avec un horodatage erroné est pire qu’un document absent, car il fait passer des données obsolètes pour actuelles.

Alertez sur la différence, pas sur la couleur

L’intérêt de tenir deux signaux, ce sont les combinaisons. Tunnel en panne devrait alerter le responsable réseau ; tunnel monté avec une sonde en échec le responsable applicatif ; un résultat de sonde manquant celui qui possède l’agent de supervision. Fusionner les trois dans un seul panneau rouge garantit que l’alerte sera coupée en un mois. Alertez sur un échec soutenu avec une fenêtre de persistance plutôt que sur un seul échantillon, et ajoutez un contrôle séparé pour la santé du pipeline d’ingestion lui-même.

Un tableau de bord rempli d’échantillons réussis d’hier ne devrait pas se lire comme un chemin sain aujourd’hui.

Écrit, le contrat est petit : la métrique du tunnel dit que la passerelle a négocié, la sonde dit que le chemin fonctionne depuis là où sont les utilisateurs, et la santé du pipeline dit si l’une ou l’autre réponse est à jour. Tout le reste sur le tableau de bord est du commentaire.