Comment une application Web Azure atteint-elle sur site via un VPN

La requête sortante de l'application Web laisse un travailleur que vous ne voyez jamais, provenant d'une source que vous n'avez pas choisie, et le pare-feu du bureau doit l'accepter. C'est tout le problème en une phrase. L'intégration régionale au réseau virtuel donne à la demande un chemin vers un réseau virtuel, et le VPN site à site l'achemine à partir de là. Tout ce qui ne va pas par la suite concerne la plage source et la route réellement utilisées par le paquet.

Ce que le travailleur envoie réellement

App Service exécute votre code sur les nœuds de calcul qui se trouvent en dehors de la vue réseau de votre abonnement. Lorsque l'intégration régionale est activée, le trafic sortant est transmis à un sous-réseau délégué dans un réseau virtuel de la même région, et le paquet y apparaît avant de continuer. L'intégration ne déplace pas l'application dans le réseau virtuel et ne modifie pas son adresse entrante. Cela donne uniquement aux flux sortants un premier saut différent.

Par défaut, seul l'espace d'adressage privé emprunte ce chemin, de sorte que les destinations Internet ordinaires partent toujours directement du travailleur. Tout acheminer via le réseau virtuel est un paramètre et une décision distincts, car cela envoie également vos dépendances publiques à travers le tunnel.

Le trafic de configuration, tel qu'une image de conteneur extraite au démarrage, suit ses propres règles de routage et peut échouer lorsque vos appels d'API réussissent.

Le sous-réseau d'intégration est la source que vous devez autoriser

Le bureau voit la plage d'adresses du sous-réseau d'intégration, ou ce que votre appareil la traduit, et non les adresses publiques sortantes de l'application. Placez cette plage dans les sélecteurs de trafic du VPN du site et dans la règle de pare-feu sur site. Si le tunnel est basé sur une stratégie, les les sélecteurs qui l'omettent abandonnent le paquet même lorsqu'une route existe.

N'autorisez pas une seule adresse de travailleur que vous avez observée. Les instances changent avec la mise à l'échelle et la maintenance de la plate-forme, et une règle épinglée à une adresse est rompue au pire moment.

Gardez le côté destination étroit: un service, un port, une direction, avec le chemin de retour autorisé explicitement.

Le peering et le transit de passerelle sont explicites

Si la passerelle VPN se trouve dans un réseau virtuel hub et le sous-réseau d'intégration dans un peer peer, le chemin nécessite que le transit de passerelle soit autorisé sur le peering hub et que l'utilisation de la passerelle distante soit activée sur le peering rayons. Le peering en lui-même transporte le trafic entre les deux réseaux virtuels et rien de plus. Les routes effectives sur le sous-réseau d'intégration sont celles où vous confirmez que le prochain tronçon de passerelle est bien là.

Une conception en étoile dont la table de routage envoie 0.0.0.0/0 à un pare-feu est une variante courante, et ce pare-feu a alors besoin de sa propre règle pour le préfixe sur site.

Dessinez le chemin sur papier avant d'ouvrir un ticket avec l'équipe réseau, car cela vous évite une journée de devinettes. Incluez la direction de retour dans le dessin, car c'est la moitié que les gens oublient.

Le point de terminaison privé entrant est l'autre sens

Un point de terminaison privé rend l'application accessible depuis un réseau virtuel. Cela ne fait rien pour les appels sortants de l'application vers le bureau, et les équipes en configurent régulièrement un alors que l'exigence réelle était l'inverse.

Une documentation plus ancienne décrit l'intégration requise par la passerelle et basée sur un VPN point à site, une fonctionnalité différente avec ses propres exigences. Microsoft prévoit le retrait de cette fonctionnalité pour le 31 mars 2027 et recommande plutôt une intégration régionale.

Ne copiez pas une ancienne configuration point à site simplement parce qu'un ancien exemple l'utilisait.

Vérifiez avec le propre contexte de l'application

Testez à partir de l'application déployée, pas depuis votre ordinateur portable ni depuis une VM dans le même réseau virtuel. Enregistrez séparément l'adresse résolue, le résultat de la connexion et la réponse au niveau de l'application, car un échec DNS, un délai d'attente TCP et un point de rejet d'authentification chez trois propriétaires différents. Si la résolution de nom échoue, corrigez le DNS privé du réseau virtuel avant de toucher au tunnel.

Un statut de tunnel vert prouve uniquement que la passerelle est active. Il ne dit rien sur les sélecteurs, les règles de pare-feu ou le DNS.

Lorsque la requête fonctionne enfin, écrivez la plage source, le port de destination et la zone DNS dans le runbook de l'application. La prochaine personne qui déboguera cela commencera à partir de votre note plutôt qu'à partir de la page d'état de la passerelle.