Cloud

Azure App Service : diagnostiquer une dérive d'IP sortante avant de changer l'allowlist

Un runbook de production pour qualifier une dérive d'IP sortante App Service avec VNet Integration, NAT Gateway, DNS, UDR, logs destination, validation et rollback avant de modifier une allowlist partenaire.

13 juil. 2026 azureapp-servicevnet-integrationnat-gatewayegressoutbound-ipallowlistdnsudrobservabilityrunbookrollbackproduction

Une dérive d’IP sortante App Service ressemble souvent à une panne applicative ou à une erreur partenaire. L’application continue de fonctionner pour certaines dépendances, mais une API externe renvoie des 403, un SaaS refuse les appels, ou un webhook ne voit plus l’adresse IP attendue. Le réflexe dangereux consiste à ajouter rapidement une nouvelle IP dans l’allowlist pour rétablir le service.

Le cas d’usage est un App Service intégré à un VNet qui sort vers une API partenaire à travers un subnet d’intégration, éventuellement une UDR, un Azure Firewall et un NAT Gateway. L’objectif du runbook est de prouver quelle IP est réellement vue par la destination, pourquoi elle a changé, puis de choisir entre correction réseau, changement d’allowlist contrôlé ou rollback.

Figer le contrat de sortie

Commencez par écrire le contrat de sortie attendu. Une allowlist ne se diagnostique pas avec “l’application ne passe plus”. Il faut lier une application, un hostname, un port, un subnet, un chemin de sortie et une IP publique attendue.

text app-service-egress-contract.txt

Flux a qualifier
Application: app-orders-prod
Plan: asp-prod-linux
Slot: production
Destination: api.partner.example / TCP 443
Integration subnet: snet-appservice-egress-prod
Chemin attendu: App Service -> VNet Integration -> NAT Gateway -> Internet
IP publique attendue: 203.0.113.20
Allowlist destination: partenaire orders-api
Dernier changement connu: association NAT, UDR, subnet integration ou config app

Preuves requises avant changement allowlist
Resolution DNS depuis le contexte applicatif
VNet Integration active sur le bon subnet
NAT Gateway associe au subnet attendu
Route effective ou intention UDR comprise
IP source observee cote destination
Logs App Service, firewall ou partenaire alignes par timestamp
Rollback de configuration ou ancienne IP documentee

Si l’équipe ne connaît pas l’IP qui devrait être vue côté destination, elle ne doit pas élargir l’allowlist. Elle doit d’abord retrouver le chemin de sortie exploitable.

Séparer exposition entrante et sortie réseau

Private Endpoint peut exister sur le même App Service pour l’entrée privée, mais il ne décide pas seul de l’IP sortante vers Internet ou vers un partenaire. Pour ce runbook, la question est le chemin egress : VNet Integration, routes, filtrage, NAT et destination.

text inbound-vs-outbound.txt

Ne pas melanger
Private Endpoint App Service:
  controle l'entree privee vers l'application
  ne prouve pas l'IP sortante vers une API partenaire

VNet Integration:
  place les flux sortants de l'application dans un subnet d'integration
  rend visibles UDR, NSG, firewall et NAT Gateway selon le chemin

NAT Gateway:
  fournit l'identite publique sortante du subnet si le routage le permet
  ne s'applique pas si une UDR envoie le flux vers une appliance ou un firewall

Allowlist partenaire:
  doit correspondre a l'IP source reellement observee
  ne doit pas etre elargie sans preuve de chemin et rollback

Cette séparation évite de corriger le mauvais plan. Un incident d’IP sortante ne se résout pas en ajoutant un Private Endpoint, et un Private Endpoint sain ne prouve pas que l’egress est maîtrisé.

Vérifier la VNet Integration et le subnet réel

Un App Service peut avoir été déplacé, recréé, swappé, ou rattaché à un autre subnet d’intégration. Avant de regarder NAT Gateway, vérifiez que le flux part du bon subnet.

bash 01-app-service-vnet-integration.sh

APP_RG="rg-prod-app"
APP_NAME="app-orders-prod"

az webapp vnet-integration list --resource-group "$APP_RG" --name "$APP_NAME" --output table

az webapp config show --resource-group "$APP_RG" --name "$APP_NAME" --query "{vnetRouteAllEnabled:vnetRouteAllEnabled, linuxFxVersion:linuxFxVersion, alwaysOn:alwaysOn}" --output table

Si vnetRouteAllEnabled ou le routage équivalent ne correspond pas à l’architecture attendue, les destinations publiques peuvent ne pas suivre le subnet d’intégration. Le test doit donc préciser si l’appel partenaire est censé sortir via le VNet ou via l’egress natif App Service.

Prouver le DNS utilisé par l’application

Une dérive d’IP sortante peut masquer une dérive DNS. Si le hostname partenaire résout vers une autre région, un endpoint de secours ou une adresse privée inattendue, l’allowlist observée peut changer alors que NAT Gateway n’a pas bougé.

text dns-egress-checks.txt

Controles DNS
Resoudre le FQDN depuis une console App Service, un endpoint de diagnostic ou un probe equivalent
Comparer l'adresse resolue avec celle attendue par le partenaire
Verifier custom DNS, Private Resolver, forwarder ou configuration WEBSITE_DNS_SERVER si utilisee
Confirmer que le test utilise le meme hostname que la production
Rejouer apres purge de cache seulement si la fenetre incident le justifie

Bloquer le changement allowlist quand
Le FQDN ne resout pas la meme cible selon les instances
Le test utilise une IP alors que le code utilise un hostname
Le partenaire a bascule de region sans contrat reseau mis a jour
Aucune preuve ne vient du contexte applicatif reel

