Pourquoi mon pare-feu (iptables) interfère-t-il dans mon pont (brctl)?

11

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' br0interface possède l'adresse IP de ma machine hôte. eth0et vnet0ne "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 iptablesrè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 eth0et vnet0. Pourtant, il semble autoriser le trafic FORWARD avec des -o br0"travaux" (je n'ai pas vérifié très attentivement cependant).

iptables virtual-machine firewall bridge Totor
la source
Jetez un oeil à mon A à cet U&L Q: Paramètres lors de l'utilisation d'un pont
slm
1
Quelle est la sortie desysctl -a | grep bridge-nf
Stéphane Chazelas
@ StéphaneChazelas 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
Totor

Réponses:

10

Le commentaire de Stéphane Chazelas donne un indice à la réponse.

Selon la foire aux questions de Bridge-nf, bridge-nf permet à iptables, ip6tables ou arptables de voir le trafic ponté.

Depuis la version 2.6.1 du noyau, il existe cinq entrées sysctl pour le contrôle comportemental bridge-nf:

  • bridge-nf-call-arptables - transmettre le trafic ARP ponté à la chaîne FORWARD d'arptables.
  • bridge-nf-call-iptables - transmettre le trafic IPv4 ponté aux chaînes d'iptables.
  • bridge-nf-call-ip6tables - transmettre le trafic IPv6 ponté aux chaînes d'ip6tables.
  • bridge-nf-filter-vlan-tagged - transmettre le trafic ARP / IP ponté avec un tag vlan aux arptables / iptables.
  • net.bridge.bridge-nf-filter-pppoe-tagged - transmettre le trafic IP / IPv6 avec un tag pppoe ponté aux tables {ip, ip6}

Vous pouvez désactiver le blocage du pare-feu netfilter avec: 

# sysctl -w net.bridge.bridge-nf-call-iptables=0
# sysctl -w net.bridge.bridge-nf-call-ip6tables=0
Mathias Weidner
la source
4
Depuis Linux 3.18, la fonctionnalité où iptables gère les paquets du pont peut être désactivée en ne chargeant pas le br_netfiltermodule. Ne pas avoir le module chargé signifie également qu'il n'y a pas d' /proc/sys/net/bridge/entrée.
Lekensteyn
Et depuis le noyau Linux 5.3, cette fonctionnalité devient par espace de noms au lieu de globale.
AB