Proxmox

1 Proxmox Virtual Environment (PVE)

Proxmox Virtual Environment (PVE) est une distribution Linux basée sur Debian doté d’un
environnement de gestion de VM libre et Open Source (licence AGPLv3) Proxmox utilise KVM/QEMU
ainsi que les containers Linux LXC.

Proxmox n'utilise pas `libvirt` pour gérer les machines virtuelles et dispose d’API REST qui inclut une
interface web intuitive et des outils de gestion des ressources virtuelles : CPU, Stockage, réseaux...

Le modèle de développement évolutif et ouvert de Proxmox VE garantit un accès complet au code

source du produit.

1.1 KVM (Kernel-based Virtual Machine)

KVM est une technologie de virtualisation native dans le noyau Linux, qui transforme le noyau Linux
en un hyperviseur de type 1.

KVM permet à Proxmox d'exécuter des machines virtuelles en utilisant les fonctionnalités de
virtualisation matérielle (comme Intel VT-x ou AMD-V) disponibles sur les processeurs modernes.

Proxmox interagit directement avec KVM via des commandes et des interfaces spécifiques, sans
nécessiter de couche intermédiaire comme `libvirt`.

1.2 QEMU (Quick EMUlator)

QEMU est utilisé en conjonction avec KVM pour fournir l'émulation matérielle nécessaire à
l'exécution des machines virtuelles. QEMU peut émuler un large éventail de matériels, ce qui permet
de virtualiser pratiquement n'importe quel système d'exploitation.

Dans Proxmox, QEMU gère les aspects non-virtualisés des VM, tels que l'émulation des
périphériques, tandis que KVM gère l'exécution des instructions CPU en mode natif.

1.3 Proxmox VE Management Stack / Gestionnaire de Clusters

Proxmox offre une interface web et des outils en ligne de commande pour gérer les clusters, les
nœuds, et les ressources virtuelles. Ce stack inclut la gestion du stockage, du réseau, des snapshots,
et des sauvegardes, ainsi que l'orchestration des VMs et des conteneurs.

1.4 L’API proxmox

Proxmox VE (Virtual Environment) propose une API RESTful qui permet d'automatiser et de gérer
presque toutes les fonctionnalités disponibles via l'interface web. Cette API est très complète et
permet d'interagir avec les différentes fonctionnalités de Proxmox, y compris la gestion des machines
virtuelles, des conteneurs, des réseaux, du stockage, et plus encore.

1.4.1API de Gestion des Machines Virtuelles (VMs)

 Création de VM : Permet de créer de nouvelles machines virtuelles avec des

configurations spécifiques.
 Gestion des Snapshots : Création, suppression, et restauration de snapshots pour les
VMs.
 Contrôle des VMs : Démarrage, arrêt, redémarrage, suspension, et autres opérations de
gestion des VMs.
 Migration des VMs : Migrer des VMs entre différents nœuds au sein du cluster Proxmox.
 Accès à la console : Gérer l'accès à la console des VMs via l'API.

1.4.2API de Gestion des Conteneurs LXC

 Création de Conteneurs : Permet de créer de nouveaux conteneurs Linux (LXC) avec des
configurations spécifiques.
 Gestion des Snapshots : Prendre des snapshots des conteneurs et les gérer.
 Contrôle des Conteneurs : Démarrer, arrêter, redémarrer, suspendre, ou cloner des
conteneurs.
 Gestion des ressources : Modifier les limites de ressources (CPU, RAM, stockage) des
conteneurs.

1.4.3API de Gestion des Clusters

 Ajout de Nœuds : Permet d'ajouter ou de retirer des nœuds dans le cluster Proxmox.
 Gestion du Cluster : Surveillance de l'état du cluster, y compris la santé des nœuds, des
VMs, et des conteneurs.
 Gestion des Groupes de Haute Disponibilité (HA) : Créer et gérer des groupes HA pour
assurer la disponibilité des services critiques.

1.4.4API de Gestion du Réseau

 Configuration des Interfaces Réseau : Gérer les interfaces réseau des nœuds, des VMs et
des conteneurs.
 Gestion des VLANs et Bridges : Créer et configurer des réseaux VLAN et des bridges pour
segmenter le trafic réseau.
 Gestion des Firewalls : Configurer des règles de firewall pour protéger les ressources au
sein du cluster.

1.4.5API de Gestion du Stockage

 Ajout de Stockage : Ajouter et configurer des pools de stockage pour les VMs et les
conteneurs.
 Gestion des Volumes : Créer, attacher, détacher, et supprimer des volumes de stockage.
 Snapshots et Backups : Gérer les snapshots de stockage et configurer des sauvegardes
régulières.
1.4.6API de Gestion des Utilisateurs et des Permissions

 Gestion des Utilisateurs : Créer, modifier, et supprimer des utilisateurs au sein du

système Proxmox.
 Gestion des Rôles et Permissions : Attribuer des rôles et configurer des permissions
spécifiques pour les utilisateurs.
 Authentification : Gérer les méthodes d'authentification et les tokens API.

1.4.7API de Surveillance et de Reporting

 Surveillance des Performances : Accéder aux métriques de performances des nœuds,

VMs, et conteneurs, comme l'utilisation CPU, RAM, et réseau.
 Logs et Audit : Accéder aux journaux d'événements et d'audit pour surveiller l'activité du
