Zaawansowany Routing

[ Pobierz całość w formacie PDF ]
.Klasyfikatory ogólnie rzecz biorąc, akceptują parę podstawowych argumentów.Wymieniono je tutaj dla wygody:protocolProtokół, który ten klasyfikator zaakceptuje - w zasadzie będziesz akceptował ruch IP.Wymagane.parentOznaczenie, do którego ten klasyfikator będzie podpięty.Musi być już zdefiniowane dla istniejącej klasy.Wymagane.prioPriorytet klasyfikatora.Niższy numer będzie sprawdzany szybciej.handleUchwyt oznacza różne rzeczy dla różnych filtrów.HostA 1:Wszystkie następne sekcje zakładają, że próbujesz kształtować ruch skierowany do.Zakłada się, że klasę-korzeń skonfigurowano na i że wyselekcjonowany ruch chcesz1:1wysyłać do.mr0vka.eu.org13.1 Klasyfikator "u32"Klasyfikator U32 jest najbardziej zaawansowanym z dostępnych filtrów, w obecnej implementacji.Jest w całości zbudowany w oparciu o tablice mieszające (ang.hashing tables),które zapewniają dużą wydajność nawet w przypadku dużej liczby reguł.W swojej najprostszej postaci, filtr U32 jest listą rekordów, z których każdy składa się z dwóch pól: selektora i akcji.Selektor, opisany poniżej, jest porównywany do aktualnieprzetwarzanego pakietu IP dopóki nie dojdzie do pierwszej zgodności.Wtedy wykonywana jest skojarzona z pasującym selektorem akcja.Najprostszym typem akcji byłobyskierowanie pakietu do zdefiniowanej klasy CBQ.tc filterLinia poleceń programu używanego do konfigurowania filtrowania składa się z trzech części: określenia filtra, selektora i akcji.Określenie filtra można opisać jako:tc filter add dev IF [ protocol PROTO ][ (preference|priority) PRIO ][ parent CBQ ]Pole protocol opisuje protokół, w stosunku do którego filtr będzie sprawdzany.Rozważamy tylko przypadek protokołu.Pole ( można używaćip preference priorityzamiennie) określa priorytet aktualnie definiowanego filtra.Jest to o tyle ważne, że możesz mieć kilka filtrów (list reguł) z różnymi priorytetami.Każda lista będzie sprawdzana wparentkolejności w jakiej dodawano reguły, następnie lista z mniejszym priorytetem (wyższym numerem preferencji) będzie przetwarzana.Pole określa górne drzewo CBQ (np.1:0) do którego powinien dołączyć się filtr.Opcje opisane wyżej dotyczą wszystkich filtrów, nie tylko U32.Selektor U32Selektor U32 zawiera definicję wzorca, który zostanie sprawdzony z przetwarzanym pakietem.Dokładniej, definiuje które bity mają pasować z nagłówka pakietu - ale jest to bardzopotężne narzędzie.Spójrzmy na następujący przykład, wzięty wprost z rzeczywistego, całkiem skomplikowanego filtra:# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \match u32 00100000 00ff0000 at 0 flowid 1:10matchNa razie zostawmy pierwszą linię w spokoju - wszystkie parametry opisują tablice mieszające filtra.Skupmy się na lini selektora, zawierającej słowo.Selektor wybieranagłówki IP, których drugi bajt jest równy 0x10 (0010).Jak łatwo zgadnąć, numer 00ff jest maską testu, mówiącą filtrowi które bajty dokładnie dopasować.Wynosi 0xff, więc bajtatma być równy dokładnie 0x10.Słowo kluczowe oznacza, że test rozpoczynany jest od określonego przesunięcia (w bajtach) -- w tym przypadku w stosunku do początku pakietu.Tłumacząc to na ludzki język, pakiet będzie pasował do filtra, jeśli pole ToS będzie miało ustawione bity `niska zwłoka'.Zanalizujmy następną regułę:# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \match u32 00000016 0000ffff at nexthdr+0 flowid 1:10nexthdrOpcja oznacza następny nagłówek zaenkapsułowany w pakiecie IP, tzn.nagłówek wyższego protokołu.Test rozpocznie się od początku następnego nagłówka i dotyczyćmr0vka.eu.orgbędzie drugiego, 32-bitowego słowa w nagłówku.W protokołach TCP i UDP pole to zawiera port przeznaczenia.Numer podawany jest w formacie big-endian, tzn.starsze bitypierwsze, więc czytamy to jako 0x16 czyli 22 decymalnie - port usługi SSH jeśli byłoby to TCP.Jak możesz zgadnąć, test jest bez sensu jeśli nie ma kontekstu i omówimy to pózniej [ Pobierz całość w formacie PDF ]

Linki