Verständnisfrage if_bridge + PF

Cédric

aka decemplex
Hallo,

Ich hab ein paar Probleme mit der neuen Implementierung der Bridge (if_bridge) + PF: früher war em0 (siehe unten) das ausgehende Interface, ausgestattet mit den nötigen IP's, darauf wurde gefiltert und gut war. Jetzt hab ich em0 bridge0 zugeteilt (weiteres Interface kommt später), und die IP Adressen auf bridge0 statt em0 gesetzt... laut man if_bridge kann man 2 sysctl setzen, die entscheiden ob auf den member Interfaces (hier ja wohl em0) / der Bridge (bridge0) gefiltert wird. Ich hab das ganze dann mal so laufen lassen, ohne die PF Regeln zu verändern: der Server war nicht mehr erreichbar, laut /var/log/pflog wurde alles an bridge0 geblockt... soweit dann eigentlich auch logisch, da beide sysctl's auf 1 waren, und meine pf.conf "block log all" enthielt, und nur hier und da was auf em0 durchgelassen wird.

Für mich sieht die Lösung dann folgendermassen aus: net.link.bridge.pfil_bridge auf 0 setzen, so das nicht mehr auf bridge0 gefiltert wird, und ich weiterhin meine Regeln für em0 beibehalten kann. Gesagt getan, Server weiterhin nicht erreichbar, weiterhin wird alles an bridge0 geblockt - wieso? Wo versteh ich hier was falsch, und wie müsste ich filtern um den gleichen Effekt zu erreichen wie jetzt (möglichst ohne bridge0 zu benutzen)?

ifconfig:

Code:
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        ether 00:12:3f:ec:xx:xx
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
[...]
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33208
[...]
bridge0: flags=8041<UP,RUNNING,MULTICAST> mtu 1500
        inet 80.237.xxx.xxx netmask 0xffffff00
        inet 80.237.xxx.xxx netmask 0xfffffff8
        inet 80.237.xxx.xxx netmask 0xfffffff8
        inet 80.237.xxx.xxx netmask 0xfffffff8
        inet 80.237.xxx.xxx netmask 0xfffffff8
        inet 80.237.xxx.xxx netmask 0xfffffff8
        inet 80.237.xxx.xxx netmask 0xfffffff8
        ether ac:de:48:65:xx:xx
        priority 32768 hellotime 2 fwddelay 15 maxage 20
        member: em0 flags=3<LEARNING,DISCOVER>

pf.conf:

Code:
lo_if="lo0"
ext_if="em0"
bck_if="em1"

localhost="127.0.0.1"
xxx_net="80.237.xxx.xxx"
box_xxx_net="80.237.xxx.xxx"

rdr on $bck_if inet proto udp from 10.12.4.69 to 10.12.4.70 port 10080 -> $localhost port 10080

# Block everything
block log all

# No restriction for $lo_if & $bck_if
pass quick on $lo_if
pass quick on $bck_if

# Outgoing
pass out on $ext_if proto tcp all modulate state
pass out on $ext_if proto { udp, icmp } all keep state

# SSH xxx.net:22
pass in on $ext_if proto tcp from any to $xxx_net port ssh modulate state

# SSH box.xxx.net:22
pass in on $ext_if proto tcp from any to $box_xxx_net port ssh modulate state

# BIND xxx.net:53
pass in on $ext_if proto udp from any to $xxx_net port domain keep state

sysctl.conf:

Code:
net.link.bridge.pfil_member=1
net.link.bridge.pfil_bridge=0
 
Ich hab mit bridges bis jetzt nur unter Linux zu tun gehabt, aber dort war es so (und hier müsste es meinem Verständniss nach auch so sein) dass du auf bridge0 filtern musst. Auf em0 und em1 findet ja im Prinzip kein Verkehr mehr statt, sie haben ja auch keine IP-Adressen.
Aber wie gesagt, ich weiss nicht wie Bridges unter BSD gehandhabt werden, womöglich ist da alles anders..

HTH Maurice
 
Ja, das wurde mir gestern auch so erklärt, aber dann frag ich mich, wie ich die 2 sysctl verstehen soll (Sinn?!) - und wieso irgendwo in einer Mailingliste gesagt wurde, man soll nicht auf der bridge0 filtern, da sie nicht zwischen einkommender/ausgehender Traffic unterscheidet, sondern dann halt auf den Interfaces... aber mit den Interface Regeln hat er scheinbar nichts mehr am Hut seit der Bridge:

Beispiel:

Gebe ich den Traffic auf bridge0 (pass in on bridge0 usw) frei, ist der Server zwar erreichbar, aber auch der WebServer auf Port 80, der laut meinen Regeln ja geblockt (auf em0) sein sollte... also scheinen die Regeln wiederum gar nicht mehr ins Gewicht zu fallen.

Ich versteh nur noch Bahnhof: man kann scheinbar auf den Interfaces filtern, auch laut manpage, aber er beachtet es nicht, und auf der Bridge soll man nicht filtern (wollte ich auch gar nicht), wegen fehlender in/out Unterscheidung, aber hier scheint nichts anderes möglich zu sein... und wozu sind dann diese sysctl's da?!
 
Zurück
Oben