système.
 Alertes : Configurer des alertes pour des conditions spécifiques (comme une surcharge
de CPU ou un manque d'espace disque).

1.4.8L'API Proxmox VE

Authentification : L'API Proxmox nécessite une authentification basée sur un ticket d'authentification
ou un token API. Les utilisateurs doivent s'authentifier en premier pour recevoir un ticket ou utiliser
un token pour les appels API.

Formats de réponse : L'API retourne généralement les réponses en format JSON, ce qui facilite
l'intégration avec d'autres outils et langages de programmation.

Exemple de requête API :

curl -k -X POST "https ://<proxmox_host> :8006/api2/json/access/ticket" -d

"username=root@pam&password=yourpassword"

Ce type de commande permet d'obtenir un ticket d'authentification pour effectuer des appels API
supplémentaires.

1.4.9Documentation de l'API

Proxmox offre une documentation complète et interactive de son API accessible via l'interface web.

https ://[Link] :8006/pve-docs/[Link]

1.5 Les Conteneurs LXC

Proxmox prend en charge LXC (Linux Containers) pour exécuter des conteneurs légers. LXC offre une
virtualisation au niveau du système d'exploitation, permettant l'exécution de plusieurs systèmes
Linux isolés sur un même hôte.

Les conteneurs LXC sont gérés via la même interface web que les VMs, offrant une gestion unifiée
des ressources.

Cela introduit un mélange des genres qui peut prêter à confusion. (-1)

1.6 Stockage et Réseaux

Proxmox supporte plusieurs types de stockage pour les VMs et les conteneurs, y compris les
systèmes de fichiers locaux, les volumes LVM, ZFS, NFS, et les systèmes de stockage distribués
comme Ceph.

Proxmox permet la configuration de réseaux complexes pour les VMs et les conteneurs, incluant le
support pour les VLANs, les ponts réseaux, et les configurations réseau avancées comme SDN
(Software-Defined Networking).

1.7 Proxmox Backup Server

Il existe une version gratuite de Proxmox Backup Server. Proxmox offre son logiciel sous une licence
open-source, ce qui signifie que vous pouvez télécharger, installer et utiliser Proxmox Backup Server
gratuitement.

1.7.1Détails de la Version Gratuite :

 Open Source : Proxmox Backup Server est distribué sous la licence GNU Affero General
Public License, version 3 (AGPLv3). Cela signifie que vous avez accès au code source
complet du logiciel.
 Fonctionnalités Complètes : La version gratuite de Proxmox Backup Server offre toutes
les fonctionnalités de base et avancées du logiciel, sans aucune limitation fonctionnelle.
Vous pouvez l'utiliser pour effectuer des sauvegardes, des restaurations, et des
vérifications d'intégrité de vos données.
 Mises à jour : Vous pouvez recevoir les mises à jour gratuites du logiciel via les dépôts
publics. Cependant, les mises à jour sont généralement publiées avec un léger décalage
par rapport aux dépôts d'entreprise (ceux accessibles avec un abonnement).

1.7.2Abonnement Proxmox :

Bien que la version gratuite soit pleinement fonctionnelle, Proxmox propose également des
abonnements payants qui offrent des avantages supplémentaires :

 Support Technique : Les abonnements payants vous donnent accès au support

technique professionnel de Proxmox.
  Dépôts Entreprise : Les abonnements incluent l'accès aux dépôts d'entreprise, qui
fournissent des mises à jour plus fréquemment testées et stables.
 Accès Prioritaire aux Correctifs : Les utilisateurs avec un abonnement reçoivent des
correctifs de sécurité et des mises à jour prioritaires.

1.8 Comparaison de l'API Proxmox et des virtlib

L'API Proxmox VE et `libvirt` servent des objectifs similaires mais sont conçues pour des contextes
d'utilisation différents.

L'API Proxmox est spécifiquement adaptée à l'écosystème Proxmox et est idéale pour la gestion
d'environnements Proxmox complets, avec une forte intégration des fonctionnalités spécifiques à
Proxmox, telles que la haute disponibilité, les conteneurs, et le stockage.

D'un autre côté, `libvirt` offre une flexibilité multi-hyperviseur et est largement utilisé dans des
environnements où l'on souhaite gérer plusieurs types de technologies de virtualisation à partir
d'une interface uniforme.

1.8.1Objectif et Portée
API Proxmox VE

Objectif : Fournir une solution complète de gestion de l'infrastructure virtuelle, incluant la gestion
des machines virtuelles, des conteneurs, des réseaux, du stockage, et des clusters. Elle est conçue
pour gérer un environnement de virtualisation entier, avec des fonctionnalités spécifiques à
Proxmox.

Portée : Orientée vers les administrateurs systèmes et les opérateurs de centres de données qui
gèrent des infrastructures complexes basées sur Proxmox VE. L'API Proxmox couvre un large éventail
de fonctions, y compris la gestion des utilisateurs, les permissions, les backups, et la haute
disponibilité (HA).

libvirt

Objectif : Fournir une interface uniforme pour gérer les hyperviseurs et les technologies de
virtualisation. `libvirt` est une API générique et un ensemble d'outils pour interagir avec divers
hyperviseurs, comme KVM, QEMU, Xen, et d'autres.

Portée : Conçue pour être utilisée comme une bibliothèque par d'autres applications (comme Virt-
Manager) pour gérer des machines virtuelles. `libvirt` offre une abstraction du matériel virtuel et des
hyperviseurs, facilitant la gestion des VM sans se soucier des spécificités de chaque hyperviseur.
1.8.2Fonctionnalités
API Proxmox VE

Gestion des Clusters : Proxmox permet la gestion centralisée de clusters complets, y compris
l'ajout/suppression de nœuds, la gestion des ressources partagées, et l'orchestration des VMs et des
conteneurs.

Multi-hyperviseur : Bien que Proxmox se concentre principalement sur KVM pour les machines
virtuelles et LXC pour les conteneurs, l'API est spécifiquement conçue pour ces environnements.

Haute Disponibilité (HA) : Proxmox offre des fonctionnalités HA pour assurer la résilience des services
critiques. L'API permet de configurer et de gérer ces groupes HA.

Intégration de Stockage : L'API gère le stockage avec des fonctionnalités telles que ZFS, Ceph, NFS, et
LVM, offrant un large éventail d'options pour la configuration et la gestion du stockage.

Gestion des Conteneurs : En plus des VMs, Proxmox gère aussi les conteneurs LXC, offrant une
flexibilité supplémentaire pour des workloads légers.

libvirt

Gestion Hyperviseur-agnostique : `libvirt` peut gérer une variété d'hyperviseurs, tels que
KVM/QEMU, Xen, VMware, etc. Cela permet aux utilisateurs de gérer différents types de VMs à partir
d'une API unique.

Contrôle Granulaire des VMs : `libvirt` offre un contrôle détaillé sur les VMs, y compris la
configuration des CPU, de la mémoire, des disques, des réseaux virtuels, et des périphériques.

Support des Réseaux Virtuels : `libvirt` permet de créer et de gérer des réseaux virtuels, des ponts, et
des VLANs, avec une gestion fine du réseau.

Snapshots et Sauvegardes : `libvirt` permet de créer et de gérer des snapshots des VMs, ainsi que
d'automatiser les processus de sauvegarde.

Gestion des Périphériques et des Ressources : `libvirt` permet de gérer les périphériques virtuels et
de configurer des politiques de ressources comme l'affinité CPU et les priorités I/O.

1.8.3Architecture et Intégration
API Proxmox VE :

Architecture : L'API Proxmox est conçue pour fonctionner au sein de l'écosystème Proxmox VE. Elle
est principalement utilisée pour l'administration de clusters, de VMs, et de conteneurs, tout en
intégrant des fonctionnalités spécifiques à Proxmox.
Interface Web et CLI : Proxmox fournit une interface web complète et une API REST qui expose
toutes les fonctionnalités disponibles, ainsi qu'un ensemble d'outils en ligne de commande (CLI).

Automatisation et Intégration : L'API est conçue pour s'intégrer facilement avec des systèmes
d'automatisation comme Ansible, Terraform, et d'autres outils DevOps, permettant une gestion
automatisée de l'infrastructure.

libvirt :

Architecture : `libvirt` est une couche d'abstraction qui s'intercale entre les hyperviseurs et les
applications qui les gèrent. Elle fournit une API unique pour interagir avec différents hyperviseurs.

Outils et Interfaces : `libvirt` est souvent utilisé avec des outils comme Virt-Manager, virsh (ligne de
commande), et d'autres interfaces graphiques. Il peut être intégré dans des systèmes d'orchestration
ou d'automatisation pour gérer des VMs.

Portabilité : `libvirt` est conçu pour être portable et s'exécuter sur divers systèmes d'exploitation,
offrant une flexibilité pour les déploiements multi-hyperviseurs.

1.8.44. Cas d'Usage

API Proxmox VE :

Environnements Proxmox Unifiés : Utilisée principalement dans des environnements où Proxmox est
le gestionnaire principal d'infrastructure. Parfait pour les clusters de virtualisation unifiés où la
gestion centralisée des ressources est cruciale.

Automatisation Spécifique Proxmox : Idéale pour les déploiements automatisés d'infrastructure

Proxmox, la gestion des sauvegardes, et la configuration réseau dans les environnements de
virtualisation gérés par Proxmox.

libvirt

Multi-hyperviseur : Convient aux environnements qui nécessitent la gestion de plusieurs

hyperviseurs, où une abstraction du matériel et du logiciel est nécessaire.

