Résoudre les problèmes d’intégration de réseau virtuel à 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.

Remarque

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 au réseau virtuel

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

Pour ce faire, utilisez 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 Accéder. Dans la page du service Kudu, sélectionnez Outils>Console de débogage>CMD.

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 au 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 tracert ne fonctionnent pas via la console en raison de contraintes de sécurité (ils 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 la suivante :

nameresolver.exe hostname [optional:DNS Server]

Vous pouvez utiliser nameresolver pour case activée les noms d’hôte dont dépend votre application. De cette façon, vous pouvez tester si vous avez mal configuré votre DNS ou si vous n’avez peut-être pas accès à votre serveur DNS. Vous pouvez voir le serveur DNS utilisé par votre application dans la console en examinant les variables d’environnement WEBSITE_DNS_SERVER et WEBSITE_DNS_ALT_SERVER.

Remarque

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

Pour tester la connectivité TCP à une combinaison d’hôte et de port, 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. Il ne peut montrer la réussite que s’il existe une application à l’écoute de la combinaison hôte et port et s’il existe un accès réseau à partir 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 à l’adresse [sitename].scm.azurewebsites.net. Dans la page du service Kudu, sélectionnez Outils>Console de débogage>CMD.

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

nslookup hostname [optional:DNS Server]

Selon les résultats ci-dessus, vous pouvez case activée en cas de configuration incorrecte sur votre serveur DNS.

Remarque

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 la suivante :

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

Déboguer l’accès aux ressources hébergées sur le 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, il s’agit de l’un des éléments suivants :

• Un pare-feu est en cours. Si vous avez un pare-feu, vous atteignez le délai d’expiration TCP. Le délai d’expiration TCP est de 21 secondes dans ce cas. Utilisez l’outil tcpping pour tester la connectivité. Les délais d’expiration TCP peuvent être causés par de nombreux éléments au-delà des pare-feu, mais commencent par là.
• DNS n’est pas accessible. Le délai d’expiration 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 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 répondent pas à vos problèmes, recherchez d’abord les éléments suivants :

Intégration au réseau virtuel régional

• Votre destination est-elle une adresse non RFC1918 et vous n’avez pas tout activé ?
• Existe-t-il un groupe de sécurité réseau bloquant la sortie de votre sous-réseau d’intégration ?
• Si vous utilisez Azure ExpressRoute ou un VPN, votre passerelle locale est-elle configurée pour acheminer le trafic vers Azure ? Si vous pouvez atteindre des points de terminaison dans votre réseau virtuel, mais pas localement, case activée vos itinéraires.
• Disposez-vous des autorisations suffisantes pour définir la délégation sur le sous-réseau d’intégration ? Pendant la configuration de l’intégration de réseau virtuel régional, votre sous-réseau d’intégration est délégué à Microsoft.Web/serverFarms. L’interface utilisateur d’intégration au réseau virtuel délègue automatiquement le sous-réseau à Microsoft.Web/serverFarms. Si votre compte ne dispose pas des autorisations réseau suffisantes pour définir la délégation, vous aurez besoin d’une personne capable de définir des attributs sur votre sous-réseau d’intégration pour déléguer le sous-réseau. Pour déléguer manuellement le sous-réseau d’intégration, accédez à l’interface utilisateur du sous-réseau Azure Réseau virtuel et définissez la délégation pour Microsoft.Web/serverFarms.

Le débogage des problèmes de mise en réseau est un défi, car vous ne pouvez pas voir ce qui bloque l’accès à une combinaison hôte/port spécifique. Voici quelques-unes des causes suivantes :

• Vous disposez d’un pare-feu sur votre hôte qui empêche l’accès au port d’application à partir de votre plage d’adresses IP point à site. La traversée des sous-réseaux nécessite souvent un accès public.
• Votre hôte cible est arrêté.
• Votre application est arrêtée.
• Vous aviez une adresse IP ou un nom d’hôte incorrect.
• Votre application écoute sur un port différent de ce que vous attendiez. Vous pouvez faire correspondre votre ID de processus au port d’écoute en utilisant « netstat -aon » sur l’hôte de point de terminaison.
• Vos groupes de sécurité réseau sont configurés de telle sorte qu’ils empêchent l’accès à votre hôte d’application et à votre port à partir de votre plage d’adresses IP point à site.

Vous ne savez pas quelle adresse votre application utilise réellement. Il peut s’agir de n’importe quelle adresse du sous-réseau d’intégration ou de la plage d’adresses de point à site. Vous devez donc autoriser l’accès à partir de la plage d’adresses entière.

Voici d’autres étapes de débogage :

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

Test-NetConnection hostname [optional: -Port]

• Affichez une application sur une machine virtuelle et testez l’accès à cet hôte et à ce port à partir de la console à partir de votre application à l’aide de 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 le 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 Diagnostic et résolution du problème, puis recherchez Utilitaire de résolution des problèmes réseau.

Remarque

Le scénario des problèmes de connexion ne prend pas encore en charge les applications Linux ou basées sur des conteneurs.

Problèmes de connexion : il case activée la status 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 de 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 case activée 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 case activée si votre sous-réseau a des verrous et s’il contient des liens d’association de service inutilisés susceptibles de bloquer 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.

Remarque

Le trafic du 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 de 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 collecte de traces réseau.

Pour obtenir le fichier de trace pour chaque instance servant une application web, dans 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 .

Services d’application Linux

Pour collecter les 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 par eth0 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.