Considérations relatives à la topologie et à la connectivité réseau pour Red Hat Enterprise Linux sur Azure
Cet article décrit les considérations et les recommandations relatives au réseau Red Hat Enterprise Linux (RHEL) qui sont basées sur les recommandations de l’article consacré à la zone de conception pour la topologie et la connectivité du réseau de la zone d’atterrissage Azure.
Architecture
L’architecture RHEL suivante est un point de départ que vous pouvez adapter pour répondre à vos besoins métier et techniques spécifiques. Vous pouvez déployer les différents composants et rôles de plateforme RHEL sur des machines virtuelles avec un dimensionnement et une redondance spécifiques en fonction de vos besoins. L’organisation simplifiée du réseau de ces exemples illustre les principes de l’architecture et ne décrit pas un réseau d’entreprise complet.
Téléchargez un fichier Visio de cette architecture.
| Element | Description |
|---|---|
| Un | Composants du Contrat client Microsoft et facturation |
| G | Composants de gestion des identités et des accès Microsoft Entra |
| C | Composants des groupes d’administration Azure |
| D | Composants de l’abonnement de gestion des identités Windows Server Active Directory |
| E | Composants de l’abonnement hub réseau |
| F | Composants de l’abonnement gestion et identité RHEL |
| G | Composants de l’abonnement de groupe d’administration Azure |
| H | Composants de l’abonnement de charge de travail de production RHEL |
| I | Composants locaux |
| J | Red Hat Cloud Services |
Considérations relatives à la conception pour la mise en réseau des zones d’atterrissage RHEL
Tenez compte des recommandations suivantes pour la conception de la mise en réseau d’une zone d’atterrissage :
Utilisez une topologie de réseau en étoile pour les déploiements à une seule région ou à plusieurs régions. Azure Virtual WAN Hub fournit des fonctionnalités supplémentaires. Vous pouvez également utiliser un hub de réseau virtuel traditionnel. Pour plus d’informations, consultez la documentation relative à la mise en réseau des zones d’atterrissage Azure.
Utilisez l’infrastructure en tant que code pour automatiser vos déploiements, la gestion de la configuration et les opérations jour 2 pour tous les composants réseau de zone d’atterrissage.
Pour améliorer la sécurité, utilisez des points de terminaison privés pour tous les services Azure pris en charge. Les points de terminaison privés garantissent que l’ensemble du trafic soit acheminé sur votre réseau privé plutôt que sur les adresses IP publiques.
Considérations relatives au pare-feu
Le diagramme suivant illustre une architecture hybride de zone d’atterrissage RHEL de région Azure.
| Element | Description |
|---|---|
| Un | Composants du réseau virtuel Red Hat Management contenu via l’abonnement Red Hat Management |
| G | Composants du réseau virtuel RHEL Workloads contenus via l’abonnement RHEL Production Workloads |
| C | Composants du réseau virtuel Identity Management contenu via l’abonnement Red Hat Identity Management |
| D | Composants du réseau virtuel RHEL Workloads contenus via l’abonnement RHEL Production Workloads |
Pour les topologies Virtual WAN, envisagez d’utiliser le Pare-feu Azure pour acheminer le trafic entre les zones d’atterrissage. Le Pare-feu Azure fournit des fonctionnalités de filtrage et de journalisation du trafic.
Une passerelle VPN Azure ou une passerelle Azure ExpressRoute contrôle la connectivité hybride au hub. Pour surveiller et contrôler le trafic, utilisez le Pare-feu Azure ou une appliance de réseau virtuel (NVA) dans le hub.
Vous pouvez utiliser un pare-feu local pour protéger et acheminer tout le trafic Internet d'entrée et de sortie. Un pare-feu peut introduire une latence pour les ressources cloud. Comprenez vos exigences en matière de performances et de sécurité pour déterminer la façon dont vous devez acheminer le trafic entrant et sortant.
Considérations relatives au sous-réseau
Le diagramme suivant illustre les sous-réseaux de gestion et de charge de travail dans une configuration résiliente à la zone.
Lorsque vous planifiez des étendues d’adresses IP et une taille de réseau virtuel pour la zone d’atterrissage RHEL, envisagez des sous-réseaux dédiés pour les ressources d’application, de base de données et de stockage.
Adoptez une approche Confiance Zéro concernant la sécurité du réseau et du trafic de votre périmètre. Pour plus d’informations, consultez Stratégies de sécurité réseau sur Azure.
Considérations relatives au groupe de sécurité réseau
Utilisez des groupes de sécurité réseau (NSG) afin protéger le trafic dans des sous-réseaux, ainsi que le trafic est-ouest sur la plateforme (trafic entre zones d’atterrissage). Azure Policy peut faire de cette configuration celle par défaut pour tous les sous-réseaux.
Utilisez des NSG et des groupes de sécurité d’application pour le trafic de micro-segment à l’intérieur de la zone d’atterrissage, et évitez d’utiliser une appliance virtuelle réseau centrale pour filtrer les flux de trafic.
Activez les journaux de flux NSG et transmettez-les dans Traffic Analytics. Pour optimiser la capacité d’audit et la sécurité, activez les journaux de flux sur tous les réseaux virtuels et sous-réseaux critiques de votre abonnement.
Utilisez des groupes de sécurité réseau pour autoriser de manière sélective la connectivité entre zones d’atterrissage.
L’équipe d’application doit utiliser des groupes de sécurité d’application dans les groupes de sécurité réseau au niveau du sous-réseau pour protéger des machines virtuelles multiniveaux au sein de leur zone d’atterrissage.
Si votre organisation implémente un tunneling forcé ou un itinéraire par défaut publié vers des emplacements locaux, envisagez d’incorporer des règles de NGS sortantes afin de refuser le trafic de sortie du réseau virtuel directement vers Internet. Cette configuration fournit une résilience si la session BGP (Border Gateway Protocol) s’interrompt. Pour plus d’informations, consultez l’article Planifier la segmentation du réseau de zone d’atterrissage.
Autres considérations
Activez l’accès à Internet ainsi que le filtrage et l’inspection du trafic. Les options de trafic sortant pour activer l’accès à Internet ainsi que le filtrage et l’inspection du trafic sont les suivantes :
- Accès sortant à Red Hat Cloud via le réseau hub.
- Route locale par défaut utilisant un accès Internet local.
- Virtual WAN ou hub de réseau virtuel traditionnel sécurisé avec Pare-feu Azure ou une appliance virtuelle réseau.
Offrez du contenu et des applications. Les options entrantes pour fournir du contenu et des applications sont les suivantes :
- Azure Application Gateway avec La couche 7, terminaison TLS (Transport Layer Security) et Web Application Firewall
- Traduction de réseau dynamique (DNAT) et un équilibreur de charge à partir d’un environnement local
- Réseau virtuel Azure avec Pare-feu Azure ou une appliance virtuelle réseau, et Azure Route Server dans divers scénarios
- Hub Virtual WAN avec le Pare-feu Azure, avec la couche 4 et la traduction DNAT
- Hub Virtual WAN avec appliance virtuelle réseau dans différents scénarios
Configurez la résolution de noms de domaine pour les ressources locales et Azure. L’environnement RHEL utilise souvent des ressources locales et des ressources Azure, ce qui nécessite une résolution efficace des noms des ressources. Tenez compte des recommandations suivantes :
- Azure fournit une résolution de nom interne par défaut au sein d’un réseau virtuel. Ce scénario ne nécessite aucune configuration. Vous ne pouvez pas modifier le suffixe de résolution de noms de domaine ni effectuer une inscription manuelle. Pour plus d’informations, consultez Résolution de noms fournie par Azure.
- Pour la résolution de noms sur les réseaux virtuels, les déploiements RHEL utilisent souvent des services DNS (Domain Name System) à partir de Redhat Identity Management Server (IdM) ou d’Azure DNS. Pour fournir un transfert basé sur des règles, combinez Azure Private DNS Resolver et l’infrastructure DNS existante.