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.
- 1299 megtekintés
Hozzászólások
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 hozzászóláshoz be kell jelentkezni
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:
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Igazad van, rossz elnevezést használtam, de tudom, mi a különbség. BTW, a filter táblában nincs POSTROUTING chain.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.ht…
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni