Dépanner l’intégration du réseau virtuel avec Azure App Service

Cet article décrit les outils que vous pouvez utiliser pour résoudre les problèmes de connexion dans Azure App Service qui s’intègrent à un réseau virtuel.

Note

L’intégration au réseau virtuel n’est pas prise en charge pour les scénarios Docker Compose dans App Service. Les stratégies de restriction d’accès sont ignorées si un point de terminaison privé est présent.

Vérifier l’intégration du réseau virtuel

Pour résoudre les problèmes de connexion, vous devez d’abord vérifier si l’intégration du réseau virtuel est configurée correctement et si l’adresse IP privée est affectée à toutes les instances du plan App Service.

Pour cela, appliquez l’une des méthodes suivantes :

Vérifier l’adresse IP privée dans la console Debug Kudu

Pour accéder à la console Kudu, sélectionnez le service d’application dans le Portail Azure, accédez à Outils de développement, sélectionnez Outils avancés, puis Sélectionnez Atteindre. Dans la page du service Kudu, sélectionnez CMD Debug>Tools>.

Vous pouvez également accéder directement à la console Debug Kudu par l’URL [sitename].scm.azurewebsites.net/DebugConsole.

Dans la console Debug, exécutez l’une des commandes suivantes :

Applications basées sur le système d’exploitation Windows

SET WEBSITE_PRIVATE_IP

Si l’adresse IP privée est attribuée avec succès, vous obtenez la sortie suivante :

WEBSITE_PRIVATE_IP=<IP address>

Applications basées sur le système d’exploitation Linux

set| egrep --color 'WEBSITE_PRIVATE_IP'

Vérifier l’adresse IP privée dans l’environnement Kudu

Accédez à l’environnement Kudu à l’adresse [sitename].scm.azurewebsites.net/Env et recherchez WEBSITE_PRIVATE_IP.

Une fois que nous avons établi que l’intégration du réseau virtuel est correctement configurée, nous pouvons procéder au test de connectivité.

Résoudre les problèmes de connectivité sortante sur les applications Windows

Dans les applications Windows natives, les outils ping, nslookup et tracet ne fonctionnent pas dans la console en raison de contraintes de sécurité (elles fonctionnent dans des conteneurs Windows personnalisés).

Accédez directement à la console Kudu à l’adresse [sitename].scm.azurewebsites.net/DebugConsole.

Pour tester la fonctionnalité DNS, vous pouvez utiliser nameresolver.exe. La syntaxe est :

nameresolver.exe hostname [optional:DNS Server]

Vous pouvez utiliser nameresolver pour vérifier les noms d’hôte dont dépend votre application. De cette façon, vous pouvez tester si vous avez quelque chose de mal configuré avec votre DNS ou si vous n’avez peut-être pas accès à votre serveur DNS. Vous pouvez identifier le serveur DNS qu’utilise votre application dans la console en examinant les variables d’environnement WEBSITE_DNS_SERVER et WEBSITE_DNS_ALT_SERVER.

Notes

L’outil nameresolver.exe ne fonctionne pas actuellement dans les conteneurs Windows personnalisés.

Pour tester la connectivité TCP à une combinaison d’hôtes et de ports, vous pouvez utiliser tcpping. La syntaxe est.

tcpping.exe hostname [optional: port]

L’utilitaire tcpping vous indique si vous pouvez atteindre un hôte et un port spécifiques. Elle peut montrer la réussite uniquement s’il existe une application à l’écoute de l’hôte et de la combinaison de ports et qu’il existe un accès réseau de votre application à l’hôte et au port spécifiés.

Résoudre les problèmes de connectivité sortante sur les applications Linux

Accédez directement à Kudu à [sitename].scm.azurewebsites.net. Dans la page du service Kudu, sélectionnez CMD Debug>Tools>.

Pour tester la fonctionnalité DNS, vous pouvez utiliser la commande nslookup. La syntaxe est :

nslookup hostname [optional:DNS Server]

En fonction des résultats ci-dessus, vous pouvez vérifier s’il existe quelque chose de mal configuré sur votre serveur DNS.

Note

L’outil nameresolver.exe ne fonctionne actuellement pas dans les applications Linux.

Pour tester la connectivité, vous pouvez utiliser la commande Curl . La syntaxe est :

