Quiz — chapitre 5

Le SDN Proxmox repose sur trois niveaux imbriqués : la Zone (domaine d'isolation réseau) est créée en premier, le VNet lui est ensuite rattaché, puis le Subnet (plage IP, gateway, DHCP) est défini à l'intérieur de ce VNet — chaque niveau dépend de l'existence du précédent.

Toute modification SDN (zone, VNet, subnet) reste à l'état pending tant que l'Apply n'a pas été déclenché — en interface via le bouton Apply, ou en CLI via pvesh set /cluster/sdn. C'est cette étape qui génère réellement les bridges Linux, les règles iptables et démarre les services dnsmasq associés.

Le VNet est l'équivalent logique d'un switch virtuel — rattaché à une zone, il n'existe concrètement sur le nœud qu'après l'Apply, où Proxmox le matérialise sous forme de bridge Linux portant son nom. Ce n'est ni un tunnel VPN, ni une interface physique, ni un objet de pare-feu.

Les zones VXLAN (et EVPN, qui y ajoute un routage BGP dynamique) encapsulent des trames Ethernet dans des paquets UDP, créant un overlay réseau L2 qui traverse un réseau L3 physique existant entre plusieurs nœuds. La zone Simple reste locale à un seul nœud, la zone VLAN segmente sans encapsulation ni traversée de réseau L3.

Proxmox laisse d'office passer l'interface web (8006) et SSH (22) depuis le réseau local du nœud et l'IP set management. Mais un administrateur qui travaille depuis un autre réseau (VPN, autre site) est coupé dès l'activation, et ne peut plus corriger qu'à la console. Créer d'abord les règles d'accès, les vérifier, puis seulement activer : on ne se retrouve jamais enfermé dehors.

pveum acl modify <chemin> --users <user>@pve --roles <role> crée l'ACL qui relie les trois briques du RBAC Proxmox : l'utilisateur, le rôle et la ressource ciblée par le chemin. pveum role add existe, mais il crée un rôle — il ne l'attribue à personne ; les deux autres syntaxes n'existent pas.

Les [RULES] de cluster.fw sont les règles des nœuds (zone hôte). Vérifié sur le lab : le nœud ne répond plus, un conteneur en politique ACCEPT répond toujours, et la règle n'apparaît que dans la chaîne PVEFW-HOST-IN. Pour les invités, on passe par leur pare-feu ou par un groupe de sécurité.

Le préfixe | marque une règle désactivée. Par l'API, une règle est créée désactivée si --enable 1 n'est pas précisé ; l'interface, elle, coche Enable par défaut. Constaté sur le lab : la règle n'apparaissait dans aucune chaîne avant d'être activée.

Chaque produit Proxmox a son port dédié pour ne jamais entrer en conflit : Proxmox VE = 8006, PBS = 8007, PDM = 8443.

PBS découpe chaque sauvegarde en blocs — de 4 Mio fixes pour un disque de VM, de taille variable pour une archive de fichiers — calcule leur empreinte SHA-256 et ne stocke qu\'une seule fois chaque bloc identique, d\'une sauvegarde à l\'autre et d\'une machine à l\'autre. La compression zstd s\'applique ensuite à chaque bloc unique : elle complète la déduplication, elle ne la remplace pas.

Avec un certificat auto-signé (le cas par défaut de PBS), il n'y a pas d'autorité de certification reconnue pour valider l'identité du serveur — le fingerprint SHA256 du certificat sert de vérification manuelle explicite. L'authentification se fait via un compte OU un token (pas obligatoirement le mot de passe root), et aucun accès SSH n'est nécessaire : tout passe par l'API HTTPS de PBS.

pvesm (Proxmox VE Storage Manager) gère l'ajout de tout type de stockage, dont PBS — avec serveur, datastore, identifiant (compte ou token complet user@realm!nom-token), le secret associé passé via --password (que ce soit le mot de passe du compte ou la valeur du token — pvesm add pbs n'a pas de paramètre --token distinct), et le fingerprint. pvecm gère le cluster Proxmox, pas le stockage.

Un token dédié à un usage précis (ex. une intégration Proxmox → PBS) peut être révoqué seul si compromis, sans casser tous les autres usages du même compte qui dépendraient du mot de passe. Un token peut aussi être restreint par ses propres permissions (privsep), contrairement à un accès root illimité — c'est l'inverse de la proposition C.

File Restore (VM → Backup, ou le stockage PBS → Backups) démarre une petite machine de lecture qui monte le disque sauvegardé et permet de télécharger un fichier ou un dossier, sans toucher au nœud ni à la VM d\'origine — c\'est l\'outil proxmox-backup-file-restore. En ligne de commande, on présente l\'image avec proxmox-backup-client map avant de monter sa partition. Les trois autres commandes n\'existent pas.

Un verify job relit les chunks stockés et vérifie leurs checksums, détectant toute corruption silencieuse (disque défaillant, bit rot) avant qu'elle ne soit découverte au pire moment — au moment d'une restauration réelle. Il ne recrée rien, ne teste pas de restauration complète, et n'est pas un mécanisme de synchronisation externe.

pvesm list liste le contenu d\'un stockage, et --content backup le restreint aux sauvegardes — pour un stockage PBS comme pour un répertoire local. L\'API offre la même chose par pvesh get /nodes/<nœud>/storage/<stockage>/content --content backup. Les trois autres commandes n\'existent pas.

Un sync job s'exécute sur le PBS qui reçoit : il déclare le PBS source comme remote, puis tire ce qui lui manque, en ne transférant que les chunks absents. C'est la copie hors site de la règle 3-2-1 : 3 copies, 2 supports, 1 hors site (cours, chapitre 5, §6.1).