L’IP sortante n’a de sens qu’associée à une destination précise. Une allowlist partenaire peut être correcte pour l’ancien endpoint et inutile pour le nouveau.

Contrôler NAT Gateway, UDR et firewall

NAT Gateway s’applique au subnet, mais seulement si le chemin atteint bien Internet par ce subnet. Une UDR vers Azure Firewall ou une NVA peut changer l’identité sortante. Une association NAT absente ou déplacée peut faire réapparaître des IP App Service non attendues.

bash 02-subnet-egress-shape.sh

NET_RG="rg-network-prod"
VNET="vnet-prod-spoke"
SUBNET="snet-appservice-egress-prod"

az network vnet subnet show --resource-group "$NET_RG" --vnet-name "$VNET" --name "$SUBNET" --query "{subnet:name,addressPrefix:addressPrefix,natGateway:natGateway.id,routeTable:routeTable.id,nsg:networkSecurityGroup.id}" --output json

az network route-table route list --resource-group "$NET_RG" --route-table-name "rt-appservice-egress-prod" --query "[].{name:name,prefix:addressPrefix,nextHop:nextHopType,nextHopIp:nextHopIpAddress}" --output table

La question n’est pas seulement “un NAT Gateway est-il présent ?”. Il faut savoir si le flux partenaire est couvert par une route plus spécifique, s’il traverse un firewall qui fait du SNAT, ou s’il sort directement par NAT Gateway.

Lire les preuves côté destination et côté Azure

La preuve la plus utile est souvent côté destination : l’IP source réellement vue, le timestamp, le hostname appelé, le code de refus et l’identifiant de requête. Côté Azure, les traces doivent confirmer le même flux.

kusto 03-egress-ip-drift-evidence.kql

let StartTime = datetime(2026-07-13T08:00:00Z);
let EndTime = datetime(2026-07-13T09:00:00Z);
let AppName = "app-orders-prod";
let PartnerHost = "api.partner.example";
AppServiceHTTPLogs
| where TimeGenerated between (StartTime .. EndTime)
| where _ResourceId has AppName
| where CsHost has PartnerHost or CsUriStem has PartnerHost
| project TimeGenerated, CsHost, CsUriStem, ScStatus, TimeTaken, UserAgent, _ResourceId
| order by TimeGenerated asc

Adaptez les noms de tables à votre collecte. Si le flux passe par Azure Firewall, corrélez aussi les logs réseau ou applicatifs du firewall. Si le partenaire peut fournir ses logs, comparez les timestamps et l’IP source observée avec le NAT ou le firewall attendu.

Valider sans élargir définitivement l’allowlist

Quand une IP non attendue est observée, ne la rendez pas permanente par défaut. Utilisez une validation courte, tracée, avec expiration et rollback.

yaml allowlist-validation-plan.yml

validation:
incident_id: egress-ip-drift-20260713-01
app: app-orders-prod
destination: api.partner.example:443
expected_source_ip: 203.0.113.20
observed_source_ip: 198.51.100.44
hypothesis:
  - app moved to another integration subnet
  - UDR sends traffic through firewall SNAT
  - NAT Gateway association changed
  - routeAll disabled for public destination
temporary_action:
  type: partner_allowlist_exception
  expires_at: 2026-07-13T12:00:00Z
  owner: platform-oncall
success:
  - destination receives traffic from documented IP
  - Azure path explains that IP
  - application probe succeeds with same hostname
rollback:
  - remove temporary allowlist entry
  - restore subnet, UDR or NAT association if drift is confirmed
  - redeploy IaC state that owns the egress path

Une exception temporaire peut être acceptable pour rétablir un service, mais elle ne remplace pas le diagnostic. Elle doit expirer et pointer vers une correction réseau ou une décision d’architecture.

Décider correction, allowlist ou rollback

La décision doit rester lisible par l’exploitation. Chaque option doit avoir ses preuves et son rollback.

text egress-ip-decision.txt

Corriger le chemin Azure
VNet Integration pointe vers le mauvais subnet
NAT Gateway n'est plus associe au subnet attendu
Une UDR envoie le flux vers un firewall qui SNAT sans contrat
routeAll ou configuration equivalente ne couvre pas la destination
L'IaC peut restaurer le chemin attendu

Changer l'allowlist partenaire
La nouvelle IP source est voulue et documentee
Le chemin Azure explique cette IP
Les anciennes et nouvelles IP ont une fenetre de coexistence bornee
Le partenaire confirme la propagation
Le rollback d'allowlist est defini

Rollbacker
L'incident suit une modification subnet, NAT, UDR ou firewall
L'ancien chemin restaure l'IP source attendue
La correction permanente demande une revue d'architecture
Une exception temporaire arrive a expiration

Bloquer
L'IP observee n'est prouvee ni cote Azure ni cote destination
Le test ne vient pas du contexte App Service reel
L'equipe ne sait pas si NAT Gateway ou firewall porte le SNAT
L'allowlist proposee ajoute un prefixe large sans date de retrait

La pire correction est une allowlist élargie sans propriétaire. Elle rétablit parfois le flux, mais rend le prochain incident plus opaque.

Conclusion

Une dérive d’IP sortante App Service se traite comme un changement de chemin de production. Il faut prouver le subnet d’intégration, la résolution DNS, le routage, le NAT ou le firewall qui porte l’identité sortante, puis comparer avec ce que la destination observe réellement.

La décision devient alors simple : restaurer le chemin Azure, mettre à jour l’allowlist avec une fenêtre contrôlée, ou rollbacker le changement réseau. Tant que l’IP source n’est pas expliquée par des preuves des deux côtés, l’allowlist doit rester temporaire ou bloquée.