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 użytkownicy będą mogli skutecznie korzystać ze współdzielonego łącza.

Oto pierwsza konfiguracja i poniżej komentarz:

Sekcja global jest wymagana i tutaj umieszczony w niej parametr run mówi, które ze skonfigurowanych sekcji należy uruchomić. Sekcji funkcyjnych można mieć dowolną liczbę, najczęściej jednak na każde łącze przypadają dwie (kontrola downloadu oraz uploadu).

Pierwszy ważny parametr:

mark-on-ifaces eth0
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ł iptables dodawane są cele MARK --set-mark. Wszystkie niezbędne operacje na każdym etapie działania, wykonywane są automatycznie przez NiceShapera.

Filtr typu FW to filtr kernela 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 Linuksa i po opuszczeniu przez pakiet routera znacznik ten znika bezpowrotnie. Dzieje się tak dlatego, że znacznik nie jest zapisywany w samym pakiecie 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.

Dyrektywa local-subnets ma za zadanie wskazać podsieć (lub podsieci) podłączone do routera po stronie interfejsu LAN. Czyli po tej stronie po której mamy szerokie pasmo a za przesył danych nie płacimy.

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.

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 450kb/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 modemie ISP.

Teraz nic nie stoi na przeszkodzie, by również statyczny podział skonfigurować za pomocą NiceShapera.

Oto konfiguracja kolejnej sekcji a poniżej komentarz:

Pojawia się tu dyrektywa:
htb scheduler sfq
SFQ jest w NiceShaperze domyślnym typem schedulera dla klas. Ta dyrektywa została tutaj przytoczona, by pokazać, że już w domyślnej konfiguracji użytkownik otrzymuje pewną ochronę przed własnym działaniem.

Co jeśli zdecydujemy się jednak download również kontrolować za pomocą dynamicznego algorytmu NiceShapera? 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 użytkownikom bezpiecznie przydzielić większe pasma. NiceShaper jeśli wykryje taką potrzebę, sam zadba o obcięcie użytkownikó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.

Przykładowe dwie klasy:

Czym się one różnią? Do pierwszej klasy zostaną zakwalifikowane pakiety pochodzące z adresu 212.77.100.101 i jednocześnie 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 (a precyzyjniej filtrów) ma kluczowe znaczenie.

Dodajemy kolejne klasy.

Utworzyliśmy tu kilka przykładowych klas. Pierwsza klasa o nazwie "www" obsługuje cały ruch www bez podziału na hosty. Dwie kolejne pary (dl z ul) są oczywiste a ostatnie przydzielają dwóm komputerom w tym samym biurze wspólne pasmo. Klasa www otrzymuje zwiększony przydział pasma, nadpisując domyślne wartości skonfigurowane w sekcji dl, do której to klasa ta należy. Po stronie uploadu również wydzielamy ruch www do samodzielnej klasy, by w razie wysycenia przez użytkownika pasma swojej klasy, ruch www ciągle działał temu użytkownikowi sprawnie.

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.