J'ai mis en place un pont br0
"attaché" à deux interfaces:
eth0
, mon interface physique connectée au vrai LAN,vnet0
, une interface virtuelle KVM (connectée à une machine virtuelle Windows).
Et j'ai cette règle de pare-feu unique dans la chaîne aval:
iptables -A FORWARD -j REJECT
Maintenant, le seul ping qui fonctionne est de la machine virtuelle vers l'hôte.
L' br0
interface possède l'adresse IP de ma machine hôte. eth0
et vnet0
ne "possède" aucune adresse IP, du point de vue de l'hôte. La machine virtuelle Windows a une configuration IP statique.
Si je change ma iptables
règle en ACCEPT
(ou même en utilise une plus restrictive iptables -A FORWARD -o br0 -j ACCEPT
), tout fonctionne bien! (c'est-à-dire que je peux cingler n'importe quelle machine LAN à partir de la VM, et vice versa aussi).
Toutes les options du noyau de transfert IP sont désactivées (comme net.ipv4.ip_forward = 0
).
Alors, comment le pare-feu netfilter peut-il bloquer quelque chose qui n'est même pas activé?
En outre, le trafic VM-LAN ne doit impliquer eth0
et vnet0
. Pourtant, il semble autoriser le trafic FORWARD avec des -o br0
"travaux" (je n'ai pas vérifié très attentivement cependant).
sysctl -a | grep bridge-nf
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-filter-pppoe-tagged = 0