Zadanie
Analiza protokołów MAC, IP, UDP oraz przepustowości
Używając oprogramowanie RouterOS wygenerować ruch sieciowy UDP z portu 10000 -> 20000, TTL3, 1000PPS, rozmiar pakietu 1024 bajty.
– zakładamy, że na hoście docelowym nie pracuje żadna usługa na porcie UDP 20000
– jakie warstwy i protokoły modelu OSI biorą udział w takim ruchu
– jakiej wielkości są dane w każdej warstwie OSI biorącej udział w takim ruchu
– jakiej wielkości są nagłówki pakietów a jakie sekcje danych
– jakiej odpowiedzi udziela host na taki pakiet
– jaką przepustowość konsumuje taki ruch
– ile % tego ruchu przenieść może faktyczne dane użytkownika
– jakie jest obciążenie routera i z czego wynika
– czy z hosta jest generowana do nadawcy jakaś odpowiedź na każdy pakiet
– jeśli tak to jaki i w jakim celu
– kolejno sprawdzić tan sam rodzaj ruchu ale na port z pracującą usługą np. serwer DNS czy coś innego
– czy host
1. Konfiguracja Trafic Generator na RouterOS
1a. Budowa pakietu
1b. Przygotowanie strumienia danych
2. Uruchomienie transmisji
3. Przechwycenie ruchu na hoście docelowym
4. Analiza przechwyconych danych
5. Analiza transferu podczas działania generatora
Tworzymy sieć jak niżej
rysunek 1
Lub w przypadku radia (będzie to miało znaczenie w dalszej części)
rysunek 2
Na urządzeniu R1 mamy MikroTik RouterOS, na Linux mmy dowolny system Linux z zainstalowanym analizatorem pakietów np Wireshark.
1. Konfiguracja Trafic Generator na RouterOS (R1)
1a. Budowa pakietu
– Z menu Tool wybieramy Traffic Gnerator
– Celem przygotowania pakietu zgodnie z założeniami klikamy w Packet Template i dodajmy nowy szablon pakietu
Zakładka General
— ustalamy nazwę
— stos nagłówków zostawiamy bez zmian (tak jak zdefiniowane są z OSI: najniżej MAC, nad nim IP i nad nim UDP)
— aby pole danych pakietu było wypełnione danymi do łatwej identyfikacji ustalimy je na powtarzające się ciągi FA (szesnastkowo)
— inne opcje tej pozycji pozwolą wygenerować dane w sposób losowy ale to zwiększy obciążenie generatora a tym samym bardziej może wpłynąć na samo generowanie ruchu zwłaszcza gdy jego wolumeny będzie duży; te dane zobaczymy w polu danych przechwyconego przez np Wireshark pakietu (te dane znajdą się w polu danych protokołu najwyższej warstwy w naszej konfiguracji czyli w tym wypadku UDP)
— ustalamy interfejs sieciowy, którym ruch będzie wysyłany (w naszym przypadku jest to interfejs A zaznaczony na schematach sieci), musi to być interfejs kierujący do urządzenia docelowego
W naszym przypadku enkapsulacja będzie wyglądała jak niżej:
Dane z wcześniej ustalonego pola trafią do danych pakietu UDP
Teraz trzeba ustalić dane protokołów kolejnych warstw wykorzystywanych przez nasz generator
Zakładka MAC
– W polu Dst należy wpisać adres MAC (sprzętowy) urządzenia docelowego
– W naszym wypadku będzie to interfejs B w przypadku sieci przewodowej
– Adres MAC tegoż interfejsu sprawdzimy łatwo:
#ip address show
– Problem się jednak pojawi gdy do naszego Linux (czy co tam mamy na urządzeniu docelowym) podłączeni jesteśmy radiem (lub przez inne routery) co pokazano na rysunku 2
– W zależności od trybu radiowego możemy być zmuszeni do podania adresu MAC interfejsu Y radia 2 (urządzenia radiowe często maskują swoim adresem MAC interfejsu radiowego interfejsy podłączone do nich po LAN)
– Jeśli nie wiemy za jakim adresem MAC znajduje się nasze urządzenie (w sieci radiowej) możemy to łatwo sprawdzić.
— otwieramy terminal
— pingujemy urządzenie docelowe
— w menu IP/Arp szukamy tegoż wpisu
— znajdziemy tu adres MAC urządzenia docelowego widziany z perspektywy naszego routera R1
— dwukrotnie klikamy na wpisie w tablicy ARP, zaznaczamy adres MAC, prawym myszki, Copy i wklejamy do pola Dst.
– Podajemy zatem adres MAC docelowy
Zakładka IP
– Tutaj podajemy adres IP docelowy
– Jeśli do miejsca docelowego (z naszego segmentu) prowadzi kilka tras można jeszcze podać Gateway czyli adres IP routera prowadzącego do celu
– Ustalamy wartość TTL na 3
Zakładka UDP
– Tutaj trzeba podać z porty źródłowe oraz docelowe
– Można podać zakres np 10000-20000
1b. Przygotowanie strumienia danych
– W generatorze pakietów klikamy w Streams i dodajmy nowy strumień (niebieski plus)
– Ustalamy nazwę np streamUDP, rozmiar pakietu na 1024 bajty
– Ilość pakietów na sekundę (PPS) na początek ustalamy na 1
– Z listy TX Templates wybieramy przygotowany wcześniej szablon pakietu „pakietTestowyUDP”
– Zatwierdzamy ustawienia
– Na listach szablonów oraz strumieni powinniśmy teraz mieć po jednym wpisie
2. Uruchomienie transmisji
Zanim uruchomimy generator przygotujemy sobie klienta
– Na naszym Linux włączamy przechwytywania pakietów (jeśli maszyna ma kilka interfejsów zwróć uwagę czy został wybrany właściwy)
– Aby ograniczyć ich ilość w danych wynikowych możemy podać filtr przechwytywania np. „host 192.168.55.2” gdzie podany IP jest adresem generatora pakietów
– Uruchamiamy strumień danych z generatora (przycisk Start) wybierając wcześniej przygotowany strumień
3. Przechwycenie ruchu na hoście docelowym
Na docelowej maszynie uruchamiamy przechwytywanie pakietów.
– Na analizatorze Wireshark obserwujemy pojawiające się pakiety, wystarczy przechwycić kilka
– Jak widać mamy tu wszystkie założone dane
– Kolor pakietu czerwony wskazuje, że według Wireshark jest z nim coś nie tak, zaraz sprawdzimy co
– Na każdy pakiet, który host otrzymał wysyła odpowiedź protokołu ICMP
– Analizujemy jeden pakiet od generatora klikając go
– Przeanalizujemy go w trzech warstwach: MAC, IP, UDP (bo tak pakiet był w generatorze skonstruowany)
4. Analiza przechwyconych danych
> Warstwa MAC (zaznaczona czerwoną ramką):
– Mamy tu trzy istotne elementy
— adres MAC docelowy (R1)
— adres MAC źródłowy (podany w generatorze, hosta docelowego)
– Typ przenoszonego protokołu (0x0800 czyli IP) także ustalony w generatorze
Budowa oraz kolejność danych jest zgodna ze standardem IEEE 802.3.
Nie widzimy tu jedynie pół „zdejmowanych” przez kartę sieciową: preambuła, SFD (o ile są) oraz FCS.
W pierwszej linii may informację o rozmiarze ramki (pola: adresy, typ i dane) równym 1024 bajty, to dokładnie tyle, ile zadaliśmy w generatorze, sekcja strumień:
> Warstwa IP
– Zgodnie z nagłówkiem IP mamy tu:
— wersje
— długość nagłówka
— pola DSCP
— całkowitą długość pakietu IP (nagłówek i dane) 1010, w stosunku do ramki to mniej o 14 bajtów co pasuje ponieważ jej nagłówek do (2×6)+2 (adresy oraz typ protokołu)
— identyfikator
— flagi
— ofset fragmentacji
— pole TTL (tutaj ma wartość 3 ponieważ to także było ustalone w generatorze)
— informacje o protokole warstwy wyższej
— suma kontrolna nagłówka
— adres źródłowy oraz docelowy
Długość nagłówka IP to 20 bajtów czyli odejmując od całkowitej wielkości ramki 1024 nagłówek ramki Ethernet oraz owe 20 bajtów nagłówka IP uzyskamy 990. Tyle zostaje na na dane przenoszone przez datagram IP czyli nasz pakiet UDP musi zmieścić się z 990 bajtach. Trzeba pamiętać, że on także ma nagłówek, ale o tym później.
Poniżej widok nagłówka IP (geeksforgeeks.org)
> Warstwa UDP (zaznaczona czerwoną ramką)
– Zgodnie z nagłówkiem UDP mamy tu:
— port źródłowy
— port docelowy
— długość całego pakietu
— suma kontrolna
Porty są zgodne z założeniami generatora
– Zaraz na nagłówkiem (o bajtów) mamy pole danych o rozmiarze 990-8 bajtów czyli 982 bajty. Zawartość pola danych także jest zgodna z danymi generatora.
Odpowiedzią hosta na każdy otrzymany na port 20000 pakiet jest komunikat ICMP o nieosiągalności portu docelowego. Jest to zrozumiałe, ponieważ port docelowy na hoście nie jest czynny innymi słowy żaden program nie nasłuchuje na nim. Poniżej przykład: w ramce nr 5 jest zapytanie do portu 20000, w ramce kolejnej czyli nr 5 mamy informację od protokołu ICMP o nieosiągalności portu
Zawartość pakietu ICMP: Destnation/Port unreachable
Jeśli teraz na hoście docelowym uruchomimy dowolną usługę na porcie 20000 np za pomocą programu netcat
#sudo netcat -l -u 192.168.55.105 20000
To host odpowiadać pakietem ICMP już nie będzie:
Jak widać mamy same zapytania ponieważ pakiet został odebrany przez netcat. Z jakiego powodu nie ma żadnej odpowiedzi? Po pierwsze netcat odebrał pakiet a po drugi to protokół UDP więc zakłada się, że nadawca nie oczekuje odpowiedzi (ruch bezpołączeniowy).
5. Analiza transferu podczas działania generatora
– Konfigurujemy teraz generator ponownie tym razem ustalając 1000 PPS (nie włączając na razie transmisji)
– Jaki wolumen ruchu zostanie wygenerowany
– Jak można to policzyć:
Każdy pakiet (ramka Ethernet w tym wypadku) to 1024 bajty bo tak mówi generator. Daje to 1024*8 bitów = 8192 bitów na ramkę/pakiet. Generowanie 1000 pakietów na sekundę to 1000 ramek na sekundę (ponieważ to UDP więc może nie być ruchu powrotnego) co daje 1000*1024 bajty = 1024000 bajtów na sekundę co daje 8192000 bitów na sekundę. Dzieląc to przez 8 (8 bitów = 1 bajt) dostaniemy 1020000 B/s. Dzieląc to przez 1024 dostaniemy wynik w kB/sek czyli 1000 kB/s. Jeśli chcemy wynik otrzymać w Mbps (megabity na sekundę) to wartość w b/s 8192000 trzeba podzielić przez „informatyczny” maga czyli 1024*1024: 8192000 / (1024*1024) = 7,8125 Mbps.
– Uruchamiamy zatem transmisje pakietów z generatora
– Na hoście docelowym uruchamiamy program ‚nload’ dla interfejsu odbierającego dane
– Dokładnie taką wartość pokazuje ‚nload’
– Patrząc na RouterOS
– Różnica może wynikać z innego rodzaju ruchu, który jeszcze jest na routerze
– Zaobserwujmy jeszcze obciążenie samego routera podczas transmisji:
– Jest w okolicach 30-40%
Podsumowanie informacji o rozmiarach nagłówków
OSI2: MAC – 6+6+2 = 14
OSI3: IP – 20 (https://www.geeksforgeeks.org/introduction-and-ipv4-datagram-header/)
OSI4: UDP – 8 (https://www.geeksforgeeks.org/user-datagram-protocol-udp/?ref=lbp)
reszta to dane, cały pakiet miał mieć 1024 bajty więc:
1024 – 14 – 20 – 8 = 982, tyle pokazuje Wireshark jako dane
