W ramach swojej pracy magisterskiej zaprojektowałem i zaimplementowałem
program służący do monitorowania sieci komputerowych. System monitorowania
sieci umożliwia między innymi śledzenie i analizowanie ruchu pakietów w
sieci komputerowej. Pozwala na znajdowanie błędów w istniejącej konfiguracji
sieci i jej składowych. Jest przede wszystkim bardzo użytecznym narzędziem
do rozwijania i pielęgnacji sieciowego oprogramowania.
Niniejszą pracę podzieliłem na trzy rozdziały. Rozdział pierwszy jest
poświęcony narzędziom do monitorowania sieci komputerowych. W rozdziale
drugim opisuję mechanizm Packet Filter (w skrócie: PF) firmy DEC.
Służy on do wyłapywania i rozpoznawania pakietów sieciowych. Jego kod
rezyduje w jądrze systemu operacyjnego. PF pozwala programom użytkowym na
bezpośredni dostęp do sieci z pominięciem pośrednictwa jądra. Trzeci rozdział
zawiera opis systemu do monitorowania sieci.
W późnych latach siedemdziesiątych sieci komputerowe zaczęły się rozrastać
z prostych, małych i odizolowanych sieci komputerowych do dużych sieci,
które stopniowo zaczęto ze sobą łączyć. Te duże sieci nazwano internetem",
a ich rozmiar rósł w tempie wykładniczym.
Zaczęły powstawać narzędzia i systemy pozwalające monitorować i zarządzać
siecią. Pozwalają one lepiej zrozumieć działanie protokołów sieciowych,
wykryć błędy w konfiguracji sieci, czy tablicach trasowania.
Monitorowanie sieci można podzielić na pasywne i aktywne. Monitorowanie
pasywne polega na obserwowaniu sieci i obiektów sieciowych bez bezpośredniego
oddziaływania na ich stan. Monitorowanie aktywne, zwane zarządzaniem, pozwala
też zmieniać stan obiektów monitorowanych, oddziaływać na nie bezpośrednio.
1.2 MONITOROWANIE PASYWNE
Monitorowanie pasywne dzieli się na obrazujące w czasie rzeczywistym komunikację
sieciową i na retrospektywne, korzystające z wcześniej zgromadzonych danych.
Programy monitorujące w czasie rzeczywistym ruch pakietów sieciowych wymagają
dostępu z poziomu użytkownika do warstwy sieci. Potrzebują więc wydajnego mechanizmu
wyłapywania pakietów sieciowych. Jednym z bardziej znanych mechanizmów jest filtr
pakietów, dla którego istnieje wiele implementacji, między innymi NIT (ang. Network
Interface Tap) w SunOS, Snoop w IRIX i PF w Ultrix i Digital Unix. Przykładami
aplikacji do monitorowania sieci w czasie rzeczywistym są etherman", interman"
i packview", a także zaimplementowany przeze mnie program. Działanie tego typu
programów można w skrócie opisać następująco. Przy użyciu PF lub innego mechanizmu
dostępu do sieci wyłapują one pakiety sieciowe, które poddają analizie. Gromadzone
w ten sposób dane statystyczne wyświetla się na bieżąco w postaci graficznej.
Oprogramowanie monitorujące retrospektywnie korzysta z danych zgromadzonych przez siebie
lub inne programy. Z takich danych korzystają między innymi programy wizualizujące sieć.
Wizualizacja jest procesem, w wyniku którego buduje się model istniejącej sieci i obrazuje
w zrozumiałej i czytelnej formie. Prezentowane informacje mogą np. opisywać topologię
sieci. Przykładem takiego programu jest Tkined".
1.3 ZARZĄDZANIE SIECIĄ
Międzynarodowa Organizacja Standaryzacyjna zdefiniowała pięć kluczowych obszarów
zarządzania siecią: zarządzanie błędami, bezpieczeństwem, wydajnością, konfiguracją i
kontami. Zarządzanie siecią można zdefiniować jako proces kompleksowego kontrolowania
danych sieci w celu zwiększenia jej wydajności i produkcyjności.
Jednym z takich całościowych komercyjnych systemów do zarządzania siecią jest NETVIEW
firmy IBM. Bazuje on na protokole SNMP, który zaprojektowano w celu umożliwienia zdalnego
zarządzania elementami sieci TCP/IP i monitorowania zdarzeń sieciowych. SNMP jest oparty
na UDP (ang. User Datagram Protocol).
NETVIEW, jak i każde oprogramowanie wykorzystujące SNMP, pracuje w modelu klient - serwer.
Składa się ono z klienta, zwanego zarządcą, uruchamianego zazwyczaj w węźle sieciowym,
z którego chcemy nadzorować sieć, oraz z serwera lub serwerów, zwanych agentami,
umiejscowionych na różnych urządzeniach sieciowych.
Zarządca komunikuje się z agentami przy użyciu poleceń odczytu/zapisu. Poprzez odczytywanie
uzyskuje dostęp do posiadanych przez agenta informacji a poprzez zapisywanie steruje pracą
urządzenia sieciowego, na którym działa agent.
Informacja zarządzana przez agenta ma strukturę drzewiastą, której wartościami są zmienne.
Definiuje ją standard MIB (ang. Management Information Base). Określa on między innymi,
które zmienne muszą być udostępniane przez każdego agenta SNMP. Wierzchołkiem tego drzewa
jest najogólniejsza informacja dostępna o sieci. Każda z gałęzi daje bardziej szczegółowe
dane o specyficznym obszarze sieci. Przykładowo, urządzenia mogą być rodzicami w takim
drzewie, ich dzieci urządzeniami równoległymi i szeregowymi. Wartościami dla nich mogą być
odpowiednio cyfry 6, 2, 4 odnoszące się do liczby przyłączonych urządzeń
(4 równoległe + 2 szeregowe = 6 urządzeń). Do każdego węzła w strukturze drzewiastej MIB
można odwoływać się jak do zmiennej (w powyższym przykładzie urządzenia, urządzenia
równoległe i urządzenia szeregowe są zmiennymi o wartościach odpowiednio 6, 2, 4). Główne
sieciowe drzewo MIB jest określane jako Internet".
Jest tylko jedno drzewo MIB zdefiniowane przez organizację ISO, chociaż częściami tego drzewa
są sekcje przeznaczone na rozszerzenia. Niektóre firmy, takie jak IBM, HP, SUN dostarczają
własne rozszerzone struktury zmiennych MIB. Nazwy tych zmiennych mogą się różnić, ale mimo
że pochodzą od różnych dostawców, przenoszona przez nie informacja jest generalnie ta sama.
PF służy do wysyłania i odbierania pakietów sieciowych. Odbieranie polega na
podglądaniu" pakietów płynących siecią i przekazywaniu każdego, który spełnia
określone kryteria, do procesu docelowego. Można to nazwać demultipleksacją,
filtrowaniem czy też rozpoznawaniem pakietów sieciowych, a PF - demultiplekserem
pakietów sieciowych. Mechanizm ten pozwala programom użytkowym na bezpośredni
dostęp do sieci z pominięciem pośrednictwa jądra.
PF to nazwa produktu firmy DEC. Jego implementacje występują między innymi w
systemie operacyjnym IRIX, Ultrix, Digital Unix i SunOS. Kod PF rezyduje w
jądrze systemu operacyjnego.
PF daje wygodną możliwość tworzenia protokołów sieciowych, których obsługa ma
miejsce poza jądrem systemu operacyjnego. Zrealizowano wiele implementacji
protokołów bazujących na PF i przeprowadzono testy wydajnościowe porównujące je do
analogicznych implementacji rezydujących w jądrze systemu operacyjnego.
2.2 MOTYWACJE
Wraz z rozwojem sieci komputerowych i technologii informatycznych oprogramowanie
realizujące protokoły sieciowe staje się coraz ważniejsze i bardziej rozbudowane.
Standardem jest występowanie kodu implementującego protokoły sieciowe w jądrze
systemu operacyjnego. I tak na przykład w 4.3 BSD UNIX 30% źródeł jądra
stanowi implementacja protokołów sieciowych, 32% w V-system.
Rozwój takiego sieciowego oprogramowania jest jednak wolny i często opóźnia
ukazanie się nowej wersji systemu operacyjnego. Znajdowanie błędów trwa jeszcze
długo po oddaniu systemu do produkcji. Przeciągające się testowanie produkcyjnego
kodu nie jest jedynie rezultatem błędów w oryginalnym kodzie. Wpływa na nie również
dynamiczny rozwój protokołów sieciowych i środowiska sieciowego. Powoduje to duże
trudności w pisaniu, poprawianiu i znajdowaniu błędów, gdyż po znalezieniu błędu,
jądro musi być rekompilowane, a system na nowo uruchamiany; błędy w kodzie jądra
najczęściej są przyczyną awarii systemu; funkcjonalnie niezależne moduły jądra
komunikują się przez zasoby dzielone; uzdatnianie (ang. debugging) dodaje pracy
programistom systemowym, wyrafinowane narzędzia do testowania i monitorowania nie
zawsze są dostępne przy tworzeniu kodu jądra; źródła kodu jądra nie zawsze są dostępne.
Jednym z rozwiązań alternatywnych pozbawionym powyższych wad jest wydzielenie poza
jądro kodu demultipleksera i obsługi protokołu sieciowego. Jest ono jednak kosztowne,
bo dla każdego otrzymanego pakietu system musi przełączyć się do procesu
demultipleksera, potem zarejestrować proces przetwarzania pakietu i znowu przełączyć
się po uprzednim dostarczeniu przetworzonego pakietu do procesu odbierającego
2.3 INTERFEJS UŻYTKOWNIKA
Komunikacja programu użytkownika z PF występuje głównie przy wysyłaniu i odbieraniu
pakietu. Wysyłanie pakietu do sieci jest proste. Użytkownik otwiera do pisania
najpierw deskryptor plików skojarzony z PF poprzez wywołanie funkcji systemowej
pfopen". Potem dostarcza do PF bufor zawierający kompletny pakiet poprzez wywołanie
funkcji systemowej write" na wcześniej otwartym deskryptorze plików. Jeśli operacja
ta nie kończy się błędem, to powoduje wstawienie pakietu na koniec kolejki pakietów
czekających na transmisję. Brak odpowiedzi sygnalizuje błąd w transmisji.
Odbieranie pakietu z sieci jest bardziej złożone. PF zarządza pewną liczbą portów,
z których każdy może być otwarty przez program użytkownika jako znakowy plik specjalny".
Z każdym takim portem jest skojarzony filtr decydujący, które pakiety należy
zaakceptować, a które odrzucić. Jeżeli filtr akceptuje pakiet, to jest on gotowy
do odebrania w porcie skojarzonym z danym filtrem. Filtr konfiguruje się w programie
użytkownika. Łączenie filtru z portem odbywa się poprzez wywołanie funkcji systemowej
ioctl". Gdy program wywoła funkcję systemową read" na deskryptorze plików odnoszącym
się do portu PF, to otrzyma pierwszy pakiet z kolejki skojarzonej z tym portem. Program
użytkownika ma też możliwość wsadowego odbierania pakietów. Wówczas otrzymuje wszystkie
oczekujące w kolejce pakiety, co może mieć spore znaczenie w przypadku dużej komunikacji
sieciowej, gdyż minimalizuje liczbę wywołań funkcji systemowej read".
2.4 PODSUMOWNANIE
W systemach, gdzie koszt zmiany kontekstu jest duży, wydajność protokołów sieciowych
poza jądrem opartych na PF jest akceptowalna. Wtedy znacznie upraszcza się proces ich
tworzenia i implementacji.
Jednak w większości systemów, ze względu na wydajność, standardem jest realizacja stosu
protokołów sieciowych w jądrze systemu operacyjnego. Zdarzają się implementacje
niektórych protokołów oparte na PF. Z jednej strony odciążają jądro od obsługi tych
protokołów. Zwiększa się wówczas efektywność pracy jądra. Z drugiej strony wysoka
wydajność takiej implementacji nie zawsze jest najważniejsza. Szczególnie wtedy, gdy
te protokoły nie generują częstego ruchu w sieci.
PF pozwala więc programom użytkowym przede wszystkim na bezpośredni dostęp do sieci.
Jest łatwy w użyciu i oferuje przyzwoitą wydajność. Dlatego wykorzystuję go w swoim
programie do filtrowania wszystkich pakietów IP.
W zależności od implementacji monitor sieciowy może spełniać mniej lub bardziej złożone
funkcje. Jeśli monitoruje się niewielką sieć lokalną, to interesujące są bardziej
szczegółowe informacje, np. dlaczego dwa węzły nie mogą się porozumieć przy użyciu danego
protokołu, który węzeł generuje największy ruch w sieci, jakie są dominujące protokoły.
Gdy monitoruje się dużą sieć komputerową, to zbyt szczegółowe dane mają mniejsze znaczenie.
Istotniejsze jest wówczas, jak wygląda komunikacja między spójnymi obszarami dużej sieci.
Dzięki takiemu systemowi można w porę otrzymać informację o tym, że któryś z ruterów nie
działa, że opisane tablice trasowania w naszej sieci nie są optymalne, co jest przyczyną
nierównomiernego rozłożenia ruchu w sieci. Taki system monitorowania jest najczęściej
składową lub systemem wspomagającym dla większego systemu do zarządzania siecią komputerową.
System monitorowania siecią komputerową składa się zazwyczaj z pewnej grupy procesów
(zwanych agentami) zbierających informacje z sieci i procesu klienta (zarządcy)
wyświetlającego dane odebrane od agentów.
3.2 KOMUNIKACJA MIĘDZY AGENTEM A KLIENTEM
Bazą dla systemu monitorowania jest sieć komputerowa, która może być niewielką siecią lokalną
lub też nawet wielką siecią korporacyjną obejmującą fizycznie odległe od siebie obszary.
Sieć taka korzysta zazwyczaj z protokołów z rodziny TCP/IP. Do komunikacji między klientem
a agentem służy najczęściej protokół SNMP lub specjalnie do tego celu zaprojektowany protokół
wyższego poziomu, położony nad warstwą protokołów TCP/UDP. Za jego pomocą, po nawiązaniu
połączenia, od procesu agenta do klienta są przesyłane pewne informacje kontrolne, czy też
struktury danych będące nośnikiem wszelkich informacji o pakietach przechwyconych przez agenta.
Do komunikacji między klientem a agentem zaprojektowałem własny protokół położony nad warstwą
transportową. Co sekundę dane o pakietach odebranych przez agenta są przekazywane do
klienta. Zawierają one informacje o liczbie pakietów odebranych w ciągu ostatniej sekundy i
ich sumarycznych rozmiarach z podziałem na protokoły IP, TCP, UDP i ICMP. Program klienta
wykorzystuje je do tworzenia wykresów obrazujących aktywność pakietów sieciowych.
3.3 AGENT
Agent jest procesem uruchamianym w węźle sieciowym. Najlepiej uruchomić agenta na jednym z
interfejsów sieciowych rutera, czyli węzła sieciowego odpowiedzialnego za kierowanie ruchem
pakietów w sieciach, które łączy. W celu śledzenia ruchu sieciowego we wszystkich sieciach
połączonych z danym ruterem uruchamia się odpowiednią liczbę procesów agenta. Obszarem
zainteresowania agenta może być wszelki ruch występujący w sieci lokalnej, do której przyłączony
jest system komputerowy.
Interfejs sieciowy zwykle odbiera tylko te pakiety, które są przeznaczone dla niego, tzn. albo
jest ich adresatem, albo są to pakiety wysyłane w trybie rozgłoszeniowym. Byłoby to
niewystarczające, gdyż system monitorujący powinien umieć śledzić cały ruch w sieci.
Na szczęście w sieciach lokalnych, takich jak Ethernet czy Token Ring, każdy wysłany pakiet
może być odebrany przez każdy węzeł w danej sieci. Wystarczy tylko, by karta sieciowa takiego
węzła nie ignorowała pakietów nie przeznaczonych dla niej. Taką kartę sieciową można programowo
przełączyć na tryb pracy, w którym będzie odbierała wszystkie pakiety. W większości systemów
operacyjnych proces agenta musi mieć odpowiednie uprawnienia w celu przestawienia trybu pracy
karty, np. w systemie UNIX proces przełączający kartę w powyższy tryb musi być wykonany z
prawami nadzorcy.
Agent mego systemu monitorującego jest napisany w języku C. Można go uruchomić na dowolnym systemie
operacyjnym Unix, na którym zainstalowano mechanizm PF.
3.4 KLIENT
Klient jest procesem, który komunikuje się z agentem w celu otrzymywania danych. Dane te może
jednocześnie wyświetlać w postaci graficznej. Środowiskiem pracy klienta może być np. dowolny
system okienkowy taki jak X Windows, Windows 95, Windows NT, OS/2 czy stacja sieciowa. Klient
może też sterować pracą agentów, np. wysyłając do nich żądania przekazania mu zebranych śladów
pakietów czy też śledzenia pakietów o zadanej specyfikacji.
Klient mego systemu monitorującego jest napisany w całości w języku Java. Można go uruchomić na
dowolnej stacji graficznej, na której zainstalowano pakiet JDK w wersji co najmniej 1.1.1 lub
inne środowisko Javy z przeglądarką do apletów Java (program Netscape począwszy od wersji 2.0
jest wystarczający).
Po uruchomieniu programu klienta wyświetla się okno z diagramem, na którym mogą rysować się wykresy
dla protokołów IP, TCP, UDP i ICMP (domyślnie rysuje się tylko jeden wykres dla protokołu IP).
Pokazują one (dla poszczególnych protokołów) w kilobajtach ilość danych odebranych z sieci
przez program agenta w danej sekundzie. Wykresy uaktualniają się co sekundę wraz z otrzymywaniem
nowych informacji od programu agenta. Wówczas wylicza się położenie punktu na diagramie dla każdego
protokołu. Rysowanie wykresu odbywa się poprzez łączeniem odcinkiem takiego punktu z
naniesionym na wykres punktem sekundę wcześniej. Można uaktywnić dodatkowe okno z diagramem,
na którym będą się rysować analogiczne wykresy pokazujące (dla poszczególnych protokołów) ilość
pakietów odebranych z sieci przez program agenta w danej sekundzie.
Dla obu diagramów istnieje możliwość wyboru wyświetlanych wykresów a także zmiany zarówno
w pionie, jak i w poziomie szczegółowości wyświetlanych danych.
3.5 PROPOZYCJE ROZSZERZEŃ
Klient jest programem wizualizującym odbierane dane. Nie uczestniczy jednak w ich powstawaniu.
Można do niego dodać elementy interakcji z użytkownikiem, które pozwolą tworzyć nowe filtry.
Taki filtr mógłby następnie na żądanie klienta zostać zainstalowany przez program agenta.
W ten sposób użytkownik miałby dostęp do danych zebranych przez agenta z wielu zainstalowanych
filtrów. Program klienta mógłby również wysyłać do agenta inne żądania, np. zbierania śladów
pakietów sieciowych i przesyłania ich do klienta - klient stałby się wówczas programem
sterującym pracą agenta.
Nowe właściwości klienta wymagałyby zmian agenta, klienta i protokołu komunikacyjnego. Po
stronie agenta nie byłoby ich zbyt wiele, gdyż np. agent potrafi już instalować filtry.
Większe zmiany dotyczyłyby samego protokołu komunikacyjnego i jego interfejsów od strony
agenta i klienta.
Wreszcie protokołem komunikacyjnym, tak jak w większości systemów komercyjnych tego typu,
mógłby być SNMP. Pozwoliłoby to klientowi na dostęp do informacji pochodzącej od innych
agentów, np. wyspecjalizowanych urządzeń sieciowych takich jak rutery, na których powszechne
stało się instalowanie agentów SNMP z własną, zgodną ze standardem strukturą MIB. Dlatego też
możliwe jest zdalne sterowanie nimi przy użyciu protokołu SNMP. Agent SNMP może przekazywać
informacje o stanie struktury MIB przy użyciu protokołu SNMP autoryzowanym zarządcom SNMP.
Taki zarządca ma też możliwość sterowania pracą agenta. Standardowe obiekty MIB nie dostarczają
jednak zbyt wielu statystyk dla protokołów. To rozwiązanie, choć bardziej standardowe, byłoby
mniej elastyczne niż zastosowanie agenta wykorzystującego PF, gdyż taki agent ma dostęp do
wszelkich informacji o pakietach płynących siecią i o ich budowie.