Nastaveni ruznych P2P sharez

[skudlik]

Pokud vim tak UTP protokol ma vetsi efektivitu prenosu dat, protoze neobsahuje ochranne a dalsi udaje packetu.Ma sice nizsi prioritu,ale to neznamena ze pro sluzby P2P,digital TV,atc. neni pouzitelny. Ba prave naopak. Nerekl jsem ze ho plne pouzivam pro P2P a ze s tim blokuji klfree. To proboha ne, jen u nekterych klientu sharezu jsou UDP porty vyuzivane pro pomocne sluzby jako napriklad listing,hledani a p2p komunikaci.A skutecna upload/download data(soubory) putuji pres cesty v TCP portech.

O efektivite by se dalo silne polemizovat. O tech par bajtu kratsi hlavicka na to ma nulovej vliv. Jde hlavne o implementaci. Jakykoliv datovy prenos ve vetsine pripadu pouziva nejake potvrzovani prijatych paketu. TCP tohle uz ma primo v sobe, u UDP je to vec ciste implementace. (Ktera muze byt bud efektivni - NEBO - taky hodne neefektivni).

Velky problem u UDP je taky v tom, ze neprobiha (pokud neni implementovana na urovni programu) zadna regulace mnozstvi dat (rychlosti posilani) v zavislosti na tom, jestli dochazi ke ztratam paketu nebo ne. Tohle muze byt velmi nebezpecne. Na wifi (a nejen na ni) pak dochazi k zahlceni vysilanymi UDP pakety.

Takze doporucoval bych, pokud nevite presne co to dela (coz bych si ja osobne troufl rict pouze v pripade, ze jsem onen komunikacni program sam napsal, jinak ne), tak se UDP prenosum pokudmozno vyhnout.

[belgarat]

Pouze neznam dana nastaveni v klfree. pokud vim tak v tabulkach se daji delat docela divy. nelibi se ze na me utocis ohledne problematiky...vzdyt firewallu pod linuxem je hafo, kazdy ma jina specifika a jinou vybavu "do boje". Tim myslim predem nastavene a podporovane sluzby,porty.Na jinych FW se to musi pro zmenu vse manualne naklepat do tabulky,ale to je holt zivot. idealni by bylo kdybys napsal primo verzi a nazev FW ktery mas na mysli a ja se sam podivam.
Stejne si ale pripadam ze si ze me stihl udelat blbce,a pritom jeden mluvi o koze a druhy o voze,tak to chapu jako vzajemne nepochopeni.

Existuje hafo firewallu, ale rucim ti za to, ze vsechny WISPy, Shorewally, Gatekeepery apod konci v naprosto stejnem rozhrani na kernel. Ono napsat packetovy filtr neni vubec zadna legrace - a predevsim proc by nekdo psal packet filter, kdyz staci napsat ruzne front-endy.

Shorewall je proste "jenom" preprocesor ze ktereho lezou "prikazy pro iptables". Kdyz pak vyjedes tabulku pravidel jak ji vidi jadro, muzes si byt jisty ze je uplne jedno ktery front-endovy balicek jsi pouzil.

To jsem udelal (pro jistotu, protoze jsem ty pravidla taky vlastorucne zavadel, ale jistota je jistota), na zaklade toho jsem Ti napsal blokovane porty... a odpoved byla opet "otazkou je co AP Paris, jestli neblokuje nejake UDP porty".  Pokud jde o delani blbcu (s prominutim), timhle sis zacal

Prirozene ze VIM ze jsi na AP/LAN Paris (podle IP adres). Vsechny routery maji co se tyce filtrace jednotne nastaveni -- lepe se to spravuje a muzes se pak spolehnout ze neexistuje "mistni anomalie" ze nekde neco nefunguje a jinde ano. Navic si fakt nedokazu predstavit proc blokovat nejake porty (krome notorickych viro-nosicu NetBios/NetBEUI a microsoft Directory Services)

jen u nekterych klientu sharezu jsou UDP porty vyuzivane pro pomocne sluzby jako napriklad listing,hledani a p2p komunikaci.A skutecna upload/download data(soubory) putuji pres cesty v TCP portech.

Pak je potiz v tom, ze v Klfree pouzivany (standardni) firewall/nat neobsahuje conntrack podporu pro takove UDP sluzby. Opet jedna z mnoha nevyhod UDP, ponevadz u TCP je identifikace spojeni vedena na urovni protokolu a proto vsechny TCP sluzby prochazeji firewallem jako maslo.

[KPR]

ok, myslim ze se vse vyjasnuje .
Netusil jsem ze paris ma stejne nastaveni FW jako vsechny ostatni.

ad linux kernel firewall... souhlasim. distribuce od distribuce, jadro od jadra. popripade vlastni distribuce + vlastni prelozene jadro s upravenou podporou.
To je taky duvod proc jednoznacne se priklanim k "all in box" routerum... ktere obsahuji ucLINUX.

Pak uz jsou moznosti jen:
-) provozovat na verejne IP
-) neverejna IP
* povolit forwarding z adres (10.102.19.x) na porty 4661 , popr. 4242

Ad. netbios a jine microsoft open port blbosti... souhlasim. jednoznacne zakaz. me na win9x to problemy nedela, win XP nepochybne ano + sireni viru v lokalni siti.

Myslim ze je vse vyreseno, a nemuseli jsme tu diskuzi tak hrotit, hm?