Wprowadzenie do NiceShapera za pomocą przykładów
Przykład #1: Wystarczający download, bardzo mały i przeciążony upload.
W przykładzie dysponujemy asymetrycznym łączem o dużej przepustowości downloadu, niech to będzie 16mb/s z bardzo wąskim pasmem wychodzącym o przepustowości np. 512kb/s, które przeciążone jest do granic możliwości.
Sprawa konfiguracji downloadu jest tu banalna, przy małej liczbie hostów można nawet rozważyć rezygnację z dynamicznego podziału.
Jednak o upload trzeba szczególnie zadbać, gdyż od niego zależało będzie czy klienci będą mogli skutecznie wysycić zakupione przez siebie pasma.
Oto pierwsza konfiguracja i poniżej komentarz:
<global>
- run ul
- mark-on-ifaces eth0
<ul>
- match srcip 192.168.0.0/23
- section speed 500kb/s
- section shape 400kb/s
- low 40kb/s
- ceil 256kb/s
- reload 2s
- mode upload
Sekcja global jest wymagana i tutaj umieszczony w niej parametr run mówi, które ze skonfigurowanych sekcji należy uruchomić. Można ich mieć dowolną liczbę, najczęściej jednak wystarczą dwie.
Pierwszy ważny parametr:
Zastępuje on w przestrzeni HTB domyślne filtry typu u32 filtrami typu fw, i ma on wpływ na wszystkie klasy kontrolowane na podanym interfejsie. Jednocześnie do regułek iptables dodawane są cele MARK --set-mark. Wszystkie niezbędne operacje na każdym etapie działania wykonywane są automatyczne przez NiceShapera.
Filtr typu fw to filtr przyporządkowujący pakiety do klas HTB, na podstawie przypisanego przez reguły iptables wirtualnego znacznika. Wirtualnego gdyż znacznik ten istnieje wyłącznie w przestrzeni jądra Systemu Operacyjnego i po opuszczeniu przez pakiet routera znacznik ten znika bezpowrotnie. Dzieje się tak dlatego że znacznik nie jest zapisywany w samym pakiecie -bo jest to niemożliwe- lecz w pamięci operacyjnej.
Opcja ta jest niezbędna chociażby wtedy gdy podsieć używająca adresów prywatnych IPv4 jest maskowana do adresu routera. Pakiety opuszczające interfejs WAN routera, mając zmienione adresy źródłowe, bez tego zabiegu były by już niemożliwe do przyporządkowania do konkretnych klas operujących na adresach źródłowych.
Tworzymy przykładową sekcje dla uploadu nazwijmy ją ul, która to nazwa jest całkowicie dowolna gdyż sama w sobie w żaden sposób nie wpływa na działanie sekcji i równie dobrze może się nazywać upload, sekcja_uploadu czy nawet przewrotnie download;) Główną rolę odgrywa tu nie nazwa sekcji a dyrektywa mode
Dyrektywa match sekcji ma za zadanie wskazać podsieć która ma być przez nią kontrolowana.
Za jej pomocą utworzony zostanie odpowiedni wpis w tabeli mangle iptables, dzięki któremu możliwe będzie zliczanie
ruchu generowanego przez klasy tej sekcji.
My wskażemy tu podsieć 192.168.0.0/23 gdyż pakiety wychodzące z tej podsieci w świat, mają być kontrolowane. Dyrektywa match ma dużo większe możliwości niż tylko wskazanie podsieci, ale będą one najczęściej używane dopiero w ramach filtrów klas, gdzie jej działanie jest jednym z fundamentów kontroli pasma.
Dalej określamy realnie osiągalną przepustowość pasma wychodzącego, przyporządkowanego konfigurowanej sekcji oraz poziom na którym oczekujemy utrzymywać jego wykorzystanie.
- section speed 500kb/s shape 400kb/s
Wartość parametru shape przy dobrej jakości łączu musi być bezwzględnie,
o kilka-kilkanaście procent niższa od wartości parametru speed!!
Zbyt wysoka wartość zwiększy ryzyko zwiększenia czasów odpowiedzi na łączu, aż do całkowitego niedziałania podziału w ekstremalnej sytuacji. Parametr speed również warto delikatnie przyciąć by uniknąć powstawania kolejek pakietów na routerze.
Jaki sens jest w używaniu NiceShapera i jednoczesnym tworzeniu skomplikowanych i dość niewygodnych klas, qdisc-ów i filtrów za pomocą programu tc?
Nic nie stoi na przeszkodzie by również statyczny podział skonfigurować za pomocą NiceShapera.
Oto konfiguracja kolejnej sekcji a poniżej komentarz:
<dl>
- match dstip 192.168.0.0/23
- section speed 16mb/s
- section shape 15mb/s
- rate 4mb/s
- htb scheduler sfq
- reload 4s
- mode download
Pojawia się tu dyrektywa:
SFQ jest w NiceShaperze domyślnym typem schedulera dla klas. Ta dyrektywa przytoczona została wyłącznie po to by pokazać że już w domyślnej konfiguracji użytkownik otrzymuje pewną ochronę przed własnym działaniem.
Co jeśli zdecydujemy się jednak kontrolować również download dynamicznie? Wystarczy zastąpić parametr rate parą parametrów low i ceil, np:
Takie rozwiązanie tak naprawdę nie ma minusów a zabezpiecza łącze w szczycie przed przeciążeniem. Dodatkowo dzięki niemu można bezpiecznie przydzielić klientów większe pasma, NiceShaper jeśli wykryje taką potrzebę sam zadba o obcięcie klientów najbardziej wysysających swoje łącza i nie dopuści do pogorszenia parametrów dostępu udostępnianego pozostałym.
Czym jest klasa.
Teraz nie pozostaje nic innego jak skonfigurować klasy.
Klasę opisać można jako pojemnik na pakiety, przyporządkowywane za pomocą filtrów. Filtry mogą przyporządkowywać pakiety poprzez kryteria którymi są adresy ip hostów, podsieci, porty, wirtualne znaczniki pakietów i inne. W trakcie swojej pracy NiceShaper dba o to, by agresywnie wykorzystujące swoje pasma klasy, możliwie najmniej przeszkadzały sobie wzajemnie oraz pozostałym klasą.
Przykładowe dwie klasy:
- 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 skierowane na adres 192.168.0.10. Do drugiej wszystkie pakiety pochodzące z adresu 212.77.100.101 lub skierowane na adres 192.168.0.10. Inaczej mówiąc w pierwszym przypadku obydwa testy muszą zostać spełnione jednocześnie a w drugim którykolwiek z nich, gdyż te filtry są od siebie niezależne.
Pamiętać należy że każdy pakiet testowany jest przez filtry w takiej kolejności w jakiej zostały skonfigurowane, stąd kolejność definiowania klas ma kluczowe znaczenie.
Dodajemy klasy.
- class dl eth1 www
- match srcport 80 proto tcp
- match srcport 8080 proto tcp
- low 4mb/s
- ceil 8mb/s
- class dl eth1 Krzysiek
- match dstip 192.168.0.10
- class dl eth1 Janek
- match dstip 192.168.0.11
- class dl eth1 Ola_dwa_komputery
- match dstip 192.168.0.12
- match dstip 192.168.0.13
- class ul eth0 Krzysiek
- match srcip 192.168.0.10
- class ul eth0 Janek
- match srcip 192.168.0.11
- class ul eth0 Ola_dwa_komputery
- match srcip 192.168.0.12
- match srcip 192.168.0.13
Utworzyliśmy tu kilka przykładowych klas dla klientów. Pierwsza klasa o nazwie "www" obsługuje wyłącznie ruch www bez podziału na hosty, dwie kolejne są oczywiste a ostatnia przydziela dwóm komputerom tego samego klienta wspólne pasmo. Klasa www otrzymuje zwiększony przydział pasma, nadpisując domyślne wartości przyporządkowane poprzez konfigurację sekcji dl, do której to klasa ta należy.
Każda klasa zostaje przyporządkowana wyłącznie jednej sekcji a pozostałe sekcje nie wiedzą o jej istnieniu.
Fakt że klasy zostają ze sobą wymieszane w ramach jednego pliku konfiguracyjnego nie ma żadnego znaczenia, każda z sekcji wczytuje i kontroluje wyłącznie przypisane jej klasy.