Dynamiczne ograniczanie pasma

Sposób na programy p2p i nie tylko.

GŁÓWNA STREFA ZRZUTU SZNURECZKI ARCHIWUM 

ZAŁOŻENIA

W naszej realnej rzeczywistości internetowej, przy tak marnych przepustowościach oferowanych nam przez ISP (patrz SDI :), jeden użytkownik korzystający z programu p2p lub choćby namiętnie ściągający coś z FTP lub WWW jest w stanie zapchać nam łącze do tego stopnia, że internet staje w miejscu. Postanowiłem coś z tym zrobić. Stworzyłem skrypt powłoki, który na podstawie zliczonego ruchu kieruje wybranych użytkowników przez interfejsy dławiące modułu shaper. Oczywiście zanim zostanie skierowany do takiego "dławika", jest szczegółowo rozpatrywane wiele czynników, ilość aktywnych hostów, zakres portów, z jakiego jest generowany największy ruch i kilka innych rzeczy.

OGRANICZENIA UŻYWALNOŚCI

Wady tego rozwiązania zamykają się generalnie w wadach użytego rozwiązania dławienia, czyli modułu shaper

  • Dławienie ruchu wychodzącego z serwera do poszczególnych hostów, czyli w przypadku "zaliczenia" shaper'a transfer z serwera plików też jest przycinany. Nowością w stosunku do poprzedniej wersji jest nie branie pod uwagę, przy liczeniu ruchu, zakresu portów netbios, czyli otoczenia sieciowego. W praktyce oznacza to, że user ściągający pliki z serwera samba nie zostanie zablokowany z tego powodu.
  • Utrata części pakietów podczas ograniczania i blokady (częściowe) oraz opóźnienia pingów przechodzących przez shaper'a. To niestety jest nie do uniknięcia, ale mając świadomość tego, że użytkownik, aby znaleźć się w "drodze przez mękę" musi naprawdę coś przeskrobać, utrata części pakietów (które i tak są retransmitowane) nie jest ogromnym problemem.
  • W dokumentacji jest mowa o maksymalnej i minimalnej przepustowości. Maksymalna to 256 kbit, jednak przekroczenie tej wartości nie powoduje żadnych komplikacji, po prostu shaper nie przepuści więcej, jeżeli ktoś się w nim znajdzie (a jeśli przepuści będzie to nieco "poszarpane"). Nie badałem tematu minimalnej przepustowości na własnej skórze
  • Praca tylko z jedną podsiecią (jeden interfejs sieci lokalnej). Może w przyszłości zostanie to rozwiązane.
  • Ograniczenie związane ze zliczaniem ruchu. W tej chwili i w obecnie przedstawionej tu wersji, skrypt ten posiada support dla statystyk MRTG jednak na obecną chwilę jeszcze w fazie testów.

INSTALACJA PAKIETU

Jeżeli stosować będziemy justice musimy usunąć paczkę z MRTG (tymczasowo) i/lub paczkę LAS. Instalujemy poprzez wydanie komendy
installpkg http://www.freesco.internetdsl.pl/plik/justice/justice33
Pakiet w wersji 3.3 można stosować także dla FreeSCO na dyskietce, jednak z problemem braku miejsca na nośniku trzeba sobie radzić we własnym zakresie.
Deinstalacja pakietu
removepkg justice
Jest też opracowana angielskojęzyczna wersja justice
installpkg http://www.freesco.internetdsl.pl/plik/justice/justice33e
Przy pomyślnym zakończeniu ściągania i rozpakowywania paczki, zostaniemy zapytani Czy chcesz skonfigurowac teraz adresy komputery ktore justice bedzie bral pod uwage ? Odpowiadając Y, w dalszej kolejności będziemy poproszeni o podanie adresów IP komputerów w sieci lokalnej, które będziemy brać pod uwagę przy liczeniu ruchu i ewentualnym ograniczaniu pasma. Adresy IP należy podawać w prostej formie (np. 192.168.0.5), i po każdym adresie potwierdzać <enter>. Jeżeli podamy już wszystkie, aby zakończyć wystarczy wcisnąć <enter> bez wpisu. Z tych IPków stworzony zostanie plik justice.hst, którym posługiwał się będzie sam skrypt główny jak i skrypt startowy. Jeżeli etap tworzenia listy adresów zostanie pominięty, do działania justice będzie trzeba ręcznie takowy plik stworzyć. No, ale zakładamy, że instalacja i tworzenie justice.hst zakończyło się pomyślnie.

