ARCHIWUM

Dynamiczne ograniczanie pasma

Sposób na programy p2p i nie tylko.

GŁÓWNA STREFA ZRZUTU SZNURECZKI KONTAKT 

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 jest w konflikcie z programami MRTG i LAS. Nie możliwe jest skuteczne stosowanie wszystkich tych rzeczy na raz. Należy dokonać więc wyboru, albo kombinujemy z tym skryptem, albo używamy statystyk. Wiem że ten problem da się rozwiązać i pewnie prędzej czy później zostaną pogodzone te rzeczy, jednak w tej chwili skupiam swą uwagę na doskonaleniu skryptu.

INSTALACJA PAKIETU

Jeżeli stosować będziemy justice musimy usunąć paczkę z MRTG i/lub paczkę LAS. Instalujemy poprzez wydanie komendy
installpkg http://www.freesco.republika.pl/justice3
lub installpkg http://radar.freesco.pl/plik/justice3/justice3
wersja dla FreeSCO na dyskietce
installpkg http://radar.freesco.pl/plik/justice3/justice3fdd

Deinstalacja pakietu
removepkg justice
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. Jeżeli jesteś posiadaczem łącza w świat z TPSA o magicznej nazwie SDI to do uruchomienia wystarczy wpisać
rc_zjustice start
Lub zresetować router/serwer. Skrypt jest w tej wersji gotowy do działania dla SDI. W przypadku posiadania NEO+ lub DSL, czy też innego łącza stałego wykorzystującego FreeSCO w trybie "ethernet router", będziemy musieli ustawić parametr spdinet, w skrypcie startowym rc_zjustice, który znajdziemy w /mnt/router/rc/rcuser. Domyślnie jest on zadeklarowany na prędkość 128000, i jeżeli wasze łącze jest szybsze to tutaj należy określić jego prędkość do podziału. W przypadku SDI rc_zjustice sam dobierze prędkość. Takie samo działanie trzeba będzie jeszcze pojąć w pliku justice, który po instalacji znajdować się będzie w /mnt/router/packages/justice. Tym razem, w pliku skryptu głównego, zmienna będzie się nazywać $speed i domyślnie ustawiona jest na prędkość SDI, czyli 115200. Oprócz tego, do 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. Jeżeli mamy mniej więcej wszystko zainstalowane i wstępnie 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...). Innym dowodem na działanie justice  jest plik j.log, który zostanie utworzony automagicznie w katalogu /mnt/router/packages/justice w momencie odpalenia justice. Testowanie u mnie czynię 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 do pliku j.log i ładnie pisze o zablokowaniu mojego komputera ze względu na przekroczony transfer. Co do samego skryptu, to często 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.

ZMIANY W STOSUNKU DO POPRZEDNIEJ WERSJI

  • pełny zakres portów branych pod uwagę przy liczeniu ruchu, czyli włącznie z pasywnym FTP i całą maskaradą. 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 jusdbg.htm
  • poprawione kilka błędów

FILOZOFIA DZIAŁANIA, krótka piłka

Zrobiłem mały schemat blokowy zasady blokowania, 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 ograniczenie. 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 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 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 przez interfejs dławiący shaper. Prędkość tegoż interfejsu 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 1000 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 porzednich wersji. Jest ona 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 mechanizm blokowania, ale teraz trzeba czasem kogoś przywrócić do "normalności". Do tego służy też zmienna wyliczana automatycznie w skrypcie, poprzez podzielenie $maxtran przez trzy. 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 interfejscy "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

BAJERY

Dołożony został interfejs www, na którym na bieżąco możemy obserwować zachowanie się sieci i aktywności poszczególnych jej użytkowników. Więc o ile aktywny jest serwer www na porcie 80, można przekonać się o tym co się dzieje w shaperze wpisując adres http://adres_serwera/justice/jusdbg.htm, gdzie adres serwera to adres serwera :)

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-70% transferu maksymalnego. Zmienna $maxsuma będzie wartością 125% zmiennej $maxtran

Co oznacza kolor czerwony, przy IP na stronie testowej ?

  • Oznacza aktywność danego hosta, a nie fakt jego blokowania

Czy mogę sobie ustawić cykl 30-sekundowy ?

  • Tak, należy zmienić na sleep 30 2>>/mnt/router/packages/justice/j.log; z 60
  • Dobrać właściwe $maxtran dla krótszego czasu.

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 justice3.sh justice3.tgz 

PODZIĘKOWANIA

eMTi (Maciek), v|rus (jusdbg to  jego robota :), Kipa (korzenie)

STARE CZASY

opis do wersji 2.3

 

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