Sprawa konfiguracji downloadu jest tu banalna i można by tu nawet zrezygnować z dynamicznego podziału,
użyć czystego htb i sprzedawać klientom konkretne przepustowości.
Jednak o upload trzeba szczególnie zadbać gdyż od niego będzie zależało czy klienci
uzyskają zakupione przez siebie pasmo.
Oto konfiguracja a poniżej komentarz:
<global>
run ul
mark-on-ifaces eth0
stats unit kb/s
</>
<ul>
iface eth0 match srcip 192.168.0.0/24
iface eth0 match srcip 192.168.1.0/24
section speed 512kb/s
section shape 400kb/s
default low 40kb/s
default ceil 128kb/s
default htb scheduler sfq
default reload 3s
iptables hook PREROUTING
</ul>
Sekcja global jest wymagana i tutaj mówi które z kolejnych skonfigurowanych sekcji należy uruchomić a można ich mieć kilka, i dla wygody przez jeden parametr określać które w danym momencie mają zostać uruchomione.
mark-on-ifaces eth0
włącza filtr fw czyli w skrócie markowanie pakietów na podanym interfejsie ( nie jest to poprawne określenie ale dobrze oddaje idee ), opcja ta jest wymagana gdy podsieć jest natowana.
Tworzymy przykładową sekcje dla uploadu nazwijmy ją ul, która to nazwa jest w przeciwieństwie do starej wersji programu całkowicie dowolna i równie dobrze może się nazywać upload, sekcja1 czy przewrotnie download;)
Dyrektywa iface ma za zadanie wskazać co dana sekcja ma obsługiwać, w naszym przypadku wszystko wychodzące do internetu z podsieci 192.168.0.0/24 oraz 192.168.1.0/24 i pojawiające się na interfejsie wyjściowym eth0
Dalej określamy przepustowość pasma wychodzącego
przyporządkowanego konfigurowanej sekcji, oraz poziom na którym oczekujemy utrzymywać jego wykorzystanie
section speed 512kb/s shape 400kb/s
Wartość shape przy dobrej jakości łączu musi być bezwzględnie!! kilkanaście procent niższa od speed
Zbyt wysoka wartość zwiększy ryzyko zwiększenia pingów na łącza aż do całkowitego niedziałania podziału w ekstremalnej sytuacji.
Dyrektywa default określa domyślne wartości podanych parametrów dla klas którym nie przypisano "indywidualnych" warunków pracy.
Po opis każdego z powyższych parametrów odsyłam do dokumentacji.
<dl>
iface eth1 match dstip 192.168.0.0/24
iface eth2 match dstip 192.168.1.0/24
section speed 4096kb/s
section shape 36000kb/s
default low 64kb/s
default ceil 2000kb/s
default htb scheduler sfq
iptables hook POSTROUTING
reload 3s
</dl>
By urozmaicić przykład przyjmujemy że nasza sieć jest podzielona na 2 podsieci obsługiwane przez niezależne karty sieciowe.
Odmiennie w sytuacji gdy obydwie podsieci współdzielą jedną kartę mamy:
iface eth1 match dstip 192.168.0.0/24
iface eth1 match dstip 192.168.1.0/24
lub jeszcze wygodniej:
iface eth1 match dstip 192.168.0.0/23
Pozostałe parametry zostały opisane wcześniej a ich ustawienia dokonujemy kierując się konsekwentnie tymi samymi zasadami.
Samą klasę zdefiniował bym jako wycinek ruchu traktowany w określony sposób, widziany jako jedna całośc wydzielona za pomocą filtrów wskazujących hosty, porty, podsieci czy też inne pakiety oznaczone przez inne kryteria.
Przykładowe dwie konstrukcje:
class dl eth1 przykladowa1
match srcip 212.77.100.101
dstip 192.168.0.10
class dl eth1 przykladowa2
match srcip 212.77.100.101
match dstip 192.168.0.10
Czym się one różnią?
Do pierwszej klasy zostaną zakwalifikowane pakiety pochodzące z adresu 212.77.100.101 i jednocześnie skierowanego do
hosta lokalnego 192.168.0.10.
Do drugiej pakiety pochodzące z adresu 212.77.100.101 oraz pakiety skierowane do 192.168.0.10
jednak filtry te są niezależne od siebie, więc dana klasa będzie obsługiwać wszystko co otrzymujemy z pierwszego adresu bez
znaczenia co do adresu docelowego oraz wszystko to co zmierza do drugiego adresu bez względu na pochodzenie.
W skrócie w pierwszym przypadku obydwa parametry muszą zostać spełnione jednocześnie a w drugim którykolwiek z podanych dwóch.
Pamiętać należy że każdy pakiet testowany jest przez kolejno zdefiniowane filtry i nieodwołalnie wpada do pierwszego który jest spełniony, stąd w wielu przypadkach kolejność definiowania klas ma kluczowe znaczenie.
class dl eth1 Krzysiek
match dstip 192.168.0.10
class dl eth1 Janek
match dstip 192.168.0.11
class dl eth1 dwa_Komputery_Oli
match dstip 192.168.0.12
match dstip 192.168.0.13
class ul eth0 Janek
match srcip 192.168.0.11
class ul eth0 dwa_Komputery_Oli
match srcip 192.168.0.12
match srcip 192.168.0.13
Co trzeba zauważyć każda klasa zostaje przyporządkowana wyłącznie jednej sekcji a pozostałe nie wiedzą o jej istnieniu, fakt że klasy zostaną ze sobą wymieszane w ramach pliku konfiguracyjnego nie ma żadnego znaczenia, dla każdej sekcji ważna jest kolejność klas własnych pozostałe nie istnieją.