WERSJA  dla FreeSCO 0.3.x

W związku z ogromnymi zmianami nowych wersji FreeSCO od 0.3.0 wzwyż (czy na lepsze ? kwestia do dyskusji), konieczne było stworzenie specjalnej wersji pakietu justice. Sama zasada działania nie zmieniła się, budowa pliku skryptu głównego, została dostosowana do nowego drzewa katalogów. Generalnie od nowa przebudowany został plik rc_justice oraz utworzony od nowa skrypt instalacyjny. Wykorzystałem także przekompilowany moduł shaper.o, pod jądrem 2.0.39. Niestety zmiany w nowszych wersjach FreeSCO są dla mnie na razie trochę zbyt małe, a stopień komplikacji i zagmatwania znacząco większy, tak więc używam starej, sprawdzonej wersji 0.2.7, z podmienionym kernel'em. dlatego też justice dla 0.3.x będzie wieczną betą, jako że nie mam gdzie tego testować, ani używać. Przystosowanie pakietu odbyło się z ogromną pomocą osobnika ukrywającego się pod nickiem MAC!EK, który na własnym routerze testował i zgłaszał uwagi oraz poprawki. Oczywiście do Niego też należała inicjatywa, samemu trudno by mi się było do tego wziąść. Instalacja pakietu z adresu:
pkg -i http://www.freesco.internetdsl.pl/plik/justice/justice33a
Konfiguracja tak jak pozostałe wersje, z tym że nie wykrywa automatycznie łącza SDI, chociaż domyślne wartości są ustawione właśnie pod kątem SDI. Deinstalacja standartowa dla FreeSCO 0.3.x.

PODSTAWOWA KONFIGURACJA

Konfiguracja odbywa się poprzez edycję pliku justice, który znajdować się będzie w /mnt/router/packages/justice. Pierwsza i najważniejsza sprawa to szybkość naszego łącza ze światem. Jeżeli posiadamy wynalazek SDI, rc_zjustice (czyli skrypt startu) sam dobierze sobie prędkość łącza. W przypadku posiadania NEO+ lub DSL, czy też innego ISP wykorzystującego FreeSCO w trybie "ethernet router", będziemy musieli edytować parametr $spdinet, w  rc_zjustice, który znajdziemy w /mnt/router/rc/rcuser. Domyślnie jest on zadeklarowany na prędkość 512000, i jeżeli wasze łącze ma inną prędkość to tutaj należy określić jego prędkość do podziału. To samo dotyczy konfiguracji prędkości łącza w pliku głównym skryptu, zmienna do ustawienia prędkości to też $spdinet, domyślnie ustawiona jest na prędkość SDI, czyli 115200. Oprócz tego, do ważnej podstawowej konfiguracji należy zastanowienie się nad zmienną $maxtran. Do czego ona służy ? Jest ona podstawową maksymalną wartością progową, i stanowi najważniejsze kryterium do ograniczania. Dobierać ją należy eksperymentalnie, tak, aby nie była zbyt restrykcyjna ani zbyt łagodna dla użytkowników. Kolejnymi, już troszkę mniej ważnymi parametrami do konfiguracji, są ścieżki do plików strony kontrolnej i dziennej historii blokowania. Do czego służy witryna kontrolna ? Opis poniżej. Możemy jeszcze przed uruchomieniem justice dobrać sobie próg minimalnego transferu potrzebnego do zaliczenia danego komputera do aktywnych, i uczestnictwa w wyliczaniu prędkości i progów. Domyślnie wartość $prg jest ustawiona na 0, czyli jeżeli transfer do hosta jest większy od zera to jest on aktywny. Prywatnie powiem, że ja mam tą wartość zadaną na 1000. Aby ruch np. Gadu-Gadu nie powodował traktowania danego komputera jako aktywnego. Ale to jest indywidualna sprawa każdego z Was.

JADZIEM !

