dla początkujących
40
czerwiec 2004
Serwer DHCP
i algorytm HTB
Piotr Machej
O
soby administrujące mniej-
szymi lub większymi sie-
ciami lokalnymi na ogół
są skazane na wieczne
skargi kierowane do nich przez użyt-
kowników. A to sieć nie działa dość
szybko, a to nie wiadomo, jak skonfi-
gurować komputer po kolejnej reinsta-
lacji Windows, a to znów nie można
sobie pograć w ulubioną grę siecio-
wą. Często ci sami użytkownicy chcie-
liby móc równocześnie ściągać pliki z
sieci P2P i nadal bez problemu oglądać
strony WWW.
Odpowiednie skonfigurowanie ser-
wera udostępniającego Internet może
nieco zmniejszyć liczbę skarg użytkow-
ników. W niniejszym artykule zajmie-
my się dwiema możliwościami uła-
twienia życia administratora. Pierwsza
z nich to skonfigurowanie ser-
wera DHCP służącego do dynamiczne-
go przydzielania adresów IP kompute-
rom podłączonym do naszej sieci lokal-
nej. Druga to przydzielenie odpowied-
niej przepustowości łącza do Inter-
netu poszczególnym użytkownikom
i usługom w taki sposób, aby nie
utrudniali sobie nawzajem korzystania
z Sieci.
Zakładamy, że udostępnianie łącza
internetowego komputerom w sieci
lokalnej jest już skonfigurowane.
W związku z tym, nie będziemy się tym
zajmować. Czytelników zainteresowa-
nych tym tematem odsyłam do artyku-
łu Konfiguracja serwera dla sieci osie-
dlowej, który pojawił się w numerze
10/2002 Linux+.
Przykład użycia
Pewnego dnia na Gadu-Gadu odezwał
się do mnie znajomy. Ze względu na to,
że swoje łącze do Internetu dzielił na
kilka osób w bloku, uskarżał się ostat-
nio na ciągłe problemy. Jeden z użytkow-
ników często obciążał łącze ściąganiem
filmów do tego stopnia, że inni nawet
nie mogli poczytać sobie stron WWW.
Jakby tego było mało, drugi użytkow-
nik (wieczny eksperymentator) co jakiś
czas reinstalował sobie system, a póź-
niej potrafił około północy dzwonić do
mojego znajomego, żeby ten skonfiguro-
wał mu dostęp do Internetu.
Cóż było robić? Zadałem mu kilka
pytań i dowiedziałem się, że w jego
sieci znajduje się dziesięć komputerów,
z czego jeden (z zainstalowanym Linuk-
sem) pełni rolę bramki do Internetu. Nie
O autorze
Autor ukończył studia na kierun-
ku Informatyka na Politechni-
ce Opolskiej. Z Linuksem (i ogól-
nie systemami uniksowymi) ma
styczność od wielu lat. Obec-
nie administruje dwoma siecia-
mi blokowymi. Wolne chwile dzieli
pomiędzy jazdy konne, pływanie,
czytanie książek, mang i oglą-
danie anime. Kontakt z autorem:
autorzy@linux.com.pl.
Na płycie CD/DVD
Na płycie CD/DVD znajdują się
pakiety źródłowe i binarne oma-
wianych programów oraz wszyst-
kie listingi z artykułu.
CD/DVD
Po uruchomieniu dystrybu-
cji Linux+ Live CD/DVD można
korzystać z programów omawia-
nych w artykule.
Rysunek 1.
Przy konfiguracji klienta DHCP
w Windows nie trzeba znać żadnych
adresów
dla początkujących
41
www.lpmagazine.org
dhcp i htb
wszystkie komputery w równym stopniu
korzystają z sieci, gdyż dwóch użytkow-
ników jest właścicielami odpowiednio
dwóch i trzech komputerów. Jako łącze
do Internetu służy im SDI, a niedługo
mają zamiar zmienić tą usługę na DSL.
Zaproponowałem mu, aby skonfigu-
rował sobie serwer DHCP, co powinno
wybawić go od nocnych wizyt u ekspe-
rymentatora. Oprócz tego opowiedziałem
mu o możliwościach, jakie oferuje stero-
wanie przepływem danych. Ucieszył się,
gdy dowiedział się, że przy odpowied-
niej konfiguracji będzie mógł spokoj-
nie pograć sobie w Neverwinter Nights
w sieci, nawet gdy znajomy będzie sobie
ściągał filmy i muzykę. Przygotowałem
mu przykładowe pliki, na podstawie któ-
rych mógł później rozbudować własną
konfigurację.
Serwer DHCP
Każdy komputer podłączony do Sieci
posiada przyporządkowany numer IP.
Może on być wpisywany ręcznie podczas
konfiguracji połączenia, ale w przypadku
bardziej rozbudowanych sieci lokalnych,
takie rozwiązanie nie jest ekonomiczne.
Jeśli administrator z jakiegoś powodu
będzie chciał zmienić numery części
komputerów, to będzie musiał odwiedzić
każdy z nich i zmieniać numer ręcznie.
To samo może zdarzyć się, gdy użytkow-
nik zainstaluje u siebie nowy system ope-
racyjny, a nie będzie potrafił skonfiguro-
wać połączenia sieciowego.
W takich przypadkach przydaje się
DHCP (Dynamic Host Configuration Pro-
tocol), czyli protokół dynamicznej konfi-
guracji komputerów. Dzięki niemu użyt-
kownik komputera nie musi znać numeru
IP, maski podsieci, adresu bramki czy
adresu serwerów DNS – wystarczy, że
zaznaczy u siebie Automatyczne pobiera-
nie adresu IP, a wszystkie te informacje
zostaną mu przesłane z serwera DHCP.
Jak to działa? Nie zagłębiając się w
szczegóły techniczne, można powiedzieć,
że DHCP funkcjonuje w modelu klient-
serwer. W sieci mamy serwer zarządza-
jący przydzielaniem adresów IP (oraz
pozostałych parametrów konfiguracyj-
nych) oraz szereg klientów domagających
się tych informacji. Klient (a więc każdy
komputer w naszej sieci lokalnej poza
serwerem) po uruchomieniu rozgłasza
komunikaty do serwerów DHCP z żąda-
niem przesłania mu parametrów konfigu-
racyjnych. Gdy taki komunikat dotrze do
serwera DHCP, sprawdza on właściwą
dla klienta konfigurację i wysyła mu ją
w komunikacie. Jeśli klientowi ona odpo-
wiada (w sieci może znajdować się kilka
serwerów DHCP, a klient może sobie
wybrać, z którego chce korzystać), odsyła
potwierdzenie do serwera, który zatwier-
dza taką konfigurację.
Adresy mogą być przydzielane na
kilka różnych sposobów. Po pierwsze,
każdemu klientowi może być przypisany
stały adres IP (np. na podstawie adresu
MAC karty sieciowej). Po drugie, adres IP
może być przyznany na określony czas
(wydzierżawiony). Taki adres pochodzi
ze specjalnej puli adresów określonej
przez administratora. Wreszcie, po trze-
cie, administrator może przypisać kom-
puterowi stały numer IP (nie jest wtedy
pobierany z DHCP).
Instalacja i uruchamianie
Na początek musimy zainstalować pakiet
dhcpd. Jest on dołączany do większości
dystrybucji, więc nie powinno być pro-
blemów z jego znalezieniem. W przy-
padku dystrybucji Aurox 9.3 pakiet ten
(pod nazwą dhcp-3.0pl2-6.16.i386.rpm)
znajduje się na trzeciej płytce instalacyj-
nej. Możemy go zainstalować korzystając
z menedżera pakietów lub z linii poleceń
(po zalogowaniu się na konto root mon-
tujemy płytę CD-ROM poleceniem
mount
/mnt/cdrom/
, a następnie instalujemy
pakiet poleceniem
rpm -Uvh /mnt/cdrom/
Aurox/RPMS/dhcp-3.0pl2-6.16.i386.rpm
).
Na tym instalacja kończy się. Kon-
figurację przeprowadzamy modyfikując
plik /etc/dhcpd.conf.
Po zakończeniu konfiguracji (według
wskazówek
umieszczonych
poni-
żej) należy stworzyć pusty plik /etc/
dhcpd.leases poleceniem
touch /etc/
dhcpd.leases
. Teraz już możemy urucho-
mić demona DHCP poleceniem
/usr/
sbin/dhcpd
. Możemy ograniczyć jego
działanie do wybranego interfejsu (tak,
aby działał tylko na interfejsie, do które-
go jest podłączona sieć lokalna). W takim
przypadku należy uruchomić go pole-
ceniem
/usr/sbin/dhcpd eth0
(w miej-
sce eth0 wstawiamy odpowiednią nazwę
interfejsu).
Jeśli wszystko działa prawidłowo,
możemy dodać wywołanie demona
DHCP do skryptów startowych. W przy-
padku dystrybucji Aurox można tego
dokonać wydając polecenie
ntsysv
i zaznaczając pozycję dhcpd.
W poniższych rozdziałach omówi-
my opcje konfiguracyjne umieszczane
w pliku /etc/dhcpd.conf.
Dynamiczne przydzielanie
adresów
Na Listingu 1 jest umieszczony przykła-
dowy plik /etc/dhcpd.conf. Jest to skróco-
na wersja pliku, który mógłby być zasto-
Listing 1.
Przykład pliku dhcpd.conf
# Opcje globalne
option
domain-name "moja.domena.pl";
option
domain-name-servers 194.204.159.1, 194.204.152.34;
option
subnet-mask 255.255.255.0;
default-lease-time
21600;
max-lease-time
86400;
# Opcje podsieci
subnet
192.168.100.0 netmask 255.255.255.0 {
range
192.168.100.2 192.168.100.250;
option
broadcast-address 192.168.100.255;
option
routers 192.168.100.1;
}
# Opcje komputerów
host
user2 {
hardware
ethernet 00:32:1F:13:44:F6;
fixed-address
192.168.100.6;
option
broadcast-address 192.168.100.255;
option
routers 192.168.100.1;
option
host-name "user2";
}
dla początkujących
42
czerwiec 2004
sowany w przypadku opisanym w roz-
dziale Przykład użycia. Jak widać, jest
podzielony na trzy sekcje.
W sekcji Opcje globalne są zawar-
te ustawienia domyślne. Zostaną one
użyte, jeśli nie nadpiszą ich ustawie-
nia zawarte w blokach subnet lub host
(odpowiednio sekcje Opcje podsie-
ci i Opcje komputerów) – najważniej-
sze są opcje zawarte w sekcji najbar-
dziej szczegółowej. Jeśli klienta, który
wysłał komunikat z żądaniem przy-
znania numeru IP, nie można dopaso-
wać do żadnego z bloków host, to roz-
patrywane są bloki subnet. Jeśli w blo-
kach tych nie zostały ustawione wszyst-
kie opcje, to pobrane zostaną one
z bloku nadrzędnego (w kolejności host
-> subnet -> opcje globalne).
Zaczynamy od ustawienia nazwy
domeny (
option domain-name
) oraz adre-
sów serwerów DNS (
option domain-name-
servers
). Jeśli chcemy podać więcej adre-
sów, oddzielamy je przecinkiem. Następ-
nie ustawiamy maskę podsieci (
option
subnet-mask
).
Opcje
default-lease-time
i
max-lease-
time
określają odpowiednio domyślny
i maksymalny czas dzierżawy adresu
przyznanego dynamicznie. Czasy te
podane są w sekundach.
Teraz dochodzimy do najciekaw-
szej części, jaką jest sekcja Opcje podsie-
ci. Zaczyna się ona od deklaracji podsie-
ci (
subnet
) i jej maski (
netmask
). Wszystkie
opcje dotyczące tej podsieci są zamknię-
te pomiędzy nawiasami klamrowymi:
{
i
}
. Każda podsieć, która będzie obsłu-
giwana, jak również każda podsieć, do
której jest podłączony serwer DHCP,
musi posiadać jeden blok subnet. Jest
to konieczne nawet w przypadku, gdy
w danej podsieci nie będziemy przypisy-
wać adresów dynamicznie.
Pierwsza opcja (
range
) określa zakres
adresów, które mogą być dynamicznie
przyznawane klientom. Adresy te muszą
należeć do tej samej podsieci, co określo-
na w deklaracji
subnet
. W jednym bloku
subnet możemy zdefiniować wiele zakre-
sów adresów – wystarczy użyć kilku
kolejnych linii zawierających opcję
range
z podanymi odpowiednimi adresami.
Następnie ustawiamy adres rozgło-
szeniowy (
option broadcast-address
) dla
naszej podsieci. Ostatnia opcja to wska-
zanie rutera (
option routers
), przez który
klienci mogą łączyć się z Internetem.
Te dwie sekcje w zasadzie wystarcza-
ją do dynamicznego przydzielania adre-
sów. Jeśli jednak chcemy mieć większą
kontrolę nad tym, jakie adresy otrzymują
poszczególni użytkownicy sieci, powin-
niśmy zainteresować się również sekcją
Opcje komputerów.
Statyczne adresy
Często będzie nam zależeć, aby konkret-
ne komputery posiadały stałe adresy. Tak
musi być w przypadku serwerów usług
(np. DNS, WWW, FTP), które znajdu-
ją się w sieci lokalnej. Może to być rów-
nież przydatne w przypadku zwykłych
komputerów podłączonych do sieci.
Dzięki temu można później łatwo ziden-
tyfikować poszczególne komputery, a ich
numery IP wykorzystać choćby do two-
rzenia odpowiednich regułek na zapo-
rze ogniowej (np. w celu udostępnienia
komuś konkretnego portu lub przeciwnie
– zablokowania niektórych usług).
Takie przypisanie stałych adresów
poszczególnym komputerom w sieci
dokonywane jest w sekcji Opcje kompu-
terów. Na Listingu 1 w tej sekcji przed-
stawiony jest tylko jeden przykłado-
wy blok host. Zaczyna się on linią
host
nazwa_komputera
, po której umieszczane
są opcje konfiguracyjne dotyczące tego
komputera, zamknięte pomiędzy nawia-
sami klamrowymi:
{
i
}
.
Pierwsza opcja w naszym przykładzie
to
hardware ethernet
. Określa ona adres
MAC karty sieciowej komputera, dla
którego przeznaczone są opcje zawar-
te w tym bloku host. W systemie Win-
dows adres MAC karty sieciowej możemy
sprawdzić uruchamiając polecenie
ipcfg
.
W przypadku Linuksa wystarczy urucho-
mić polecenie
/sbin/ifconfig
. Możemy
również sprawdzić adresy MAC innych
komputerów podłączonych do sieci, uru-
chamiając na ruterze polecenie
/sbin/arp
(jednak nie wypisze ono adresów kom-
puterów, które akurat są wyłączone lub
nie korzystają z sieci).
Opcja
fixed-address
to serce naszego
statycznego przydziału numeru IP. Jeśli
byśmy jej nie użyli, to komputer otrzy-
małby adres z puli określonej w odpo-
wiednim bloku subnet. Podczas wyszuki-
wania bloku host odpowiadającego kom-
puterowi, który wysłał żądanie, w pierw-
szej kolejności rozpatrywane są bloki host
zawierające opcję
fixed-address
z adre-
sem pasującym do podsieci, w której
został uruchomiony komputer. Jeśli taki
blok nie zostanie znaleziony, to w następ-
nej kolejności przeszukiwane są bloki
host nie zawierające opcji
fixed-address
.
Kolejne dwie opcje (
option broad-
cast-address
i
option routers
) pozwalają
na przekazanie do komputera odpowia-
dających mu adresu rozgłoszeniowego
i adresu rutera. Opcje zawarte w tym
bloku mają pierwszeństwo przed tymi
określonymi w bloku subnet, więc mamy
możliwość wskazania innego rutera
wybranym komputerom. Jeśli jednak są
takie same, możemy po prostu usunąć
te dwie linie z bloku host – w takim
przypadku będą obowiązywać wartości
umieszczone w bloku subnet.
Ostatnia opcja (
option host-name
)
pozwala na ustawienie odpowiedniej
nazwy komputera.
W analogiczny sposób można utwo-
rzyć bloki host dla pozostałych kompu-
terów w sieci, zmieniając odpowiednio
nazwę komputera, jego adres MAC oraz
przypisany numer IP.
Dzielenie pasma
Tym, co bardzo irytuje wielu użytkow-
ników sieci korzystających z Interne-
tu za pośrednictwem niewielkich sieci
lokalnych (blokowych, osiedlowych),
jest zapychanie łącza przez inne osoby.
Nieraz dochodzi do sytuacji, w której
część użytkowników przejmuje więk-
szość pasma i cieszy się z szybko ściąga-
jących się plików, podczas gdy inni mają
problemy z otwarciem nawet pojedynczej
strony WWW.
Receptą na ten problem jest odpo-
wiednie sterowanie przepływem danych
(traffic control). Dzięki temu możemy nie
tylko ograniczyć przepustowość wyko-
rzystywaną przez poszczególnych użyt-
kowników, ale również zapewnić odpo-
Rysunek 2.
Po uruchomieniu serwera
DHCP wystarczy polecić Linuksowi
automatyczne pobieranie z niego adresów
dla początkujących
43
www.lpmagazine.org
dhcp i htb
wiednie parametry łącza dla wybranych
transmisji (np. dla pracy z SSH).
Jak to działa?
Zacznijmy od tego, że każde łącze ma
określoną przepustowość. Łącze w sieci
lokalnej (często jest to Ethernet o przepu-
stowości 10 lub 100 Mbit) jest zazwyczaj
znacznie szybsze od łącza do Internetu
(np. SDI o przepustowości 115Kbit lub
DSL o przepustowości 1Mbit). Nas inte-
resuje, co dzieje się na styku tych łączy,
czyli tam, gdzie znajduje się nasz ruter.
Dane przesyłane przez użytkowni-
ków przychodzą do rutera przez jeden z
interfejsów (np. ppp0 w przypadku SDI
lub eth0 w przypadku sieci lokalnej).
Następnie podlegają analizie – w uprosz-
czeniu, ruter ocenia, do jakiego adresata
mają trafić poszczególne pakiety. Znając
adresata, ruter wyznacza adres następ-
nego rutera i interfejsu, do którego skie-
ruje dane. Takie dane przeznaczone do
wysłania trafiają do kolejki wyjściowej,
z której są usuwane, gdy tylko interfejs
zdoła je obsłużyć.
Może się zdarzyć, że do kolejki wyj-
ściowej dane trafiają tak szybko, że inter-
fejs nie nadąża z wysyłaniem. Jeśli prze-
ciążenie takie trwa na tyle długo, że
liczba pakietów przeznaczonych do
wysłania przekroczy rozmiary kolejki
wyjściowej, to część pakietów zostanie
zagubiona. O tym, które pakiety zostaną
zagubione, decyduje algorytm obowiązu-
jący w danej kolejce.
Jak widać z tego opisu, mamy możli-
wość kształtowania jedynie ruchu wycho-
dzącego z rutera. Może się to wyda-
wać dziwne, jednak jest dosyć natural-
ne. Ruter otrzymujący dane z przeciążo-
nego łącza nie ma możliwości zmniejsze-
nia tego przeciążenia za pomocą kolejki
– może to zrobić jedynie ruter wysyłający
dane. Powstaje zatem pytanie, jak mamy
ograniczyć przepustowość dla danych
pobieranych z Internetu.
Dokonamy tego w ten sposób, że
nałożymy ograniczenia na interfejs sieci
lokalnej – jeśli ruter będzie wysyłał jakieś
dane z Internetu do jednego z użytkow-
ników sieci lokalnej, to zadba, aby były
one wysyłane z określoną szybkością.
W ten sam sposób możemy ogra-
niczyć przepustowość wykorzystywa-
ną przez użytkowników do wysyłania
danych do Internetu. Tym razem jednak
ograniczenia należy założyć na interfejs
zewnętrzny (np. ppp0).
Do nakładania ograniczeń posłuży
nam program tc (traffic control) z pakie-
tu iproute2.
Warto zauważyć, że przy takim
modelu możemy kształtować ruch
wychodzący bezpośrednio z rutera,
jednak nie mamy wpływu na szybkość
pobierania danych przez ruter – ruch
kształtujemy na ruterze, a dane przezna-
czone dla niego nie przechodzą przez
żaden interfejs wyjściowy. W większo-
ści przypadków nie jest to jednak niedo-
godnością. Gdybyśmy jednak na naszym
ruterze udostępniali konta innym użyt-
kownikom, to powinniśmy zaintereso-
wać się IMQ (InterMediate Queueing
device), czyli pośrednim urządzeniem
kolejkującym.
Podstawowe wymagania
Przede wszystkim musimy sprawdzić,
czy posiadamy odpowiednią konfigu-
rację. HTB (wykorzystywany przez nas
algorytm kolejkowania – patrz ramka
Algorytmy kolejkowania) jest włączo-
ne w jądrach od wersji 2.4.20, dlatego
najlepiej korzystać z najnowszych jąder
linii 2.4.x. Można co prawda skorzystać
z wersji wcześniejszej niż 2.4.20, jednak
wymaga to nakładania łaty na jądro. My
nie będziemy sobie utrudniać życia i sko-
rzystamy z jądra 2.4.20 lub nowszego.
Drugim ważnym elementem jest
pakiet iproute2 (a dokładniej, wchodzą-
cy w jego skład program tc). Najnow-
sze wersje tego pakietu nie wymagają już
nakładania łatki HTB, co oszczędza nam
pracy z kompilowaniem źródeł. Użyt-
kownicy dystrybucji Aurox mogą wyko-
rzystać pakiety dołączane do dystrybu-
cji (iproute-2.4.7 z pierwszej płyty insta-
lacyjnej).
To w zasadzie wszystko, co będzie
nam potrzebne. Teraz możemy już spraw-
dzić, czy wszystko działa tak, jak powin-
no. W tym celu korzystając z uprawnień
administratora (czyli po zalogowaniu na
konto root lub skorzystaniu z polecenia
su -
) wydajemy następujące polecenia:
tc qdisc show
tc filter show
tc class show
Na tym etapie nie powinny one zwrócić
żadnego wyniku. Jeśli pojawi się komu-
nikat błędu zawierający tekst no such
device, to znaczy, że podczas kompilo-
wania jądra pominęliśmy jakieś istot-
ne opcje. W przeciwnym przypadku
możemy przejść do właściwej konfigu-
racji.
Dzielimy według
użytkowników
W rozdziale Przykład użycia opisaliśmy
przykładową konfigurację sieci lokalnej.
Dla przypomnienia, mamy do czynienia
z siecią lokalną złożoną z dziesięciu kom-
puterów. Jeden z nich pełni rolę bramki
do Internetu. Sieć lokalna (Ethernet) ma
przepustowość 10Mbit, natomiast łącze
Rysunek 3.
Przykład statystyk zarządzania przepustowością łącza przez HTB
dla początkujących
44
czerwiec 2004
do Internetu to SDI (o przepustowości
115Kbit). Dwóch użytkowników posiada
więcej niż jeden komputer – jeden z nich
posiada trzy, a drugi dwa komputery.
Aby pozostali użytkownicy sieci nie byli
poszkodowani, łącze dzielimy pomiędzy
użytkowników, a nie komputery (czyli
trzy komputery jednego użytkownika
otrzymają razem taką samą przepusto-
wość, jak jeden komputer innego).
Na Listingu 2 znajduje się jedno
z możliwych rozwiązań, które można
w tym przypadku zastosować. Omówimy
je teraz krok po kroku.
Zaczynamy od zdefiniowania zmien-
nych, dzięki czemu nasz skrypt będzie
później łatwiejszy do modyfikowania.
W sekcji 1) określamy następujące zmien-
ne:
• CALE – przepustowość całego łącza
sieci lokalnej;
• SDI – przepustowość łącza do Inter-
netu;
• ETH_CEIL – maksymalna przepusto-
wość możliwa do wykorzystania na
transmisję z rutera do komputerów
w sieci lokalnej;
• USER – przepustowość gwarantowa-
na każdemu z użytkowników (nie
może być większa niż wartość SDI
podzielona przez liczbę użytkowni-
ków);
• USER_CEIL – maksymalna przepusto-
wość, którą może wykorzystać użyt-
kownik, jeśli nie jest ona zajmowana
przez innych użytkowników;
• INT_LOC – nazwa interfejsu rutera,
do którego podłączona jest sieć lokal-
na.
Następnie w sekcji 2) określamy zmienne,
w których przechowywane są numery IP
wszystkich komputerów znajdujących się
w sieci lokalnej. Zmienna IP_SERWER
przechowuje numer IP rutera. Pozostałe
zmienne to numery IP komputerów nale-
żących do użytkowników. Nazwy zmien-
nych można dobrać według własnych
upodobań. W tym przypadku przyję-
to zasadę, że nazwa składa się z ciągu
IP_USER uzupełnionego o numer użyt-
kownika (np. IP_USER2). Jeśli użyt-
kownik posiada więcej komputerów,
to dodatkowo po znaku podkreślenia
jest podany numer kolejny komputera
należącego do tego użytkownika (np.
IP_USER3_2 to drugi komputer użytkow-
nika numer 3).
Polecenie zawarte w sekcji 3) powo-
duje, że usunięte są wszystkie kolej-
ki i klasy, które mogły być zdefiniowa-
ne na interfejsie $INT_LOC. Przy okazji
warto zaznaczyć, że o ile przy definiowa-
niu zmiennych wykorzystywaliśmy same
nazwy, to przy wstawianiu ich wartości w
poleceniach nazwy zmiennych poprze-
dzamy znakiem $.
W sekcji 4) określamy, jaka dyscy-
plina kolejkowania będzie wykorzysta-
na do zarządzania ruchem wychodzą-
cym z sieci lokalnej. W naszym przypad-
ku wybieramy dyscyplinę HTB. Utwo-
rzonemu obiektowi nadajemy uchwyt
(handle) 1:0.
Następnie w utworzonym obiek-
cie tworzymy klasę odpowiedzialną za
przypisanie przepustowości dla całego
łącza do sieci lokalnej. Odpowiada za to
instrukcja umieszczona w sekcji 5). Użyta
tu wartość zmiennej CALE nie powinna
być większa od rzeczywistej przepusto-
wości sieci.
W sekcji 6) rozdzielamy naszą klasę
na dwie podklasy. Jedna z nich (o rate
i ceil ustawionym na wartość $SDI)
będzie służyć do kolejkowania pakie-
tów pochodzących z Internetu. Druga
natomiast pozwoli na przesyłanie pakie-
tów pochodzących bezpośrednio z rutera
do komputerów w sieci lokalnej z maksy-
malną szybkością.
Szereg poleceń zawartych w sekcji
7) przydziela poszczególnym użytkow-
nikom fragmenty pasma przeznaczo-
nego do ściągania danych z Internetu.
Warto zauważyć, że pasmo jest dzielo-
ne na liczbę użytkowników, a nie kom-
puterów. Opcją rate przydzielamy im
pasmo gwarantowane. Należy pamiętać,
aby suma wartości opcji rate wykorzysta-
nych w tej sekcji nie przekroczyła warto-
ści rate ustalonej dla kolejki nadrzędnej
w sekcji 6). To samo dotyczy opcji ceil. Jeśli
nie chcemy iść na rękę użytkownikom,
a jedynie przydzielić im konkretne pasmo
(czyli jeśli chcemy, aby gwarantowane
pasmo było zarazem maksymalnym), to
możemy zmiennej USER_CEIL przypisać
tę samą wartość, co zmiennej USER.
Czas na ustawienie filtrów, które będą
odpowiadać za kierowanie pakietów do
odpowiednich kolejek. Zaczynamy od
zapewnienia, że pakiety pochodzące
z rutera nie będą podlegały ogranicze-
Algorytmy kolejkowania
O doborze pakietów do wysłania decy-
duje algorytm przypisany do danej kolejki
wyjściowej. Domyślnie jest to najprostszy
algorytm FIFO (First In First Out). Przy
jego wykorzystaniu pakiety są wysyła-
ne w takiej kolejności, w jakiej pojawiły
się w kolejce. To właśnie dlatego użyt-
kownik uruchamiający duże ilości obcią-
żających łącze programów potrafi dopro-
wadzić do sytuacji, gdy korzystanie
z sieci jest dla innych bardzo trudne.
Z tego powodu stworzono inne algoryt-
my, z których możemy korzystać. Należą
do nich między innymi TBF (Token Bucket
Filter), PRIO (Simple Priority Queueing)
czy SFQ (Stochastic Fairness Queueing
– sprawiedliwe kolejkowanie). W dalszej
części będziemy korzystać tylko ze spra-
wiedliwego kolejkowania SFQ.
Kolejka nie musi wykorzystywać
tylko pojedynczego algorytmu. Może ona
wykorzystywać znacznie bardziej złożo-
ny algorytm, podzielony na klasy, z któ-
rych każda ma przyporządkowany inny
algorytm kolejkowania. O tym, które
pakiety przejdą do których klas, decydu-
ją filtry. W ten sposób można rozdzielać
ruch różnego rodzaju, jak również przy-
porządkowywać wybranym pakietom
wyższy priorytet. Do takich złożonych
algorytmów kolejkowania należą między
innymi CBQ (Class Based Queueing)
i HTB (Hierarchical Token Bucket). Ponie-
waż HTB jest szybsze i dokładniejsze niż
CBQ, właśnie z tego algorytmu będzie-
my korzystać.
Do ustawiania algorytmu kolejkowa-
nia (to trochę nieszczęśliwe tłumaczenie
angielskiego queueing discipline – dalej
będziemy zamiennie używać zwrotu dys-
cyplina kolejkowania) służy nam polece-
nie
tc qdisc add
z podanymi parametra-
mi. Analogicznie do tworzenia poszcze-
gólnych klas służy polecenie
tc class
add
, a do tworzenia filtrów
tc filter
add
. Przykłady tych poleceń i ich skład-
nia opisane są w artykule w praktycznych
przykładach.
Rysunek 4.
Po skonfigurowaniu
zarządzania przepustowością możemy
spokojnie czytać strony WWW nawet, gdy
kolega uparcie korzysta z KaZaA
dla początkujących
45
www.lpmagazine.org
dhcp i htb
niom nakładanym na łącze internetowe.
Uzyskujemy to dzięki poleceniu zawarte-
mu w sekcji 8). Warto zwrócić uwagę na
opcję preference 1, dzięki której reguła
ta zostanie rozpatrzona przed umiesz-
czonymi w kolejnych liniach (posiadają-
cymi opcję preference 2). Dzieje się tak,
gdyż opcja ta określa priorytet filtru – im
niższy numer, tym wcześniej będzie roz-
patrzony filtr. Do dopasowania pakietów
wykorzystano filtr u32. Numer kolejki,
do której ma być skierowany dopasowa-
ny pakiet, określony jest opcją flowid.
W analogiczny sposób filtrujemy
pakiety przeznaczone dla poszczegól-
nych komputerów w sieci lokalnej i kie-
rujemy je do odpowiednich kolejek. Zaj-
mują się tym polecenia zawarte w sekcji
9). Warto zwrócić uwagę, że zgodnie
z wcześniejszymi założeniami, pakiety
pobierane przez komputery należące do
jednego użytkownika (np. IP_USER1_1
i IP_USER1_2) kierowane są do tej samej
kolejki. Dzięki temu użytkownik nie
otrzymuje dodatkowego pasma tylko
dlatego, że posiada więcej komputerów.
Wykorzystana w tych liniach opcja pre-
ference 2 sprawia, że linie te są rozpa-
trywane dopiero po linii umieszczonej
w sekcji 8). Gdyby było inaczej, to pod-
czas pobierania przez użytkownika
danych z rutera (a nie z Internetu) trans-
misja odbywałaby się z szybkością prze-
znaczoną dla pobierania danych z Inter-
netu. Ponieważ dysponujemy siecią
o przepustowości 10Mbit, nie miałoby to
większego sensu.
Aby użytkownicy podczas pobie-
rania danych z rutera wzajemnie sobie
nie przeszkadzali, to do klasy 1:3 opisa-
nej w sekcji 6) dodamy jeszcze dyscypli-
nę kolejkowania SFQ (odpowiednia linia
znajduje się w sekcji 10)). W zasadzie
jest wątpliwe, aby w sieci lokalnej ktoś
tak mocno „przytkał” łącze, żeby było to
konieczne, jednak dodatkowa pojedyn-
cza linia w skrypcie nie powinna nam
zaszkodzić.
Analogicznie postępujemy w sekcji
11), gdzie przypisujemy dyscyplinę kolej-
kowania SFQ do każdej z kolejek przy-
dzielonych poszczególnym użytkowni-
kom.
Na tym kończy się działanie skryp-
tu. Możemy go umieścić na przykład w
pliku /etc/rc.d/init.d/rc.htb. Plikowi temu
należy nadać prawa wykonywania (po-
leceniem
chmod u+x /etc/rc.d/init.d/
rc.htb
), a następnie jego wywołanie
możemy umieścić w jednym ze skryp-
tów startowych. Ważne jest, aby skrypt
ten był wykonywany dopiero po podnie-
sieniu wszystkich interfejsów.
Równi i równiejsi
No dobrze, mamy sprawiedliwy podział
łącza, ale jedna z użytkowniczek sieci
tak ładnie się do nas uśmiecha, że nie
mamy sumienia traktować jej na równi
z pozostałymi. Czy można w jakiś sposób
uprzyjemnić jej korzystanie z sieci? Oczy-
wiście.
Narzucającą się od razu myślą jest
zwiększenie wartości opcji rate i ceil
w jej kolejce. Dzięki temu miałaby do
Listing 2.
Przykładowa zawartość pliku rc.htb dla podziału pasma według użytkowników
# 1) określamy przepustowości
CALE=8700kbit
SDI=110kbit
ETH_CEIL=8000kbit
USER=16kbit
USER_CEIL=100kbit
INT_LOC=eth0
# 2) wskazujemy adresy komputerów
IP_SERWER=192.168.100.1
IP_USER1_1=192.168.100.2
IP_USER1_2=192.168.100.3
IP_USER2=192.168.100.6
IP_USER3_1=192.168.100.8
IP_USER4=192.168.100.15
IP_USER5=192.168.100.50
IP_USER3_2=192.168.100.100
IP_USER6=192.168.100.200
IP_USER1_3=192.168.100.205
# 3) usuwamy wszelkie ustawienia qdisc
tc qdisc del root dev
$INT_LOC
# 4) dodajemy obiekt qdisc - htb
tc qdisc add dev
$INT_LOC
root handle 1:0 htb
# 5) tworzymy klasę odpowiadającą całej dostępnej przepustowości sieci lokalnej
tc class add dev
$INT_LOC
parent 1:0 classid 1:1 htb rate
$CALE
ceil
$CALE
# 6) wydzielamy klasy dla transmisji danych z Internetu i z serwera
tc class add dev
$INT_LOC
parent 1:1 classid 1:2 htb rate
$SDI
ceil
$SDI
tc class add dev
$INT_LOC
parent 1:1 classid 1:3 htb rate
$ETH_CEIL
ceil
$ETH_CEIL
# 7) rozdzielamy przepustowość pomiędzy poszczególnych użytkowników
tc class add dev
$INT_LOC
parent 1:2 classid 1:4 htb rate
$USER
ceil
$USER_CEIL
tc class add dev
$INT_LOC
parent 1:2 classid 1:5 htb rate
$USER
ceil
$USER_CEIL
...
# 8) ustawiamy filtr oddzielający transmisję z serwera
tc filter add dev
$INT_LOC
protocol ip preference 1 parent 1:0 u32 match ip src
S
$IP_SERWER
flowid 1:3
# 9) ustawiamy filtry oddzielające transmisję do poszczególnych komputerów w sieciS
lokalnej
tc filter add dev
$INT_LOC
protocol ip preference 2 parent 1:0 u32 match ip dst
S
$IP_USER1_1
flowid 1:4
tc filter add dev
$INT_LOC
protocol ip preference 2 parent 1:0 u32 match ip dst
S
$IP_USER1_2
flowid 1:4
...
# 10) ustawiamy sprawiedliwe dzielenie łącza z serwera
tc qdisc add dev
$INT_LOC
parent 1:3 handle 3:0 sfq perturb 10
# 11) ustawiamy sprawiedliwe dzielenie łączy poszczególnych użytkowników
tc qdisc add dev
$INT_LOC
parent 1:4 handle 4:0 sfq perturb 10
tc qdisc add dev
$INT_LOC
parent 1:5 handle 5:0 sfq perturb 10
...
dla początkujących
46
czerwiec 2004
dyspozycji większą gwarantowaną prze-
pustowość, jak również większe łącze
do wykorzystania. To jednak wiąże się
z koniecznością dokonania kolejnych
przeliczeń i dostosowania wartości w
pozostałych kolejkach.
Możemy rozwiązać to inaczej.
Zwykle jest tak, że nie wszyscy użyt-
kownicy wykorzystują w całości przy-
dzielone im pasmo. W takim przypadku
jest ono rozdzielane po równo pomiędzy
pozostałych, potrzebujących użytkowni-
ków (aż do wartości opcji ceil). Możemy
sprawić, że dodatkowe pasmo będzie
w pierwszej kolejności przydzielane
wskazanej osobie. Wystarczy w sekcji 7)
w każdej linii dopisać opcję prio LICZBA,
gdzie LICZBA określa priorytet danego
użytkownika. Im LICZBA mniejsza, tym
większy priorytet – użytkownik o naj-
wyższym priorytecie będzie miał pierw-
szeństwo podczas rozdzielania dodatko-
wego pasma.
Przypuśćmy, że w liniach z opcjami
classid o wartościach 1:4, 1:5, 1:6 i 1:8
ustawimy opcję prio 2. W linii z classid
1:9 damy prio 1 (to nasza uśmiechnięta
koleżanka), a w linii z classid 1:7 dopi-
szemy prio 3 (to znajomy, który nadep-
nął nam na odcisk). W takim przypad-
ku, jeśli nasza koleżanka będzie ściąga-
ła jakiś duży plik z szybkiego serwera,
a dostępne będzie jeszcze wolne pasmo,
to zostanie ono przydzielone właśnie jej.
Dopiero w następnej kolejności będą
obsłużeni pozostali użytkownicy, a na
samym końcu nasz niegrzeczny kolega
z kolejki 1:7.
Dzielimy według usług
Załóżmy, że nasz serwer udostępnia
jakieś usługi. Może to być serwer WWW,
FTP, czy na przykład SSH. Zapewniliśmy
już komfort korzystania z sieci naszym
użytkownikom lokalnym, ale co z użyt-
kownikami Internetu? Również i o nich
możemy zadbać. Tym razem będziemy
pracować na interfejsie zewnętrznym (w
naszym przykładzie jest to ppp0), gdyż
chcemy kształtować ruch wychodzący
z serwera do Internetu.
W naszym przykładzie dla uprosz-
czenia założymy, że na serwerze udo-
stępniamy tylko usługi WWW i FTP.
Pierwszej z nich przypiszemy przepusto-
wość gwarantowaną 30kbit na sekundę
(z góry ograniczoną tylko przepustowo-
ścią SDI), natomiast drugiej zagwarantu-
jemy taką samą przepustowość (z tą róż-
nicą, że transfer FTP nie będzie większy
niż te gwarantowane 30kbit na sekundę).
Wszystkie pozostałe transmisje wycho-
dzące (a więc również i ruch wychodzą-
cy od użytkowników sieci lokalnej) będą
miały zagwarantowane 20kbit na sekun-
dę z ograniczeniem do maksymalnie
40kbit na sekundę. Dzięki temu wszelkie
programy typu KaZaA nie będą miały
szans zapchać nam łącza wychodzącego.
Na Listingu 3 podane jest przykłado-
we rozwiązanie tego problemu. Zawar-
tość możemy później dopisać do pliku
rc.htb stworzonego w poprzednich roz-
działach, dzięki czemu jeden skrypt
będzie odpowiadał za kształtowa-
nie zarówno ruchu wychodzącego, jak
i przychodzącego.
Zaczynamy od zdefiniowania zmien-
nych zawierających wartości poszczegól-
nych przepustowości. Nazwy SDI, WWW,
FTP i INNE mówią same za siebie. Zmien-
na INNE_CEIL odpowiada za górne ogra-
niczenie pasma dla pozostałego (poza
WWW i FTP) ruchu wychodzącego.
W zmiennej INT_INT zawarta jest nazwa
interfejsu rutera, przez który podłączony
jest do Internetu.
W sekcji 2) kasujemy wszystkie usta-
wienia dotyczące kształtowania ruchu na
interfejsie $INT_INT. Nie należy się oba-
wiać wstawienia tej linii w skrypcie po
stworzeniu regułek dla innego interfej-
su. Polecenie to kasuje ustawienia tylko
i wyłącznie na wskazanym interfejsie.
Polecenie zawarte w sekcji 3) powo-
duje ustawienie HTB jako dyscypli-
ny kolejkowania dla ruchu wychodzą-
cego do Internetu. Warto zauważyć, że
ponownie użyliśmy uchwytu (handle)
1:0. Jest to możliwe, gdyż uchwyty są
numerowane osobno dla każdego inter-
fejsu. Tak więc uchwyt 1:0 na interfejsie
eth0 nie ma nic wspólnego z uchwytem
1:0 na interfejsie ppp0.
Dodatkową ciekawostką jest użycie
w tej sekcji opcji default. Wskazuje ona
klasę domyślną, czyli taką, do której kie-
rowany będzie ruch nie obsłużony przez
filtry – jeśli jakieś pakiety nie zostaną
dopasowane w filtrach, to trafią wła-
śnie do wskazanej tu klasy. Należy jesz-
cze wyjaśnić, w jaki sposób wskazywa-
na jest klasa domyślna. Użyliśmy tutaj
opcji default 4. Ponieważ została ona
użyta w obiekcie o uchwycie 1:0, więc
Listing 3.
Przykładowa zawartość pliku rc.htb dla podziału pasma według usług
# 1) określamy przepustowości i interfejsy
SDI=110kbit
WWW=30kbit
FTP=30kbit
INNE=20kbit
INNE_CEIL=40kbit
INT_INT=ppp0
# 2) usuwamy wszelkie ustawienia qdisc
tc qdisc del root dev
$INT_INT
# 3) dodajemy obiekt qdisc - htb
tc qdisc add dev
$INT_INT
root handle 1:0 htb default 4
# 4) tworzymy klasę odpowiadającą całej dostępnej przepustowości sieci lokalnej
tc class add dev
$INT_INT
parent 1:0 classid 1:1 htb rate
$SDI
ceil
$SDI
# 5) wydzielamy klasy dla transmisji danych z poszczególnych portów
tc class add dev
$INT_INT
parent 1:1 classid 1:2 htb rate
$WWW
ceil
$SDI
tc class add dev
$INT_INT
parent 1:1 classid 1:3 htb rate
$FTP
ceil
$FTP
tc class add dev
$INT_INT
parent 1:1 classid 1:4 htb rate
$INNE
ceil
$INNE_CEIL
# 6) ustawiamy filtry oddzielające transmisję z poszczególnych portów do Internetu
tc filter add dev
$INT_INT
protocol ip parent 1:0 u32 match ip sport 80 0xffff
S
flowid 1:2
tc filter add dev
$INT_INT
protocol ip parent 1:0 u32 match ip sport 20 0xffff
S
flowid 1:3
# 7) ustawiamy sprawiedliwe dzielenie przepustowości poszczególnych usług
tc qdisc add dev
$INT_INT
parent 1:2 handle 2:0 sfq perturb 10
tc qdisc add dev
$INT_INT
parent 1:3 handle 3:0 sfq perturb 10
tc qdisc add dev
$INT_INT
parent 1:4 handle 4:0 sfq perturb 10
dla początkujących
47
www.lpmagazine.org
dhcp i htb
klasą domyślną będzie klasa o uchwy-
cie 1:4 (numer powstaje przez złożenie
uchwytu obiektu i numeru podanego w
opcji default). Klasa ta zdefiniowana jest
w sekcji 5).
Sekcja 4) to znane nam już polecenie
tworzące główną klasę odpowiedzialną
za przypisanie przepustowości gwaran-
towanej i maksymalnej całego łącza do
Internetu.
Następnie w sekcji 5) tworzymy pod-
klasy odpowiadające za kolejkowanie
ruchu odpowiednich usług.
O tym, jakie pakiety znajdą się w
odpowiednich kolejkach, decydują filtry
zdefiniowane w sekcji 6). Objaśnienie
użytej tu konstrukcji filtru znajduje się
na końcu rozdziału Równi i równiej-
si. Ruch wychodzący z portu numer 80
(a więc WWW ) kierowany jest do klasy
1:2, natomiast wychodzący z portu 20
(FTP) do klasy 1:3. Nie ma filtru kieru-
jącego pakiety do klasy 1:4. Za to wła-
śnie odpowiada opcja default 4 zawar-
ta w sekcji 3).
Sekcja 7) kończy skrypt ustawiając
na poszczególnych klasach sprawiedliwy
algorytm kolejkowania SFQ.
Konfigurator podziału
pasma
Jeśli nie mamy ochoty na własnoręczne
wyliczenia i wpisywanie kolejnych regu-
łek, możemy skorzystać z pomocy konfi-
guratora. Michał Łukaszek napisał bardzo
użyteczny skrypt rchtb, który można zna-
leźć na stronie http://www.rc.htb.prv.pl/.
W chwili pisania artykułu serwis wciąż
jeszcze odczuwał skutki awarii, lecz sam
skrypt (w najbardziej aktualnej wersji
0.3.3) został udostępniony do pobrania.
Instalacja
Po pobraniu pliku na dysk należy rozpa-
kować go poleceniem
tar xvzf rchtb-
0.3.3.tar.gz
. W wyniku zostanie utwo-
rzony katalog rchtb/, a w nim umiesz-
czona zawartość archiwum. Na początku
należy zapoznać się z plikami README
i INSTALL, w których opisany jest sposób
wykorzystania skryptu oraz możliwe pro-
blemy.
Najpierw należy zadbać, aby w sys-
temie znajdowały się następujące narzę-
dzia: tree, grep, cut, dialog, ls, where
is, cat (w przypadku Auroksa 9.3 znaj-
dują się one w pakietach tree-1.4b3-
1.i386.rpm,
grep-2.5.1-17.4.i386.rpm,
dialog-0.9b-20031002.1.i386.rpm, coreu-
tils-5.0-24.i386.rpm,
util-linux-2.11y-
29.i386.rpm, znajdujących się na pierw-
szej, drugiej i czwartej płytce instalacyj-
nej). Jeśli któregoś z tych narzędzi bra-
kuje, to należy doinstalować odpowied-
ni pakiet.
Wskazywanie użytkowników
sieci
Następnym krokiem jest przygotowanie
spisu komputerów, pomiędzy które ma
być dzielone pasmo. Umieszczamy go
w pliku /etc/rchtb/htbusers.conf (w tym
celu powinniśmy pracować z uprawnie-
niami administratora). Jego zawartość
odpowiadająca naszemu przykładowi
przedstawiona jest na Listingu 4. Jak
widać, jego składnia jest bardzo prosta.
Pojedynczy komputer opisywany jest
jedną linią składającą się z adresu IP
i odpowiadającej mu nazwy symbolicz-
nej. Nazwa ta może być taka sama, jak
w pliku /etc/hosts. Jeśli kilka kompute-
rów ma korzystać ze wspólnego pasma,
to należy je przydzielić do jednej grupy.
Robimy to umieszczając ich wpisy
pomiędzy liniami
NewGroup NazwaGru-
py
i
EndGroup
. Pamiętajmy, aby w pliku
/etc/rchtb/htbusers.conf nie umieszczać
wpisu odnoszącego się do samego ser-
wera, na którym będzie realizowane
dzielenie pasma.
Po stworzeniu odpowiednich wpisów
w pliku /etc/rchtb/htbusers.conf pozosta-
je nam uruchomienie właściwego skryp-
tu konfiguratora. Dokonujemy tego prze-
chodząc do katalogu rchtb/, w którym
wydajemy polecenie
./rchtb_configure
.
Parametry łączy
Pierwsze pytanie dotyczy katalo-
gu, do którego ma zostać skopiowa-
ny plik rchtb_tc dostarczony w pliku
rchtb-0.3.3.tar.gz. Możemy go użyć
jako zamiennika programu tc pocho-
dzącego z pakietu iproute2. Jest to
szczególnie użyteczne, gdy posiadamy
starszą wersję pakietu iproute2, nie
wspierającą HTB. Program rchtb_tc
został skompilowany z obsługą HTB,
ESFQ oraz WRR. Najlepiej wybrać zale-
caną lokalizację, czyli katalog /usr/
sbin/.
Kolejną decyzją, którą musimy
podjąć, to wskazanie interfejsu siecio-
wego wykorzystywanego do łączenia
z Internetem (w naszym przykładzie
jest to interfejs ppp0). Jeśli na spisie
nie ma jakiegoś interfejsu, należy
opuścić program (dwukrotnie wci-
skając klawisz [Esc]), a następnie
podnieść interfejs poleceniem
ifup
nazwa_interfejsu
. Po wykonaniu tej
czynności można od nowa uruchomić
skrypt.
W analogiczny sposób wskazujemy
interfejs służący do połączenia z siecią
lokalną. W naszym przykładzie jest to
eth0.
Czwarte pytanie dotyczy przepu-
stowości naszego łącza do Interne-
tu. Mamy do wyboru kilka standardo-
wych pozycji, między innymi SDI (które
wybralibyśmy w naszym przykładzie),
kablówkę (w wersji 128/128), Neo-
stradę+, jak również DSL 1Mbit. Jeśli
żaden z proponowanych wyborów nam
nie odpowiada, możemy wskazać pozy-
cję Inne łącze, po czym zostaniemy
poproszeni o podanie prędkości down-
loadu i uploadu w kilobitach na sekun-
dę.
Analogicznie określamy przepu-
stowość sieci lokalnej, tym razem
w megabitach na sekundę. Do
wyboru mamy Ethernet (10 Mbit), Fast
Ethernet (100 Mbit) oraz Gigabit Ether-
net (1000 Mbit). Oprócz tego możemy
samodzielnie
określić
przepusto-
wość wybierając pozycję Inna prze-
pusowość W opisywanym przykładzie
właściwym wyborem jest Ethernet 10
Mbit.
Następnie otrzymujemy informa-
cję, jakie wartości parametrów przyję-
to dla poszczególnych interfejsów. Warto
zauważyć, że w przypadku łącza interne-
towego wartości uploadu i downloadu
zostały automatycznie nieco zmniejszone
w porównaniu do podanych przez nas
parametrów łącza.
Listing 4.
Zawartość przykładowego
pliku /etc/rchtb/htbusers.conf
NewGroup
user1
192.168.100.2 user1_1
192.168.100.3 user1_2
192.168.100.205 user1_3
EndGroup
192.168.100.6 user2
NewGroup
user3
192.168.100.8 user3_1
192.168.100.100 user3_2
EndGroup
192.168.100.15 user4
192.168.100.50 user5
192.168.100.200 user6
dla początkujących
48
czerwiec 2004
Klasy dla użytkowników
W kolejnym oknie zapoznamy się z gra-
ficznym przedstawieniem zawartości
pliku /etc/rchtb/htbusers.conf. Jeśli coś
się nie zgadza, powinniśmy przerwać
działanie skryptu (podwójnym wciśnię-
ciem klawisza [Esc]) a następnie popra-
wić wpisy w pliku.
Następnie należy wybrać algorytm,
który będzie stosowany do zapewnie-
nia, że użytkownicy nie „przytkają”
sobie przydzielonego im pasma urucha-
miając np. programy P2P. Do wyboru
mamy SFQ i ESFQ. Ze względu na to,
że zastosowanie ESFQ wymaga nakła-
dania łaty na jądro, zastosujemy SFQ,
które jest domyślnie wspierane w obec-
nych jądrach.
Pozostaje nam wskazanie programu
tc, który pozwala na definiowanie reguł
kontroli ruchu. Możemy spokojnie sko-
rzystać z domyślnego rchtb_tc, dostarcza-
nego w pakiecie z rchtb.
Ponieważ skrypt tworzy klasę prio-
rytetową, do której skierowane zosta-
ną wybrane pakiety (te z TOS ustawio-
nym na Minimal Delay) i cały ruch ICMP,
możemy dodatkowo określić jeden port
TCP, z którego ruch trafi do tej klasy.
Domyślnie jest to port 22 wykorzystywa-
ny przez usługę SSH -- dzięki temu nawet
przy znacznym obciążeniu łącza korzy-
stanie z SSH nadal powinno być kom-
fortowe.
W kolejnym oknie wybieramy mini-
malną wartość, jaką mają być znakowane
pakiety użytkowników. Jeśli nie stosuje-
my jeszcze żadnego znakowania na zapo-
rze sieciowej (firewall), to możemy pozo-
stawić domyślną wartość.
Możemy teraz zapoznać się z dotych-
czasowymi wyliczeniami. Dowiemy się,
na ile klas zostanie podzielone pasmo,
oraz jaką gwarantowaną przepustowość
ma każda klasa. Na tym etapie wskazu-
jemy też, czy skrypt ma dodać osobną
klasę na użytek serwera pośredniczą-
cego Squid. W naszym przykładzie
nie stosujemy Squida, więc wybieramy
opcję brak.
Ruch wychodzący
Czas określić przepustowość gwa-
rantowaną dla klientów chcących
połączyć się z naszym serwerem z
Internetu. Wartość tą podajemy jako pro-
cent rozmiaru pasma wychodzącego.
Domyślnie jest to 30% . Jeśli nie
zamierzamy uruchamiać na serwe-
rze żadnych usług (np. WWW, FTP lub
innych), to możemy wpisać 0. W takim
przypadku klienci z zewnątrz nie
będą mieli gwarantowanej przepusto-
wości.
Podobnie jak w przypadku ruchu
przychodzącego, tworzona jest klasa
priorytetowa. Możemy podać jeden
numer portu TCP, do którego ruch będzie
do niej kierowany. Domyślnie jest to port
SSH, o numerze 22.
Wykorzystanie skryptu
Na tym kończą się pytania zadawa-
ne przez konfigurator. W wyniku jego
działania w katalogu rchtb/ready/ zosta-
ły utworzone dwa pliki: rc.htb oraz
fwmarks.htb. Pierwszy z nich zawie-
ra skrypt odpowiadający za ustawie-
nie podziału pasma według naszych
wytycznych. Można umieścić go np. w
katalogu /etc/rc.d/init.d/ (poleceniem
cp
rc.htb /etc/rc.d/init.d/
) lub w innym
katalogu, gdzie przechowujemy skrypty
startowe. Dzielenie pasma uruchamiamy
wydając polecenie
/etc/rc.d/init.d/
rc.htb
start
, natomiast zatrzymu-
jemy poleceniem
/etc/rc.d/init.d/
rc.htb stop
. Wywołanie tego skryptu
można dodać do skryptów startowych.
Należy jednak pamiętać, aby urucha-
miany był on dopiero w momencie,
gdy wszystkie interfejsy sieciowe są już
postawione.
Drugi plik, czyli fwmarks.htb, zawie-
ra regułki iptables służące do znakowa-
nia poszczególnych pakietów. Regułki
te są konieczne do poprawnego funk-
cjonowania niektórych filtrów zdefi-
niowanych w pliku rc.htb. Również
jego można skopiować do katalogu
/etc/rc.d/init.d/ i uruchamiać polece-
niem
/etc/rc.d/init.d/fwmarks.htb
start
(do zatrzymania służy parametr
stop
).
Zakończenie
W ten sposób dotarliśmy do końca.
Mam nadzieję, że korzystając z powyż-
szych wskazówek, każdy Czytelnik
będzie w stanie skonfigurować u siebie
podstawowy serwer DHCP oraz kształ-
tować ruch sieciowy według swoich
potrzeb. Gorąco zachęcam do lektury
materiałów dostępnych w sieci i głęb-
szego poznawania przedstawionych tu
narzędzi.
Rysunek 5.
Poprawne wprowadzenie
danych o komputerach w sieci jest bardzo
ważne
W Internecie:
• DHCP mini-HOWTO:
http://www.tldp.org/HOWTO/DHCP/
index.html
• Konfiguracja demona DHCP:
http://www.baseciq.org/linux/dhcp/
• DHCP + ARP:
http://linux.insurgents.net/artykuly/
dhcp_arp.htm
• DHCP – opis protokołu i konfiguracja
serwera pod Linuksem:
http://www.pckurier.pl/archiwum/
art0.asp?ID=707
• Strona domowa HTB:
http://luxik.cdi.cz/~devik/qos/htb/
• Podręcznik użytkownika HTB:
http://luxik.cdi.cz/~devik/qos/htb/
manual/userg.htm
• Opis teorii działania HTB:
http://luxik.cdi.cz/~devik/qos/htb/
manual/theory.htm
• Kilka interesujących dokumentów
o kształtowaniu ruchu:
http://www.docum.org/
• Kształtowanie Ruchu
i Zaawansowany Routing HOWTO:
http://lukasz.bromirski.net/docs/
translations/lartc-pl.html
• Zaawansowany routing IP w Linuksie:
http://echelon.pl/pubs/NET4.pdf
• Sterowanie przepływem danych w
Linuksie:
http://echelon.pl/pubs/NET4_tc.pdf
• HTB – strażnik trafficu:
http://linio.terramail.pl/htb.html
• Kompilacja kernela 2.4.24 z iptables
i iproute2 + HTB:
http://newbie.linux.pl/wydruk.php?
wydruk=170&show=artykul
• HTB w Debianie "Woody"
z Neostradą+:
http://www.debianusers.pl/article.
php?aid=54&top10=1
• Strona domowa skryptu rc.htb:
http://www.rc.htb.prv.pl/
• Skrypty HTB + iptables:
http://endemic.org/htb/