curl -v https://hostname
curl hostname:[port]

Déboguer l’accès aux ressources hébergées sur un réseau virtuel

Un certain nombre de facteurs peuvent empêcher votre application d’atteindre un hôte et un port spécifiques. La plupart du temps, c’est l’un des éléments suivants :

• Un pare-feu se trouve sur le trajet. Si vous utilisez un pare-feu sur le trajet, vous dépassez le délai d’expiration TCP. Dans ce cas, il est de 21 secondes. Utilisez l’outil tcpping pour tester la connectivité. Les délais d’expiration TCP peuvent avoir de nombreuses autres origines, mais commencez par vérifier ce point.
• DNS n’est pas accessible. Le délai d’expiration du DNS est de trois secondes par serveur DNS. Si vous avez deux serveurs DNS, le délai d’expiration est de six secondes. Utilisez nameresolver pour voir si le DNS fonctionne. Vous ne pouvez pas utiliser nslookup, car cela n’utilise pas le DNS avec lequel votre réseau virtuel est configuré. S’il est inaccessible, vous pouvez avoir un pare-feu ou un groupe de sécurité réseau bloquant l’accès au DNS, ou il peut être arrêté. Certaines architectures DNS qui utilisent des serveurs DNS personnalisés peuvent être complexes et peuvent parfois rencontrer des délais d’expiration. Pour déterminer si c’est le cas, la variable WEBSITE_DNS_ATTEMPTS d’environnement peut être définie. Pour plus d’informations sur DNS dans App Services, consultez Résolution de noms (DNS) dans App Service.

Si ces éléments ne suffisent pas à résoudre vos problèmes, commencez par vous poser les questions suivantes :

Intégration du réseau virtuel régional

• Votre destination est-elle une adresse non RFC1918 sans l’Itinéraire activé ?
• Y a-t-il un groupe de sécurité réseau qui bloque la sortie de votre sous-réseau d’intégration ?
• Si elle transite par Azure ExpressRoute ou un VPN, votre passerelle locale est-elle configurée pour réacheminer le trafic vers Azure ? Si vous pouvez accéder à des points de terminaison dans votre réseau virtuel, mais pas en local, vérifiez vos routes.
• Disposez-vous d’autorisations suffisantes pour définir la délégation sur le sous-réseau d’intégration ? Durant la configuration de l’intégration au réseau virtuel régional, votre sous-réseau d’intégration est délégué à Microsoft.Web/serverFarms. L’interface utilisateur de l’intégration au réseau virtuel délègue automatiquement le sous-réseau à Microsoft.Web/serverFarms. Si votre compte ne dispose pas d’autorisations de mise en réseau suffisantes pour définir la délégation, vous devez demander à une personne autorisée de configurer les attributs de votre sous-réseau d’intégration de manière à déléguer celui-ci. Pour déléguer manuellement le sous-réseau d’intégration, accédez à l’interface utilisateur du sous-réseau de Réseau virtuel Microsoft Azure et définissez la délégation sur Microsoft.Web/serverFarms.

Le débogage des problèmes de mise en réseau constitue un défi, car cette opération ne vous permet pas de voir ce qui bloque l’accès à une combinaison hôte-port spécifique. Les causes peuvent inclure :

• Un pare-feu activé sur l’hôte empêche l’accès au port de l’application à partir de votre plage d’adresses IP de point à site. Des sous-réseaux croisés requièrent souvent un accès public.
• Votre hôte cible est hors-service.
• Votre application est arrêtée.
• L’IP ou le nom d’hôte sont incorrects.
• Votre application est à l’écoute sur un port autre que celui auquel vous vous attendiez. Vous pouvez faire correspondre votre ID de processus avec le port d’écoute en utilisant « netstat -aon » sur l’hôte du point de terminaison.
• Vos groupes de sécurité réseau sont configurés de telle sorte qu’ils empêchent l’accès à l’hôte et au port de votre application à partir de votre plage d’adresses IP de point à site.

Vous ne savez pas quelle adresse votre application utilise réellement. Cela peut être n’importe quelle adresse de la plage d’adresses de sous-réseau d’intégration ou de point à site. De ce fait, vous devez autoriser l’accès depuis toutes les adresses de la plage.

Voici d’autres étapes de débogage :

