ipfw: beznych sluzeb od p2p

Milan Cizek Cizek.Milan at seznam.cz
Thu Oct 21 09:25:52 CEST 2004


< 	Jestlize je ed0 vnejsi interface a vnitrni je ed1 a neni na nem jina 
< sit nez "LAN", pak vhodnejsi je patrne
< ... ip from any ${FS} to any out recv ed0 xmit ed1

ed0 je, jak si spravne vydedukoval vnejsi interface, lokalni sit je 10.0.0.0/16, vnitrni interfaci jsou dva (wi0,xl0).

< 	Slovne receno nam jde o "pakety jdouci zvenku dovnitr".

< 	Pro ICMP je nutne podminku sestavit zvlast - a o zadnych portech se 
< nezminovat. Nemusim snad zduraznovat, ze  "Podminku zvlast" neznamena, 
< ze musi mit samostatnou separatni pipe ...

Aha, tak nejak podobne jsem si to myslel.

< 	No, schazi dodat jeden zasadni postreh. Filtrujeme az "za linkou" - tj. 
< (pripadne) zahazujes az pakety, ktere uz linkou prosly a jeji kapacitu 
< vyuzily.
< 
< 	Takove filtrovani ma smysl jen u tech protokolu, ktere maji nejakou 
< flow-control a ktera zareaguje na tuto situaci spravne - tedy snizenim 
< frekvence zasilanych paketu.
< 
< 	To lze ale s jistotou rict jen o TCP (pozor, UDP neni TCP, to je neco 
< jineho) ...
< 
< 	U ostatnich IP protokolu je flow-control zalezitosti aplikacni vrstvy a 
< zminene chovani zaruceno v zadnem pripade neni.

Aha, nevit tedy prozatim co znamena flow-control, ale snad jsem to spravne pochopil. Pokud nebudu v cilovem bode dostatecne rychle pakety odebirat/budu je zahazovat, tak protokol podporujici flow-control rekne odesilateli "posilej jich mene nebo pomaleji". Protokol bez flow-control nijak nezareaguje a pude posilat stale stejne. Tak nejak?

Treba uzivatel navaze p2p spojeni s jinym uzivatelem v netu. Ten bude mit dostatecne rychlou linku, rekneme 512kbps, ale na firewallu pujde tento spoj pres pipe rekneme o sirce 256kbps. Znamena to ze az k memu firewallu bude stale odchazet rychlosti 512 a az tam se orizne. To si asi opravdu prilis nepomuzu.

< 	A, v neposledni rade, bojujes boj predem prohrany. Jestli's ty neslysel 
< o tom, ze skrz SSH a HTTP protokol lze protunelovat jakakoliv data (a to 
< nemluvimo moznosti, ze na druhem konci na patricnem portu vubec nesedi 
< SSH a HTTP, ale neco uplne jineho), pak tvoji uzivatele o tom slyseli 
< urcite - a pokud ne, opatreni je zahy donuti si tuto diru ve vzdelani 
< doplnit.

To je mi samozrejme znamo, kdysi jsem si dokonce jeden takovy tuneling na Win32 platforme napsal (2 sifrovaci proxyny proti sobe :)). Nepodcenuju uzivatele, ale tohodle se opravdu nebojim. Oni jsou pouze cilova skupina spotrebitelu internetu, nic jineho je nezajima, na toz aby neco studovali. Maji uplne jine zajmy a svym zpusobem pro ne nejsou "omezene" sluzby nic, zac by se jim vyplatilo bojovat. V 90% procentech totiz ani nepoznaji, ze k nejake zmene v konfiguraci vubec doslo a pokud ano, je jim to proste jedno. A to zas verte vy, ja je mam kolem sebe. ;-) Horsi je ale jina vec kterou jste zminil a to, kdyz treba uzivatel narazi na nejaky DC++ hub nebo jinou sluzbu, ktera bezi trreba na portu 80 (uz jsem nejakou potkal)... Ted me ale napada ze to vlastne problem neni, protoze p2p spoj se stejne nezrealizuje.

< 	Domnivam se, ze "shaping" neni vhodnym nastrojem pokud se nam jedna o 
< vynuceni "fair-use" od uzivatelu, kteri se aktivne snazi pojem "rozumne 
< uziti" ignorovat. Ver mi. Mam v siti 800 uzivatelu ...

Byl bych docela rad, pokud byste mi mohl napsat, v cem vidite spravnou cestu reseni. V napsanych pravidlech? Organizaci? Restriktivnim krokum proti narusovatelum (zastrasovani ostatnich :))? Nebo v uplatneni jine technologie (QoS)?

Milan



More information about the Users-l mailing list