Cloud

Azure : rendre les chemins privés vérifiables avec des probes synthétiques

Construire des probes synthétiques utiles pour contrôler DNS, TLS, Application Gateway, WAF et Private Endpoint avant qu’un chemin privé Azure ne casse en production.

06 juin 2026 azureprivate-endpointdnsapplication-gatewaywafmonitoringkqlrunbookautomation

Un chemin privé Azure peut être correct sur le papier et fragile en exploitation. Le Private Endpoint existe, la zone DNS privée est liée, Application Gateway voit un backend, le WAF journalise des requêtes, mais personne ne sait rapidement si le chemin complet fonctionne depuis le bon réseau, avec le bon nom, le bon certificat et le comportement applicatif attendu.

Le cas d’usage est simple : une application interne est publiée derrière Application Gateway, consomme un backend privé via Private Endpoint et dépend d’une résolution DNS hybride. L’équipe veut détecter une dérive avant l’incident, pas seulement constater un 502, un timeout ou une vague de blocages WAF après déploiement. Les probes synthétiques deviennent alors un contrôle d’exploitation, pas un gadget de monitoring.

Tester le chemin réel, pas seulement la ressource

Une probe utile ne vérifie pas seulement qu’une ressource Azure existe. Elle traverse le chemin que le service ou l’utilisateur emprunte réellement. Pour un backend privé, cela signifie partir d’un point de test représentatif : runner CI dans le réseau privé, VM d’administration, container de diagnostic ou worker de supervision autorisé.

Le contrôle doit séparer plusieurs questions :

  • le nom applicatif résout-il vers l’adresse privée attendue ?
  • la chaîne CNAME passe-t-elle par le domaine privatelink prévu ?
  • le port répond-il depuis le réseau consommateur ?
  • le certificat présenté correspond-il au nom utilisé ?
  • Application Gateway voit-il le backend comme sain ?
  • le WAF bloque-t-il une requête légitime de probe ?
  • l’application retourne-t-elle un statut attendu sur un endpoint léger ?

Ces questions doivent rester séparées. Une probe qui retourne seulement down oblige l’équipe à recommencer le diagnostic à zéro.

Construire une matrice de probe minimale

Le bon point de départ est une matrice courte. Elle relie chaque contrôle à une preuve, un seuil et une action attendue. L’objectif n’est pas d’obtenir une supervision parfaite, mais d’éviter les alertes impossibles à exploiter.

text matrice-probes-chemin-prive.txt 
Contrôle
DNS public attendu fermé
DNS privé depuis workload
Connexion TCP au backend
TLS avec hostname applicatif
Health probe Application Gateway
Requête applicative légère
Logs WAF sur la même fenêtre

Preuve attendue
Adresse privée ou échec contrôlé
CNAME privatelink cohérent
Port ouvert depuis le bon réseau
Certificat valide pour le nom
Backend healthy
HTTP 200, 204 ou statut métier attendu
Aucun blocage inattendu sur la probe

La matrice doit être versionnée avec le runbook. Quand un endpoint change, l’équipe sait quel contrôle mettre à jour et quel comportement reste acceptable.

Ne pas mélanger probe DNS et probe applicative

Un échec DNS n’a pas le même sens qu’un échec applicatif. Si le nom résout encore vers une adresse publique, le problème est probablement dans la zone privée, le lien de VNet, le forwarding hybride ou le cache du résolveur. Si le DNS est correct mais que la requête HTTP échoue, le diagnostic se déplace vers Application Gateway, TLS, health probe, WAF ou application.

La probe DNS doit donc être explicite :

bash probe-dns-chemin-prive.sh 
HOST=api.internal.example.com

dig +short "$HOST"
dig +short CNAME "$HOST"

resolved_ip="$(dig +short "$HOST" | tail -n 1)"
case "$resolved_ip" in
10.*|172.16.*|172.17.*|172.18.*|172.19.*|172.2*|172.30.*|172.31.*|192.168.*)
  echo "private_dns_ok=$resolved_ip"
  ;;
*)
  echo "private_dns_unexpected=$resolved_ip"
  exit 2
  ;;
