Už delší dobu se potýkám s protokolem bit-torrent. Jeho užívání způsobuje na routerech značné problémy. Otevírá velké množství spojení
řádově tisíce na uživatele bit-torrentu. A hlavě po sobě spojení ani neuzavírá. Následkem je 100% vytížení CPU routerboardu při datovém toku 5 Mbit/s. Tento datový tok vysosají uživatlé výměnných sítí a na běžného uživatele potom zbyde jen pohled na pomalu se načítající webovou stránku . Problém se hlavně projevuje, na routeru kde je uživatel bit-torrentu připojen i když jeho spojení procházejí i routerem před ním, ale ten slouží jako retranslace a všesměr, tzn. že je na něm ještě více klientů a není zdaleka tak vytížen jako router za ním. Z toho soudím, že routeru dává zabrat udržet veké množství spojení na anténě s více klienty oproti PtP spoji. Nebo je možné že je to tím, že všesměry jsou v modu AP-bridge a PtP spoje v mode Bridge?
Řesení problému:
Vyzkoušel jsem toho už hodně, ale nic nebylo efektivní ba nekdy i horší než lepší. Napiši sem pár věcí, které jsem již vyzkoušel, možná někoho napadne jak to vylepšit nebo udělat jinak. Na všech routerech používám RouterOS!
Nějaký QOS na routeru kde je uživatel připojen se vůbec neosvedčil, protoze jakákoli pravidla ve firewallu routeru akorád přitíží a navíc v ip/firewall/mangle sice mohu znackovat packety P2P dokonce i samotných torrentu, ale ne se 100% učinností. Označkují se jen nějaké a zbytek se tváří jako jiný druh taficu a z routeru odchazí vesele dál pod jinou prioritou než P2P. Navíc nelze definovat max. propustnost, protože když je router bez bit-torrentu je schopen přenést 14 Mbit/s a s bit-torrentem 5 Mbit/s takže QOS nemůže fungovat správně.
Dále jsem zkoušel omezovat počet spojení na jednoho uživatele na 200 a to pravidlo bylo také hodně náročné na CPU. A hlavně ani moc nefungovalo.
Pak jsem zkoušel v ip/firewall/connections/tracking změnit parametr TCP Established Timeout na 2h misto 24h to počet spojení snížilo, ale stejně jich bylo pořád moc.
Pak jsem také zkoušel nastavit ve firewallu na hlavním routeru pravildla ze uživatel s vice spojeníma než 200 bude zařazen do skupiny, kde jsou povoleny je nějaké základní porty. A poté co spojení uvolní bude zařazen zpět do normální skupiny. To se také neosvědčilo, protože uživateli se sice omezil provoz, ale torrent protekal pořád, ale pouze pomaleji. Routerům se nijak neulehčilo.
Poslední věc kterou jsem proti torrentu vymyslel funuguje na 100%, ale zakazuje torrent úplně a donutí uživatele aby ho nepoužíval. Ale to nechci, ale v současné době nemám lepší řešení.
Hlavně uživatelům typu BFU a Lamy se to moc nelíbi, protože pod slovem stahovani si představuji jen Torrent.
Obdivuji toto kdo tento příspěvek dočetl až sem:)
A budu rád když někdo přispějete nějakým nápadem nebo radou.
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Bit-torrent a RouterOS
Krabík píše:Taky bych rad vedel, jak to mate udelany, kdyz jsem mel omezeny pocet spojeni, tak tem "omezenym" prakticky nesel net. Je asi treba nejak vyresit provoz na portech 80, 53, atd.... Ale i to se mi nejak nedarilo...
Jak jsi to omezil? Musis dat ten limit aby kazda IP mela 70 spojeni je mozne ze ti to dava limit 70 spojeni na vsechny IP na routeru a to je malo. A kdyz nemuzes otevrit dalsi spojeni tak proste nic nefunguje.
A pokud nemas na tom stroji PC tak ti to asi moc nepomuze
0 x
.gorila píše:fcc píše:Na hlavním routeru v síti mám nastavené max. 70 oteřených portů na uživatele a od te doby neni problém.
ahoj.mohol by si to popisat prosim ? ako na to ? vyzera to dobry napad,len neviem ako s tou realizaciou.script ? vopred dakujem.
Mam tam prskle PC PII 366 a na nem Debian. Ani jej to moc nevytezuje, tak do 60% pri routovani 6Mbit a obsluze cca 30 lidi zaraz.
0 x
Tak dnes jsem doladil moje provizorni reseni a mam v planu ho jeste vylepsit o par veci a nechat ho natrvalo, pokud se osvedci.
Zjistil jsem ze v ip/firewall/mangle funguje znackovani packetu jen s nekolika malo procentni uspesnosti co se tyka torrentu, ale vzdy to nejaky ten packet oznaci spravne. Vycházím z toho, pokud je nekolik packetu oznaceno jako torrent, je jisté ze ho daný uživatel používá a pravidlo v mangle mi danou ip zaradi do adreslistu s nazvem torrent. Adreslist je tvoren dynamicky a promazavaji se vzdy ty adresy, ktere jiz nemely po dobu 15 minut zadnou torrentovou aktivitu. Dále vytvorim ve firewallu pravidlo, ktere zakaze veskerý provoz na ip adresach v adreslistu s nazvem torrent. A aby uživatel vedel co se deje, tak pomoci NATu presmerovavam veskerý pokusy o komunikaci na portu 80 na webový server, kde je napsano co se deje a co maji udelat aby jim zase vse fungovalo jako driv.
Funguje to v praxi tak, ze uzivatel zapne torrent a firewall nejaky ten packet rozpozna a hodi ho do adreslistu, tim se mu zakaze jakoli komunikace. Uzivatel kdyz zjisti ze mu vse spadlo, tak stejne zkusi otevrit internetovy prohlizec, ale misto jeho oblibene domovské stranky, nebo jakekoli stranky se mu objevi mnou podstrceny web s tim co ma delat aby se vse vratilo do normalu. Tzn. ukoncit torrentoveho klienta a pockat 15 min nez vyprsi time out v adreslistu.
Takto to zatim funguje skvele, ale omezuje to i uživatele kteri s torrenty zachazeji s rozumem a neni je treba omezovat. To vyresim pridanim dalsi podminky a tou bude nejaky limit otevrenych spojeni za urcitou dobu. A pokud preleze urcitou mez, tak se teprve aplikuje pravidlo zakazu vseho a presmerovani na info web.
Zjistil jsem ze v ip/firewall/mangle funguje znackovani packetu jen s nekolika malo procentni uspesnosti co se tyka torrentu, ale vzdy to nejaky ten packet oznaci spravne. Vycházím z toho, pokud je nekolik packetu oznaceno jako torrent, je jisté ze ho daný uživatel používá a pravidlo v mangle mi danou ip zaradi do adreslistu s nazvem torrent. Adreslist je tvoren dynamicky a promazavaji se vzdy ty adresy, ktere jiz nemely po dobu 15 minut zadnou torrentovou aktivitu. Dále vytvorim ve firewallu pravidlo, ktere zakaze veskerý provoz na ip adresach v adreslistu s nazvem torrent. A aby uživatel vedel co se deje, tak pomoci NATu presmerovavam veskerý pokusy o komunikaci na portu 80 na webový server, kde je napsano co se deje a co maji udelat aby jim zase vse fungovalo jako driv.
Funguje to v praxi tak, ze uzivatel zapne torrent a firewall nejaky ten packet rozpozna a hodi ho do adreslistu, tim se mu zakaze jakoli komunikace. Uzivatel kdyz zjisti ze mu vse spadlo, tak stejne zkusi otevrit internetovy prohlizec, ale misto jeho oblibene domovské stranky, nebo jakekoli stranky se mu objevi mnou podstrceny web s tim co ma delat aby se vse vratilo do normalu. Tzn. ukoncit torrentoveho klienta a pockat 15 min nez vyprsi time out v adreslistu.
Takto to zatim funguje skvele, ale omezuje to i uživatele kteri s torrenty zachazeji s rozumem a neni je treba omezovat. To vyresim pridanim dalsi podminky a tou bude nejaky limit otevrenych spojeni za urcitou dobu. A pokud preleze urcitou mez, tak se teprve aplikuje pravidlo zakazu vseho a presmerovani na info web.
0 x
Hm, docela obdivuju zakazniky nekterych zdejsich prispevovatelu. Zakazat lidem jakykoliv p2p a to treba jen pres den, to si moc dobre neumim predstavit. Myslim, ze tak do jednoho mesice bych mel o 50% zakazniku mne...
To je jako byste zakazali rychla auta, protoze jejich bouracky maji fatalni nasledky...
I kdyz uznavam, ze torrent je velky problem. Obzvlast u lidi, kteri stahnou nejakyho klienta, nechaji vse v defaultu a jedou...
To je jako byste zakazali rychla auta, protoze jejich bouracky maji fatalni nasledky...
I kdyz uznavam, ze torrent je velky problem. Obzvlast u lidi, kteri stahnou nejakyho klienta, nechaji vse v defaultu a jedou...
0 x
Úplně se stotožnuji s Krabíkem. Už jenom to slovo "omezuji" se hodne lidem nelíbí a někdy hodně dlouho vysvětluji lidem, že pokud netahaji přes P2P, tak je omezení nikdy nestihne. Spousta ani neví co je p2p.
Já to mám nastaveno tak, že na hlavním routru omezuji max. počet spojení na 200 pro 1 IP (to už se tu řešilo několikrát jak na to) a na AP mám ve 2,4G nastaveny standartni porty, jež jsou pro odchozí provoz neomezeny a všechno ostatní řežu na nějakých cca 350kbit. Je to z důvodu zvyšování latence pri uploadu vetším jak 512Kbit na 2,4GHz.
Takže hlavní routr je výkonný stroj, který vpohodě zvládá ořezávat spojení a Firewall + Queue a RB si pak jenom lehce poradí s tím zbytkem, co na něj zůstalo.
Já to mám nastaveno tak, že na hlavním routru omezuji max. počet spojení na 200 pro 1 IP (to už se tu řešilo několikrát jak na to) a na AP mám ve 2,4G nastaveny standartni porty, jež jsou pro odchozí provoz neomezeny a všechno ostatní řežu na nějakých cca 350kbit. Je to z důvodu zvyšování latence pri uploadu vetším jak 512Kbit na 2,4GHz.
Takže hlavní routr je výkonný stroj, který vpohodě zvládá ořezávat spojení a Firewall + Queue a RB si pak jenom lehce poradí s tím zbytkem, co na něj zůstalo.
0 x
Krabík píše:Hm, docela obdivuju zakazniky nekterych zdejsich prispevovatelu. Zakazat lidem jakykoliv p2p a to treba jen pres den, to si moc dobre neumim predstavit. Myslim, ze tak do jednoho mesice bych mel o 50% zakazniku mne...
To je jako byste zakazali rychla auta, protoze jejich bouracky maji fatalni nasledky...
I kdyz uznavam, ze torrent je velky problem. Obzvlast u lidi, kteri stahnou nejakyho klienta, nechaji vse v defaultu a jedou...
ahoj.a máš teda nejaké rozumné riešenie ?
určite to viacerí uvítajú.ak áno,mohol by si to hodi do placu ?
vïaka.
0 x
Krabík píše:Misto RB jsem dal PC a poridil dostatecnou konektivitu
Ja používam všade iba PC,ale žia¾,ak by som chcel riadnu konektivitu,nemohol by som da net za 300.- SK s DPH.Pretože aj teraz to vychádza len tak.Ale malo by to tak by,ako píšeš.Hold,u nás sú tie ceny furt ove¾a vyššie,ako u vás.
Ahoj.A dík za odpoveï.
0 x