Partager via

Scénario d’appliance virtuelle

  • Article

Un scénario courant chez les grands clients Azure est la nécessité de fournir une application à deux niveaux qui est exposée à l’Internet tout en permettant l’accès au niveau arrière depuis un centre de données local. Cet article vous guide dans un scénario utilisant des tables de routage, une passerelle VPN et des appliances virtuelles réseau pour déployer un environnement à deux niveaux conforme aux exigences suivantes :

  • L’application web ne doit être accessible seulement depuis l’Internet public.
  • Un serveur web hébergeant l’application doit pouvoir accéder à un serveur d’application back-end.
  • Tout le trafic transitant entre l’Internet et l’application web doit passer par une appliance virtuelle de pare-feu. Cette appliance virtuelle est utilisée seulement 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 l’accès au serveur back-end et pour l’accès depuis le réseau local via une passerelle VPN.
  • Les administrateurs doivent pouvoir gérer les appliances virtuelles de pare-feu depuis leurs ordinateurs locaux, en utilisant une troisième appliance virtuelle de pare-feu consacrée exclusivement à la 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é. Vous pouvez construire ce scénario dans Azure en utilisant des groupes de sécurité réseau, des appliances virtuelles de pare-feu ou une combinaison des deux.

Le tableau suivant présente quelques-uns des avantages et inconvénients des groupes de sécurité réseau et des appliances virtuelles de pare-feu.

Article Avantages Inconvénients
Groupe de sécurité réseau Aucun coût.
Intégré à l’accès en fonction du rôle Azure.
Possibilité de créer des règles dans des 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.
Pas 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é.

À propos de l’installation