esac

Ce type de probe peut tourner depuis un runner autorisé. Elle ne prouve pas que l’application fonctionne, mais elle évite de confondre un problème de nommage avec un problème applicatif.

Vérifier TLS avec le vrai hostname

Beaucoup de diagnostics Application Gateway deviennent flous quand le backend est interrogé avec une IP, un nom technique ou un hostname différent de celui utilisé par la configuration. La probe TLS doit reprendre le nom réellement attendu par le backend ou par Application Gateway.

bash probe-tls-hostname.sh 
HOST=api.internal.example.com
PORT=443

echo | openssl s_client -connect "$HOST:$PORT" -servername "$HOST" 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Le résultat doit être lu dans le contexte du chemin : certificat expiré, mauvais SAN, SNI absent, backend setting incorrect ou probe Application Gateway qui n’utilise pas le bon hostname. L’intérêt est de produire une preuve rapide avant de modifier le routage.

Relier la probe aux logs WAF et Application Gateway

Une probe synthétique doit laisser assez de traces pour être retrouvée. Utiliser un user-agent dédié ou un header de corrélation permet de filtrer les logs sans polluer l’analyse.

bash probe-http-correlated.sh 
HOST=https://api.internal.example.com/healthz
RUN_ID="synthetic-private-path-$(date -u +%Y%m%d%H%M)"

curl -fsS "$HOST" -H "User-Agent: naxaya-private-path-probe" -H "X-Probe-Run: $RUN_ID" --max-time 5

Dans les logs, ce marqueur permet de distinguer une vraie panne d’un bruit de trafic utilisateur. Il permet aussi de vérifier que le WAF n’a pas commencé à bloquer la probe après un changement de règle.

Définir le runbook avant l’alerte

Une probe qui échoue doit pointer vers une lecture courte. Le runbook ne doit pas commencer par “ouvrir le portail Azure”. Il doit indiquer la première séparation à faire.

text runbook-probe-chemin-prive.txt 
Si la probe DNS échoue
Vérifier CNAME privatelink
Vérifier lien Private DNS Zone / VNet
Vérifier forwarding hybride et cache

Si DNS OK mais TLS échoue
Vérifier SNI, SAN certificat, backend setting et expiration

Si TLS OK mais HTTP échoue
Vérifier health probe Application Gateway, backend pool et logs applicatifs

Si HTTP attendu mais WAF bloque
Lire ruleId, match field, URI et user-agent en KQL

Si tout est OK depuis une VM mais KO depuis CI
Comparer identité, DNS resolver, route et réseau du runner

Cette structure réduit le temps perdu pendant l’incident. Elle évite aussi les corrections trop rapides : modifier le WAF alors que le DNS dérive, ou changer l’application alors que la health probe ne porte pas le bon hostname.

Automatiser sans rendre le diagnostic opaque

Les probes synthétiques peuvent être lancées par un job planifié, un pipeline, un script AWX ou une fonction de supervision. L’automatisation est utile si elle garde les résultats lisibles : sortie DNS, statut TLS, code HTTP, identifiant de run, lien vers les logs et dernière modification connue.

Un bon signal d’alerte doit rester précis :

  • private_dns_unexpected
  • tls_hostname_mismatch
  • appgw_backend_unhealthy
  • waf_blocked_synthetic_probe
  • http_status_unexpected
  • ci_runner_path_differs_from_workload

Ces noms sont plus utiles qu’une alerte unique “probe failed”. Ils alimentent mieux les tags, les parcours et l’Atlas des pannes, parce qu’ils décrivent un symptôme exploitable.

Conclusion

Une probe synthétique n’est utile que si elle traverse le vrai chemin et produit une preuve lisible. Pour les chemins privés Azure, elle doit séparer DNS, réseau, TLS, Application Gateway, WAF et comportement applicatif, puis relier chaque échec à un premier contrôle.

Le gain n’est pas seulement de savoir qu’un endpoint répond. C’est de transformer un chemin privé difficile à expliquer en runbook mesurable : où tester, quoi observer, quel signal corréler et quelle décision prendre avant de toucher à la configuration.