Phase de conception 3 : Connectivité Internet entrante
Les choix que vous effectuez pendant cette phase de conception sont déterminés par les exigences des applications s’exécutant sur Azure VMware Solution qui doivent être accessibles via des adresses IP publiques. Presque invariablement, les applications accessibles sur Internet sont publiées via des appareils réseau qui fournissent la sécurité (pare-feu de nouvelle génération, pare-feu d’applications web) et l’équilibrage de charge (équilibreurs de charge de couche 3 ou 4, contrôleurs de remise d’applications). Vous pouvez déployer ces appareils dans le cloud privé lui-même ou dans un réseau virtuel Azure connecté au cloud privé. Votre choix est fondé sur ces considérations :
- Pour optimiser les coûts et assurer la cohérence, vous pouvez utiliser des appliances virtuelles réseau préexistantes déployées dans des réseaux virtuels Azure (comme des pare-feu et des contrôleurs de remise d’applications) pour publier des applications s’exécutant sur vos clouds privés.
- Les services PaaS Azure qui peuvent être utilisés pour publier des applications accessibles sur Internet, comme Pare-feu Azure (lorsqu’elles sont déployées dans un réseau virtuel géré par le client et lorsqu’elles sont déployées dans un hub Azure Virtual WAN) et Azure Application Gateway, peuvent contribuer à réduire la surcharge de gestion.
- Vous pouvez déployer des pare-feu et des contrôleurs de remise d’applications en tant qu’appliances virtuelles sur Azure VMware Solution, si cela est pris en charge par le fournisseur.
L’organigramme suivant résume comment aborder cette phase :
Appliances virtuelles réseau hébergées dans un réseau virtuel Azure
La publication d’applications Azure VMware Solution via des services Azure (Pare-feu Azure, Application Gateway) ou des appliances virtuelles réseau tierces hébergées dans un réseau virtuel nécessite uniquement une connectivité de couche 3 entre le réseau virtuel et le cloud privé Azure VMware Solution. Pour plus d’informations, consultez Phase de conception 2 : Connectivité avec des réseaux virtuels Azure.
Les sections suivantes fournissent des conseils pour chaque option.
Considérations relatives au Pare-feu Azure
Le Pare-feu Azure est l’option préférée pour exposer des points de terminaison TCP ou UDP génériques via un appareil Microsoft de couche 3 ou 4. Pour publier une application Azure VMware Solution via le Pare-feu Azure, vous devez configurer une règle de traduction d’adresses réseau de destination (DNAT) qui mappe l’une des adresses IP publiques du pare-feu à l’adresse IP privée du point de terminaison d’application Azure VMware Solution. Le Pare-feu Azure utilise automatiquement la traduction d’adresses réseau sources (SNAT) pour traduire les adresses IP entrantes d’Internet vers sa propre adresse IP privée. Par conséquent, les machines virtuelles Azure VMware Solution reçoivent le trafic dont l’adresse IP source est l’adresse IP du pare-feu. Pour en savoir plus, consultez Filtrer le trafic Internet entrant avec le Pare-feu Azure DNAT à l’aide du Portail Azure.
Considérations relatives à Azure Application Gateway
Application Gateway est l’option préférée pour exposer des applications HTTP(S) s’exécutant sur Azure VMware Solution. Ce proxy inverse HTTP Microsoft fournit les éléments suivants :
- Routage des requêtes HTTP
- Fonctionnalités de pare-feu d’applications web (WAF).
Lorsque vous utilisez Application Gateway, les serveurs d’applications s’exécutant dans le cloud privé Azure VMware Solution reçoivent le trafic dont l’adresse IP source est l’adresse IP de la passerelle d’application. L’adresse IP du client peut être transmise dans les requêtes HTTP (généralement sous la forme d’un en-tête x-forwarded-for personnalisé) si la logique d’application nécessite l’accès à ces informations. Pour plus d’informations, consultez cet article sur la publication d’une application Azure VMware Solution via Application Gateway.
Remarque
Application Gateway est actuellement le seul équilibreur de charge Microsoft que vous pouvez utiliser pour exposer des applications web s’exécutant sur des machines virtuelles Azure VMware Solution. Cela est dû au fait qu’il vous permet de pointer directement vers les adresses IP privées des machines virtuelles exécutées sur Azure VMware Solution lorsque vous configurez les pools back-end des machines virtuelles.
Considérations relatives aux appliances virtuelles réseau tierces
Les appliances virtuelles réseau tierces peuvent fournir des fonctionnalités de pare-feu de couche 3 ou 4 ou des fonctionnalités de proxy inverse/WAF de couche 7. Suivez les instructions du fournisseur de l’appliance virtuelle réseau pour déployer l’appareil dans des réseaux virtuels Azure. Les instructions détaillées sur la création de clusters hautement disponibles d’appliances virtuelles réseau sur Azure ne sont pas incluses dans ce guide. Les considérations générales suivantes sont suffisamment générales pour s’appliquer à n’importe quelle technologie d’appliance virtuelle réseau :
- La haute disponibilité est votre responsabilité. Les clusters d’appliances virtuelle réseau doivent inclure deux instances d’appliances virtuelles réseau actives ou plus (le modèle N-active HA). Vous devez éviter la haute disponibilité active-passive, car elle empêche la mise à l’échelle horizontale.
- Vous devez distribuer toutes les connexions Internet entrantes à toutes les instances en cours d’exécution à l’aide d’une référence SKU Azure Load Balancer Standard.
- Les appliances virtuelles réseau de couches 3 et 4 doivent être configurées de façon à utiliser DNAT pour traduire les connexions Internet entrantes vers l’adresse IP privée de l’application Azure VMware Solution que vous souhaitez publier.
- Pour préserver la symétrie du flux, vous devez configurer les appliances virtuelles réseau de couches 3 et 4 de façon à utiliser SNAT pour traduire les connexions Internet entrantes vers l’adresse IP privée de leur interface de sortie.
- Les appliances virtuelles réseau de couche 7 agissent en tant que proxys inverses et gèrent deux sessions TCP distinctes pour chaque connexion cliente entrante : une entre le client et l’appliance virtuelle réseau et l’autre entre l’appliance virtuelle réseau et le serveur d’applications en amont. Cette dernière session provient de l’adresse IP privée de l’interface de sortie de l’appliance réseau virtuelle. Les applications HTTP(S) permettent aux appliances virtuelles réseau de couche 7 de passer l’adresse IP publique du client aux serveurs d’applications dans les en-têtes de requête HTTP.
Appliances virtuelles réseau hébergées dans Azure VMware Solution (adresse IP publique sur la périphérie du centre de données NSX-T)
Pour publier des applications Azure VMware Solution via des appliances virtuelles réseau tierces déployées sur Azure VMware Solution, vous devez activer l’adresse IP publique sur la périphérie du centre de données NSX-T pour le cloud privé. Cette fonctionnalité associe des adresses IP publiques Azure à partir d’un préfixe d’adresse IP publique Azure au cloud privé et configure l’infrastructure principale de Microsoft pour acheminer le trafic Internet destiné à ces adresses IP vers les passerelles NSX-T T0 ou T1 du cloud privé. Les passerelles T1 peuvent ensuite être configurées pour utiliser DNAT pour traduire les connexions entrantes en adresses IP privées d’appliances virtuelles réseau attachées à des segments NSX-T. Pour obtenir des conseils sur la configuration de l’adresse IP publique sur NSX-T Data Center Edge et la configuration des règles DNAT pour la connectivité Internet entrante, consultez Activer l’adresse IP publique sur la périphérie du centre de données NSX-T. Lorsque vous utilisez Azure VMware Solution avec une adresse IP publique sur la périphérie du centre de données NSX-T, les considérations suivantes s’appliquent :
- Effectuez NAT sur des passerelles T1, et non sur des passerelles T0. Dans les clouds privés Azure VMware Solution, les passerelles T0 sont des paires d’appareils actives et ne peuvent donc pas gérer les sessions NAT avec état.
- Vous devez associer des adresses IP publiques à un préfixe d’adresse IP publique Azure. L’utilisation d’adresses IP à partir de préfixes d’adresses IP personnalisées (BYOIP) n’est actuellement pas prise en charge.
- Lorsqu’un cloud privé Azure VMware Solution est configuré avec une adresse IP publique sur la périphérie du centre de données NSX-T, un itinéraire par défaut est installé dans les passerelles T0/T1. Il route les connexions Internet sortantes via la périphérie du réseau principal de Microsoft. Par conséquent, l’utilisation de l’adresse IP publique sur la périphérie du centre de données NSX-T pour la connectivité Internet entrante détermine également l’option d’implémentation pour la connectivité sortante, qui est abordée dans l’article suivant de ce guide.
Étapes suivantes
Découvrez la connectivité Internet sortante.