Scénario d’appliance virtuelle
Pour les clients Azure volumineux, il faut souvent fournir une application à deux niveaux exposée à Internet, tout en autorisant l’accès au niveau d’arrière-plan à partir d’un centre de données local. Ce document vous guide dans un scénario utilisant des tables de routage, une passerelle VPN et des appliances virtuelles de réseau pour déployer un environnement à deux niveaux conforme aux exigences suivantes :
L’application web ne doit être accessible qu’à partir de l’Internet public.
Le serveur web hébergeant l’application doit pouvoir accéder à un serveur d’application principal.
Tout le trafic transitant entre Internet et l’application web doit passer par une appliance virtuelle de pare-feu. Cette appliance virtuelle n’est utilisée que pour le trafic Internet.
Tout le trafic envoyé au serveur d’applications doit transiter par une appliance virtuelle de pare-feu. Cette appliance virtuelle est utilisée pour accéder au serveur principal depuis le réseau local via une passerelle VPN.
Les administrateurs doivent pouvoir gérer les appliances virtuelles de pare-feu à partir de leurs ordinateurs locaux, en utilisant une troisième appliance virtuelle de pare-feu exclusivement à des fins de gestion.
Cet exemple est un scénario de réseau de périmètre standard (également nommé DMZ) avec une zone DMZ et un réseau protégé. Ce scénario peut être mis en œuvre dans Azure à l’aide de groupes de sécurité réseau, d’appliances virtuelles de pare-feu ou d’une combinaison des deux.
Le tableau ci-dessous présente certains avantages et inconvénients des groupes de sécurité réseau et appliances virtuelles de pare-feu.
| Élément | Avantages | Inconvénients |
|---|---|---|
| Groupe de sécurité réseau | Aucun coût. Intégré à l’accès en fonction du rôle Azure. Il est possible de créer des règles dans les modèles Azure Resource Manager. |
Complexité variable dans les environnements de grande taille. |
| Pare-feu | Contrôle total sur le plan des données. Gestion centralisée via la console du pare-feu. |
Coût de l’appliance de pare-feu. Non intégré à l’accès en fonction du rôle Azure. |
La solution suivante utilise des appliances virtuelles de pare-feu pour implémenter un scénario de réseau de périmètre (DMZ)/réseau protégé.
Considérations
Vous pouvez déployer l’environnement décrit précédemment dans Azure à l’aide de différentes fonctionnalités disponibles aujourd’hui, comme suit.
Réseau virtuel. Un réseau virtuel Azure se comporte de manière similaire à un réseau local et peut se décomposer en un ou plusieurs sous-réseaux pour isoler le trafic et les problèmes.
Appliance virtuelle. Plusieurs partenaires fournissent des appliances virtuelles dans la Place de marché Azure, utilisables pour les trois pare-feu décrits précédemment.
Tables de routage. Les tables de routage sont utilisées par les itinéraires définis par l’utilisateur, utilisées par la mise en réseau Azure pour contrôler le flux de paquets dans un réseau virtuel. Ces tables d’itinéraires peuvent être appliquées à des sous-réseaux. Vous pouvez appliquer une table de routage à GatewaySubnet, qui transfère tout le trafic entrant dans le réseau virtuel Azure d’une connexion hybride à une appliance virtuelle.
Transfert IP. Par défaut, le moteur de mise en réseau Azure ne transfère les paquets aux cartes réseau que si l’adresse IP de destination des paquets correspond à l’adresse IP de la carte réseau. Par conséquent, si une table de routage définie par l’utilisateur détermine qu’un paquet doit être envoyé à une appliance virtuelle donnée, le moteur de mise en réseau Azure supprime ce paquet. Pour vérifier que le paquet est envoyé à une machine virtuelle (dans ce cas, une appliance virtuelle) qui n’est pas la destination réelle du paquet, activez le transfert IP pour l’appliance virtuelle.
Groupes de sécurité réseau (NSG) . L’exemple suivant ne tire pas parti de groupes de sécurité réseau, mais vous pouvez utiliser les groupes de sécurité réseau appliqués aux sous-réseaux et/ou à des NIC dans cette solution. Les groupes de sécurité réseau filtrent davantage le trafic entrant et sortant de ces sous-réseaux et cartes réseau.
Dans cet exemple, il existe un abonnement qui contient les éléments suivants :
Deux groupes de ressources, non représentés sur le diagramme.
ONPREMRG. Contient toutes les ressources nécessaires pour simuler un réseau local.
AZURERG. Contient toutes les ressources nécessaires pour l’environnement du réseau virtuel Azure.
Un réseau virtuel nommé onpremvnet segmenté comme suit utilisé pour imiter un centre de données local.
onpremsn1. Sous-réseau contenant une machine virtuelle exécutant une distribution Linux pour imiter un serveur local.
onpremsn2. Sous-réseau contenant une machine virtuelle exécutant une distribution Linux pour simuler un ordinateur local utilisé par un administrateur.
Une appliance virtuelle de pare-feu nommée OPFW sur onpremvnet utilisée pour conserver un tunnel vers azurevnet.
Un réseau virtuel nommé azurevnet segmenté comme suit.
azsn1. Sous-réseau utilisé exclusivement pour le pare-feu externe. Tout le trafic Internet entrera par ce sous-réseau. Ce sous-réseau ne contient qu’une carte réseau liée au pare-feu externe.
azsn2. Sous-réseau front-end hébergeant une machine virtuelle exécutée en tant que serveur web accessible à partir d’Internet.
azsn3. Sous-réseau principal hébergeant une machine virtuelle exécutant un serveur d’applications principal sollicité par le serveur web front-end.
azsn4. Sous-réseau utilisé exclusivement pour fournir un accès de gestion à toutes les appliances virtuelles de pare-feu. Ce sous-réseau ne contient qu’une carte réseau pour chaque appliance virtuelle de pare-feu utilisée dans la solution.
GatewaySubnet. Sous-réseau de connexion hybride Azure requis pour une route ExpressRoute et une passerelle VPN assurant la connectivité entre des réseaux virtuels Azure et d’autres réseaux.
Le réseau azurevnet contient 3 appliances virtuelle de pare-feu.
AZF1. Pare-feu externe exposé à l’Internet public par l’utilisation d’une ressource ayant une adresse IP publique dans Azure. Vous devez vous procurer un modèle auprès de Marketplace ou directement auprès de votre fournisseur d’appliances, qui déploie une appliance virtuelle à 3 cartes réseau.
AZF2. Pare-feu interne utilisé pour contrôler le trafic entre azsn2 et azsn3. Ce pare-feu est également une appliance virtuelle à 3 cartes réseau.
AZF3. Pare-feu de gestion accessible aux administrateurs à partir du centre de données local, et connecté à un sous-réseau servant à gérer toutes les appliances de pare-feu. Vous pouvez trouver des modèles d’appliance virtuelle à 2 cartes réseau dans Marketplace ou en demander un à votre fournisseur d’appliances.
Tables de routage
Chaque sous-réseau dans Azure peut être lié à une table de routage utilisée pour définir le mode d’acheminement du trafic dans ce sous-réseau. Si aucun UDR n’est défini, Azure utilise les itinéraires par défaut pour autoriser le trafic d’un sous-réseau à un autre. Pour mieux comprendre les tables de routage et le routage du trafic, consultez Routage du trafic de réseau virtuel Azure.
Pour assurer que la communication transite par l’appliance de pare-feu appropriée, conformément à la dernière exigence indiquée précédemment, vous devez créer la table de routage suivante dans azurevnet.
azgwudr
Dans ce scénario, seul le trafic local dirigé vers Azure sert à gérer le pare-feu en se connectant à AZF3. De plus, le trafic doit transiter par le pare-feu interne AZF2. Par conséquent, un seul itinéraire est nécessaire dans GatewaySubnet comme indiqué ci-dessous.
| Destination | Tronçon suivant | Explication |
|---|---|---|
| 10.0.4.0/24 | 10.0.3.11 | Autorise le trafic local à atteindre le pare-feu de gestion AZF3 |
azsn2udr
| Destination | Tronçon suivant | Explication |
|---|---|---|
| 10.0.3.0/24 | 10.0.2.11 | Autorise le trafic vers le sous-réseau principal qui héberge le serveur d’applications, à transiter par AZF2 |
| 0.0.0.0/0 | 10.0.2.10 | Autorise tout autre trafic à transiter par AZF1 |
azsn3udr
| Destination | Tronçon suivant | Explication |
|---|---|---|
| 10.0.2.0/24 | 10.0.3.10 | Autorise le trafic destiné à azsn2 à circuler du serveur d’applications vers le serveur web via AZF2. |
Vous devez également créer des tables d’itinéraires pour les sous-réseaux dans onpremvnet afin d’imiter le centre de données local.
onpremsn1udr
| Destination | Tronçon suivant | Explication |
|---|---|---|
| 192.168.2.0/24 | 192.168.1.4 | Autorise le trafic destiné à onpremsn2 à transiter par OPFW. |
onpremsn2udr
| Destination | Tronçon suivant | Explication |
|---|---|---|
| 10.0.3.0/24 | 192.168.2.4 | Autorise le trafic vers le sous-réseau sauvegardé dans Azure à transiter par OPFW |
| 192.168.1.0/24 | 192.168.2.4 | Autorise le trafic destiné à onpremsn1 à transiter par OPFW. |
transfert IP
Les tables de routage et le transfert IP sont des fonctionnalités que vous pouvez combiner pour permettre à des appliances virtuelles de contrôler le trafic dans un réseau virtuel Azure. Une appliance virtuelle n’est rien de plus qu’une machine virtuelle qui exécute une application permettant de gérer le trafic réseau d’une certaine façon, comme un pare-feu ou un périphérique NAT.
La machine virtuelle d’appliance virtuelle doit être capable de recevoir le trafic entrant qui ne lui est pas adressé. Pour permettre à une machine virtuelle de recevoir le trafic adressé à d’autres destinations, vous devez activer le transfert IP pour la machine virtuelle. Il s’agit d’un paramètre Azure, pas d’un paramètre du système d’exploitation invité. Votre appliance virtuelle doit toujours exécuter un type d’application pour gérer le trafic entrant et l’acheminer correctement.
Pour en savoir plus sur le transfert IP, consultez Routage du trafic de réseau virtuel Azure.
Par exemple, imaginez un réseau virtuel Azure avec la configuration suivante :
Le sous-réseau onpremsn1 contient une machine virtuelle nommée onpremvm1.
Le sous-réseau onpremsn2 contient une machine virtuelle nommée onpremvm2.
Une appliance virtuelle nommée OPFW est connectée à onpremsn1 et à onpremsn2.
Un itinéraire défini par l’utilisateur et lié à onpremsn1 spécifie que tout le trafic destiné à onpremsn2 doit être envoyé à OPFW.
À ce point, si onpremvm1 tente d’établir une connexion à onpremvm2, l’UDR sera utilisé et le trafic sera envoyé à OPFW en tant tronçon suivant. N’oubliez pas que la destination réelle du paquet n’est pas modifiée (onpremvm2).
Si le transfert IP n’est pas activé pour OPFW, la logique du réseau virtuel Azure supprime les paquets, car elle n’autorise l’envoi des paquets qu’à une machine virtuelle dont l’adresse IP correspond à la destination du paquet.
Avec le transfert IP, la logique du réseau virtuel Azure transmet les paquets à OPFW, sans modifier leur adresse de destination d’origine. OPFW doit gérer les paquets et déterminer ce qu’il faut en faire.
Pour que ce scénario vu précédemment fonctionne, vous devez activer le transfert IP sur les cartes réseau d’OPFW, AZF1, AZF2 et AZF3 qui sont utilisées pour le routage (toutes les cartes réseau sauf celles liées au sous-réseau de gestion).
Règles de pare-feu
Comme décrit précédemment, le transfert IP ne garantit que l’envoi des paquets à des appliances virtuelles. Votre appliance doit encore décider quoi faire avec les paquets. Dans le scénario précédent, vous devez créer les règles suivantes dans vos appliances :
OPFW
OPFW représente un appareil local contenant les règles suivantes :
Itinéraire : tout le trafic vers 10.0.0.0/16 (azurevnet) doit être envoyé via le tunnel ONPREMAZURE.
Stratégie : autoriser tout le trafic bidirectionnel entre port2 et ONPREMAZURE.
AZF1
AZF1 représente une appliance virtuelle Azure contenant les règles suivantes :
- Stratégie : autoriser tout le trafic bidirectionnel entre port1 et port2.
AZF2
AZF2 représente une appliance virtuelle Azure contenant les règles suivantes :
- Stratégie : autoriser tout le trafic bidirectionnel entre port1 et port2.
AZF3
AZF3 représente une appliance virtuelle Azure contenant les règles suivantes :
- Itinéraire : tout le trafic vers 192.168.0.0/16 (onpremvnet) doit être envoyé à l’adresse IP de la passerelle Azure (par exemple, 10.0.0.1) via port1.
Groupes de sécurité réseau (NSG)
Dans ce scénario, les groupes de sécurité réseau ne sont pas utilisés. Toutefois, vous pouvez appliquer des groupes de sécurité réseau à chaque sous-réseau pour limiter les trafics entrant et sortant. Par exemple, vous pouvez appliquer les règles de groupe de sécurité réseau suivantes au sous-réseau FW externe.
Entrant
Autoriser tout le trafic TCP provenant d’Internet vers le port 80 sur toutes les machines virtuelles du sous-réseau.
Refuser tout autre trafic provenant d’Internet.
Sortant
- Refuser tout le trafic provenant d’Internet.
Étapes de haut niveau
Pour déployer ce scénario, suivez les étapes générales suivantes.
Connectez-vous à votre abonnement Azure.
Si vous souhaitez déployer un réseau virtuel pour imiter le réseau local, déployez les ressources qui font partie d’ONPREMRG.
Déployez les ressources qui font partie d’AZURERG.
Déployez le tunnel reliant onpremvnet à azurevnet.
Une fois toutes les ressources approvisionnées, connectez-vous sur onpremvm2 et envoyez la commande ping 10.0.3.101 pour tester la connectivité entre onpremsn2 et azsn3.