Vous pouvez déployer l’environnement précédent dans Azure en utilisant des fonctionnalités disponibles aujourd’hui :

  • Réseau virtuel : un réseau virtuel Azure agit d’une façon similaire à un réseau local. Vous pouvez le segmenter en un ou plusieurs sous-réseaux pour assurer l’isolation du trafic et la séparation des problèmes.
  • Appliance virtuelle : plusieurs partenaires fournissent des appliances virtuelles sur la Place de marché Azure, utilisables pour les 3 pare-feux décrits précédemment.
  • Tables de routage : les tables de routage sont utilisées par la mise en réseau Azure pour contrôler le flux de paquets dans un réseau virtuel. Vous pouvez appliquer ces tables de routage aux sous-réseaux. Vous pouvez appliquer une table de routage à GatewaySubnet, qui transfère tout le trafic entrant dans le réseau virtuel Azure depuis une connexion hybride vers une appliance virtuelle.
  • Transfert IP : par défaut, le moteur de mise en réseau Azure transfère les paquets aux cartes réseau virtuelles seulement si l’adresse IP de destination des paquets correspond à l’adresse IP de la carte réseau. Si une table de routage définit qu’un paquet doit être envoyé à une appliance virtuelle spécifique, le moteur de mise en réseau Azure supprime ce paquet. Pour faire en sorte que le paquet soit délivré à une machine virtuelle (dans le cas présent, 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 : l’exemple suivant n’utilise pas de groupes de sécurité réseau, mais vous pouvez utiliser des groupes de sécurité réseau appliqués aux sous-réseaux et/ou aux cartes réseau dans cette solution. Les groupes de sécurité réseau filtrent ensuite le trafic entrant et sortant de ces sous-réseaux et de ces cartes réseau.

Diagramme montrant la connectivité IPv6.

Dans cet exemple, un abonnement contient les éléments suivants :

  • Deux groupes de ressources (non représentés dans 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 est segmenté et utilisé pour imiter un centre de données local :

    • onpremsn1 : un sous-réseau contenant une machine virtuelle exécutant une distribution Linux pour imiter un serveur local.
    • onpremsn2 : un 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 est nommée OPFW sur onpremvnet. Elle est utilisée pour maintenir un tunnel vers azurevnet.

  • Un réseau virtuel nommé azurevnet est segmenté comme suit :

    • azsn1 : un sous-réseau de pare-feu externe utilisé exclusivement pour le pare-feu externe. Tout le trafic Internet entre via ce sous-réseau. Ce sous-réseau contient seulement une carte réseau liée au pare-feu externe.
    • azsn2 : un sous-réseau front-end hébergeant une machine virtuelle exécutée en tant que serveur web accessible depuis Internet.
    • azsn3 : un sous-réseau back-end hébergeant une machine virtuelle exécutant un serveur d’applications back-end auquel le serveur web front-end accède.
    • azsn4 : un sous-réseau de gestion utilisé exclusivement pour fournir un accès de gestion à toutes les appliances virtuelles de pare-feu. Ce sous-réseau contient seulement une carte réseau pour chaque appliance virtuelle de pare-feu utilisée dans la solution.
    • GatewaySubnet : un sous-réseau de connexion hybride Azure requis pour ExpressRoute et Passerelle VPN Azure afin d’assurer la connectivité entre des réseaux virtuels Azure et d’autres réseaux.

  • Il y a 3 appliances virtuelles de pare-feu dans le réseau azurevnet :

    • AZF1 : un pare-feu externe exposé à l’Internet public en utilisant une ressource d’adresse IP publique dans Azure. Vous devez disposer d’un modèle de la Place de marché Azure ou provenant directement de votre fournisseur d’appliance, qui déploie une appliance virtuelle avec 3 cartes réseau.
    • AZF2 : un pare-feu interne utilisé pour contrôler le trafic entre azsn2 et azsn3. Ce pare-feu est également une appliance virtuelle avec 3 cartes réseau.
    • AZF3 : un pare-feu de gestion accessible aux administrateurs depuis le centre de données local et connecté à un sous-réseau qui est utilisé pour gérer toutes les appliances de pare-feu. Vous trouverez des modèles d’appliance virtuelle avec deux cartes réseau dans la Place de marché Azure. Vous pouvez également en demander un directement auprès de votre fournisseur d’appliance.

Tables de routage

Liez chaque sous-réseau dans Azure à une table de routage pour définir comment le trafic initié dans ce sous-réseau est routé. S’il n’y a aucune route définie par l’utilisateur, Azure utilise des routes par défaut pour autoriser la circulation du trafic d’un sous-réseau vers un autre. Pour mieux comprendre les tables de routage et le routage du trafic, consultez Routage du trafic de réseau virtuel Azure.

Pour garantir 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 qui circule du site local vers Azure est utilisé pour gérer les pare-feux en se connectant à AZF3, et le trafic doit transiter par le pare-feu interne, AZF2. Une seule route est nécessaire dans GatewaySubnet, comme indiqué ici :

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 back-end qui héberge le serveur d’applications via AZF2.
0.0.0.0/0 10.0.2.10 Autorise tout le trafic autre à être routé via AZF1.

azsn3udr

Destination Tronçon suivant Explication
10.0.2.0/24 10.0.3.10 Autorise le trafic vers azsn2 à circuler depuis un serveur d’applications vers le serveur web via AZF2.

Vous devez également créer des tables de routage 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 vers onpremsn2 via OPFW.

onpremsn2udr

Destination Tronçon suivant Explication
10.0.3.0/24 192.168.2.4 Autorise le trafic vers le sous-réseau back-end dans Azure via OPFW.
192.168.1.0/24 192.168.2.4 Autorise le trafic vers onpremsn1 via 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 flux du trafic dans un réseau virtuel Azure. Une appliance virtuelle n’est rien de plus qu’une machine virtuelle qui exécute une application utilisée pour gérer le trafic réseau d’une certaine façon, comme un pare-feu ou un appareil effectuant la traduction d’adresses réseau (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 donc exécuter une application capable de gérer le trafic entrant et de le router de façon appropriée.

Pour en savoir plus sur le transfert IP, consultez Routage du trafic de réseau virtuel Azure.

Par exemple, imaginez que vous avez la configuration suivante dans un réseau virtuel Azure :

  • 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.
  • Une route définie par l’utilisateur(UDR) liée à onpremsn1 spécifie que tout le trafic vers onpremsn2 doit être envoyé à OPFW.

À ce stade, si onpremvm1 tente d’établir une connexion avec onpremvm2, l’UDR est utilisée et le trafic est envoyé à OPFW comme tronçon suivant. La destination réelle du paquet n’est pas modifiée. Il indique toujours que onpremvm2 est la destination.

Si le transfert IP n’est pas activé pour OPFW, la logique du réseau virtuel Azure supprime les paquets, car elle autorise l’envoi des paquets seulement à 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 changer 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 fonctionne, vous devez activer le transfert IP sur les cartes réseau pour 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 garantit seulement que les paquets sont envoyés aux 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 :

  • Route : 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 :

Route : tout le trafic vers 192.168.0.0/16 (onpremvnet) doit être envoyé à l’adresse IP de la passerelle Azure (c’est-à-dire 10.0.0.1) via port1.

Groupes de sécurité réseau

Dans ce scénario, les groupes de sécurité réseau ne sont pas utilisés. Cependant, vous pouvez appliquer des groupes de sécurité réseau à chaque sous-réseau pour restreindre le trafic entrant et le trafic sortant. Par exemple, vous pouvez appliquer les règles de groupe de sécurité réseau suivantes au sous-réseau de pare-feu 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 vers Internet.

Étapes générales

Pour déployer ce scénario, suivez les étapes suivantes :

  1. Connectez-vous à votre abonnement Azure.

  2. Si vous voulez déployer un réseau virtuel pour imiter le réseau local, déployez les ressources qui font partie de ONPREMRG.

  3. Déployez les ressources qui font partie de AZURERG.

  4. Déployez le tunnel de onpremvnet vers azurevnet.

  5. Une fois toutes les ressources approvisionnées, connectez-vous à onpremvm2 et effectuez un test ping sur 10.0.3.101 pour tester la connectivité entre onpremsn2 et azsn3.