ipfw + nat + dummynet (+ bridge)

Martin Horcicka horcicka at freebsd.cz
Sun Mar 7 20:44:36 CET 2004


Ahoj,

mam dojem, ze nektere odpovedi tu jeste nepadly, nebo byly nespravne, takze
tady je jeste muj prispevek:

Zbyněk Burget (2004-03-04 08:31 +0100):

> V ipfw(8) jsem se docetl, ze po pruchodu paketu pres pravidlo dummynet se
> paket vraci do firewallu, pokud neni nastaveny jednopruchodovy ipfw. Jak je
> to v pripade pravidla divert natd ... ? Taky by se pri jednopruchodovem ipfw
> uz nevratil?

Promenna net.inet.ip.fw.one_pass je, jak je ostatne napsano v ipfw(8), jen pro
dummynet, takze s divert nesouvisi. Pravidlem divert se paket preda z jadra
externimu programu (napr. natd) a je pak na nem co s paketem udela. Bud ho
muze vlozit zpet do jadra a pak bude pokracovat pruchod paketu firewallem
typicky pravidlem s nejnizsim vetsim cislem, nez bylo prislusne pravidlo
divert, nebo muze program paket treba zahodit, jako to napriklad dela u
nekterych paketu natd s volbou -d.

> Pokud nemam jednopruchodove ipfw a povolim prichozimu paketu pruchod pres
> ipfw (pravidlo allow), kam ten paket potom jde? Uz rovnou na odchozi adapter
> (tedy skrz prislusne komunikacni vrstvy) nebo je jeste nejaka sance
> (nebezbeci) ze se do ipfw vrati?

Ani pravidlo allow nesouvisi s dummynetem a tedy ani s promennou
net.inet.ip.fw.one_pass. Je-li na paket aplikovano pravidlo allow, pruchod
firewallem konci a paket jde na dalsi zpracovani jadrem. Dany paket se tedy do
ipfw "nevrati", ale to neznamena, ze pri dalsim zpracovani nebude prochazet
tymz firewallem treba jeste nekolikrat. Podle nastaveni a typu stroje, muze
paket firewallem projit az ctyrikrat:

- na ethernetove vrstve pri prijmuti
- na IP vrstve pri prijmuti
- na IP vrstve pri odeslani
- na ethernetove vrstve pri odeslani

> K cemu jsou dobra pravidla zpracovavajici pakety v layer 2? Jde s nimi
> udelat vsechno to, co s normalnimi pravidly nebo jsou tam nejaka omezeni? To
> jsem z zadneho textu oprvadu nepochopil. Asi by pruchod takoveho paketu
> firewallem mel byt rychlejsi (jak potom funguje nat a dummynet).

Na 2. vrstve, zpravidla ethernetove, je paket jeste zabalen v ethernetovem
ramci, takze jsou pro zkoumani pristupne i ethernetove hlavicky. Pri
zpracovani na IP vrstve uz budou tyto hlavicky odriznute. Takze pri zkoumani
paketu na 2. vrstve lze pouzit nektere vyrazy, ktere na IP vrstve uz dostupne
nejsou. Dummynet na 2. vrstve zrejme pouzit lze, ale chova se jako by hodnota
net.inet.ip.fw.one_pass byla vzdy 1. Tezko rici, zda jsou tam nejaka dalsi
omezeni a stejne tak netusim, zda na 2. vrstve funguje divert. Napr. fwd tam
nefunguje.

> K cemu je bridge(4)? Urychleni pruchodu paketu routerem? Paket se v tomhle
> pripade nijak nezmeni? Paket se nejak zmeni, pokud bridge neni aktivovany?
> Jsou v pripade pouziti bridge nejake omezene moznosti ipfw (resp. dummynetu
> a natu)?

Nevzpominam si na presnou definici bridge, tak vas radeji nebudu prilis
mystifikovat, ale jiste byste ji nasel nekde na Internetu nebo v nejake knize
o sitich. Navic se terminologie casem trochu menila. Predstavte si pro
zjednoduseni switch, coz je jeden konkretni priklad bridge, ten jiste znate.
Mechanizmus bridge(4) vam tedy umozni, aby se stroj nechoval jako router, ale
jako switch, nebo jako jakysi hybrid. K tomu se zpravidla pristupuje jen
proto, ze k tomu nejake okolnosti nuti. Lze-li pouzit router, je to vetsinou
rozumnejsi.

Firewallem paket v tomto pripade prochazi jen jednou (tedy ne jednou na vstupu
a podruhe na vystupu) a to pouze na 2. vrstve. Firewall je pro tento pripad
nutne zapnout pomoci net.link.ether.bridge_ipfw a moznosti jsou zrejme podobne
jako u vyse popisovane 2. vrstvy pri pruchodu paketu normalnim routerem.

> Jak dalece je pouzitelny dummynet pro nastaveni spravedlnosti pri rozdeleni
> pasma pri prichozi traffic?
...

S prichozim provozem je potiz. Na 100% to proste z principialnich duvodu
nejde. Pro jisty druh provozu mozna teoreticky pujde pouzit reseni, o kterem
tu, myslim, ted nekdy uz byla rec (zuzeni linky). Kazdopadne se o tom v tehle
konferenci mluvilo pred nejakym casem a vysvetlovali to tu Vita Novy a Dan
Lukes.

Martin




More information about the Users-l mailing list