Outils de Gestion Personnalisés : Utilisé par les développeurs d'outils de gestion de virtualisation qui
nécessitent une interface standardisée pour interagir avec différents hyperviseurs.

1.9 Corosync Cluster Engine

Corosync Cluster Engine est le composant central utilisé par Proxmox VE pour gérer la
communication et la coordination au sein d'un cluster.
1.9.1Gestion du Quorum :

Quorum est un concept fondamental dans les systèmes distribués où les décisions sont prises par un
consensus de la majorité des nœuds actifs. Corosync gère le quorum en assurant que seules les
décisions prises par une majorité de nœuds sont appliquées. Cela évite les incohérences qui
pourraient survenir si des sous-ensembles de nœuds prenaient des décisions de manière
indépendante.

1.9.2Communication entre Nœuds :

Corosync assure une communication fiable entre les nœuds du cluster. Il utilise un protocole de
diffusion pour s'assurer que tous les nœuds reçoivent les messages essentiels, comme les
changements d'état des ressources ou les notifications de défaillance de nœuds.

La communication est rapide et se fait généralement via une connexion réseau dédiée ou partagée
(multicast ou unicast).

1.9.3Détection des Défaillances :

Corosync surveille en permanence l'état des nœuds au sein du cluster. Si un nœud ne répond plus ou
est détecté comme étant hors ligne, Corosync notifie les autres nœuds, ce qui permet à des
mécanismes de tolérance de panne, comme la haute disponibilité (HA), de prendre le relais et de
redémarrer les ressources critiques sur un autre nœud fonctionnel.

1.9.4Synchronisation des États :

Les informations de configuration et l'état des ressources sont synchronisés entre les nœuds grâce à
Corosync. Cela garantit que chaque nœud a une vue cohérente de l'ensemble du cluster et de ses
ressources.

1.9.5Proxmox VE et Corosync

Dans l'écosystème Proxmox VE, Corosync est intégré en tant que service fondamental pour assurer la
stabilité et la fiabilité du cluster. Il fonctionne conjointement avec d'autres composants tels que
QDevice pour améliorer le quorum dans des clusters avec un nombre pair de nœuds, et Pacemaker
pour gérer la haute disponibilité des services.

QDevice : Un service supplémentaire qui aide à maintenir le quorum dans les petits clusters en
ajoutant un vote virtuel, souvent via un tiers (un QDevice), pour éviter le blocage du cluster en cas de
défaillance d'un nœud.

Pacemaker : En complément de Corosync, Pacemaker est utilisé pour gérer les ressources de haute
disponibilité. Corosync assure la communication et Pacemaker décide où et comment démarrer les
services ou les VMs en cas de défaillance.
1.9.6La communauté Corosync

Corosync est maintenu et développé au sein du projet ClusterLabs, où il joue un rôle clé dans la
gestion des communications et de la synchronisation dans les environnements de haute disponibilité.
Le projet continue de recevoir des mises à jour et des contributions, ce qui montre que la
communauté est bien vivante.

Sur GitHub, le dépôt de Corosync montre une activité continue avec des contributions régulières, des
résolutions de problèmes (issues), et des demandes de tirage (pull requests) actives. Cela indique que
les développeurs et les utilisateurs continuent d'améliorer et de soutenir Corosync 【 38†source 】
【40†source】.

Corosync est toujours largement utilisé dans divers projets de haute disponibilité, tels que
Pacemaker, ce qui témoigne de sa pertinence continue dans l'écosystème de clustering[39†sources].

La communauté Corosync reste dynamique et engagée dans le développement et le support de cet

outil essentiel pour les systèmes de haute disponibilité.

1.10 Description de l'Architecture Proxmox

1.10.1 Nœuds Proxmox (Hosts)

o Ce sont les serveurs physiques sur lesquels est installé Proxmox VE. Chaque nœud
peut héberger plusieurs VMs et conteneurs.
o Un cluster Proxmox peut être composé de plusieurs nœuds, ce qui permet la gestion
centralisée, la haute disponibilité, et la migration de VMs entre nœuds.

1.10.2 Cluster Proxmox

o Un ensemble de nœuds reliés entre eux pour former un cluster. Cela permet la
gestion centralisée des ressources et des machines virtuelles.
o Le clustering permet également des fonctionnalités avancées comme la haute
disponibilité (HA), où les VMs sont redémarrées automatiquement sur un autre
nœud en cas de panne d'un nœud.

1.10.3 Réseau de Stockage (Storage Network)

o Le stockage peut être partagé entre les nœuds via des solutions telles que NFS, Ceph,
iSCSI ou ZFS. Cela permet aux VMs d'accéder aux données de manière transparente
même si elles sont déplacées entre les nœuds.
o Les volumes de stockage peuvent être dédiés à des VMs spécifiques ou partagés
entre plusieurs.

1.10.4 Réseau de Gestion (Management Network)

o Un réseau dédié utilisé pour la gestion des nœuds Proxmox et des VMs.
o Ce réseau est généralement séparé du réseau de production pour des raisons de
sécurité.
1.10.5 Réseau de Production (Production Network) :

o Le réseau utilisé par les VMs pour communiquer avec l'extérieur. Il peut être
configuré avec des VLANs pour isoler les différentes couches de service.

1.10.6 Interfaces Web et API :

o Proxmox offre une interface web riche pour la gestion de l'ensemble de

l'infrastructure, ainsi qu'une API RESTful pour l'automatisation des tâches.

1.10.7 VMs et Conteneurs :

o Hébergés sur les différents nœuds du cluster, avec la possibilité de migrer d'un nœud
à l'autre sans interruption de service (live migration).
o Les VMs sont connectées au réseau de production et, si nécessaire, au réseau de
stockage.

1.10.8 Gestion et Surveillance :

o Interface web Proxmox accessible via le réseau de gestion.

o Outils de surveillance (comme Prometheus, Grafana) pour surveiller la performance
et l'intégrité des nœuds et des VMs.

2 Mise en œuvre
2.1 Update sans souscription

E : Failed to fetch https

://[Link]/debian/pve/dists/bookworm/InRelease401Unauthorized [IP :
[Link] 443]
E : The repository 'https ://[Link]/debian/pve bookworm InRelease' is not signed.
N : Updating from such a repository can't be done securely, and is therefore disabled by default.
N : See apt-secure(8) manpage for repository creation and user configuration details.

L'erreur indique que le système tente de récupérer des mises à jour ou des paquets depuis le dépôt
d'entreprise de Proxmox, mais ne parvient pas à s'authentifier. Cela se produit généralement lorsque
la version gratuite de Proxmox VE est utilisé sans souscription à une licence d'entreprise, mais que les
dépôts d'entreprise sont toujours configurés dans votre liste de sources.

Désactiver le dépôt d'entreprise Proxmox

nano /etc/apt/[Link].d/[Link]

Commenter ou supprimer la ligne suivante :

deb https ://[Link]/debian/pve bookworm pve-enterprise

