Ce navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
S'APPLIQUE À : développeur | Premium
Gestion des API Azure peut être déployé (injecté) dans un réseau virtuel Azure (VNet) pour accéder aux services backend au sein du réseau. Pour connaître les options de connectivité de VNet, les exigences et les considérations, consultez :
Cet article explique comment configurer la connectivité VNet pour votre instance Gestion des API en mode interne. Dans ce mode, vous pouvez uniquement afficher les points de terminaison Gestion des API suivants dans un réseau virtuel dont vous contrôlez l’accès.
Notes
Utilisez la Gestion des API en mode interne pour :
Pour les configurations spécifiques au mode externe, où les points de terminaison de Gestion des API sont accessibles depuis l'Internet public et où les services backend sont situés sur le réseau, consultez Déployer votre instance de Gestion des API Azure sur un réseau virtuel – mode externe.
Notes
Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.
Passez en revue la configuration requise pour l’injection de gestion des API dans un réseau virtuel avant de commencer.
Certains prérequis varient en fonction de la version (stv2 ou stv1) de la stv2 qui héberge votre instance Gestion des API.
Conseil
Quand vous utilisez le portail pour créer ou mettre à jour la connexion réseau d’une instance Gestion des API existante, l’instance est hébergée sur la plateforme de calcul stv2.
Un réseau et un sous-réseau virtuels dans la même région et le même abonnement que votre instance Gestion des API.
Un groupe de sécurité réseau associé au sous-réseau ci-dessus. Un groupe de sécurité réseau (NSG) est nécessaire pour autoriser explicitement la connectivité entrante, car l’équilibreur de charge utilisé en interne par Gestion des API est sécurisé par défaut et rejette tout le trafic entrant. Pour une configuration spécifique, consultez Configurer des règles NSG plus loin dans cet article.
Pour certains scénarios, activez des points de terminaison de service dans le sous-réseau pour des services dépendants tels que Stockage Azure ou Azure SQL. Pour obtenir plus d’informations, consultez Forcer le tunneling du trafic vers le pare-feu local à l’aide d’ExpressRoute ou de l’appliance virtuelle réseau plus loin dans cet article.
(Facultatif) Une adresse IPv4 publique de la référence SKU Standard.
Important
Si elle est fournie, l’adresse IP doit être dans la même région et le même abonnement que l’instance Gestion des API et le réseau virtuel.
Lorsque vous créez une ressource d’adresse IP publique, veillez à lui attribuer une étiquette de nom DNS. En général, vous devez utiliser le même nom DNS que votre instance Gestion des API. Si vous le modifiez, redéployez votre instance afin que la nouvelle étiquette DNS soit appliquée.
Pour des performances réseau optimales, il est recommandé d’utiliser la préférence de routage par défaut : réseau Microsoft.
Lors de la création d’une adresse IP publique dans une région où vous envisagez d’activer la redondance de zone pour votre instance de Gestion des API, configurez le paramètre redondant interzone.
La valeur de l’adresse IP est affectée en tant qu’adresse IPv4 publique virtuelle de l’instance Gestion des API dans cette région.
Pour les déploiements de Gestion des API dans plusieurs régions, configurez les ressources de réseau virtuel séparément pour chaque emplacement.
Accédez au portail Azure pour rechercher votre instance Gestion des API. Recherchez et sélectionnez Services Gestion des API.
Choisissez votre instance Gestion des API.
Sélectionnez Réseau>Réseau virtuel.
Sélectionnez le type d’accès Interne.
Dans la liste des localisations (régions) où votre service Gestion des API est provisionné :
Sélectionnez Appliquer. La page Réseau virtuel de votre instance de Gestion des API est mise à jour avec vos nouveaux choix de réseau virtuel et de sous-réseau.
Poursuivez la configuration des paramètres de réseau virtuel pour les autres emplacements de votre instance de Gestion des API.
Dans la barre de navigation supérieure, sélectionnez Enregistrer.
La mise à jour de l’instance Gestion des API peut prendre de 15 à 45 minutes. Le niveau Développeur présente un temps d’arrêt pendant le processus. Les références SKU De base et supérieures n’ont pas de temps d’arrêt pendant le processus.
Une fois le déploiement réussi, vous devez voir l’adresse IP virtuelle privée et l’adresse IP virtuelle publique de votre service Gestion des API s’afficher dans le panneau Vue d’ensemble. Pour plus d’informations sur les adresses IP, consultez la section Routage dans cet article.
Notes
L’URL de la passerelle n’étant pas inscrite sur le DNS public, la console de test disponible dans le portail Azure ne fonctionnera pas pour un service déployé dans un réseau virtuel Interne. À la place, vous devez utiliser la console de test fournie dans le portail des développeurs.
Modèle Azure Resource Manager (Version API 2021-08-01)
Créez ou mettez à jour une instance de Gestion des API dans un réseau virtuel.
Configurez des règles de réseau personnalisées dans le sous-réseau Gestion des API pour filtrer le trafic vers et à partir de votre instance de Gestion des API. Nous vous recommandons d’utiliser les règles NSG minimales suivantes pour garantir le bon fonctionnement et l’accès à votre instance. Passez soigneusement en revue votre environnement pour déterminer si d’autres règles sont nécessaires.
Important
En fonction de votre utilisation de la mise en cache et d’autres fonctionnalités, il est possible que vous deviez configurer des règles NSG supplémentaires au-delà des règles minimales du tableau suivant. Pour plus d’informations sur les paramètres, consultez Informations de référence sur la configuration de réseau virtuel.
| Sens | Balise du service source | Plages de ports source | Identification de destination | Plages de ports de destination | Protocol | Action | Objectif | Type de réseau virtuel |
|---|---|---|---|---|---|---|---|---|
| Trafic entrant | Internet | * | VirtualNetwork | [80], 443 | TCP | Autoriser | Communication client avec Gestion des API | Externe uniquement |
| Entrante | ApiManagement | * | VirtualNetwork | 3443 | TCP | Autoriser | Point de terminaison de gestion pour le Portail Azure et PowerShell | Externe et interne |
| Entrante | AzureLoadBalancer | * | VirtualNetwork | 6390 | TCP | Autoriser | Équilibrage de charge de l’infrastructure Azure | Externe et interne |
| Entrante | AzureTrafficManager | * | VirtualNetwork | 443 | TCP | Autoriser | Routage Azure Traffic Manager pour le déploiement multi-région | Externe uniquement |
| Sortant(e) | VirtualNetwork | * | Stockage | 443 | TCP | Autoriser | Dépendance sur stockage Azure pour les fonctionnalités de service de base | Externe et interne |
| Sortant(e) | VirtualNetwork | * | SQL | 1433 | TCP | Autoriser | Accès aux points de terminaison Azure SQL pour les fonctionnalités de service de base | Externe et interne |
| Sortant(e) | VirtualNetwork | * | AzureKeyVault | 443 | TCP | Autoriser | Accès à Azure Key Vault pour les fonctionnalités de service de base | Externe et interne |
| Sortant(e) | VirtualNetwork | * | AzureMonitor | 1886, 443 | TCP | Autoriser | Publier les journaux et métriques de diagnostic, Resource Health et Application Insights | Externe et interne |
En mode réseau virtuel interne, vous devez gérer votre propre DNS pour permettre l’accès entrant à vos points de terminaison Gestion des API.
Nous recommandons les actions suivantes :
Apprenez à configurer une zone privée dans Azure DNS.
Notes
Le service Gestion des API n’écoute pas les requêtes sur ses adresses IP. Il répond uniquement aux requêtes au nom d’hôte configuré sur ses points de terminaison. Ces points de terminaison sont les suivants :
Lorsque vous créez un service Gestion des API (contosointernalvnet, par exemple), les points de terminaison suivants sont configurés par défaut :
| Point de terminaison | Configuration du point de terminaison |
|---|---|
| API Gateway | contosointernalvnet.azure-api.net |
| Portail des développeurs | contosointernalvnet.portal.azure-api.net |
| Le nouveau portail des développeurs | contosointernalvnet.developer.azure-api.net |
| Point de terminaison de la gestion directe | contosointernalvnet.management.azure-api.net |
| Git | contosointernalvnet.scm.azure-api.net |
Si vous ne souhaitez pas accéder au service de Gestion des API avec les noms d'hôte par défaut, configurez des noms de domaine personnalisés pour tous vos points de terminaison, comme indiqué dans l'image suivante :
Créez des enregistrements dans votre serveur DNS pour accéder aux points de terminaison accessibles à partir de votre réseau virtuel. Mappez les enregistrements de point de terminaison à l’adresse IP virtuelle privée de votre service.
À des fins de test, vous pouvez mettre à jour le fichier hosts sur une machine virtuelle dans un sous-réseau connecté au réseau virtuel dans lequel Gestion des API Management est déployé. En supposant que l’adresse IP virtuelle privée de votre service est 10.1.0.5, vous pouvez mapper le fichier hôte comme suit. Le fichier de mappage des hôtes se trouve à l’adresse %SystemDrive%\drivers\etc\hosts (Windows) ou /etc/hosts (Linux, macOS).
| Adresse IP virtuelle interne | Configuration du point de terminaison |
|---|---|
| 10.1.0.5 | contosointernalvnet.azure-api.net |
| 10.1.0.5 | contosointernalvnet.portal.azure-api.net |
| 10.1.0.5 | contosointernalvnet.developer.azure-api.net |
| 10.1.0.5 | contosointernalvnet.management.azure-api.net |
| 10.1.0.5 | contosointernalvnet.scm.azure-api.net |
Vous pouvez alors accéder à tous les points de terminaison Gestion des API à partir de la machine virtuelle que vous avez créée.
Les adresses IP virtuelles suivantes sont configurées pour une instance Gestion des API dans un réseau virtuel interne.
| Adresse IP virtuelle | Description |
|---|---|
| Adresse IP virtuelle privée | Adresse IP à charge équilibrée à partir de la plage de sous-réseaux de l’instance Gestion des API (DIP), par le biais de laquelle vous pouvez accéder à la passerelle API, au portail des développeurs, à la gestion et aux points de terminaison Git. Inscrivez cette adresse auprès des serveurs DNS utilisés par le réseau virtuel. |
| Adresse IP virtuelle publique | Utilisée uniquement pour le trafic du plan de contrôle vers le point de terminaison de gestion sur le port 3443. Peut être verrouillée sur l’étiquette de service GestionApi. |
Les adresses IP privées et publiques à charge équilibrée se trouvent dans le panneau Vue d’ensemble sur le portail Azure.
Pour plus d’informations et d’éléments à prendre en considération, consultez Adresses IP de Gestion des API Azure.
Des adresses IP dynamiques (DIP) seront attribuées à chaque machine virtuelle sous-jacente du service et utilisées pour accéder aux points de terminaison et aux ressources au sein du réseau virtuel et des réseaux virtuels appairés. L’adresse IP virtuelle (VIP) publique du service Gestion des API est utilisée pour accéder aux ressources publiques.
Si une restriction d’IP liste des ressources sécurisées au sein du réseau virtuel ou des réseaux virtuels appairés, nous vous conseillons de préciser la plage entière du sous-réseau où le service Gestion des API est déployé pour accorder ou restreindre l’accès à partir du service.
En savoir plus sur la taille de sous-réseau recommandée.
Si vous déployez une unité de capacité de la Gestion des API dans le niveau Premium dans un réseau virtuel interne, trois adresses IP sont utilisées : une pour l’adresse IP virtuelle privée et une chacune pour les adresses DIP de deux machines virtuelles. Si vous effectuez un scale-out jusqu’à quatre unités, davantage d’adresses IP seront consommées pour les adresses DIP supplémentaires du sous-réseau.
Si le point de terminaison de destination n’a autorisé qu’un ensemble fixe d’adresses DIP, des échecs de connexion se produiront si vous ajoutez de nouvelles unités à l’avenir. Pour cette raison, et puisque le sous-réseau est entièrement sous votre contrôle, nous recommandons d’autoriser l’ensemble du sous-réseau dans le serveur principal.
Un tunneling forcé vous permet de rediriger ou de « forcer » tout le trafic Internet vers votre sous-réseau localement à des fins d'inspection et d'audit. Généralement, vous configurez et définissez votre propre route par défaut (0.0.0.0/0), ce qui force tout le trafic du sous-réseau Gestion des API à traverser un pare-feu local ou une appliance virtuelle réseau. Ce flux de trafic interrompt la connectivité avec la Gestion des API Azure, car le trafic sortant est bloqué en local ou fait l’objet d’une opération NAT sur un jeu d’adresses non reconnaissable qui ne fonctionne plus avec différents points de terminaison Azure. Vous pouvez résoudre ce problème en appliquant les méthodes suivantes :
Activez les points de terminaison de service sur le sous-réseau où le service Gestion des API est déployé pour :
stv2)En activant des points de terminaison directement du sous-réseau Gestion des API vers ces services, vous pouvez utiliser le réseau principal Microsoft Azure pour un routage optimal du trafic du service. Si vous utilisez des points de terminaison de service avec le service Gestion des API tunnelisé de force, le trafic des services Azure susmentionnés n’est pas tunnelisé de force. Cependant, l’autre trafic de dépendance du service Gestion des API est tunnelisé de force. Assurez-vous que votre pare-feu ou votre appliance virtuelle ne bloque pas ce trafic, ou que le service Gestion des API ne fonctionne pas correctement.
Notes
Nous vous recommandons vivement d’activer les points de terminaison des services directement à partir du sous-réseau Gestion des API vers les services dépendants tels qu’Azure SQL et Stockage Azure qui les prennent en charge. Toutefois, certaines organisations peuvent avoir besoin de forcer le tunneling de l’ensemble du trafic à partir du sous-réseau Gestion des API. Dans ce cas, veillez à configurer votre pare-feu ou votre appliance virtuelle pour autoriser ce trafic. Vous devez autoriser la plage d’adresses IP complète de chaque service dépendant et mettre à jour cette configuration quand l’infrastructure Azure change. Votre service Gestion des API peut également faire l’objet d’une latence ou d’expirations de délai inattendus en raison du tunneling forcé de ce trafic réseau.
Tout le trafic du plan de contrôle provenant d’Internet vers le point de terminaison de gestion de votre service Gestion des API est acheminé via un ensemble spécifique d’adresses IP entrantes, hébergées par la Gestion des API et regroupées sous la balise de serviceApiManagement. Lorsque le trafic est tunnelisé de force, les réponses ne sont pas mappées de manière symétrique à ces adresses IP sources entrantes et la connectivité au point de terminaison de gestion est perdue. Pour surmonter cette limitation, configurez une route définie par l’utilisateur (UDR) pour l’étiquette de service ApiManagement avec le type de tronçon suivant défini sur « Internet » pour renvoyer le trafic vers Azure.
Notes
L’autorisation du trafic de gestion de la Gestion des API pour contourner un pare-feu local ou une appliance virtuelle réseau n’est pas considérée comme un risque de sécurité significatif. La configuration recommandée pour votre sous-réseau Gestion des API autorise le trafic de gestion entrant sur le port 3443 uniquement à partir de l’ensemble d’adresses IP Azure comprises par l’étiquette de service ApiManagement. La configuration UDR recommandée n’est que pour le chemin d’accès de retour de ce trafic Azure.
(Mode réseau virtuel externe) Le trafic de plan de données pour les clients tentant d’atteindre la passerelle Gestion des API et le portail des développeurs à partir d’Internet sera également supprimé par défaut en raison du routage asymétrique introduit par le tunneling forcé. Pour chaque client qui nécessite un accès, configurez un UDR explicite avec le type de tronçon suivant « Internet » pour contourner le pare-feu ou l’appliance de réseau virtuel.
Pour les autres dépendances du service Gestion des API tunnelisées de force, résolvez le nom d’hôte et atteignez le point de terminaison. Il s’agit notamment des paramètres suivants :
Pour plus d'informations, consultez Référence de configuration de réseau virtuel.
Cette section a été déplacée. Consultez Informations de référence sur la configuration de réseau virtuel.
stv2)Important
Après avoir validé la connectivité, supprimez toutes les ressources du sous-réseau avant de déployer la Gestion des API dans le sous-réseau (nécessaire quand la Gestion des API est hébergée sur la plateforme stv1).
Après avoir déployé Gestion des API dans le sous-réseau, utilisez le portail pour vérifier la connectivité de votre instance aux dépendances, telles que Stockage Azure.
Dans le menu de gauche du portail, sous Déploiement et infrastructure, sélectionnez Réseau>État du réseau.
| Filtrer | Description |
|---|---|
| Obligatoire | Sélectionnez cette option pour vérifier la connectivité aux services Azure requis pour Gestion des API. Un échec indique que l’instance ne peut pas effectuer des opérations de base pour gérer les API. |
| Facultatif | Sélectionnez cette option pour vérifier la connectivité aux services facultatifs. Tout échec indique uniquement que la fonctionnalité spécifique ne fonctionnera pas (par exemple, SMTP). Un échec peut entraîner une dégradation dans l’utilisation et la surveillance de l’instance de Gestion des API et empêcher d’offrir le contrat SLA validé. |
Pour résoudre les problèmes de connectivité, sélectionnez :
Métriques : pour passer en revue les métriques de l’état de la connectivité réseau
Diagnostiquer : pour exécuter un vérificateur de réseau virtuel sur une période spécifiée
Pour résoudre les problèmes de connectivité, consultez les paramètres de configuration réseau, puis corrigez les paramètres réseau nécessaires.
Lorsque vous changez votre réseau, consultez API NetworkStatus pour vérifier que le service Gestion des API n’a pas perdu l’accès aux ressources critiques. L’état de connectivité doit être mis à jour toutes les 15 minutes.
Pour appliquer une modification de configuration du réseau à l’instance de Gestion des API à l’aide du portail :
Une instance API Management hébergée sur la plateforme de calculstv1, quand elle est déployée dans un sous-réseau de réseau virtuel Resource Manager, réserve le sous-réseau en créant un lien de navigation dans les ressources. Si le sous-réseau contient déjà une ressource d’un autre fournisseur, le déploiement échoue. De même, lorsque vous supprimez un service Gestion des API ou le déplacez vers un sous-réseau différent, le lien de navigation des ressources est supprimé.
stv1, sa suppression et une attente sont nécessaires pour déployer un service stv2 basé sur une plateforme dans le même sous-réseau.Une connectivité réseau à Microsoft Graph est nécessaire pour les fonctionnalités, notamment une connexion utilisateur dans le portail des développeurs en utilisant le fournisseur d’identité Microsoft Entra.
Pour résoudre des problèmes de connectivité à Microsoft Graph à partir d’un VNet :
Vérifiez qu’un NSG et d’autres règles de réseau sont configurés pour une connectivité sortante à partir de votre instance API Management dans Microsoft Graph (en utilisant une étiquette de service AzureActiveDirectory).
Vérifiez que le réseau et la résolution DNS accèdent à graph.microsoft.com à partir du réseau virtuel. Par exemple, approvisionnez une machine virtuelle dans le réseau virtuel, connectez-vous-y et essayez de GET https://graph.microsoft.com/v1.0/$metadata à partir d’un navigateur ou en utilisant cURL, PowerShell ou d’autres outils.
Pour en savoir plus :
Entrainement
Module
Implémenter et gérer le réseau pour Azure Virtual Desktop - Training
Implémenter et gérer le réseau pour Azure Virtual Desktop
Certification
Microsoft Certified : Azure Network Engineer Associate - Certifications
Faites la démonstration de la conception, de l’implémentation et de la maintenance de l’infrastructure de mise en réseau, du trafic d’équilibrage de charge, du routage réseau Azure et bien plus encore.