Po skonfigurowaniu wystarczy wpisać
rc_zjustice start
Jeżeli wszystko jest dobrze skonfigurowane, po instalacji i uruchomieniu (lub restarcie) możemy wstukać na konsoli
ifconfig
Co powinno pokazać nam nowe interfejsy sieciowe od shaper0 do shapern gdzie n jest liczbą komputerów zadeklarowanych w justice.hst (o jeden mniejszą jako że liczymy od zera...). Testowanie czynię u mnie poprzez włączenie download'u jakiegoś większego pliku przy aktywnej liczbie kilku użytkowników sieci, i po minucie patrząc na wykres, np. programu DUmeter widzę obniżenie średniej prędkości ściągania. Zaglądam sobie teraz na witrynkę kontrolną http://adres_serwera/justice/justice.htm i mój IPek jest ładniutki czerwony oraz w pliku historii ładnie pisze o zablokowaniu mojego komputera ze względu na przekroczony transfer. Co do samego skryptu, to często przy jakiś przeróbkach lub korektach zdarzają się tzw literówki. Aby przetestować skrypt pod tym kątem uruchamiamy go po prostu z konsoli (nie w tle jak poleceniem fork). W razie popełnienia jakiegoś błędu zostaniemy poinformowani przez powłokę gdzie (linijka) został znaleziony błąd składni.

FILOZOFIA DZIAŁANIA, krótka piłka

Zrobiłem mały schemat blokowy zasad ograniczania, który możecie zobaczyć tutaj waży niestety ok 110Kb