Ajouter le dépôt communautaire Proxmox (si ce n'est pas déjà fait) dans le fichier :
`/etc/apt/[Link]` :

deb http ://[Link]/debian/pve bookworm pve-no-subscription

2.2 Réseaux
2.2.1Topologie du Réseau
Réseau de gestion : Utilisé pour l'administration des nœuds Proxmox.

Réseau de production : Utilisé pour le trafic des machines virtuelles et des conteneurs.

Réseau de stockage : un réseau dédié pour le stockage est recommandé pour le stockage partagé
(NAS, Ceph),

VLAN : Pour segmenter le réseau pour différentes classes de trafic.

2.2.2Configuration des Interfaces Réseau

Proxmox utilise le fichier `/etc/network/interfaces` pour configurer les interfaces réseau :

auto lo
iface lo inet loopback
iface enp1s0 inet manual
auto vmbr0
iface vmbr0 inet static
address [Link]/24
gateway [Link]
bridge-ports enp1s0
bridge-stp off
bridge-fd 0
iface enp2s0 inet manual
source /etc/network/interfaces.d/*

2.2.3#Exemple de configuration de base :

```bash
auto lo
iface lo inet loopback
# Interface réseau principale
auto enp3s0
iface enp3s0 inet static
address [Link]
netmask [Link]
gateway [Link]
# Bridge pour les VMs
auto vmbr0
iface vmbr0 inet static
address [Link]
netmask [Link]
bridge_ports enp3s0
bridge_stp off
bridge_fd 0
```

`auto lo` : Interface de loopback pour le système local.

`enp3s0` : Interface physique principale avec une adresse IP statique.

`vmbr0` : Bridge réseau utilisé pour les VMs. Le bridge relie les VMs à l'interface physique `enp3s0`,
leur permettant d'accéder au réseau externe.

2.2.4Configuration Avancée avec VLANs et Multiples Interfaces

auto lo
iface lo inet loopback
# Interface réseau principale pour la gestion
auto enp3s0
iface enp3s0 inet static
address [Link]
netmask [Link]
gateway [Link]
# Bridge pour les VMs sur VLAN 10 (Réseau de production)
auto vmbr0
iface vmbr0 inet static
address [Link]
netmask [Link]
bridge_ports enp4s0.10
bridge_stp off
bridge_fd 0
# Bridge pour les VMs sur VLAN 20 (Réseau de stockage)
auto vmbr1
iface vmbr1 inet static
address [Link]
netmask [Link]
bridge_ports enp4s0.20
bridge_stp off
bridge_fd 0
```

VLAN : Ici, `enp4s0.10` et `enp4s0.20` représentent les interfaces VLAN 10 et 20 respectivement.

vmbr0 et vmbr1 : Les bridges sont utilisés pour connecter les VMs à leurs réseaux respectifs via
VLANs.

2.2.5Configurer les Réseaux dans l'Interface Web Proxmox

1. Accéder à l'interface Web Proxmox :

Allez à `https ://<votre_ip_proxmox> :8006` dans un navigateur.

Connectez-vous avec vos informations d'identification.

2. Naviguer vers la Configuration Réseau :

Dans l'interface Web, allez à Datacenter > Node > Network.

Vous verrez toutes les interfaces disponibles.

3. Ajouter ou Configurer un Bridge :

Cliquez sur "Create" puis "Linux Bridge".

Donnez un nom au bridge (par exemple, `vmbr0`).

Sélectionnez les interfaces physiques à attacher au bridge.

Configurez les paramètres IP si nécessaire (ou laissez-le vide si vous utilisez des VLANs ou une
configuration DHCP).

4. Configurer les VLANs :

Si vous avez des VLANs, sélectionnez l'interface réseau correspondante, puis configurez les VLANs
dans la section appropriée.

Vous pouvez également ajouter des interfaces VLAN manuellement via l'interface Web.

5. Tester la Configuration

Une fois la configuration terminée, il est essentiel de tester pour s'assurer que tout fonctionne
comme prévu :

Ping les différentes adresses IP pour vérifier la connectivité.

Vérifiez que les VMs peuvent accéder au réseau externe et aux autres VMs si nécessaire.

Assurez-vous que la gestion du cluster fonctionne via l'interface réseau dédiée à cet effet.

6. Haute Disponibilité et Réplication

Si vous avez un cluster Proxmox, configurez le réseau pour supporter la haute disponibilité et la
réplication entre nœuds, en s'assurant que tous les nœuds peuvent accéder au réseau de stockage
partagé avec une latence minimale.

2.3 Stratégies de Stockage dans Proxmox

2.3.1Stockage Local :
Description : Utilisation des disques locaux du serveur Proxmox. Ce type de stockage est simple à
configurer et peut être basé sur des systèmes de fichiers tels que ext4, xfs, ou zfs.
Avantages : Facile à mettre en place, pas de dépendance réseau, idéal pour les configurations simples
ou les tests.

Inconvénients : Pas de haute disponibilité (HA), difficile à mettre à l'échelle, nécessite des solutions
de sauvegarde séparées.

2.3.22. LVM (Logical Volume Manager) :

Description : Utilise LVM pour gérer des volumes logiques sur des disques physiques. Peut être utilisé
en combinaison avec ZFS pour des fonctionnalités avancées comme les snapshots.

Avantages : Flexibilité dans la gestion des volumes, prise en charge des snapshots et de la
redimension des volumes.

Inconvénients : Peut nécessiter des connaissances plus approfondies pour la configuration et la

gestion.

2.3.33. ZFS (Zettabyte File System) :

Description : Système de fichiers avancé avec des fonctionnalités de gestion de volume intégré. Offre
des fonctionnalités comme la compression, la déduplication, et la gestion des snapshots.

Avantages : Intégrité des données, gestion avancée des volumes, snapshots efficaces, peut être
utilisé pour des configurations HA avec réplication.

Inconvénients : Peut nécessiter plus de mémoire RAM (8 Go minimum recommandé), performance

variable en fonction de la configuration matérielle.

2.3.44. NFS (Network File System) :

Description : Utilise des partages NFS pour stocker les images de disques et les fichiers de données.
Accessible par le réseau.

Avantages : Partage de stockage simple, facile à mettre à l'échelle, peut être utilisé pour des
configurations HA.

Inconvénients : Performance dépendante du réseau, peut nécessiter une infrastructure réseau

dédiée pour éviter la congestion.

2.3.55. Ceph :
Description : Système de stockage distribué hautement évolutif, intégré à Proxmox pour les
configurations HA. Offre des fonctionnalités de stockage d'objets, de blocs et de fichiers.

Avantages : Haute disponibilité, tolérance aux pannes, échelonnable horizontalement, intégration

native avec Proxmox pour la gestion.

Inconvénients : Configuration plus complexe, nécessite une infrastructure dédiée, performance

optimale avec des disques SSD et un réseau rapide.

2.3.66. iSCSI :
Description : Utilise le protocole iSCSI pour accéder aux dispositifs de stockage en réseau. Peut être
configuré pour utiliser LVM sur iSCSI.

Avantages : Bonne performance, compatible avec de nombreux équipements de stockage SAN.

Inconvénients : Complexité de configuration, dépendance du réseau.

2.4 Types de Disques à Utiliser
2.4.11. HDD (Hard Disk Drive) :
Utilisation : Bon marché, utilisé principalement pour le stockage de données volumineuses ou peu
fréquemment utilisées. Convient aux backups et aux systèmes où la performance n'est pas critique.

Avantages : Moins cher par Go, disponible en grandes capacités.

Inconvénients : Moins performant en termes de latence et de vitesse de lecture/écriture par rapport

aux SSD.

2.4.22. SSD (Solid State Drive) :

Utilisation : Utilisés pour les systèmes d'exploitation, les VMs, et les applications nécessitant des
performances élevées. Recommandé pour les systèmes de fichiers ZFS en raison de ses besoins en
IOPS élevés.

Avantages : Faible latence, haute performance, améliore la réactivité des applications et des VMs.

Inconvénients : Plus cher par Go, capacités généralement inférieures aux HDD.

2.4.33. NVMe (Non-Volatile Memory Express) :

Utilisation : Utilisés pour des performances ultra-élevées, idéal pour les journaux ZFS, les caches de
lecture, ou les bases de données intensives en E/S.

Avantages : Latence extrêmement faible, vitesse de lecture/écriture très élevée.

Inconvénients : Coût plus élevé, nécessite une infrastructure compatible NVMe (slots PCIe).

2.4.44. Disques SAS (Serial Attached SCSI) :

Utilisation : Option intermédiaire entre HDD et SSD, utilisé dans des environnements où la fiabilité et
la performance sont importantes.

Avantages : Plus fiable que les HDD standard, bon compromis entre capacité et performance.

Inconvénients : Plus cher que les HDD SATA standard, mais moins rapide que les SSD.

2.4.5Bonnes Pratiques pour le Stockage Proxmox

1. Combiner SSD et HDD : Utilisez des SSD pour le stockage des systèmes d'exploitation et des
données critiques qui nécessitent une haute performance, et des HDD pour le stockage de données
archivées ou moins fréquemment utilisées.

2. Utilisation de ZFS avec des SSD : Si vous utilisez ZFS, il est recommandé d'utiliser des SSD pour les
journaux ZIL (ZFS Intent Log) et les caches L2ARC pour améliorer les performances.

3. Redondance : Pour les configurations critiques, utilisez des configurations RAID matérielles ou ZFS
RAID pour assurer la redondance des données et éviter les points de défaillance uniques.

4. Réseau dédié pour le stockage partagé : Lorsque vous utilisez NFS, iSCSI, ou Ceph, configurez un
réseau dédié pour le trafic de stockage afin de minimiser la congestion réseau et d'améliorer la
performance.

5. Surveillance et Gestion des Ressources : Utilisez les outils de surveillance intégrés de Proxmox pour
surveiller l'utilisation du stockage, la performance et les alertes de santé pour anticiper les
problèmes.
Priorisez l'utilisation de SSD pour les VMs et les conteneurs qui nécessitent des
performances élevées.
Utilisez ZFS si vous avez besoin de snapshots fréquents, de compression, et d'intégrité des
données, mais assurez-vous de disposer d'une quantité suffisante de RAM.
Configurez un réseau dédié au stockage pour éviter toute congestion et maximiser la
performance dans les environnements partagés.
Pour la haute disponibilité, Ceph est une solution robuste mais nécessite une infrastructure
dédiée.
La configuration de la bande passante pour différents types de réseaux dans une infrastructure
Proxmox est cruciale pour assurer une performance optimale et une gestion efficace des ressources.
Voici une analyse des besoins en bande passante pour les différents réseaux couramment utilisés
dans une infrastructure Proxmox :

3 Networking
3.1 Réseau d'administration
Description : Ce réseau est utilisé pour la gestion et le contrôle des nœuds Proxmox, incluant l'accès à
l'interface web, SSH, et autres services d'administration.

Recommandation de bande passante : 1 Gbps est généralement suffisant pour les tâches
d'administration, car ces tâches ne génèrent pas beaucoup de trafic réseau. Cependant, pour des
environnements très grands ou critiques, il peut être utile d'avoir une redondance.

Latence et disponibilité : Priorité sur une faible latence et une haute disponibilité. Envisagez un
réseau dédié ou une interface VLAN séparée pour l'administration afin de sécuriser l'accès.

3.2 2. Réseau de stockage

Description : Utilisé pour accéder au stockage partagé (NAS, Ceph, iSCSI, etc.) par les nœuds Proxmox
et les VMs.

Recommandation de bande passante : 10 Gbps est recommandé, surtout si vous utilisez des solutions
de stockage haute performance comme Ceph ou iSCSI. Dans les grandes infrastructures, vous
pourriez envisager 25 Gbps ou plus, en fonction de la charge de travail.

Latence et disponibilité : Critique pour les performances. Utilisez des interfaces réseau dédiées avec
des cartes réseau de haute qualité, et envisagez des réseaux avec latence minimale (liaisons directes,
etc.). Pour Ceph ou d'autres systèmes de stockage distribués, une faible latence et une haute
disponibilité sont essentielles.

3.3 3. Réseau de VMotion (migration en direct)

Description : Utilisé pour la migration en direct des machines virtuelles d'un nœud Proxmox à un
autre sans interruption de service.

Recommandation de bande passante : 10 Gbps recommandé pour les environnements de taille

moyenne à grande. Pour les petites configurations, 1 Gbps peut suffire, mais cela prolongera le
temps de migration.

Latence et disponibilité : Faible latence et haute disponibilité recommandées pour assurer des
migrations rapides et sans problème. Considérez des interfaces réseau dédiées ou des VLANs pour
VMotion afin d'isoler ce trafic des autres.
3.4 4. Réseau de backup
Description : Utilisé pour les transferts de données de sauvegarde des VMs et des conteneurs vers un
serveur de sauvegarde ou un stockage dédié.

Recommandation de bande passante : 10 Gbps si vous effectuez des sauvegardes fréquentes et

volumineuses. 1 Gbps peut être suffisant pour des sauvegardes différentielles ou incrémentales
moins fréquentes.

Latence et disponibilité : La latence n'est pas aussi critique ici que pour les réseaux de stockage ou de
migration, mais une haute disponibilité est toujours recommandée pour éviter les interruptions de
sauvegarde. Envisagez de programmer les sauvegardes pendant les périodes de faible utilisation pour
minimiser l'impact.

3.5 5. Réseau de production

Description : Utilisé par les VMs et les conteneurs pour communiquer avec l'extérieur et entre eux.
C'est le réseau principal pour les opérations des applications hébergées.

Recommandation de bande passante : 10 Gbps ou plus, en fonction du type et du volume de trafic

généré par les applications. Des liens multiples avec l'équilibrage de charge peuvent être utilisés pour
des besoins plus élevés.

Latence et disponibilité : Latence très faible et haute disponibilité sont critiques. Utilisez des switches
et des routeurs de qualité professionnelle avec des configurations de redondance.

3.6 6. Réseau de réplication

Description : Utilisé pour la réplication des données entre nœuds Proxmox, souvent en conjonction
avec ZFS ou Ceph pour assurer la continuité des données.

Recommandation de bande passante : 10 Gbps recommandé, particulièrement pour les opérations

de réplication fréquentes ou les environnements avec de gros volumes de données.

Latence et disponibilité : Latence faible et tolérance aux pannes sont importantes. Un réseau dédié
ou des VLANs isolés peuvent aider à minimiser l'impact sur les autres services.

3.7 Considérations supplémentaires

1. Redondance : Pour les réseaux critiques (administration, stockage, production), envisagez une
configuration redondante (agrégation de liens, réseaux multiples) pour éviter les points de
défaillance uniques.

2. Qualité de Service (QoS) : Configurer QoS sur les switches et routeurs pour prioriser le trafic
critique, comme la gestion et la VMotion, par rapport à d'autres types de trafic.

3. VLANs : L'utilisation de VLANs pour séparer les types de trafic peut améliorer la sécurité et la
gestion du réseau.

4. Switches de haute qualité : Utilisez des switches compatibles avec des débits élevés (10 Gbps et
plus) et supportant des fonctionnalités avancées comme le VLAN tagging, le LACP (Link Aggregation
Control Protocol), et QoS.

4 Structurer et sécuriser le réseau

Dans le contexte d'une organisation privée utilisant une infrastructure de virtualisation comme
Proxmox, les concepts de Zones, VNets (Virtual Networks), et Subnets peuvent être appliqués pour
structurer et sécuriser le réseau. Bien que ces termes soient plus couramment associés aux
environnements de cloud public comme Azure ou AWS, ils peuvent également être appliqués dans
des environnements de cloud privé ou de virtualisation sur site.

En utilisant des concepts de zones, de VNets, et de sous-réseaux dans une infrastructure de

virtualisation comme Proxmox, une organisation peut atteindre un haut niveau de contrôle, de
sécurité, et d'efficacité.

Ces concepts permettent de segmenter les réseaux, de gérer le trafic de manière optimale, et
d'appliquer des règles de sécurité adaptées à chaque type de service ou de département, ce qui est
crucial pour une infrastructure réseau robuste et évolutive.

4.1 1. Zones

Définition : Dans une infrastructure réseau, une zone est une subdivision logique ou physique du
réseau, souvent utilisée pour segmenter et sécuriser les ressources. Les zones permettent d'isoler
différents types de trafic ou de systèmes afin de mieux contrôler l'accès et d'appliquer des règles de
sécurité spécifiques.

Application dans un contexte Proxmox :

Zone DMZ (Demilitarized Zone) : Une zone dédiée où les serveurs accessibles depuis l'extérieur sont
placés, par exemple, des serveurs web ou des serveurs de messagerie. Ces serveurs sont isolés du
réseau interne pour limiter les risques d'intrusion.

Zone de gestion : Une zone réservée aux tâches d'administration, accessible uniquement aux
administrateurs et aux systèmes de gestion. Elle héberge les interfaces de gestion des nœuds
Proxmox et des services critiques.

Zone de production : La zone où les machines virtuelles et les conteneurs qui hébergent les
applications métier sont déployés. Cette zone peut être subdivisée en fonction des applications ou
des départements.

Zone de stockage : Dédiée aux systèmes de stockage. Dans un contexte Proxmox, il pourrait s'agir de
réseaux pour l'accès aux systèmes de stockage comme Ceph ou des NAS.

4.2 2. VNets (Virtual Networks)

Définition : Un VNet, ou réseau virtuel, est une abstraction logique du réseau physique qui permet de
créer des segments de réseau isolés pour des environnements virtuels. Les VNets permettent de
regrouper des machines virtuelles et des conteneurs de manière à contrôler le trafic entre eux et
avec l'extérieur.

Application dans un contexte Proxmox :

Création de VNets pour chaque zone : Par exemple, un VNet pour la zone de production, un autre
pour la zone de gestion, et un pour la DMZ. Cela permet de contrôler et d'isoler le trafic entre les
différentes zones.

Isolation des services : Des VNets peuvent être utilisés pour isoler les services critiques, tels que les
bases de données, des services frontaux moins sécurisés.
Support des VLANs : Proxmox permet l'utilisation de VLANs pour segmenter le réseau. Les VNets
peuvent être mappés à des VLANs spécifiques pour faciliter la gestion du trafic et appliquer des
règles de sécurité adaptées.

Réseau de stockage : Un VNet spécifique peut être configuré pour le trafic de stockage, garantissant
que les VMs et les conteneurs accèdent aux ressources de stockage sur un réseau isolé, optimisant
ainsi la performance et la sécurité.

4.3 3. Subnets (Sous-réseaux)

Définition : Un sous-réseau est une subdivision d'un réseau IP en plusieurs segments plus petits, ou
sous-réseaux. Les sous-réseaux sont utilisés pour organiser et segmenter le réseau, améliorer la
sécurité et l'efficacité de la gestion du réseau.

Application dans un contexte Proxmox :

Segmentation des VNets : Chaque VNet peut contenir un ou plusieurs sous-réseaux, permettant une
gestion fine du trafic. Par exemple, un VNet de production pourrait contenir des sous-réseaux
distincts pour les applications, les bases de données, et le trafic interne des applications.

Gestion des adresses IP : Les sous-réseaux facilitent la gestion des adresses IP, aidant à éviter les
conflits et à garantir que chaque segment de réseau dispose de suffisamment d'adresses IP
disponibles.

Application des politiques de sécurité : En configurant des sous-réseaux, il est possible d'appliquer
des politiques de sécurité différentes selon les besoins. Par exemple, des règles de pare-feu
spécifiques peuvent être appliquées pour restreindre le trafic entre sous-réseaux.

Isolation des environnements de test et de développement : Des sous-réseaux peuvent être utilisés
pour isoler les environnements de test et de développement du réseau de production, évitant ainsi
que les tests ou les modifications n'affectent les services en direct.

4.4 Exemple d'Architecture Réseau dans Proxmox

1. Zones Définies :

Zone de Gestion : Contient les interfaces de gestion de Proxmox. Accessible uniquement par les
administrateurs via un VNet dédié.

Zone de Production : Contient les applications en direct. Différents sous-réseaux peuvent être créés
pour séparer les applications par type (web, base de données, application).

Zone de DMZ : Accessible depuis l'extérieur pour les services publics comme les serveurs web. Isolée
de la zone de production pour des raisons de sécurité.

Zone de Stockage : Utilisée pour accéder au stockage Ceph ou NAS. Isolée pour éviter que le trafic de
stockage ne perturbe le trafic de production.

2. Utilisation de VNets et Subnets :

Chaque zone peut être associée à un ou plusieurs VNets pour isoler le trafic et appliquer des règles
de sécurité spécifiques.

Des sous-réseaux au sein de chaque VNet peuvent être utilisés pour segmenter davantage le trafic,
par exemple, un sous-réseau pour chaque département ou service spécifique.
3. Règles de Sécurité et de Pare-feu :

Des règles de pare-feu spécifiques peuvent être appliquées entre les sous-réseaux et les VNets pour
contrôler le flux de trafic et restreindre l'accès en fonction des besoins de sécurité.

5 Bandes passantes des réseaux

Pour une infrastructure d'entreprise, il est essentiel de bien dimensionner la bande passante de
chaque réseau en fonction de son utilisation spécifique. Voici des recommandations pour la bande
passante de différents réseaux en tenant compte des besoins courants en entreprise :

5.1 1. LAN d’administration

- Description : Ce réseau est utilisé pour les tâches de gestion et d'administration, comme l'accès aux
consoles de gestion, aux interfaces web des équipements réseau, et aux serveurs d'administration.

- Recommandation de bande passante : 1 Gbps est généralement suffisant. Ce réseau ne transporte

pas un volume important de trafic, mais la faible latence est importante pour la réactivité des tâches
d'administration.

- Redondance : Envisagez une redondance pour garantir une disponibilité continue en cas de
défaillance.

2. LAN de stockage
- Description : Utilisé pour accéder aux systèmes de stockage partagés, comme les SAN, NAS, ou les
solutions de stockage distribuées (par exemple, Ceph).

- Recommandation de bande passante : 10 Gbps est recommandé pour des performances optimales,
surtout si vous utilisez des solutions de stockage haute performance ou en cas d'accès concurrentiel
élevé. Pour des environnements très exigeants, envisagez 25 Gbps ou plus.

- Redondance et Qualité de Service : Utiliser des chemins redondants et des VLANs spécifiques pour
le trafic de stockage afin d'assurer la disponibilité et la qualité du service.

5.2 3. LAN VMotion

- Description : Ce réseau est utilisé pour la migration en direct des machines virtuelles d'un hôte à un
autre sans interruption de service.

- Recommandation de bande passante : 10 Gbps est recommandé pour des migrations rapides et
efficaces, particulièrement dans des environnements avec de nombreuses VMs ou des migrations
fréquentes. 1 Gbps pourrait suffire pour des environnements plus petits.

- Sécurité : Utiliser un réseau isolé ou des VLANs pour le trafic VMotion pour éviter tout risque
d'interception.

5.3 4. LAN Sauvegardes/Restaurations

- Description : Réseau dédié pour les opérations de sauvegarde et de restauration des données des
serveurs et des VMs.

- Recommandation de bande passante : 10 Gbps est recommandé, surtout pour des sauvegardes
fréquentes et volumineuses. 1 Gbps peut suffire pour des environnements où les sauvegardes sont
moins fréquentes ou incrémentales.
- Considération : Planifier les opérations de sauvegarde en dehors des heures de pointe pour
minimiser l'impact sur les autres opérations réseau.

5.4 5. LAN Application

- Description : Réseau principal utilisé par les applications en production pour communiquer avec les
utilisateurs et d'autres services.

- Recommandation de bande passante : 10 Gbps ou plus, selon le type et le volume de trafic généré
par les applications. Pour des applications critiques ou à haute performance, envisagez des liens
multiples avec équilibrage de charge.

- Redondance et QoS : Utilisez des mécanismes d'équilibrage de charge et de qualité de service pour
garantir la disponibilité et la performance.

5.5 6. LAN Bureautique des Bâtiments

- Description : Réseau utilisé pour les activités de bureautique générales, comme l'accès à Internet,
l'envoi d'e-mails, et l'utilisation d'applications internes.

- Recommandation de bande passante : 1 Gbps par segment est généralement suffisant. Si le nombre
d'utilisateurs est très élevé, des liens de 10 Gbps peuvent être envisagés pour éviter la congestion.

- Gestion : Prioriser le trafic critique (par exemple, VoIP) sur le trafic bureautique classique pour
assurer la qualité de service.

5.6 7. Interco entre les Bâtiments

- Description : Connexions inter-bâtiments pour relier les différents sites d'une entreprise.

- Recommandation de bande passante : 10 Gbps est une base solide pour les interconnexions entre
bâtiments, assurant un flux de données rapide et des applications performantes. En fonction des
besoins, des débits de 40 Gbps ou 100 Gbps peuvent être nécessaires.

- Redondance : Toujours prévoir des chemins redondants pour les interconnexions critiques afin
d'assurer la continuité des services en cas de panne d'un lien.

5.7 8. Interco entre les Centres de Calculs

- Description : Connexions entre les centres de données pour la synchronisation des données, la
réplication, et la gestion des charges de travail.

- Recommandation de bande passante : 40 Gbps ou 100 Gbps, en fonction de la quantité de données

transférées et de la distance entre les centres de calculs. Des débits élevés sont souvent nécessaires
pour la réplication en temps réel et les sauvegardes.

- Redondance et Sécurité : Redondance obligatoire, souvent via des liaisons fibre dédiées. Sécuriser
ces liens avec des VPNs ou d'autres mesures de sécurité.

9. Heartbeat des Clusters

- Description : Réseau utilisé pour la communication de heartbeat entre les nœuds d'un cluster pour
vérifier la disponibilité des nœuds et coordonner les actions de failover.

- Recommandation de bande passante : 1 Gbps est généralement suffisant. La bande passante

requise est faible, mais la faible latence et la fiabilité sont essentielles pour assurer une détection
rapide des défaillances.
- Redondance : Utiliser des chemins redondants ou plusieurs interfaces réseau pour éviter les points
de défaillance uniques.

Conclusion

Le dimensionnement de la bande passante des différents réseaux doit être fait en tenant compte des
besoins spécifiques de chaque segment, de la taille de l'organisation, et des exigences de
performance et de sécurité. Une planification adéquate et une surveillance continue des
performances réseau sont essentielles pour assurer la disponibilité et l'efficacité des services dans
une infrastructure d'entreprise.

6 Segmentation physique
Dans une infrastructure réseau d'entreprise, séparer physiquement certains réseaux peut être
essentiel pour des raisons de sécurité, de performance, de fiabilité, et de gestion.

La séparation physique des réseaux dans une infrastructure d'entreprise est cruciale pour protéger
les systèmes critiques, assurer des performances optimales, et sécuriser les données sensibles. En
identifiant les réseaux qui nécessitent une isolation stricte, les organisations peuvent réduire leur
surface d'attaque, éviter les interruptions de service dues à la congestion, et garantir une
architecture réseau fiable et sécurisée.

6.1 1. Réseau d'administration

Sécurité : Le réseau d'administration doit être isolé pour éviter que des utilisateurs non autorisés
n'accèdent aux interfaces de gestion des serveurs, des équipements réseau (commutateurs,
routeurs), et des systèmes de virtualisation (comme Proxmox ou vCenter). Un accès non autorisé
pourrait conduire à des compromissions graves de la sécurité.

Protection contre les attaques internes : En cas de compromission du réseau utilisateur, l'isolement
physique du réseau d'administration protège les systèmes critiques.

Comment le séparer : Utilisez des interfaces réseau dédiées ou des VLANs spécifiques uniquement
accessibles via des chemins sécurisés, tels que des VPNs ou des segments dédiés du réseau.

6.2 2. Réseau de stockage

- Pourquoi le séparer :

- Performance : Les réseaux de stockage (SAN/NAS) transportent souvent un volume important de

données. Les pics d'utilisation pourraient affecter la performance des autres réseaux s'ils ne sont pas
isolés.

- Sécurité des données : Isoler le réseau de stockage empêche les utilisateurs finaux et les
applications non autorisées d'accéder directement aux données sensibles.

- Fiabilité : En cas de défaillance ou de congestion sur le réseau principal, les opérations de stockage
critiques ne doivent pas être interrompues.

- Comment le séparer : Utilisez des infrastructures de stockage dédiées, telles que des switchs SAN,
des interfaces fibre optique, ou des connexions iSCSI dédiées.

6.3 3. Réseau VMotion (migration en direct)

- Pourquoi le séparer :
- Sécurité : La migration en direct de VMs expose potentiellement des données sensibles en transit.
Isoler ce trafic réduit le risque de capture ou d'interception par des acteurs malveillants.

- Performance : Les opérations de VMotion peuvent consommer une bande passante significative,
affectant la performance des autres services si elles ne sont pas sur un réseau séparé.

- Comment le séparer : Déployer des interfaces réseau dédiées pour VMotion, ou utiliser des VLANs
isolés pour le trafic VMotion avec des politiques de QoS pour garantir la bande passante.

6.4 4. Réseau de sauvegarde

- Pourquoi le séparer :

- Performance : Les opérations de sauvegarde peuvent générer des volumes importants de trafic
réseau, en particulier lors des sauvegardes complètes. Ce trafic peut saturer les réseaux partagés,
affectant les performances des applications en production.

- Sécurité : La séparation physique permet de sécuriser les données de sauvegarde et de les protéger
contre les accès non autorisés, les attaques par ransomware, ou d'autres menaces.

- Comment le séparer : Utilisez des chemins réseau dédiés pour les sauvegardes, des switches
spécifiques ou des VLANs réservés aux opérations de sauvegarde.

6.5 5. Réseau de DMZ (Demilitarized Zone)

- Pourquoi le séparer :

- Sécurité : La DMZ héberge des systèmes accessibles depuis l'extérieur (serveurs web, serveurs de
messagerie). Isoler la DMZ protège le réseau interne des attaques potentielles ciblant ces systèmes
exposés.

- Prévention des mouvements latéraux : Si un système dans la DMZ est compromis, la séparation
physique limite la capacité d'un attaquant à se déplacer latéralement vers des systèmes internes.

- Comment le séparer : Utiliser des interfaces réseau dédiées et des pare-feu pour segmenter la DMZ
du réseau interne. Des segments DMZ distincts peuvent être utilisés pour différents types de
services.

6.6 6. Réseau de heartbeat des clusters

- Pourquoi le séparer :

- Fiabilité : Le réseau de heartbeat est crucial pour la détection de défaillance des nœuds de cluster.
Une congestion sur le réseau principal pourrait provoquer des faux positifs de défaillance et des
basculements inutiles.

- Sécurité : La communication de heartbeat doit être protégée contre les manipulations, car des
interruptions pourraient entraîner des interruptions de service non nécessaires.

- Comment le séparer : Utiliser des liens réseau dédiés entre les nœuds de cluster, souvent des
liaisons directes pour éviter les points de défaillance intermédiaires.

6.7 7. Interco entre les centres de calculs (Data Centers)

- Pourquoi le séparer :
- Bande passante et performance : Les interconnexions entre centres de calculs transportent souvent
de grandes quantités de données pour la réplication, la synchronisation, et les sauvegardes. Utiliser
un réseau séparé garantit que les autres services ne sont pas affectés.

- Sécurité : Séparer physiquement les liens de communication entre centres de calculs protège les
données sensibles en transit et empêche les attaques de type "Man-in-the-middle".

- Comment le séparer : Utiliser des fibres optiques dédiées ou des circuits MPLS, souvent avec des
tunnels chiffrés pour assurer la sécurité.

7 Attaques fréquentes sur les VLAN et mode de

protection

Pour protéger efficacement une infrastructure réseau, il est crucial de comprendre les types
d'attaques les plus courantes ciblant les VLANs et comment elles peuvent être utilisées pour
compromettre la sécurité. Certaines de ces attaques peuvent nécessiter une séparation physique de
certains segments réseau pour une protection optimale.

La séparation physique de certains segments réseau est une mesure de sécurité efficace pour
protéger contre les attaques liées aux VLANs. Les segments réseau qui bénéficieraient le plus de la
séparation physique incluent :

 - Réseaux d'administration : Pour protéger les systèmes de gestion et éviter les accès non
autorisés.
 - Réseaux de stockage : Pour assurer la confidentialité et l'intégrité des données.
 - Réseaux de VMotion et de Heartbeat de cluster : Pour garantir la performance et la
fiabilité des opérations de migration et de gestion des clusters.
 - Réseaux de DMZ : Pour isoler les systèmes exposés du réseau interne et minimiser les
risques de compromission.

En combinant la séparation physique avec des mesures de sécurité appropriées, telles que les ACLs,
le DHCP Snooping, et les configurations de pare-feu, les organisations peuvent renforcer la sécurité
de leurs infrastructures réseau et réduire la surface d'attaque disponible aux cybercriminels.

7.1 1. VLAN Hopping (Bonding des VLANs)

Description : L'attaque de VLAN Hopping se produit lorsque l'attaquant exploite des configurations de
commutateurs incorrectes pour accéder à un VLAN non autorisé à partir d'un autre VLAN. Cela peut
se produire de deux manières principales :

Double Encapsulation : L'attaquant envoie des trames avec deux balises VLAN (802.1Q) imbriquées.
Le premier switch retire la balise externe et envoie la trame au switch suivant, qui interprète la balise
interne, permettant à l'attaquant de sauter de VLAN.

Attaque de mode Trunking : L'attaquant configure son interface pour qu'elle apparaisse comme un
trunk (lien inter-switchs), permettant ainsi de recevoir le trafic de tous les VLANs.
Contre-mesures : Pour prévenir VLAN Hopping :

 Désactiver le mode trunking sur les ports inutilisés ou ceux qui ne doivent pas
transmettre de trafic de plusieurs VLANs.
 Utiliser des listes de contrôle d'accès (ACL) pour filtrer les trames 802.1Q et limiter les
accès.
 Mettre en œuvre une sécurité de port pour restreindre les adresses MAC pouvant
accéder à chaque port.

Justification de la séparation physique : Dans les environnements très sensibles, tels que les réseaux
de stockage ou les réseaux d'administration, une séparation physique assure que même si une
attaque VLAN Hopping est tentée, elle ne compromet pas les segments critiques. En isolant
physiquement les segments réseau, on réduit la surface d'attaque disponible pour un attaquant
exploitant VLAN Hopping.

7.2 2. Attaques de Spoofing de DHCP

Description : Un attaquant configure un serveur DHCP non autorisé pour répondre aux requêtes
DHCP, attribuant ainsi de fausses adresses IP, passerelles, et serveurs DNS aux hôtes sur le réseau.
Cela peut conduire à des attaques de type "Man-in-the-Middle" (MitM).

Contre-mesures :

 Utiliser DHCP Snooping sur les commutateurs pour autoriser uniquement les réponses
DHCP des serveurs autorisés.
 Filtrage ARP pour prévenir le spoofing ARP sur les VLANs.

Justification de la séparation physique : Dans des segments critiques, comme ceux des serveurs de
production ou de gestion, la séparation physique garantit que les attaques DHCP ne peuvent pas être
initiées depuis des segments utilisateurs moins sécurisés.

7.3 3. Attaques par usurpation de VLAN (VLAN Spoofing)

Description : Cette attaque implique qu'un attaquant configure son port avec le même VLAN ID que
celui utilisé par un segment sensible, permettant ainsi d'intercepter ou d'envoyer du trafic sur ce
VLAN.

Contre-mesures :

 Configurer les ports pour utiliser des VLANs natifs différents des VLANs utilisateurs.
 Limiter les VLANs accessibles à chaque port via des ACLs spécifiques.

Justification de la séparation physique : L'isolation physique des segments sensibles empêche un

attaquant d'utiliser le spoofing de VLAN pour intercepter ou influencer le trafic critique.
7.4 4. Attaques par réflexion de VLAN (VLAN Reflection)

Description : Dans cette attaque, l'attaquant tire parti des règles de routage de VLAN pour forcer le
trafic à rebondir entre différents VLANs, permettant ainsi de voir des paquets qui ne lui sont pas
destinés initialement.

Contre-mesures :

 Configurer des politiques de sécurité strictes pour les ports trunk.

 Utiliser des listes de filtrage sur les commutateurs pour contrôler le routage des paquets
entre les VLANs.

Justification de la séparation physique : En séparant physiquement les VLANs critiques, on empêche

le trafic non autorisé de se propager ou de rebondir entre les VLANs.

7.5 5. Man-in-the-Middle (MitM) Attaques via VLAN

Description : Les attaques MitM exploitent des vulnérabilités dans la configuration des VLANs pour
intercepter, modifier ou détourner le trafic entre les hôtes et les serveurs.

Contre-mesures :

 Utiliser le chiffrement pour protéger le trafic entre les hôtes et les serveurs.
 Implémenter des pare-feux internes et des contrôles d'accès pour surveiller et contrôler
le trafic réseau.

Justification de la séparation physique : La séparation physique des réseaux critiques réduit la

possibilité pour un attaquant de s'insérer dans le chemin de communication, protégeant ainsi les
communications sensibles contre l'interception et la manipulation.