Question de l'exploitant : pourquoi les regles au pare-feu global alors que chaque
VNet peut en porter ? La reponse honnete a demande trois corrections.
CE QUE J'AVAIS TORT D'AFFIRMER :
- « une regle de VNet serait trop grossiere » : faux, elle porte source, dest,
dport, proto. Eprouve (regle creee, relue, retiree).
- « c'etait un arbitrage » : faux. Zero mention du pare-feu SDN dans le depot.
Pas un choix, une omission presentee comme un raisonnement.
- « sur Debian 12 iptables c'est iptables-nft » : faux ici. Mesure sur asgard :
iptables v1.8.9 (legacy). Proxmox force l'alternative sur legacy. LE DEFAUT
D'UNE DISTRIBUTION N'EST PAS UNE MESURE.
MESURE : proxmox-firewall 0.7.1 installe mais ABSENT des services ; seul
pve-firewall 5.1.3 tourne ; node firewall enable 0. Le pare-feu de VNet est
entierement expressif (source/dest/dport/proto, policy_forward ACCEPT|DROP) et
implemente par le SEUL moteur nftables : une regle posee aujourd'hui serait
acceptee, stockee, visible, et n'appliquerait rien. Quatrieme occurrence du motif
de la journee.
TROIS GAINS DANS LE MEME GESTE : moteur xtables -> nftables natif (la doctrine que
les invites respectent deja), pare-feu de VNet reel, et regles qui SURVIVENT a la
reconstruction la ou 38 groupes par VM doivent etre re-attaches a chaque cycle.
Differe apres la reconstruction, sur un noeud d'abord, avec controle negatif.
Reserves : jeu de regles charge non inspecte (nft exige root), aucun blocage reel
eprouve (aucune VM en service).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Daniel Allaire
03aa035cab