Zakładam, że mamy za sobą opracowanie dotyczące samego modułu shaper'a i wiemy z grubsza jak działa (zasada). Aby wyłuskać osoby (komputery), które blokują nam sieć ściągając duże pliki, lub wiele małych, będziemy zliczać ruch wychodzący z serwera do konkretnych hostów. Zakres liczenia ruchu w obecnej wersji został rozbity na trzy zakresy portów TCP, zakres niski (lowports), który obejmuje porty 1-79, zakres portów średnich (80-136) czyli midports, oraz zakres wysoki (upports) na portach 140:65535. Dodatkowo w tym podziale jak widać pominięte zostały porty używane przez netbios (137:139), czyli w naszym przypadku otoczenie sieciowe na komputerach z windows. Oznacza to, że ruch z serwera plików samba, nie będzie zliczany jako podstawa do ograniczania użytkowników. Niestety jednak, jeżeli użytkownik przekroczy kryteria transferu z internetu, manewry z plikami na serwerze samba też będą utrudnione. Co chciałem osiągnąć przez podział na zakresy portów ? Otóż w ten sposób można uzależnić kryteria ograniczania od używanych usług. Jak wiadomo wysoki zakres TCP używany jest przez większość programów p2p, co umożliwia bardziej restrykcyjne traktowanie ruchu w tym zakresie. I to ma miejsce, jak wynika ze schematu blokowego. Wartość transferu progowego w przypadku tego zakresu obniżana jest o jedną czwartą, tak jak sama też prędkość shaper’a. Rozstrzygnięcie, jakie porty przeważają w ruchu do danego hosta, jest dokonywane za pomocą porównania ilości bajtów transmitowanych. Dla środkowego zakresu portów, w którym zamyka się ruch http, podwyższony jest do 125 % próg graniczny maksymalny. Więc znacznie trudniej zostać przyblokowanym z powodu nadmiernego transferu z witryn internetowych, aczkolwiek przy naprawdę przesadzonej ilości danych jest dość prawdopodobne zaliczenie shaper'a. Niski zakres jest traktowany normalnie, czyli próg $maxtran, nie będzie ani obniżany, ani podwyższany. To samo dotyczy prędkości shaper’a. Reguły liczenia ustawi nam rc_zjustice przy starcie, na podstawie justice.hst. Będą one później zerowane co minutę w samym skrypcie sterującym. Suwerenność justice w zliczaniu ruchu jest głównym powodem konfliktu z programami MRTG (tymczasowo) czy LAS. W rc_zjustice ładują się też do systemu moduły shaper'a, które następnie są podczepiane pod interfejs sieci lokalnej oraz włączane przez ifconfig. Co minutę skrypt porównuje ilości danych przekazanych z serwera do adresów określonych w justice.hst, ze zmienną $exetran (pochodną z $maxtran w zależności od typu serwisu z którego korzysta host) i w przypadku jej przekroczenia, ruch do danego komputera zostaje skierowany poprzez interfejs dławiący shaper. Prędkość tegoż interfejsu też jest wyliczana co minutę na podstawie aktywności komputerów w sieci i jak wyżej zostało opisane na podstawie zakresu portów dominujących w ruchu. Ustalenie ilości aktywnych komputerów, to sprawdzenie czy jest przekroczona granica $prg bajtów do danego IP. Jeżeli jest, to takowy komputer jest aktywny dla skryptu, i bierze udział w podziale prędkości interfejsów dławiących. To pozwala dość sprawnie regulować ograniczanie, pod kątem ilości komputerów korzystających w danej chwili z internetu. Aby nie dopuścić do sytuacji, kiedy kilka komputerów naraz generuje w sumie duży ruch i zapycha łącze innym, ale osobno żaden nie przekracza $maxtran, funkcjonuje zmienna $maxsuma, wyliczana automatycznie jako 125% wartości $maxtran, co jest nowością w stosunku do poprzednich wersji (w wersji 2.3 była ręcznie konfigurowalna granica $maxsuma). Jest to granicą maksymalnego sumarycznego transferu wszystkich hostów. I jeżeli zostanie przekroczona, to zmienną $maxtran obniżymy (poprzez podzielenie sumy danych z danego cyklu przez liczbę aktywnych kompów) do takiego poziomu, że każdy będzie miał matematycznie wyliczone pasmo do ściągania. Wtedy najbardziej nadgorliwi „ściągacze” zostaną wychwyceni, i nawet jeżeli ktoś niewinny się znajdzie na „drodze przez mękę”, to w następnym cyklu się wydostanie, natomiast „ściągacze” będą w dalszym ciągu ograniczani. Jako że znacznie łatwiej dostać się do shaper’a niż z niego wydostać.
To byłby pokrótce mechanizm blokowania, ale teraz trzeba czasem kogoś przywrócić do "normalności". Do tego służy też zmienna wyliczana automatycznie w skrypcie, na podstawie prędkości shaper'a, i z założenia powinna wynosić połowę tego co jest w stanie zassać user w danym shaper'ze. Nazywa się to $mintran, i jest minimalną wartością transferu potrzebnego do odblokowania danego hosta (czyli realizacji ruchu internetowego bez ograniczeń). W przypadku aktywności tylko jednego komputera w sieci, przyjmuje wartość $maxtran. Czyli w momencie, kiedy zostanie jeden tylko użytkownik internetu, podciągamy tak wartość $mintran aby nawet po przyblokowaniu danego kompa natychmiast (w tym samym cyklu, minucie) został on odblokowany. Samo kierowanie ruchu przez interfejsy "wąskiego gardła" jest realizowane poprzez manipulację tablicą routingu, co w szczegółach opisuje opracowanie na temat samego modułu shaper’. Przedstawiłem z grubsza główne czynniki odpowiedzialne za włączanie i wyłączanie blokowania oraz regulację prędkości. Jeżeli ktoś chce się zagłębić w szczegóły to musi samodzielnie analizować skrypt, gdyż przy takim stopniu komplikacji, uznałem wnikanie za niepotrzebne. Można się też kierować opisami starszych wersji (linki poniżej), które zawierają szczegółowy rozkład na łopatki skryptu sterującego, z tym  że troszeczkę starszej wersji.

BAJERY

Od wersji 3.0 istnieje interfejs www, na którym na bieżąco możemy obserwować zachowanie się sieci i aktywności poszczególnych jej użytkowników, ich blokowanie oraz historię blokowania. Więc o ile aktywny jest serwer www na porcie 80, można przekonać się o tym co się dzieje w shaper'ze i justice wpisując adres http://adres_serwera/justice/justice.htm, gdzie adres serwera to adres serwera :). Ścieżka do plików witryny kontrolnej oraz nazwy plików z historią i kontrolą, a także jednostki ilości danych w ostatniej rubryce są konfigurowalne w sekcji konfiguracji pliku głównego justice.

FAQ - KILKA ODPOWIEDZI NA PYTANIA

