Exemples d'environnements virtuels sur Proxmox VE

Au sommaire :

• Réseau n°1 : environnement standard
• Réseau n°2 : environnement multi-locataire

Aujourd'hui je vais vous présenter 2 exemples de réseaux virtuels que vous pouvez mettre en place avec Proxmox VE ainsi que les solutions réseaux pfSense et OPNsense.

Les images sont issus du livre de référence "Mastering Proxmox VE: Third Edition" (2017) qui est disponible uniquement en anglais aux éditions Packt Publishing.

Evidemment, aucune traduction de ma part. Je vous vulgarise avec mes propres termes ma compréhension des différents environnements.

N'oubliez pas, les environnements représentés ne sont qu'une version simplifié de ce qu'on trouve en entreprise.

Réseau n°1 : environnement standard

Comme son nom l'indique, c'est un environnement standard qu'on trouve dans nombre de petites et moyennes entreprises.

Dans l'ordre, l'environnement se compose de la manière suivante :

• Un accès internet
• Un pare-feu physique
• Un switch physique

Le cluster se compose de 3 serveurs physiques qui gère chacun deux sous réseaux utilisant les ponts "vmbr0" (carte physique eth0) et "vmbr1" (carte réseau eth1).

• vmbr0 (réseau 192.168.0.254) est isolé d'internet et sert à l'administration du cluster ainsi qu'à la gestion de machines virtuelles dans le "subnet 1". On peut en déduire que ce sont des machines qui n'ont aucun interet à être mis à disposition dans l'internet public (serveur de fichier, base de données, etc)
• vmbr1 (réseau 192.168.1.254) a accès à internet par le biais du pare-feu physique et le rend accessible aux machines virtuelles du "subnet 2". Cela peut-être des sites web, serveur de messageries; serveur mail, etc.

Enfin, un poste client est représenté pour l'administration du cluster.

On peut remarquer plusieurs détails :

• Aucun switch virtuel utilisé pour le subnet 2
• Un énorme SPOF (Single Point of Failure ou Point de Défaillance unique) qui est le pare-feu physique
• Aucune haute disponibilité côté pare-feu

Si ce pare-feu tombe, plus d'accès internet pour le "subnet 2" et pour le reste des postes clients vu qu'il à la charge de gérer l'interface "WAN".

Réseau n°2 : environnement multi-locataire

Nous avons toujours un cluster composé de 3 nœuds sous PVE.

• Le pare-feu physique est toujours en front des serveurs physiques sur le réseau 192.168.1.254 et gère l'interface "WAN" pour l'accès internet,
• Le switch physique et le poste d'administration sont toujours présents

Jusqu'ici, rien n'a changer.

Sauf que la nouveauté dans l’environnement n°2, c'est que les machines virtuelles des subnet 2 et 3 sont connectés à des switch virtuels (Open vSwitch/Linux Bridge) et passent par des pare-feux virtualisés.

Tout cela est permis grâce aux pilotes de para-virtualisation VirtIO,

À noter que cela implique une plus grosse charge de travail du côté des serveurs physiques car VirtIO étant un "Software Defined Network" (réseau défini par logiciel), c'est le processeur qui prend en charge ce type de tâche.

Mais une carte réseau dite SmartNIC (carte réseau intelligente) peut décharger le processeur de ce type de tâche en ayant la topologie réseau de VirtIO et gérer le tout au niveau matériel.

Poursuivons :

• Dans l'environnement n°1, seul le subnet 2 bénéficier des services du pare-feu physique tandis que le subnet 1 était isolé via le pare-feu par défaut de Proxmox VE (iptable/netfilter). Ce n'est pas indiqué par l'auteur mais c'est quasiment sûr
• Le subnet 1 (vmbr0, pont par défaut des nœuds) n'est plus isolé d'internet et voit son accès desservi par l'interface WAN du pare-feu physique
• Les subnet 2 et 3 qui ont respectivement comme interface LAN les ponts vmbr1 et vmbr200 utilisent vmbr0 comme interface WAN pour l'accès internet

C'est un type d'environnement qu'on trouve chez les fournisseurs cloud qui proposent du IaaS (Infrastructure as a Service).

Dernier observation, le SPOF est toujours présent car le pare-feu physique n'est toujours pas en haute disponibilité et étant donné que plusieurs sous réseaux virtuels sont présents sur les serveurs, cela implique une plus grosse charge de travail pour le pare-feu physique, notamment dans le cas où un fournisseur cloud propose ses services à de multiples entreprises.

Pour fournir des services à leur clientèles, les fournisseurs ont besoin de segmenter leur réseau en de multiples sous réseaux virtuels pour des raisons de sécurité.

Imaginez que chaque sous réseau appartient à un client et que ce dernier dispose de son propre pare-feu virtualisé pour plus de sécurité.

Par exemple, si une entreprise loue les service IaaS d'un fournisseur cloud et qu'il a besoin d'un serveur VPN pour ses salariés, il lui suffira de l'installer dans un pare-feu virtualisé pour que ses salariés puissent accéder au réseau.

Enfin, l'auteur du livre donne également deux conseils :

• Ne JAMAIS utiliser l'interface WAN sur un pare-feu virtualisé dans un cluster
• Toujours mettre un pare-feu physique en front des serveurs physique et comme barrière entre internet et le réseau interne

Source :