- parametry łącz lokalnych w sieci należy wpisać do pliku konfiguracyjnego /etc/shaper/shaper.X.cfg - gdzie X to cyfra od 0-7 oznaczająca numer konfiguracji dla kolejnych, pracujących równolegle daemonów shaperd. W przypadku, gdy nie mamy zamiaru uruchamiać kilku shaper'ów - wystarczy używać cyfry 0 dla wszystkich plików konfiguracyjnych.
Przykładowy plik konfiguracyjny dla serwera z 1 interfejscem lokalnym eth0 o przepustowości 10Mbit i łączem internetowym ppp0 o maksymalnej przepustowości 115Kbit (SDI). Używam go dla SDI i normalnej dzierżawki (po zmianie parametrów dotyczących szybkości ;).timeout_ipchains_22=3600 timeout_ipchains_24=7200 timeout_iptables_24=432000 timeout_global=300 high_start_speed=yes even_division=no continuous_control=yes squid_support=no squid_port=8080 divide_upload=yes extended_queue=no nomasq=yes check_sum_of_bandwidth=yes class_type=cbq upload_class_type=cbq check_download_factor_cnt=5 check_upload_factor_cnt=5 remove_dead_class=yes jump_type=5 nop_factor=60 add_factor=80 speed_ext=bit delay_mesg=yes mask_mesg=yes debug=0 delay=10 write_delay=1 inter_int=ppp0;8000;92000;1000;60000;auto;1 local_int=eth0;10485760;192.168.0.0/16;192.168.1.0/24;2
Gdzie:- timeout_ipchains_22 - czas trzymania połączeń TCP na maskaradzie dla kerneli 2.2.x. Wartość ta jest wpisywana komendą ipchains -M -S. Po tym czasie wszystkie starsze, nieaktywne połączenia będą usuwane z tablicy maskarady.
- timeout_ipchains_24 - czas trzymania połączeń TCP na maskaradzie ipchains dla kerneli 2.4.x - standardowo - na nieprzerabianych kernelach - ten czas wynosi 7200 minut czyli 5 dni. W przypadku gdyby ktoś sobie przerobił źródła ip_conntrack tak aby zmniejszyć ten czas to tu należy podać taki sam czas. Podobno w kernelu 2.4.20 jest już dołączona łatka pozwalająca zmieniać ten czas w prosty sposób bez potrzeby rekompilowania kernela.
- timeout_iptables_24 - czas trzymania połączeń TCP na maskaradzie iptables dla kerneli 2.4.x - standardowo - na nieprzerabianych kernelach - ten czas wynosi 432000 sekund czyli 5 dni. W przypadku używania kerneli z przerobionym ip_conntrack i innym czasem należy tu podać prawdziwą wartość.
- high_start_speed - sposób przydzielania łącza przy pojawieniu się nowego numeru ip. Dla yes początkowa szybkość jest równą częścią szybkości łącza wynikłą z podziału szybkości przez ilość userów aktualnie z niego korzystających (np. dla SDI z 5 pracującymi userami = 100000/5 czyli 20000 (kbitów)). Dla no przydzielona szybkość jest minimalna (taka jak podana w parametrze lospeed w konfiguracji interfejsu internetowego).
- even_division - yes załącza podział łącza po równo niezależnie od jego wykorzystania.
- continuous_control - yes włącza ciągłą kontrolę transferów przez regułki QoS.
- squid_support - włączanie współpracy ze SQUID'em (działa tylko z iptables). Wymagane jest aby squid pracował na serwerze którego numer IP mieści się w zakresie podanym w local_int (pierwszy numer z maską) (czyli najprościej - squid może działać na tym samym serwerze na którym działa shaperd). Ponadto aby squid działał należy go załatać zgodnie z opisem na stronie http://sed.pl/~mrk/qos/. Klasy tworzone komendą tc a opisane w sekcji Użycie tworzy shaperd więc nie ma potrzeby robić z nimi czegokolwiek. Testowałem ze squid-2.4.STABLE7 i działa - z wersją squid-2.5.STABLE1, która jakoby już standardowo obsługuje TOS, shaperd nie chciał mi działać - nie stwierdziłem aby pole TOS było przez tego squida zmieniane (ale może to kwestia konfiguracji squida). Z informacji jakie dostałem od Marcina Siennickiego wynika, że tą samą łatką da się załatać wersję 2.5 i działa ona prawidłowo z shaperem. Nie testowałem tego.
- squid_port - numer portu na którym pracuje squid.
- divide_upload - yes włącza dzielenie łącza w kierunku wychodzącym do internetu.
- extended_queue - yes włącza kolejkowanie w ramach indywidualnych przydziałów użytkowników (tylko dla iptables).
- nomasq - yes wyłącza kontrolę aktualnych połączeń na maskaradzie. W przypadku wyłączenia, kontrola jest robiona na zasadzie obserwacji liczników odpowiednich regułek na firewall'u. Jeśli licznik jakiegoś numeru IP zwiększy się w czasie cyklu pracy o pewien próg (lospeed/4) to shaperd przydzieli dla niego widełki. Opcja przydatna dla tych, którzy nie używają maskarady lub posiadają przydzielone dodatkowe numery IP na lokalne interfejsy sieciowe (opcja w fazie testów!).
- check_sum_of_bandwidth - yes włącza kontrolę sumy wszystkich przydzielonych widełek. Shaperd pilnuje aby suma przydziałów nie była większa niż szybkość łącza (z wyjątkiem sytuacji gdy ustawimy za dużą wartość lospeed
- class_type - typ klasy zarządzający pasmem w kierunku download. Możliwe do wyboru klasy to: standardowa CBQ oraz HTB.
- upload_class_type - typ klasy zarządzający pasmem w kierunku upload. Możliwe do wyboru klasy to: standardowa CBQ oraz HTB.
- check_download_factor_cnt - licznik zmniejszajacy się co cykl jeśli jakiś użytkownik pobiera dane z szybkością większą niż przydzielone widełki. Gdy licznik osiągnie 0 - w logu pojawia się komunikat Can't control download bandwidth of IP i jeśli jest włączona opcja remove_dead_class=yes shaperd usuwa tą klasę i w kolejnym cyklu tworzy ją ponownie. W przypadku używania CBQ wartość tego parametru powinna być większa od 0 ponieważ klasy z CBQ są niedokładne i obliczanie współczynnika korekcyjnego może potrwać nawet kilka cykli. Dla HTB pojawienie się takiego komunikatu może oznaczać nieprawidowe działanie klasy HTB lub znakowania pakietów MARK na firewallu.
- check_upload_factor_cnt - licznik zmniejszajacy się co cykl jeśli jakiś użytkownik wysyła dane z szybkością większą niż przydzielone widełki. Gdy licznik osiągnie 0 - w logu pojawia się komunikat Can't control upload bandwidth of IP i jeśli jest włączona opcja remove_dead_class=yes shaperd usuwa tą klasę i w kolejnym cyklu tworzy ją ponownie. W przypadku używania CBQ wartość tego parametru powinna być większa od 0 ponieważ klasy z CBQ są niedokładne i obliczanie współczynnika korekcyjnego może potrwać nawet kilka cykli. Dla HTB pojawienie się takiego komunikatu może oznaczać nieprawidowe działanie klasy HTB lub znakowania pakietów MARK na firewallu.
- ceil_download - (Tylko dla HTB) procentowa wielkość pasma w kierunku pobierania jakie użytkownik może pożyczyć od innych użytkowników. Wartość 50 oznacza, że uzytkownik może pożyczyć od innych dodatkowo 50% dla swojego przydziału.
- ceil_upload - (Tylko dla HTB) procentowa wielkość pasma w kierunku wysyłania jakie użytkownik może pożyczyć od innych użytkowników. Wartość 50 oznacza, że uzytkownik może pożyczyć od innych dodatkowo 50% dla swojego przydziału.
- burst_download - (Tylko dla HTB) ilość danych możliwa do pobrania bez ograniczeń.
- burst_upload - (Tylko dla HTB) ilość danych możliwa do wysłania bez ograniczeń.
- remove_dead_class - yes włącza usuwanie klas, gdy shaperd nie może przy ich pomocy kontrolować szybkości. Usunięcie jakiejś klasy objawia się błędem w logu: Removing download class of IP. Jeśli taki komunikat pojawi się sporadycznie to można przeżyć ale jak pojawia się ciągle to znaczy, że problem jest nie w jednej uszkodzonej klasie a w systemie.
- speed_ext - jednostka szybkości (bit, Kbit lub Mbit). Pamiętaj o przeliczeniu wszystkich parametrów zawierających szybkość na nową jednostkę:
- inter_int
- local_int
- w pliku iplist.X również trzeba przeliczyć jeśli narzucone zostały indywidualne limity dla poszczególnych numerów IP
- jump_type - wielkość skoku przy zwiększaniu przydziałów. 0 - przydział reszty niewykorzystanego łącza (podzielonej na ilość userów, którym ma być zwiększony transfer). Wielkość większa od 0 jest mnożnikiem parametru lospeed czyli np 1 oznacza zwiększanie szybkości o lospeed a 2 - o 2*lospeed. Odradzam stosowanie 0 jako wyjątkowo przykre dla rozpędzonych userów - shaperd przy tej wielkości bardzo szarpie transferem.
- nop_factor - 1 współczynnik wykorzystania łącza. Wartość podajemy w procentach. Jeśli użytkownik będzie pracował z szybkością o ten faktor mniejszą od przydziału (domyślna wartość 50 procent) to wtedy widełki zostaną mu obcięte.
- add_factor - 2 współczynnik wykorzystania łącza. Wartość podajemy w procentach. Jeśli użytkownik będzie pracował z szybkością większą niż przyznany limit pomnożony przez ten faktor (domyślnie 75 procent) to widełki zostaną zwiększone. Jeśli szybkość utrzymuje się między nop_factor a add_factor to przydział nie jest zmieniany. te dwa współczynniki można wykorzystać do zwiększenia wykorzystania łącza. Jeśli ktoś ma o tym pojęcie i ma ochotę poeksperymentować to życzę miłej zabawy.
- debug - jak coś nie działa to można ustawić poziom śledzenia w logu (dostepne poziomy 0 - brak, 1, 2, 3, 4)
- debug_output - cel komunikatów o błędach wysyłanych z powłoki w trakcie uruchamiania komend systemowych. Domyślnie /dev/null - można wpisać zamiast tego nazwę pliku i po ustawieniu wartości debug większej niż 0 można zobaczyć jakie błędy wyrzucają komendy uruchamiane przez shapera.
- delay - czas oczekiwania między kolejnymi cyklami (minimum 10 sekund - przy większej ilości numerów IP może pojawić się potrzeba ustawienia dłuższego czasu.
- delay_mesg - no wyłącza pojawianie się w logu informacji typu: Delay parameter has too low amount for this number of IP's or possibility of server., Increasing delay to XX seconds. Dla wrażliwych na wpisy w logu.
- mask_mesg - no wyłącza pojawianie się w logu informacji typu Can't find mask for IP.
- write_delay - co ile cykli ma być generowany plik bitrate_user_sh.X.old, który zawiera listę numerów IP i spis aktualnie przydzielonych widełek (potrzebne jedynie do wizualizacji przy pomocy skryptu kto.php - przykład działania). Jeśli 0 to tworzenie plików z przydziałami zostanie wyłączone.
- inter_int - parametry zewnętrznych interfejsów (internetowych)
- ppp0 - nazwa interfejsu internetowego.
- 8000 - lospeed - minimalna gwarantowana szybkość pobierania.
- 92000 - hispeed - maksymalna możliwa szybkość pobierania.
- 1000 - upload_lospeed - minimalna gwarantowana szybkość wysyłania.
- 60000 - upload_hispeed - maksymalna możliwa szybkość wysyłania (upload) dla interfejsu. Jest to szybkość z jaką maksymalnie może pracować łącze w czasie wysyłania danych z sieci do internetu. Wartość 0 wyłącza całkowicie ograniczenie szybkości upload.
- auto - IP - Numer IP interfejsu. auto - włącza automatyczne pobieranie numeru IP z interfejsu.
- 1 - identyfikator klasy (starszy bajt) (dla każdego interfejsu musi być inny - najlepiej kolejny po 1).
- local_int - parametry lokalnych interfejsów
- eth0 - nazwa interfejsu lokalnego. Nie wpisuj tutaj interfejsu łączącego z internetem!
- 10485760 - szybkośc interfejsu w bitach/sek (10MBit=10*1024*1024 bit)
- 192.168.0.0/16 - numer ip serwera wraz z maską (w tym przypadku jest to maska sieci klasy C co powoduje, że wszystkie transfery od numerów ip pasujących do tej maski nie będą miały ograniczeń. Chodzi o to aby transfer lokalny z serwera bądź rutowany przez interfejsy od ludzi lokalnych w sieci nie był przycinany).
- 192.168.1.0/24 - numer ip docelowy z maską dla którego stosowany jest shaper (czyli maska podsieci stosowana na danym interfejsie - np eth0 może mieć 192.168.1.0/24 a eth1 192.168.2.0/24 - numery ip w podsieci to 192.168.2.0-255).
- 2 - identyfikator klasy (starszy bajt) (dla każdego interfejsu musi być inny - najlepiej kolejny po 1).
O co chodzi z tymi dwoma numerami IP? Jeśli masz w systemie tylko jeden interfejs lokalny to nie masz się co kłopotać. Ustawiasz pierwszy numer IP z maską /32 (np. 192.168.1.1/32) a drugi z maską jak dla interfejsu lokalnego (np. 192.168.1.1/24 co jest rónoznaczne z wpisem 192.168.1.0/24) i tyle. Wpis taki pozwala shaperowi stworzyć regułkę, która nie będzie ograniczała szybkości przy wystąpieniu transferów między tymi numerami IP. Czyli wszystko co będzie lecieć bezpośrednio z serwera (192.168.1.1) do któregoś z userów (192.168.1.0/24) będzie miało pełny transfer taki jak podana szybkość interfejsu lokalnego. W przypadku kilku lokalnych interfejsów musimy rozważyć, czy chcemy aby userzy łączący się między tymi interfejsami (czyli trasa prowadzi przez serwer) mieli ograniczony transfer czy pełną lokalną szybkość. Jeśli chcemy aby mieli pełną szybkość to pierwszy numer IP musi mieć taką maskę aby wszyscy userzy z wszystkich interfejsów lokalnych pasowali do tej maski. Czyli np dla interfejsów z numerami ip 192.168.1.0/24 i 192.168.2.0/24 możemy stworzyć źródłowy numer IP 192.168.0.0/16 który obejmie swoją maską wszystkie interfejsy. Jak ktoś tego nie zrozumie to polecam lekturę NET-3-HOWTO.
Przykładowy plik konfiguracyjny dla serwera z 2 interfejsami lokalnymi eth0 i eth1 o przepustowości 10Mbit i 100Mbit i stosując jednostkę szybkości Kbit. Łacze internetowe ppp0 od ISP o szybkości 930Kbit.
divide_upload=yes class_type=cbq upload_class_type=cbq jump_type=5 speed_ext=Kbit delay=10 write_delay=0 inter_int=ppp0;16;900;1;300;auto;1 local_int=eth0;10240;192.168.0.0/16;192.168.1.0/24;2 local_int=eth1;102400;192.168.0.0/16;192.168.2.0/24;3
Przykładowy plik konfiguracyjny dla serwera z 3 interfejsami lokalnymi eth1, eth2, ppp2 (łącze dzierżawione miedzy np dwoma budynkami) o przepustowości 10Mbit, 100Mbit i 768Kbit (dla tego interfejsu ograniczamy transfery również lokalne). Łącza internetowe ppp0 (SDI) i eth0 (DSL 0.5Mbit) (UWAGA! shaperd nie tworzy regułek na firewallu tak aby część userów pracowała przez jedno łącze a część przez drugie - zadbać o to należy w trakcie konfiguracji firewall'a.
divide_upload=yes class_type=cbq upload_class_type=cbq jump_type=5 speed_ext=Kbit debug=0 delay=10 write_delay=0 inter_int=eth0;8;440;1;100;auto;1 inter_int=ppp0;8;92;1;60;auto;2 local_int=eth1;10240;192.168.0.0/16;192.168.1.0/24;3 local_int=eth2;102400;192.168.0.0/16;192.168.2.0/24;4 local_int=ppp2;768;192.168.3.0/24;192.168.3.0/24;5
cd /usr/src/shaper makelub dla wersji starszych niż 2.2.2
gcc /usr/src/shaperd/shaperd.c -o /sbin/shaperd
192.168.1.2=eth0 ppp0 192.168.1.3=eth0 ppp0 192.168.1.4=eth0 ppp0 8000 16000 1000 16000 192.168.1.5=eth0 ppp0 192.168.2.2=eth1 ppp0 192.168.2.3=eth1 ppp0 192.168.2.4=eth1 ppp1 192.168.2.5=eth1 ppp1Wprowadziłem dodatkowo możliwość ustawiania indywidualnych limitów dla poszczególnych numerów IP. W powyższym przykładzie dla numeru IP 192.168.1.4 ustawiłem następujące widełki dla ściągania (download): 8000 (1KB - minimum gwarantowane) i 16000 (2KB - maksymalna możliwa przydzielona szybkość) oraz dla wysyłania (upload): 8000 (1KB - minimum gwarantowane) i 16000 (2KB - maksymalna możliwa do osiągnięcia prędkość wysyłania). Pamiętaj, że wartości te są podawane w jednostce szybkości takiej samej jak ustawiona jednostka w pliku shaper.cfg w parametrze speed_ext. W przypadku braku wpisów shaperd przyjmuje dla każdego numeru IP wartości ustawione globalnie w pliku shaper.X.cfg.
Istnieje możliwość wpisu numerów IP wraz z maskami. Przykład:
192.168.1.2=eth0 ppp0 192.168.1.3=eth0 ppp0 # numery 192.168.1.4 i 192.168.1.5 mają jeden wspólny przydział łącza 192.168.1.4/31=eth0 ppp0 192.168.2.2=eth1 ppp0 192.168.2.3=eth1 ppp0 192.168.2.4=eth1 ppp1 192.168.2.5=eth1 ppp1Co spowoduje, że numery IP od 192.168.1.4-192.168.1.5 będą traktowane jako jeden i otrzymają wspólnie widełki.
Inny przykład:
192.168.1.0/24=eth0 ppp0 192.168.2.0/24=eth1 ppp0Jest to podział między dwoma interfejsami. Przy włączonej opcji even_division=1 możemy zaczynać działalność providerską :)
- lospeed - minimalna gwarantowana szybkość. Nie może być większa (ale mniejsza może być) od wartości wyliczonej na podstawie tego prostego wzoru:
lospeed = hispeed / liczba_IP
gdzie:- hispeed - maksymalna szybkość z jaką można ściągać dane z łącza internetowego
- liczba_IP - maksymalna ilość numerów IP, które mogą pracować przez to łącze.
Proszę nie podawać bzdurnych wartości lospeed sugerując się nazwą "minimalna gwarantowana przepustowość". Jeśli mamy łącze SDI gdzie hispeed wynosi 92000 (jednostka bit) a userów do tej sieci jest podpiętych 10 to bezsensem jest dać każdemu lospeed równe 16000 (czyli transfer 2KB/sek) ponieważ gdy będzie na łączu pracowało 10 userów i każdy dostanie przydział 16000 to po prostym przemnożeniu wychodzi, że łącze powinno mieć szybkość ok 160Kbit! Skutek takiego ustawienia będzie taki, że część userów "załapie się" na przydział a część pomimo, że dostanie przydział to nigdy go nie wykorzysta (jeśli wogóle uda im się cokolwiek pociągnąć z internetu). Analogicznie liczymy upload_lospeed na podstawie upload_hispeed. - hispeed - należy podawać szybkość łącza nie deklarowaną przez provider'a lecz rzeczywistą, jaką udaje się uzyskać ciągnąc (lub wysyłając dla upload_hispeed) coś przez dłuższy czas przez to łącze. Inaczej dzielenie wirtualnej szybkości mija się z celem. Łącze SDI nie pracuje z szybkością 115kbit tylko 92kbit (w jedną stronę) więc wpisywanie większych wartości powoduje tylko tyle, że ktoś dostanie w sieci przydział szybkości, którego nigdy nie uda mu się osiągnąć. Po co więc kogoś oszukiwać. Ja dla SDI ustawiam dla parametru hispeed wartość 92000 a upload_hispeed wartość70000.
Jeśli nie znasz możliwości swojego łącza, ustaw na początek deklarowaną szybkość, zainstaluj (i skonfiguruj) program lstat do robienia statystyk a następnie obciąż maksymalnie łącze przez kilkadziesiąt minut (pociągnij coś dużego - najlepiej kilka dużych plików na raz) zapuszczając kilka (lub kilkanaście) pracujących równolegle wget na serwerze. Na statystykach zobaczysz ile poszło w tym czasie przez łącze.
Jeśli łącze nie pracuje równomiernie w ciągu doby (najczęściej jest tak jak się ma kupione łącze u jakiegoś nieuczciwego provider'a, który sprzedał w sumie więcej łącz niż sam posiada to trzeba sobie zrobić kilka konfiguracji shapera (dublujemy wszystkie pliki konfiguracyjne (shaper.X.cfg, ignore.X oraz iplist.X) z katalogu /etc/shaper i zmieniamy im cyferki w nazwach np. shaper.0.cfg - dla normalnej pracy łącza, shaper.1.cfg - gdy łącze pracuje beznadziejnie (w godzinach popołudniowych i w weekend? ;) (oczywiście shaper.1.cfg trzeba odpowiednio zmodyfikować dla beznadziejnej pracy łącza - np. obniżyć hispeed i lospeed :). Potem wrzucamy do crontab odpowiednie wpisy:00 00 * * * root /etc/init.d/shaperd stop;sleep 5;/sbin/shaperd -config=0 00 15 * * * root /etc/init.d/shaperd stop;sleep 5;/sbin/shaperd -config=1
Co spowoduje, że shaperd będzie używał konfiguracji 0 w godzinach od 00:00-15:00 a od 15:00-00:00 konfiguracji 1. - upload_hispeed - podobnie jak z hispeed - powinno się wpisać taką wartość z jaką szybkością da się przepchać dane przez łącze w kierunku od userów do internetu. W przypadku łącz synchronicznych wartość ta będzie równa hispeed a w przypadku łącz asynchronicznych może być również taka sama lecz w przypadku pchania danych z pełną szybkością można zauważyć spadek szybkości ściągania. Można więc sobie tą wartość ustawić na poziomie takim, na jakim nie zauważamy jeszcze wpływu szybkości wysyłania do szybkości pobierania. W przypadku łącz DSL wartość upload_speed jest dużo niższa niż hispeed i należy ustawić ją o kilka procent mniej niż deklarowana dla danego typu łącza szybkość upload (np. dla DSL 512/128 upload_speed można próbować ustawić na 110Kbit).
tc -s class show dev eth0możemy zobaczyć miedzy innymi klasę dla tego numeru IP (w przykładzie używana klasa HTB):
class htb 2:5 parent 2:1 prio 3 rate 214Kbit ceil 214Kbit burst 27391b cburst 1872b Sent 27025335 bytes 34960 pkts (dropped 0, overlimits 0) rate 21702bps 28pps lended: 0 borrowed: 0 giants: 0 injects: 0 tokens: 778767 ctokens: 15581A dla upload:
tc -s class show dev eth0zobaczymy coś takiego (w przykładzie używana klasa CBQ):
class cbq 1:5 parent 1:1 rate 14Kbit (bounded) prio 5 Sent 554775 bytes 4674 pkts (dropped 0, overlimits 0) borrowed 30 overactions 0 avgidle 379301 undertime 0Dodatkowe 4 podklasy do kolejkowania mają numery tworzone zgodnie z zasadą X:Y gdzie X to identyfikator klasy, Y = (4*(A+4))+PRIO
gdzie A - pozycja numeru IP w pliku iplist.X, PRIO - priorytet, możliwe są 4 priorytety: 100 (najwyższy), 101, 102 i 103 (najniższy - wpada do tej klasy cały ruch nieprzesłany przez klasy z wyższym priorytetem). Poniżej znajdują się regułki dla iptables dla jednego uzytkownika tworzone przy starcie shapera. Niestety - nie są tworzone odpowiednie regułki dla ipchains - i proszę mnie nie prosić o przykłady - jak bym wiedział jak to na ipchains zrobić to w shaperze by to było. Przykład:
# download # najwyzszy priorytet download - klasa 2:120 iptables -t mangle -A FORWARD -d 192.168.1.2 -m tos --tos 0x10 -j MARK --set-mark 2120 # sredni priorytet download - klasa 2:121 iptables -t mangle -A FORWARD -d 192.168.1.2 -m tos --tos 0x08 -j MARK --set-mark 2121 # niski priorytet download - 2:122 iptables -t mangle -A FORWARD -d 192.168.1.2 -m tos --tos 0x04 -j MARK --set-mark 2122 # Pozostały ruch z polem tos innym niż podane trafi do klasy 2:123.Teraz przykład skryptu do tworzenia regułek dla firewalla na podstawie wpisów w pliku /etc/shaper/queue_download_high.0, które ustawią odpowiednie TOS dla odpowiedniego ruchu. Analogicznie do tego przykładu należy sobie dorobić pętle dla pozostałych plików konfiguracyjnych.
#!/bin/sh extqueue=`grep extended_queue=yes /etc/shaper/shaper.0.cfg | wc -l` IFS=';' if [ $extqueue -eq 1 ];then grep -E -v "^#|^$" /etc/shaper/queue_download_high.0 | while read prot src sport dst dport do if [ "$prot" == "*" ];then prot="!icmp" fi if [ "$src" == "*" ];then src="0/0" fi if [ "$dst" == "*" ];then dst="0/0" fi if [ "$sport" == "*" ];then sport="0:65535" fi if [ "$dport" == "*" ];then dport="0:65535" fi if [ "$prot" != "icmp" ];then iptables -t mangle -I FORWARD -p $prot -s $src --sport $sport -d $dst --dport $dport -j TOS --set-tos 0x10 else iptables -t mangle -I FORWARD -p $prot -s $src -d $dst -j TOS --set-tos 0x10 fi done fiZnacznik (MARK) wyliczamy ze wzoru:
M = (1000 * X) + PRIO + (4 * (A + 4))gdzie: M - znacznik, X - identyfikator klasy (w tym przypadku 2 - dla local_int), A - pozycja numery IP w pliku iplist.X
Sprawdźmy teraz czy dobrze wyliczyliśmy. Po przeliczeniu tej liczby na system szesnastkowy dostajemy w wyniku liczbę 0x848. Piszemy:
tc -s filter show dev eth1 | grep 848i dostajemy w wyniku:
filter parent 2: protocol ip pref 10 fw handle 0x848 classid 2:120Czyli ruch zaznaczony przez tą regułkę trafi do klasy 2:120. Teraz możemy sobie obserwować ruch wpadający do tej klasy:
watch tc -s class show dev eth1i jeśli tylko połączymy się pod ssh lub telnetem z jakimś zewnętrznym serwerem to zobaczymy:
class htb 2:120 parent 2:5 leaf a688: prio 0 rate 273Kbit ceil 273Kbit burst 15Kb cburst 1948b Sent 10644 bytes 133 pkts (dropped 0, overlimits 0) rate 11bps lended: 133 borrowed: 0 giants: 0 injects: 0 tokens: 315623 ctokens: 39721I jak widać 10644 bajty przeszły przez klasę 2:120
Teraz stworzymy regułkę na firewallu dla ruchu wychodzącego:
# upload # najnizszy priorytet upload - klasa 1:123 iptables -t mangle -A FORWARD -s 192.168.1.2 -d ! 192.168.0.0/16 -j MARK --set-mark 1123 # najwyzszy priorytet upload - klasa 1:120 iptables -t mangle -A FORWARD -s 192.168.1.2 -d ! 192.168.0.0/16 -m tos --tos 0x10 -j MARK --set-mark 1120 # sredni priorytet upload - klasa 1:121 iptables -t mangle -A FORWARD -s 192.168.1.2 -d ! 192.168.0.0/16 -m tos --tos 0x08 -j MARK --set-mark 1121 # niski priorytet upload - klasa 1:122 iptables -t mangle -A FORWARD -s 192.168.1.2 -d ! 192.168.0.0/16 -m tos --tos 0x10 -j MARK --set-mark 1122Wzór do obliczenia znacznika jest identyczny jak powyżej - zwracam uwagę, że upload ograniczany jest na interfejsie internetowym a nie jak download na lokalnym więc w tym przypadku identyfikator klasy mamy taki jak dla inter_int czyli w tym przypadku 1. Teraz sprawdzamy:
tc -s filter show dev eth0 | grep 460i dostajemy w wyniku:
filter parent 1: protocol ip pref 10 fw handle 0x460 classid 1:120Czyli wszystko jest prawidłowo. Możemy teraz obserwować klasę 1:120:
watch tc -s class show dev eth0aby zobaczyć czy coś przez nią przechodzi. I widzimy:
class cbq 1:120 parent 1:5 leaf a69c: rate 18Kbit prio 3 Sent 12122 bytes 208 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 8.07342e+06 undertime 0Czyli jak widać, przez klasę przeszły 12122 bajty.
Teraz tworzymy regułki dla ruchu od serwera do internetu:
iptables -t mangle -A POSTROUTING -p tcp -s 213.97.124.129/32 --sport 22:23 -d 0/0 -j MARK --set-mark 1164 iptables -t mangle -A POSTROUTING -p udp -s 213.97.124.129/32 --sport 22:23 -d 0/0 -j MARK --set-mark 1164numer IP serwera znajduje się w pliku iplist.X na pozycji 12 (wpis w iplist.X: 213.97.124.129=eth0 eth0).
tc -s filter show dev eth0 | grep 48ci wynik:
filter parent 1: protocol ip pref 10 fw handle 0x48c classid 1:164I cały ruch wychodzący z serwera z portu 22 lub 23 będzie miał najwyższy priorytet.
Wszystkie przykłady bazują na iptables ponieważ nie posiadam systemu na ipchains i nie mam jak tego przetestować.
W archiwum shapera dołożonych zostało 12 dodatkowych plików, w tym 3, które są uzywane przez shapera przy tworzeniu regułek tylko w przypadku gdy używany jest firewall na iptables (queue_upload_serwer_high|med|low):
/etc/shaper/queue_download_default.X /etc/shaper/queue_download_high.X /etc/shaper/queue_download_med.X /etc/shaper/queue_download_low.X /etc/shaper/queue_upload_default.X /etc/shaper/queue_upload_high.X /etc/shaper/queue_upload_med.X /etc/shaper/queue_upload_low.X /etc/shaper/queue_upload_server_default.X /etc/shaper/queue_upload_server_high.X /etc/shaper/queue_upload_server_med.X /etc/shaper/queue_upload_server_low.XTrzy ostatnie pliki konfiguracyjne są używane przez shaperd do tworzenia regułek. Pozostałe 6 plików w chwili obecnej nie są używane przez shaperd i trzeba sobie napisać skrypt operujący na nich.
Jeśli komuś nic nie przechodzi przez klasy to proszę do mnie nie pisać - nie daję żadnych gwarancji, że będzie to działać na każdej dystrybucji i systemie. Jak komuś bardzo zależy aby to działało - to pofatyguję się do niego osobiście i mu zainstaluję taki system że będzie to działać - zgodnie z tym co napisałem w ofercie.
- Shaperd musi mieć wpisany taki sam numer portu jak squid.
- Należy ustawić w przeglądarce w miejscu konfiguracji PROXY aby nie używała PROXY do wczytywania lokalnych stron WWW. Jest to o tyle istotne, że jeśli się tego nie zrobi to shaperd będzie ograniczał (lub nie - w zależności od "trafień" squida) lokalne połączenia.
- Testowałem działanie shaperd wraz ze squid przy ustawionej na firewallu translacji DNAT z portu docelowego 80 na port squida (takie wymuszenie na chama - aby wszystkie połączenia www były przekierowane na proxy - tzw transparent proxy). I wygląda na to, że to działa.
- shaperd tworzy dla squida specjalne regułki na firewallu - przykład:
iptables -t mangle -vxL POSTROUTING -n | grep 8080
pokazuje regułki do znakowania pakietów (MARK)
oraziptables -vxL squid0 -n
pokazuje rzeczywisty transfer ze squida. - Jeśli nie wiesz czy twój squid prawidłowo zaznacza pole TOS to możesz to
sprawdzić wpisując:
iptables -vxL squid0 -n | grep -E -v "destination|squid" | awk '{print $9,"\t",$2}'Wynik prawidłowo działającego squida będzie wyglądał mniej więcej tak:192.168.1.3 135967 0.0.0.0/0 2074683 192.168.1.7 2432944 192.168.1.6 18121074
Oznacza to, że np user 192.168.1.3 ściągnął przez squida 135967 bajtów danych (nietrafionych czyli takich - które trzeba było ściągać z internetu i zrobione to zostało w ramach przydziału tego usera). Wpis 0.0.0.0/0 oznacza, że 2074683 zostało przesłanych w sumie do wszystkich userów, były to dane trafione (z cache) i nie było na nie nałożonego ograniczenia.
Jeśli tylko licznik obok 0.0.0.0/0 rejestruje ruch a liczniki użytkowników już nie to znaczy, że squid nie znakuje prawidłowo TOS - wtedy cały ruch ze squida jest puszczony bez ograniczeń.
modprobe sch_cbq modprobe sch_tbf modprobe cls_u32Dla HTB trzeba załadować następujące moduły:
modprobe sch_htb modprobe sch_sfq modprobe cls_u32
217.96.55.5 411 - numer ip i port 411
213.180.130.190 - numer ip i kazdy port
22$ - każdy numer ip i port 22 (telnet)
Zrobione jest to po to, żeby skrypt nie rezerwował łącza na transmisje nie generujące praktycznie ruchu (np. GaduGadu, IRC, telnet, Chaty itp). Należy pamiętać aby każdy numer IP kończył się znakiem spacji. Proszę nie wstawiać pustych linii w tym pliku oraz nie edytować go pod systemem Windows (problem z CR+LF).
Aktualną listę branych pod uwagę przy podziale numerów ip i portów na maskaradzie (czyli po wyeliminowaniu połączeń z pliku /etc/shaper/ignore.X) można podglądnąć pisząc:
/sbin/shaperd shownatW dostarczonym przykładowym pliku są zrobione wpisy dla popularnych komunikatorów np. GaduGady, Tlen oraz dla kilku czatów i MUD'ów.
- bitrate_user_sh.X.old - zawiera numery ip oraz przydzielone widełki dla download.
- bitrate_user_up.X.old - zawiera numery ip oraz przydzielone widełki dla upload. Można to wykorzystać do wizualizacji na stronie www - przykład użycia. Zawartość tych plików może wyglądać mniej-więcej tak:
192.168.1.2/32 40000 192.168.1.9/32 58000lub gdy speed_ext jest ustawiony inny niż bit (w tym przypadku Kbit):
192.168.1.2/32 40 Kbit 192.168.1.9/32 58 Kbit
tc -s qdisc show dev eth1gdzie: eth1 to nazwa interfejsu lokalnego jeśli sprawdzamy dzielenie download
Jeśli używasz HTB zamiast CBQ to sprawdzaj komendą:
tc -s class show dev eth1Wyniki jej działania mogą wyglądać tak:
qdisc tbf d09f: dev eth0 rate 5430bps burst 10Kb lat 1.2s
Sent 108930 bytes 73 pkts (dropped 0, overlimits 0)
qdisc tbf d09e: dev eth0 rate 5430bps burst 10Kb lat 1.2s
Sent 126618 bytes 89 pkts (dropped 0, overlimits 0)
qdisc tbf d09d: dev eth0 rate 1638bps burst 10Kb lat 3.8s
Sent 54699 bytes 65 pkts (dropped 0, overlimits 321)
backlog 6110b 5p
qdisc tbf d09c: dev eth0 rate 10Mbit burst 10Kb lat 4.8ms
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc tbf d09b: dev eth0 rate 10Mbit burst 10Kb lat 4.8ms
Sent 5690 bytes 53 pkts (dropped 0, overlimits 0)
qdisc cbq 10: dev eth0 rate 10Mbit (bounded,isolated) prio no-transmit
Sent 310829 bytes 302 pkts (dropped 0, overlimits 1555)
backlog 5p
borrowed 0 overactions 0 avgidle 624 undertime 0
Nalezy zwrócić szczególną uwagę na linie z rate innym niż 10Mbit (lub innym w przypadku posiadania łącza lokalnego o innej szybkości maksymalnej). W tym przypadku trzy pierwsze klasy obrazują transfery trzech różnych komputerów w sieci lokalnej. Należy zwrócić uwagę, czy rejestrowane są wielkości wysłanych danych Sent. Jeśli tak to znaczy, że CBQ działa i obcina transfer przekraczający widełki.
Statystyki wygenerowano programem lstat 2.2
Ponieważ część z Was zanudza mnie mailami z prośbą o pomoc w konfiguracji programu lstat do współpracy z shaperd to poniżej postaram się wyjaśnić jak to zrobić.
- Zakładamy nowy wykres Statystyki Pakietów i jakoś go tam nazywamy (dla identyfikacji). Właściwie to domyślna konfiguracja jest wystarczająca do współpracy z shaperd więc nie zmieniamy w ustawieniach wykresu niczego.
- Pod wykresem klikamy na przycisk Nowy element i w tabelce, która pojawi się poniżej wpisujemy w pozycji Filtr danych nazwę filtru dla lokalnego usera oraz jego nazwę. Nazwę filtru dla transferów przychodzących (download) znajdujemy wpisując:
/usr/local/lstat/bin/show_filters | grep shaper | awk '{print $1,$11}'a dla wychodzących (upload):/usr/local/lstat/bin/show_filters | grep shaout | awk '{print $1,$10}'Dostaniemy listę z nazwami filtrów po lewej stronie i numerami ip im odpowiadającymi Kolejność jest taka sama jak wpisy w pliku iplist dlatego lepiej potem nie przestawiać linijek w iplist.
Zakładamy osobne wykresy dla download i upload (z tego co zauważyłem to można maksymalnie 10 userów na jeden wykres wpisać a potem trzeba tworzyć kolejne wykresy) i to jest cała filozofia. Mam nadzieję, że mi wreszcie dacie spokój z lstat'em.
- Wersja shaper'a
- Opis systemu na serwerze (dystrybucja, wersja kernela, inne uwagi)
- swój e-mail kontaktowy (możesz go zakończyć jakimś "ściemniaczem anyspamowym" ;) typu .NOSPAM)
- url strony www (jesli isnieje) serwera
<p><a href="http://sp9wun.republika.pl/"> <img src="http://sp9wun.republika.pl/linux/pics/shaper.png" border="0" width="89" height="32" alt="Powered by Shaper CBQ"></a></p>