• Connectez-vous à une machine virtuelle de votre réseau virtuel et essayez d’atteindre la combinaison hôte-port de vos ressources. Pour tester l’accès à TCP, utilisez la commande PowerShell Test-NetConnection. La syntaxe est :

Test-NetConnection hostname [optional: -Port]

• Démarrez une application sur une machine virtuelle, puis testez l’accès à ces hôte et port à partir de la console de votre application en utilisant l’outil tcpping.

Utilitaire de résolution des problèmes réseau

Vous pouvez également utiliser l’utilitaire de résolution des problèmes réseau pour résoudre les problèmes de connexion pour les applications dans App Service. Pour ouvrir l’utilitaire de résolution des problèmes réseau, accédez au service d’application dans le Portail Azure. Sélectionnez Diagnostiquer et résoudre le problème, puis recherchez Utilitaire de résolution des problèmes réseau.

Note

Le scénario de problèmes de connexion ne prend pas encore en charge les applications Linux ou conteneur.

Problèmes de connexion : il vérifie l’état de l’intégration du réseau virtuel, notamment la vérification si l’adresse IP privée a été affectée à toutes les instances du plan App Service et aux paramètres DNS. Si un DNS personnalisé n’est pas configuré, Azure DNS par défaut est appliqué. Vous pouvez également exécuter des tests sur un point de terminaison spécifique auquel vous souhaitez tester la connectivité.

Problèmes de configuration : cet utilitaire de résolution des problèmes vérifie si votre sous-réseau est valide pour l’intégration de réseau virtuel.

Problème de suppression de sous-réseau/réseau virtuel : cet utilitaire de résolution des problèmes vérifie si votre sous-réseau a des verrous et s’il contient des liens d’association de services inutilisés qui bloquent peut-être la suppression du réseau virtuel/sous-réseau.

Collecter les traces réseau

La collecte des traces réseau peut être utile pour analyser les problèmes. Dans Azure App Services, les traces réseau sont extraites du processus d’application. Pour obtenir des informations précises, reproduisez le problème lors du démarrage de la collection de traces réseau.

Note

Le trafic réseau virtuel n’est pas capturé dans les traces réseau.

Windows App Services

Pour collecter les traces réseau pour Windows App Services, procédez comme suit :

1. Dans le Portail Azure, accédez à votre application web.
2. Dans le volet de navigation gauche, sélectionnez Diagnostiquer et résoudre les problèmes.
3. Dans la zone de recherche, tapez Collecter la trace réseau et sélectionnez Collecter la trace réseau pour démarrer la collection de traces réseau.

Pour obtenir le fichier de trace de chaque instance servant une application web, sur votre navigateur, accédez à la console Kudu pour l’application web (https://<sitename>.scm.azurewebsites.net). Téléchargez le fichier de trace à partir du dossier C :\home\LogFiles\networktrace ou D :\home\LogFiles\networktrace .

Linux App Services

Pour collecter des traces réseau pour Linux App Services qui n’utilisent pas de conteneur personnalisé, procédez comme suit :

1. Installez l’utilitaire tcpdump de ligne de commande en exécutant les commandes suivantes :

   apt-get update
   apt install tcpdump
   

2. Connectez-vous au conteneur via le protocole SSH (Secure Shell Protocol).

3. Identifiez l’interface opérationnelle en exécutant la commande suivante (par exemple) eth0:

   root@<hostname>:/home# tcpdump -D
   
   1.eth0 [Up, Running, Connected]
   2.any (Pseudo-device that captures on all interfaces) [Up, Running]
   3.lo [Up, Running, Loopback]
   4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
   5.nflog (Linux netfilter log (NFLOG) interface) [none]
   6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
   7.dbus-system (D-Bus system bus) [none]
   8.dbus-session (D-Bus session bus) [none]
   

4. Démarrez la collection de traces réseau en exécutant la commande suivante :

   root@<hostname>:/home# tcpdump -i eth0 -w networktrace.pcap
   

   Remplacez eth0 par le nom de l’interface réelle.

Pour télécharger le fichier de trace, connectez-vous à l’application web via des méthodes telles que Kudu, FTP ou une requête d’API Kudu. Voici un exemple de demande pour déclencher le téléchargement du fichier :

https://<sitename>.scm.azurewebsites.net/api/vfs/<path to the trace file in the /home directory>/filename

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.