Jak dobrać zmienną $maxtran ?

  • Poczekać na moment, kiedy nasz komputer będzie sam w sieci
  • Zapodać ściąganie jakiegoś większego pliku z szybkiego serwera
  • Obserwować na stronie testowej (http://adres_serwera/jusdbg.htm) parametr "Transfer", zapisywać sobie szczytowe wartości. To da nam realny transfer maksymalny naszego łącza, liczony przez justice
  • Dobrać $maxtran na poziomie 60-65% transferu maksymalnego. Zmienna $maxsuma będzie wartością 125% zmiennej $maxtran
  • Ewentualnie można też spróbować wyliczyć "matematycznie" $maxtran. Zakładając że łącze szeregowe na bajt danych zużywa średnio 10 bitów, należy pomnożyć $spdinet razy 6 (to będzie w okolicach maksymalnego transferu na minutę - 115200 * 6 = 691200 w bajtach), i zredukować to do około 67%. Czyli  691200 * 0,67 = 463104, na przykładzie SDI. To się tyczy łącza szeregowego, jak jest z DSL'ami, nie mam pojęcia. Rad będę jak to ktoś zbada na innych sposobach połączenia z inetem, i mnie oraz innych o tym powiadomi.

Co oznacza kolor czerwony, przy IP na stronie testowej ?

  • Oznacza skierowanie ruchu do danego hosta przez interfejs dławiący. Natomiast  pogrubienie adresu to zaliczona aktywność danego komputera.

Czy mogę sobie ustawić cykl 30-sekundowy ?

  • Tak, należy zmienić na sleep 30 2>>$wwwpacz$his; z 60
  • Dobrać właściwe $maxtran dla krótszego czasu.

Strona kontrolna justice wygląda jakby się załadowała tylko do połowy, nie widzę wszystkich IP

  • Do odświeżania użyj ctrl-F5

Na stronie kontrolnej justice same krzaki, chaos kompletny

  • Najprawdopodobniej twoje FreeSCO jest w trybie read-only. Receptę na to znajdziesz we FreeSCO INFO

Czy mogę używać razem z justice statycznego ograniczania osobnym shaperem, tak aby jeden z hostów miał na stałe przycięte pasmo ?

  • Oczywiście, tylko ten "ręcznie" załadowany shaper powinien mieć numerek wyższy niż te ładowane i obsługiwane przez justice.
  • Trzeba także odjąć z pasma dostępnego dla justice wartość "stałej" przepustowości dodatkowego shapera
  • Należy odpowiednio rekonfigurować zmienną $maxtran.
  • Nie należy uwzględniać tego IP w konfiguracji justice, co niestety spowoduje sytuację że w przypadku maksymalnego wykorzystania pasma przez hosta będącego jedynym w danej chwili w justice, IP ograniczane w indywidualnym shaperze dostanie tylko ochłapy. Może udoskonalę to następnej wersji.

 ZMIANY w wersji 3.3 w stosunku do wersji 3.2 

  • Zmienny próg mintran (odblokowywanie), zależny od wyliczonej prędkości shaper'a, co powinno wyeliminować efekt "migotania" ssaczy w większych sieciach (czyt. przy większej ilości komputerów).
  • Liczony transfer dzienny do konkretnego hosta (i na tym też działa testowane obecnie MRTG dla justice).
  • Poprawiona konfiguracja, w tym momencie konfigurowalne są oprócz maxtran także ścieżki dostępu do plików witryny kontrolnej i pliku tekstowego historii, nazwy tych plików (uwaga tutaj, zamiast justdbg.htm domyślnie jest justice.htm), jednostki w jakich będzie podawana wartość transferu dziennego, oraz minimalny próg zaliczenia danego kompa do aktywnych.
  • Poprawiono "log rotate", a właściwie w tej wersji jest tylko jeden, dzienny plik historii blokowania, który jest kasowany razem z licznikami dziennymi o północy.
  • Wyeliminowano osobną wersję dla FreeSCO dyskietkowego, wersja 3.3 może działać zarówno z twardym dyskiem jak i z dyskietką
  • Kilka poprawek mechanizmu wyliczania progów blokowania, już nie powinny się zdarzać ujemne wartości.

opis do wersji 3.2

Instalacja wersji justice 3.2
installpkg http://www.freesco.republika.pl/justice32
oraz installpkg http://radar.freesco.pl/plik/justice/justice32

ZMIANY w wersji 3.2 w stosunku do wersji 3.1

  • Pełny zakres portów branych pod uwagę przy liczeniu ruchu, czyli włącznie z pasywnym FTP i całą maskaradą. (1-79, 80-136, 140-65535, tylko bez NetBIOS'u) Oczywiście porty tylko TCP, jeżeli ktoś Mnie przekona to weźmiemy się też za UDP 
  • Zmiana lokalizacji strony przedstawiającej działanie justice, przerzucona do katalogu, aby w razie potrzeby można było zabezpieczyć hasłem. By ją zobaczyć należy wpisać teraz http://TWOJ_SERWER/justice/jusdbg.htm
  • Osobna wersja dla FreeSCO na dyskietce
  • Kosmetyczne zmiany samej strony kontrolnej
  • Poprawione kilka błędów

Instalacja wersji justice 3.1
installpkg http://www.freesco.republika.pl/justice31
oraz installpkg http://radar.freesco.pl/plik/justice/justice31

ZMIANY w wersji 3.1 w stosunku do wersji 3.0

  • Wersja 3.1 to poprawiona wersja 3.0, pod kątem wielu błędów technicznych, literówek itp. Brak zamian w sposobie działania czy konstrukcji skryptu

ZMIANY w wersji 3.0 w stosunku do wersji 2.3

  • Podział liczenia ruchu na trzy zakresy portów TCP (1-79, 80-136, 140-32768), ruch 137:139, nie brany pod uwagę (chodzi o nieliczenie transferu z lokalnego serwera plików samba)
  • W związku z powyższym osobne kryteria blokowania i prędkości shaper'a dla każdego zakresu portów TCP
  • Wyeliminowana została ręczna konfiguracja zmiennej $maxsuma, jest ona wyliczana automatycznie, natomiast zmienną $maxtran trzeba ustawić do własnych potrzeb jak w poprzedniej wersji.
  • Możliwość śledzenia na bieżąco pracy justice poprzez przeglądarkę internetową (warunek-> serwer lokalny www), pod adresem http://adres_serwera/jusdbg.htm, z automatycznym odświeżaniem co minutę.
  • Przebudowany gruntownie skrypt

opis do wersji 2.3

Instalacja wersji justice 2.3

installpkg http://www.freesco.republika.pl/justice23
oraz installpkg http://radar.freesco.pl/plik/justice/justice23

ZMIANY w wersji 2.3 w stosunku do starszych wersji 

  • Nie ma co opisywać, to były bardzo prymitywne skrypty, do konfiguracji na każdym serwerze bardzo żmudnej. Wykasowałem je z dysku i z pamięci :)

SŁOWO NA KONIEC

Rozwiązanie doskonale się sprawuje w mojej sieci (SDI i 6 kompów). Bardziej zawansowani użytkownicy na pewno będą w stanie dostosować skrypt do własnych oczekiwań. Prosiłbym też o UWAGI i OCENY powyższego opracowania problemu. Nawet te krytyczne. Jeżeli ktoś chciałby pomóc, lub podsunąć jakieś rozwiązanie to zapraszam. Zadowolony byłbym także gdyby ktoś posiadający więcej wiedzy ode Mnie usprawnił by owe mechanizmy i przedstawił szerokiemu ogółowi swoje pomysły. POTRZEBA MATKĄ POMYSŁÓW i ROZWIĄZAŃ. Zamierzam kontynuować ten projekt

PRZESTROGA

WSZYSTKICH ZMIAN W STOSUNKU DO ORYGINALNEJ KONFIGURACJI DOKONUJECIE NA WŁASNĄ ODPOWIEDZIALNOŚĆ !!! W RAZIE NIEPOWODZENIE UMYWAM RĘCE !!!

Z uwagi na problemy z kompatybilnością (znak końca linii), edycja plików DOS z poziomu linux'a i plików linux'a z poziomu DOS/Windows, niesie za sobą zagrożenie utraty funkcjonalności plików wykonywalnych !!!

PLIKOLOGIA

justice rc_zjustice sch1.jpg shaper.o insmod shapecfg readme.shaper readme.credits justice33.sh justice33.tgz 

PODZIĘKOWANIA

eMTi (Maciek)<- wersja EasyFreeSCO , v|rus<- kilka pomysłów i stronka testowa , Kipa (korzenie)

 

© 2002 - 2003 Robert R - Kopiowanie w całości lub części bez pozwolenia autora zabronione