Az iptables physdev match tényleg csak a bridge-elt csomagokat latja, a route-oltakat pedig nem?

 ( nice | 2018. november 6., kedd - 20:25 )

Sziasztok!

Adott egy Linux gép a következő három hálókártyával: eth0, eth1 és eth2. Az utóbbi kettő a br1 nevű virtuális switch interfésze:


root@rt:~# brctl show
bridge name      bridge id               STP enabled     interfaces
br1              8000.90e2ba7a1ae6        no              eth1
                                                          eth2

Létrehozok egy iptables szabályt, amivel MINDEN olyan új csomagot el szeretnék kapni, ami az eth2 interfészen megy ki:

iptables -t filter -A FORWARD -m physdev --physdev-out eth2 -m state --state NEW -j TABLE_eth2

Igen ám, de azt tapasztalom, hogy ez a physdev alapú szabály csak azokat az eth2-n kimenő csomagokat látja, amelyek az eth1-en jöttek be (azaz bridge-eltek), de az eth0-n bejövőket (azaz route-oltakat) nem. Tényleg ez a helyzet, vagy én rontottam el valamit? Rá lehet valahogy a physdev match-et, hogy route-olt csomagokat is lásson? Ha a csomag egy MÁSIK virtuális bridge egyik interfészén jönne be, azaz két bridge között route-olva lenne, akkor sem látná a physdev match?

Előre is köszönöm a válaszokat.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Miért nem -A OUTPUT ? Az a tippem, hogy a routolás szempontjából br1 a kimenő interfész, és a br1->ethX továbbítás egy mélyebb rétegben történik.

Doksi, nem olvastam el, de releváns: http://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html

A route-olás szempontjából tényleg a br1 a kimenő interfész, de az OUTPUT tábla ide nem jó, mert az csak a kernel által generált csomagokat látja. A releváns infót ld. lejjebb:

mit szólsz POSTROUTING chain-hez?

egyébként észrevettem h kevered a table és a chain fogalmakat. nem lehet h ezzel megvezeted magad?

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Igazad van, rossz elnevezést használtam, de tudom, mi a különbség. BTW, a filter táblában nincs POSTROUTING chain.

hát attól függ a TABLE_eth2-ban mit akarsz a csomagokkal kezdeni, teheted mangle táblára is.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

jol latod, pontosan ez van. a megoldas: veth par egyik felet a bridgebe, masik felet kifele, es akkor mar a routeolas is mukodik. irto sokat szivtunk vele :)

itt a relevans level: http://lists.netfilter.org/pipermail/netfilter/2007-September/069659.html

Köszönöm a szuper releváns infót! Ez azt jelenti, hogy a bridge forgalmát a kernel ne közvetlenül fogadja layer 3 szinten, hanem egy veth páron keresztül, ezáltal az adott bridge forgalmát kétszer is megjáratva a FORWARD táblán routing+bridging esetén?

pontosan.

ha a bridget nem bridgelt interfeszen hagyja el a csomag, akkor nem lehet ra szurni megfeleloen. 2x25Gbitig teszteltuk ezt a megoldast, nem okozott performancia problemakat, es mashogy nem tudtuk a neutron L2-es reszet mukodesre birni, ugyhogy nalunk most ez uzemel productionben.

Én nem értek ehhez annyira, de érdekelne kicsit bővebben. A --phydev-out működni fog a veth-ban? Nem az a kiinduló probléma, hogy az csak a bridge-en belül működik, de a posztoló kívülről szeretné tudni?

Egyelőre nincs időm kipróbálni, de szerintem az lesz, hogy mondjuk az eth0-n keresztül az eth1-re érkező csomagok először route-oláskor mennek át a FORWARD táblán, majd "kimennek" a hosztból a veth pár egyik (IP-címmel rendelkező) tagján, viszont azonnal "beérkeznek" a veth pár másik (a bridge-hez csatolt, és ahhoz hasonlóan IP-címmel nem rendelkező) tagján egyenesen bele a bridge-be, ahol bridge-elés történik, és másodszor is átmegy a FORWARD táblán a csomag, de ezúttal lesz physdev-in és physdev out paramétere is, előbbiben a bridge-hez csatolt veth, utóbbiban az eth1 interfész fog szerepelni. Visszafelé értelemszerűen minden fordítva történik, ha jól gondolom, de mondom, egyelőre nincs időm kipróbálni. Egyébként jobban belegondolva elegánsabb is ez a bridge-et tisztán layer2 szinten használó elrendezés mint az, hogy a bridge-ek layer2 és layer3 szinten is működnek, de azért jár egy fekete pont a kernelfejlesztőknek, hogy a dmesg-ben félrevezető figyelmeztetéssel jelszik a bugot, ami feature.

azt irta, hogy el akar kapni minden olyan csomagot, ami az eth2-on megy ki (tehat egy bridgen beluli interfeszen)

ha csak az erdekel, hogy hol megy be/ki, akkor jo ez igy, mert az ut az lesz, hogy akarmi -> veth (kulso) -> [veth (belso) -> eth2], azaz az eth2 fele/felol jovo csomagokat tudod szurni.

nalunk igy vannak implementalva az openstack security groupok: a virtualis gepek tap interfeszei egy bridgen vannak,a bridge veth *kulso* laban van az anycast gateway cime - igy el lehet kapni minden VMbol es VMbe meno csomagot, es szurni.

Ja, hogy a [ ] lenne a bridge, és a plusz hop a veth-eth2 között már bridge-elt forgalomnak számít, amire értelmesen működik az iptables.