Contexte : fiche de l'hôte unique qui porte tous les CT et VM de l'infrastructure · Testé sur : Intel NUC10i5FNB, Proxmox VE 9.2.11, Debian 13 trixie, noyau 7.0.14-14-pve · Dernière vérification : 01/10/2026
| Élément | Valeur |
|---|---|
| Matériel | Intel NUC10i5FNB |
| Nom et adresse | alpha, 192.168.1.213 en IP fixe (bail statique Proxmox-alpha en plus) |
| Système | Proxmox VE 9.2.11 sur Debian 13 trixie, noyau 7.0.14-14-pve |
| Interface web | https://192.168.1.213:8006 |
| Disque système | NVMe |
| Stockage des CT et VM | thin pool LVM pool1 (~3,7 To) sur SSD Samsung 870 QVO 4 To, déclaré dans Proxmox sous le nom pool |
| Autres stockages | local (ISO, modèles, dumps ; peu d'espace libre) et local-lvm |
| Réseau | carte eno1 (MAC (voir le bail sur la Livebox)) ; ponts vmbr0 (LAN, 192.168.1.213/24), vmbr1, vmbr20 et vmbr150 (sans IPv4) |
| Machines | 8 CT et 3 VM : voir l'inventaire |
| Redondance | aucune : nœud unique, pas de cluster, disque de données unique |
| Wake-on-LAN | actif et permanent sur eno1 ; voir Wake-on-LAN |
sudo. La connexion SSH de root est refusée et l'authentification par mot de passe désactivée.ignoreip = 127.0.0.1/8 192.168.1.0/24) : un poste du LAN n'est jamais banni par lui, et la jail sshd n'a d'ailleurs jamais rien attrapé (0 bannissement au total). Ce qui bloque un poste du LAN, c'est la pénalité par source d'OpenSSH (voir l'avertissement plus bas). Depuis l'extérieur, en revanche, le bannissement s'applique ; pour le lever, depuis le shell de l'interface web :sudo fail2ban-client unban <IP_DU_POSTE>
mass@pam (rôle Administrator).sudo pct enter <ID> ou sudo pct exec <ID> -- <commande>.Ne tentez jamais une connexion SSH en
rootpour « voir si ça passe ». Ce n'est pas fail2ban qui sanctionne — il ignore le réseau local — mais la pénalité par source d'OpenSSH :authfail:5ajoute 5 secondes par échec, dès 15 secondes cumulées la source est refusée, jusqu'à 10 minutes au plus. Elle bloque tous les comptes depuis le même poste, y compris ceux qui sont autorisés, et elle se lève d'elle-même :fail2ban-client unbann'y peut rien.
sudo pct list
sudo qm list
sudo pvesm status
sudo lvs --units g -o lv_name,lv_size,data_percent,metadata_percent pool1
sudo pveversion
startdelay, startorder) qui ajoutent des avertissements aux sorties de pct : filtrez-les avec grep -viE 'startdelay|startorder'.fstrim d'un gros volume, suppression d'un gros snapshot) se lancent en tâche détachée pour survivre à la coupure de la session :sudo systemd-run --unit=tache-x bash -c 'commande longue > /var/log/tache-x.log 2>&1'
systemctl is-active tache-x
unable to shrink disk size), et ce serait inutile.data_percent vide = volume inactif (machine arrêtée), pas un volume vide.metadata_percent autant que data_percent : au-delà de 80 %, un thin pool devient difficile à récupérer.sudo pct fstrim <ID> pour un CT en marche), avant d'envisager toute suppression.La procédure complète (dépôts deb822, apt dist-upgrade, redémarrage) est décrite dans Proxmox VE 9 : dépôts et mises à jour.
Aucune sauvegarde externe n'existe. Pas de tâche
vzdumpplanifiée, pas de Proxmox Backup Server. Les copies faites le 01/10/2026 avant travaux (dumps SQL, snapshotsavant-refonte-20261001du CT 103 etavant-securisation-20261001du CT 105) sont sur le même disque que les données : elles ne protègent pas d'une panne du SSD.
État à contrôler avant toute affirmation :
sudo cat /etc/pve/jobs.cfg
sudo ls -lh /var/lib/vz/dump/
sudo lvs -o lv_name,lv_size,origin pool1 | grep snap_
Cible à mettre en place :
local n'a pas la place : les données Nextcloud pèsent à elles seules environ 711 Go) ;vzdump planifiée en mode snapshot pour les CT, complétée par des dumps de bases cohérents pour Nextcloud et Wiki.js ;Les snapshots temporaires du 01/10/2026 sont à supprimer une fois les travaux validés, car ils retiennent des blocs dans le pool.
root refusé, fail2ban actif.sshd et la jail proxmox, qui couvre enfin l'interface web du port 8006 (maxretry 6, findtime 30 min, bantime 1 h, sur le journal de pvedaemon). Elle a déjà banni 5 adresses, dont une encore active. Le port 8006 était jusque-là à découvert, alors qu'environ 9 300 échecs d'authentification y avaient été relevés sur 7 jours en septembre 2026, presque tous depuis une seule adresse. Pour les compter :sudo journalctl --since "7 days ago" | grep -i "authentication failure" | grep -oE 'rhost=[^ ]+' | sort | uniq -c | sort -rn | head
firewall=1, mais aucun fichier cluster.fw n'existait au 30/09/2026 : le pare-feu ne filtrait donc rien au niveau de l'hôte.| Date | Changement |
|---|---|
| 30/09/2026 | Accès SSH du compte dédié confirmé (sudo) ; CT passés en DHCP avec baux statiques ; CT 100 renuméroté en 101 ; CT 108 créé par clonage du 107 ; CT 112 et 114 supprimés par Mass ; service wol-eno1.service créé |
| 01/10/2026 | Dumps et snapshots avant la sécurisation de Nextcloud et la refonte du wiki |