Generowanie ruchu sieciowego stanowi fundamentalne narzędzie w pracy inżyniera sieciowego, pozwalające na kontrolowane testowanie infrastruktury przed jej wdrożeniem produkcyjnym. Dzięki specjalizowanym generatorom można symulować różnorodne scenariusze obciążeniowe, od prostego ruchu UDP po złożone sesje TCP z niestandardowymi flagami. Narzędzia takie jak Ostinato i Scapy umożliwiają precyzyjne sterowanie każdym bajtem pakietu, co jest nieocenione przy debugowaniu protokołów i testowaniu zabezpieczeń. W ramach tej części poznamy zarówno rozwiązania sprzętowe (MikroTik RouterOS Traffic Generator), jak i programowe (Ostinato, Scapy), a także porównamy je pod kątem wydajności i elastyczności. Wiedza ta pozwoli świadomie dobierać narzędzie do konkretnego zadania pomiarowego w sieci LAN i WAN.

Plan części jedenastej został ułożony w sposób progresywny – zaczynamy od uzasadnienia potrzeby generowania ruchu, poprzez narzędzia wbudowane w routery MikroTik, aż po zaawansowane biblioteki programistyczne. Każde z omawianych narzędzi zostanie przedstawione od strony praktycznej: instalacja, konfiguracja, uruchomienie oraz analiza wyników. Szczególny nacisk położono na porównanie wydajności i obszarów zastosowań, aby student mógł samodzielnie podjąć decyzję, które narzędzie wybrać w konkretnym scenariuszu. Część obejmuje również przykłady skryptów automatyzujących testy oraz zadania praktyczne do samodzielnego wykonania.

Celowe generowanie pakietów sieciowych pozwala na przeprowadzanie testów w warunkach laboratoryjnych bez konieczności oczekiwania na rzeczywiste obciążenie sieci. Dzięki temu można zmierzyć maksymalną przepustowość łącza (throughput), sprawdzić zachowanie mechanizmów QoS (Quality of Service) oraz zweryfikować poprawność reguł dostępu (ACL) na firewallach i routerach. W środowisku edukacyjnym generatory ruchu służą do nauki protokołów – student może prześledzić cały cykl życia pakietu, od wygenerowania przez transmisję aż po analizę w programie Wireshark. W przemyśle narzędzia te wykorzystuje się do certyfikacji urządzeń sieciowych zgodnie ze standardami RFC 2544 i ITU-T Y.1564. Kluczową zaletą jest powtarzalność testów – ten sam scenariusz można odtworzyć wielokrotnie w identycznych warunkach.

Podział generatorów na programowe, sprzętowe i skryptowe wynika z różnych potrzeb użytkowników – inżynier laboratorium potrzebuje wysokiej wydajności, a student elastyczności i niskiego kosztu. Generatory programowe, takie jak Ostinato czy hping3, są wystarczające dla większości zastosowań laboratoryjnych i oferują przyjazny interfejs użytkownika. Generatory sprzętowe, reprezentowane przez urządzenia firm IXIA (obecnie Keysight) i Spirent, potrafią generować ruch z prędkością 400 Gb/s i więcej, ale ich ceny sięgają dziesiątek tysięcy złotych. Generatory biblioteczne, na czele z Scapy, dają pełną kontrolę nad strukturą pakietu, co jest niezastąpione przy testowaniu niestandardowych protokołów i analizie bezpieczeństwa. Wybór odpowiedniego typu zależy od budżetu, wymaganej wydajności oraz stopnia skomplikowania testów.

Porównanie generatorów ruchu uwzględnia kilka kluczowych kryteriów: wspierane protokoły, maksymalną przepustowość, łatwość automatyzacji oraz dostępność na różnych platformach systemowych. hping3, działający wyłącznie w środowisku Linux/Unix, jest niezastąpiony do szybkich testów CLI i sprawdzania pojedynczych reguł firewalla. Ostinato, dostępny na Windows, Linux i macOS, oferuje wygodny interfejs graficzny i wysoką wydajność dzięki implementacji w C++. Scapy, napisany w Pythonie, zapewnia największą elastyczność kosztem wydajności – jego przepustowość rzadko przekracza 100 Mb/s. RouterOS Traffic Generator jest ograniczony do ekosystemu MikroTik, ale nie wymaga dodatkowego sprzętu poza routerem. packeth to lekkie narzędzie z GUI GTK dla Linux, przydatne do szybkiego generowania pojedynczych ramek Ethernet.

Wybór generatora ruchu powinien być podyktowany konkretnym scenariuszem testowym oraz dostępnymi zasobami. Jeśli dysponujemy routerem MikroTik i chcemy szybko sprawdzić przepustowość łącza między dwoma biurami, Traffic Generator będzie najprostszym rozwiązaniem – nie wymaga instalacji dodatkowego oprogramowania. Do testowania zapór ogniowych i tworzenia złożonych strumieni z różnymi protokołami lepiej sprawdzi się Ostinato ze względu na edytor warstw i precyzyjną kontrolę szybkości. Scapy jest idealny do prototypowania nowych rozwiązań, edukacji oraz automatyzacji – skrypt Pythona może wykonać cały zestaw testów i zapisać wyniki do pliku. hping3 sprawdza się w sytuacjach, gdy potrzebujemy szybko zweryfikować regułę firewalla z poziomu terminala. W praktyce inżynierskiej warto znać co najmniej dwa narzędzia, aby móc elastycznie dostosować się do wymagań zadania.

RouterOS Traffic Generator jest integralną częścią systemu MikroTik RouterOS i nie wymaga zakupu żadnych dodatkowych licencji ani pakietów. W starszych wersjach RouterOS (przed 6.x) narzędzie to było dostępne jako oddzielny pakiet do instalacji, ale obecnie jest wbudowane domyślnie. Traffic Generator działa w przestrzeni użytkownika, co oznacza, że każdy pakiet musi zostać skopiowany między pamięcią jądra a aplikacją – to główne ograniczenie wydajności. Niemniej jednak dla łączy do 1 Gb/s i na sprzęcie średniej klasy (RB750, RB951) narzędzie to w pełni wystarcza do podstawowych testów. Weryfikacja konfiguracji kolejkowania (queue tree), reguł filtrowania (firewall filter) oraz translacji adresów (NAT) to typowe zastosowania, w których Traffic Generator sprawdza się doskonale.

Uruchomienie Traffic Generator w konsoli RouterOS odbywa się przez wpisanie komendy /tool traffic-generator, która przenosi użytkownika w kontekst narzędzia. W tym kontekście dostępne są podkomendy: start (uruchomienie generowania), stop (zatrzymanie), stream (konfiguracja poszczególnych strumieni) oraz monitor (podgląd statystyk na żywo). Przed pierwszym uruchomieniem należy skonfigurować adresy źródłowe i docelowe oraz interfejsy, przez które ruch będzie wysyłany i odbierany. Traffic Generator wymaga, aby po obu stronach testu znajdowały się urządzenia MikroTik – jedno działa jako nadajnik, drugie jako odbiornik. Warto pamiętać, że komendy kontekstu TG można poprzedzać pełną ścieżką /tool traffic-generator, co jest przydatne w skryptach.

Podstawowa konfiguracja Traffic Generator w RouterOS sprowadza się do ustawienia czterech parametrów: adresu IP źródła (src-address), adresu IP celu (dst-address), interfejsu źródłowego (src-interface) oraz interfejsu docelowego (dst-interface). Adresy IP mogą należeć do tej samej lub różnych podsieci, o ile routing między nimi jest poprawnie skonfigurowany. Interfejsy powinny wskazywać na fizyczne porty lub interfejsy VLAN, przez które będzie przepływał ruch testowy. Komenda /tool traffic-generator print wyświetla aktualną konfigurację, umożliwiając weryfikację poprawności ustawień przed rozpoczęciem testu. W przypadku błędnej konfiguracji generator zgłosi błąd podczas próby uruchomienia, informując o brakujących parametrach.

Strumienie UDP w RouterOS Traffic Generator konfiguruje się za pomocą podkomendy /tool traffic-generator stream add, gdzie określamy nazwę strumienia, protokół (udp), porty źródłowy i docelowy, szybkość generowania oraz rozmiar pakietu. Szybkość (rate) podaje się w bitach na sekundę z jednostkami takimi jak k (kilobity), M (megabity) lub G (gigabity). Rozmiar pakietu (size) określa się w bajtach – typowe wartości to 64 (minimalny rozmiar ramki Ethernet), 512, 1024 i 1500 (standardowy MTU). W przypadku UDP można generować ruch z prędkością zbliżoną do maksymalnej przepustowości łącza, o ile CPU routera jest w stanie obsłużyć taką liczbę pakietów na sekundę. Podczas testów UDP należy pamiętać, że protokół ten nie ma mechanizmów kontroli przepływu ani retransmisji, więc wszelkie straty pakietów są natychmiast widoczne w statystykach.

Strumienie TCP w Traffic Generator różnią się od UDP możliwością ustawienia flag TCP oraz rozmiaru okna. Należy jednak pamiętać, że Traffic Generator nie wykonuje trójstopniowego uzgadniania (three-way handshake) – wysyła pakiety z zadanymi flagami, nie oczekując odpowiedzi. Oznacza to, że generowane pakiety TCP mogą być odrzucane przez stos sieciowy odbiornika, jeśli nie pasują do stanu istniejącego połączenia. Flagi TCP ustawia się za pomocą parametru tcp-flags, gdzie można podać kombinacje takie jak syn, ack, syn,ack, fin, psh, ack itd. Rozmiar okna TCP (tcp-window) określa ilość danych, jaką nadawca może wysłać przed otrzymaniem potwierdzenia, co ma wpływ na przepustowość w sieciach o dużym opóźnieniu. W praktyce testy TCP z Traffic Generator najlepiej sprawdzają się przy weryfikacji reguł firewalla filtrujących określone flagi.

Monitorowanie strumieni w Traffic Generator odbywa się za pomocą komendy /tool traffic-generator monitor, która wyświetla w czasie rzeczywistym statystyki dla każdego aktywnego strumienia. Kluczowe wskaźniki to przepustowość rzeczywista (throughput), liczba wysłanych i odebranych pakietów, procentowa utrata pakietów (packet loss), zmienność opóźnienia (jitter) oraz średnie opóźnienie (latency). W przypadku testów UDP utrata pakietów na poziomie poniżej 0,1% jest uznawana za akceptowalną, natomiast powyżej 1% wskazuje na poważne przeciążenie łącza lub brak mocy obliczeniowej routera. Wartość jitter ma kluczowe znaczenie dla aplikacji czasu rzeczywistego – dla VoIP nie powinna przekraczać 30 ms, a dla wideokonferencji HD 50 ms. Monitor można uruchomić przed rozpoczęciem generowania strumienia, aby zaobserwować wartości wyjściowe.

Scenariusz testu między dwoma routerami MikroTik wymaga starannego skonfigurowania zarówno nadajnika, jak i odbiornika. Po stronie odbiornika ustawiamy adres źródłowy na jego własny interfejs oraz adres docelowy na interfejs nadajnika – to konfiguracja symetryczna. Nadajnik dodaje strumień testowy, uruchamia generator, odczekuje zadany czas (np. 30 sekund) i zatrzymuje generator. W skrypcie można użyć komendy :delay do odmierzenia czasu testu. Po zakończeniu testu wyniki odczytuje się komendą /tool traffic-generator monitor, która pokazuje średnie wartości z całego okresu testu. W przypadku testowania łączy symetrycznych warto przeprowadzić test w obie strony, aby wykryć ewentualną asymetrię przepustowości. Testy można też zautomatyzować, zapisując wyniki do pliku za pomocą /file print.

Monitorowanie obciążenia CPU podczas generowania ruchu jest kluczowe dla interpretacji wyników Traffic Generator. Narzędzie /tool profile w RouterOS wyświetla procentowe wykorzystanie CPU przez poszczególne procesy, w tym traffic-gen. Jeśli proces traffic-gen przekracza 80% użycia CPU, rzeczywista przepustowość będzie niższa niż zadana, ponieważ CPU nie nadąża z przetwarzaniem pakietów. Wynika to z architektury Traffic Generator, który działa w przestrzeni użytkownika i wymaga kopiowania danych między przestrzenią jądra a użytkownika. Na słabszych modelach, takich jak RB750 (jednordzeniowy CPU 400 MHz), maksymalna osiągalna przepustowość to około 200-300 Mb/s, podczas gdy na modelach CCR (Cloud Core Router) z wieloma rdzeniami można osiągnąć kilka Gb/s. W przypadku osiągnięcia limitu CPU zaleca się zmniejszenie szybkości generowania lub zastosowanie zewnętrznego generatora sprzętowego.

Ograniczenia Traffic Generator w RouterOS są istotne przy planowaniu testów wydajnościowych. Przede wszystkim generator obciąża procesor routera, co oznacza, że na słabszych modelach nie można osiągnąć przepustowości 1 Gb/s. Kolejnym ograniczeniem jest wymóg posiadania RouterOS po obu stronach połączenia – Traffic Generator nie współpracuje z urządzeniami innych producentów. Kontrola nad pakietami jest ograniczona do podstawowych pól nagłówka – nie można ustawić dowolnych opcji IP, rozszerzeń TCP ani niestandardowych protokołów warstwy 2. Traffic Generator nie generuje surowych ramek Ethernet, co uniemożliwia testowanie przełączników na poziomie ramek. Brak wbudowanego zapisu strumienia do pliku pcap utrudnia późniejszą analizę przechwyconego ruchu – konieczne jest stosowanie dodatkowych narzędzi, takich jak tcpdump na interfejsie lustrzanym (port mirroring).

Porównanie Traffic Generator z iperf na RouterOS pokazuje, że oba narzędzia mają swoje mocne i słabe strony. Traffic Generator oferuje większą kontrolę nad strukturą pakietów (flagi TCP, rozmiar okna, porty) oraz umożliwia generowanie ruchu ICMP, czego iperf nie obsługuje. Z kolei iperf, dostępny w RouterOS od wersji 7.x, cechuje się wyższą wydajnością dzięki zoptymalizowanemu kodowi w C i lepszej integracji ze stosem TCP/IP systemu operacyjnego. iperf mierzy wyłącznie przepustowość i nie nadaje się do testowania reguł firewalla ani generowania specyficznych pakietów. W praktyce warto stosować oba narzędzia komplementarnie: Traffic Generator do weryfikacji reguł i testowania warstwy 3/4, a iperf do pomiarów czystej przepustowości łącza. iperf oferuje również tryb dwukierunkowy (--bidir) oraz raportowanie w formacie JSON.

Scenariusz praktyczny z tunelem IPsec między dwoma biurami obrazuje typowe zastosowanie Traffic Generator w rzeczywistej infrastrukturze. Przed przystąpieniem do testu należy upewnić się, że tunel IPsec jest poprawnie skonfigurowany i aktywny – można to sprawdzić komendą /ip ipsec installed-sa print. Test polega na wygenerowaniu strumienia UDP z prędkością zbliżoną do oczekiwanej przepustowości tunelu i obserwacji statystyk. Jeśli rzeczywista przepustowość jest znacząco niższa od zadanej, przyczyną może być zbyt słaby CPU routera (szyfrowanie IPsec jest obliczeniowo intensywne) lub nieoptymalna konfiguracja parametrów IPsec (np. zbyt mały rozmiar okna IKE). W opisanym przykładzie spadek z 200 Mb/s do 180 Mb/s i utrata 2% pakietów sugeruje, że router osiąga granicę swoich możliwości obliczeniowych przy szyfrowaniu AES-256. Rozwiązaniem może być wymiana routera na model z akceleracją AES-NI lub zmniejszenie szybkości szyfrowania.

Testowanie przez interfejsy VLAN z Traffic Generator jest szczególnie przydatne w środowiskach, gdzie ruch między sieciami VLAN jest izolowany i podlega różnym regułom QoS. RouterOS Traffic Generator nie wymaga specjalnej konfiguracji dla VLAN – wystarczy utworzyć interfejs VLAN (/interface vlan add) i wskazać go jako src-interface oraz dst-interface w konfiguracji generatora. Należy upewnić się, że przełączniki między routerami poprawnie przekazują ramki z tagiem VLAN (porty trunk). Testowanie przez VLAN pozwala zweryfikować, czy konfiguracja kolejkowania (queue tree) dla poszczególnych VLAN działa poprawnie oraz czy reguły firewalla filtrują ruch między VLAN zgodnie z polityką bezpieczeństwa. W laboratorium dydaktycznym jest to doskonały sposób na zademonstrowanie izolacji ruchu między sieciami VLAN i wpływu priorytetyzacji QoS na przepustowość.

Tworzenie skryptów testów Traffic Generator w języku skryptowym RouterOS umożliwia pełną automatyzację pomiarów, co jest szczególnie cenne przy regularnych testach SLA lub monitorowaniu wydajności łącza. W skrypcie można definiować zmienne lokalne (:local), dodawać strumienie, uruchamiać generator, odmierzacz czas (:delay), zatrzymywać test i odczytywać wyniki. Wyniki monitora można przypisać do zmiennej i wyświetlić za pomocą :put. Zaawansowane skrypty mogą zapisywać wyniki do pliku (/file set ... content=...), wysyłać raporty e-mailem (/tool e-mail send) lub uruchamiać się cyklicznie z poziomu Scheduler (/system scheduler add). Automatyzacja pozwala na prowadzenie ciągłych pomiarów przez wiele dni i analizę trendów, co jest niemożliwe przy ręcznym uruchamianiu testów. Należy jednak pamiętać, że zbyt częste testy mogą obciążać CPU routera i wpływać na jakość usług dla użytkowników.

Ostinato to zaawansowane, otwarte narzędzie do generowania i analizy ruchu sieciowego, rozpowszechniane na licencji GPLv3. W przeciwieństwie do Traffic Generator od MikroTik, Ostinato działa na wielu platformach (Windows, Linux, macOS) i oferuje graficzny interfejs użytkownika, co znacznie obniża próg wejścia dla początkujących. Narzędzie to umożliwia tworzenie pakietów dowolnego typu za pomocą edytora warstw – każdy protokół (Ethernet, IP, TCP, UDP i wiele innych) stanowi osobną warstwę, którą można dowolnie konfigurować. Ostinato pozwala na generowanie wielu strumieni jednocześnie, każdy z własnymi ustawieniami szybkości, czasu trwania i priorytetu. Wbudowany odbiornik (receive mode) umożliwia przechwytywanie i analizę odebranych pakietów, co czyni Ostinato kompletnym narzędziem do testowania urządzeń sieciowych w laboratorium.

Instalacja Ostinato różni się w zależności od systemu operacyjnego, ale we wszystkich przypadkach jest prosta i dobrze udokumentowana. Na Windows wystarczy pobrać instalator ze strony oficjalnej i uruchomić – instalator zawiera zarówno Drone (serwer), jak i GUI (klient). Na Debianie/Ubuntu zaleca się pobranie paczki .deb ze strony ostinato.org i instalację przez menedżer pakietów apt. Na Fedorze/RHEL zaleca się pobranie paczki .rpm ze strony ostinato.org i instalację przez menedżer pakietów yum. Dla systemów, na których nie ma pakietu w repozytorium, dostępna jest wersja AppImage, która działa bez instalacji – wystarczy pobrać plik, nadać mu uprawnienia do wykonania i uruchomić. Po instalacji należy upewnić się, że użytkownik ma odpowiednie uprawnienia do przechwytywania pakietów (na Linux wymagane są prawa root lub ustawienie odpowiednich capability CAP_NET_RAW).

Architektura klient-serwer Ostinato, oparta na modelu Drone + GUI, zapewnia dużą elastyczność w konfiguracji laboratoriów pomiarowych. Drone (serwer) to proces działający na hoście, który ma fizyczny dostęp do interfejsów sieciowych – odpowiada za wysyłanie i odbieranie pakietów na najniższym poziomie. GUI (klient) to aplikacja graficzna, która łączy się z Drone przez sieć z wykorzystaniem protokołu TCP (domyślnie port 7878). Taka architektura pozwala na zdalne sterowanie generatorem – Drone może działać na maszynie w laboratorium, a GUI na laptopie studenta w dowolnym miejscu sieci. Możliwe jest również podłączenie wielu Drone do jednego GUI, co umożliwia testy rozproszone z wykorzystaniem kilku generatorów jednocześnie. W środowisku dydaktycznym zaleca się uruchomienie Drone na dedykowanej maszynie testowej, a GUI na komputerach studentów, co minimalizuje problemy z uprawnieniami.

Uruchomienie Ostinato rozpoczyna się od wystartowania procesu Drone z odpowiednimi uprawnieniami. Na Linux wymagane jest użycie sudo, ponieważ Drone potrzebuje dostępu do surowych gniazd (raw sockets). Parametr -p określa port, na którym Drone nasłuchuje połączeń od GUI – domyślnie jest to port 7878, ale można go zmienić w przypadku kolizji z innymi usługami. Po uruchomieniu Drone otwieramy GUI komendą ostinato-gui (lub klikając ikonę na Windows). W GUI należy dodać port (Add Port), wybrać odpowiedni interfejs sieciowy i kliknąć Connect – GUI połączy się z Drone i port pojawi się na liście dostępnych interfejsów. Port można włączyć (Enable) i wyłączyć (Disable), co odpowiednio aktywuje lub dezaktywuje przechwytywanie na tym interfejsie. W przypadku błędów połączenia należy sprawdzić, czy Drone jest uruchomiony i czy firewall nie blokuje portu 7878.

Edytor warstw Ostinato to kluczowa funkcjonalność odróżniająca to narzędzie od prostszych generatorów. Każdy protokół jest reprezentowany jako osobna warstwa, którą można dodawać, usuwać i edytować. Warstwy układa się w stos zgodnie z modelem OSI – od warstwy 2 (Ethernet) przez warstwę 3 (IP) aż po warstwę 4 (TCP/UDP) i warstwę aplikacji (payload). Każda warstwa ma zestaw pól, które można edytować bezpośrednio w drzewiastej strukturze – wystarczy kliknąć dwukrotnie na pole, aby zmienić jego wartość. Nową warstwę dodaje się przez kliknięcie prawym przyciskiem myszy i wybranie Append Protocol, gdzie dostępna jest lista kilkudziesięciu protokołów. Edytor pokazuje również podgląd surowych danych (hex dump) w czasie rzeczywistym, co pomaga zrozumieć, jak zmiany w warstwach przekładają się na strukturę bitową pakietu.

Stream Editor w Ostinato to centralne miejsce konfiguracji parametrów wysyłania. Dla każdego strumienia definiuje się wzorzec pakietu (Packet Template), który określa strukturę warstw, a następnie parametry transmisji: szybkość (Rate), liczbę pakietów w serii (Burst), odstęp między pakietami (Inter-Packet Gap, IPG), czas trwania lub liczbę pakietów. Rate można ustawić w bitach na sekundę (bps), pakietach na sekundę (pps) lub jako procent przepustowości łącza. IPG mierzy się w nanosekundach lub mikrosekundach – im mniejszy IPG, tym wyższa chwilowa przepustowość. Burst pozwala na wysłanie określonej liczby pakietów jeden po drugim bez przerwy, co jest przydatne do testowania buforów przełączników. Strumienie można włączać i wyłączać niezależnie, klonować, grupować oraz ustawiać ich kolejność uruchamiania za pomocą osi czasu.

Adresacja w pakietach generowanych przez Ostinato oferuje trzy tryby: stały, inkrementujący i z listy. Tryb stały (Fixed) jest najprostszy – każdy pakiet w strumieniu ma ten sam adres źródłowy i docelowy. Tryb inkrementujący (Incrementing) automatycznie zwiększa adres o 1 z każdym wysłanym pakietem, co jest przydatne przy testowaniu reguł firewalla dla całej podsieci – zamiast tworzyć osobny strumień dla każdego adresu, definiujemy jeden strumień z adresem startowym i maską. Tryb z listy (List) pozwala na podanie zbioru adresów, z których losowo lub sekwencyjnie wybierany jest adres dla każdego pakietu. Adresacja inkrementująca jest szczególnie przydatna w testach NAT – generujemy pakiety z różnych prywatnych adresów IP i sprawdzamy, czy firewall poprawnie transluje je na adres publiczny. Dla adresów MAC dostępne są te same trzy tryby konfiguracji.

Konfiguracja portów i flag w warstwie TCP Ostinato daje pełną kontrolę nad nagłówkiem TCP, co jest kluczowe przy testowaniu reguł firewalla i systemów IPS. Porty źródłowe i docelowe można ustawić jako stałe, inkrementujące lub losowe – tryb losowy jest przydatny przy symulacji ruchu sieciowego z wieloma równoczesnymi sesjami. Flag TCP (SYN, ACK, FIN, RST, PSH, URG, ECE, CWR) można dowolnie kombinować, co pozwala na generowanie pakietów inicjujących połączenie (SYN), zamykających (FIN), resetujących (RST) czy też sprawdzających zachowanie firewalla wobec niestandardowych kombinacji flag. Numer sekwencyjny (Sequence Number) można ustawić jako stały lub inkrementujący – ma to znaczenie przy testowaniu mechanizmów TCP sequence prediction. W warstwie UDP konfiguracja jest prostsza – porty źródłowe i docelowe oraz długość datagramu (Length), która może być wyliczana automatycznie.

Wybór trybu wypełniania danych (payload) w Ostinato ma znaczenie dla rodzaju przeprowadzanego testu. Tryb Fixed pattern ze stałym wzorcem (np. same zera lub 0xDEADBEEF) jest przydatny przy testowaniu integralności danych – po stronie odbiorczej można sprawdzić, czy payload dotarł bez modyfikacji. Tryb Incrementing, gdzie bajty zwiększają się sekwencyjnie od 0x00 do 0xFF, ułatwia wykrywanie błędów desynchronizacji w strumieniu. Tryb Random jest zalecany przy testach kompresji i kryptografii, ponieważ losowe dane nie podlegają kompresji i stanowią najgorszy przypadek wydajnościowy. User defined pozwala na wprowadzenie dowolnego ciągu szesnastkowego, co jest przydatne przy testowaniu specyficznych protokołów aplikacyjnych. Długość payload można dostosować do potrzeb – od 0 B (sam nagłówek) do 65535 B dla UDP, z ograniczeniem MSS dla TCP.

Możliwość definiowania wielu strumieni jednocześnie w Ostinato pozwala na realistyczne symulowanie ruchu sieciowego w laboratorium. W rzeczywistej sieci jednocześnie przepływają pakiety różnych protokołów, od HTTP i DNS po VoIP i transmisje strumieniowe. Każdy strumień w Ostinato ma własną konfigurację warstw, szybkości i czasu trwania, co umożliwia stworzenie złożonego profilu ruchu. Strumienie można uruchamiać równocześnie lub sekwencyjnie z użyciem osi czasu (timeline). Dodatkowo można ustawić priorytety strumieni, co wpływa na kolejność wysyłania pakietów w przypadku rywalizacji o dostęp do interfejsu. Funkcjonalność ta jest szczególnie przydatna przy testowaniu mechanizmów QoS – generujemy jednocześnie ruch wysoko- i niskopriorytetowy i sprawdzamy, czy urządzenie odpowiednio priorytetyzuje pakiety zgodnie z konfiguracją.

Zaawansowana kontrola wysyłania w Ostinato, obejmująca parametry Burst, IPG i Rate Limit, pozwala na precyzyjne kształtowanie ruchu testowego. Burst to liczba pakietów wysyłanych jedna po drugiej bez przerwy, co symuluje sytuację, w której wiele pakietów czeka w kolejce na wysłanie. Parametr ten ma kluczowe znaczenie przy testowaniu buforów przełączników i routerów – jeśli burst przekracza pojemność bufora, dochodzi do utraty pakietów (tail drop). Inter-Packet Gap (IPG) to odstęp między pakietami mierzony w nanosekundach – ustawienie IPG=0 powoduje wysyłanie pakietów back-to-back z maksymalną chwilową szybkością. Rate Limit pozwala na ograniczenie średniej szybkości wysyłania, co jest przydatne przy testowaniu mechanizmów kształtowania ruchu (traffic shaping). Należy zachować ostrożność przy testach z IPG=0 i wysokim Burst, ponieważ może to spowodować chwilowe przeciążenie interfejsu odbiorczego lub przepełnienie buforów.

Tryb nasłuchu (Receive Mode) w Ostinato przekształca generator w analizator ruchu, umożliwiając odbiór i statystykę pakietów odebranych na interfejsie. Po włączeniu nasłuchu (Start Capture) Ostinato wyświetla w czasie rzeczywistym liczbę odebranych pakietów, bajtów, chwilową szybkość w pps i bps oraz histogram rozmiarów pakietów. Statystyki można w każdej chwili zresetować (Reset) i wyeksportować do pliku CSV do dalszej analizy w arkuszu kalkulacyjnym. Tryb nasłuchu jest szczególnie przydatny przy testach firewalla – na interfejsie po stronie wewnętrznej włączamy nasłuch i obserwujemy, które pakiety przeszły przez reguły filtrowania. W połączeniu z generatorem po stronie zewnętrznej otrzymujemy kompletne środowisko testowe, gdzie widzimy zarówno pakiety wysłane, jak i odebrane, co pozwala na precyzyjną diagnostykę reguł dostępu.

Pliki konfiguracji Ostinato z rozszerzeniem .ost przechowują kompletną konfigurację sesji, w tym wszystkie strumienie, warstwy pakietów, skonfigurowane porty oraz ustawienia szybkości i czasu trwania. Format .ost oparty jest na XML, co umożliwia ręczną edycję pliku w edytorze tekstu oraz generowanie konfiguracji programowo za pomocą skryptów. W środowisku dydaktycznym prowadzący może przygotować plik .ost z gotowymi scenariuszami testowymi i udostępnić studentom – wystarczy wczytać plik (File → Open) i uruchomić strumienie. Umożliwia to szybkie przełączanie między różnymi konfiguracjami bez konieczności ręcznego definiowania warstw za każdym razem. Pliki .ost można również przechowywać w systemie kontroli wersji (Git), co ułatwia śledzenie zmian w konfiguracji testów i współpracę w zespole.

Testowanie reguł firewalla z użyciem Ostinato to jedno z najczęstszych zastosowań tego narzędzia w praktyce inżynierskiej. Scenariusz polega na umieszczeniu zapory ogniowej między generatorem (strona zewnętrzna) a odbiornikiem (strona wewnętrzna) i sprawdzeniu, które pakiety przechodzą przez reguły filtrowania. Ostinato pozwala na precyzyjne określenie adresów IP źródłowych i docelowych, portów, protokołów i flag TCP, co umożliwia testowanie każdej reguły z osobna. Przy użyciu adresacji inkrementującej można w jednym teście sprawdzić, czy reguły działają dla całego zakresu adresów podsieci. Dodatkowo można testować translację NAT – wysyłamy pakiety z prywatnych adresów IP i obserwujemy, czy firewall poprawnie zamienia je na adres publiczny. Wyniki testów można zapisać w pliku .ost jako dokumentację przeprowadzonej walidacji, co jest wymagane przy audytach bezpieczeństwa.

Porównanie Ostinato, Scapy i hping3 pokazuje, że każde narzędzie ma optymalny obszar zastosowań. Ostinato wygrywa w kategoriach łatwości obsługi i wydajności – interfejs graficzny i implementacja w C++ sprawiają, że jest najlepszym wyborem dla początkujących i do szybkich testów w laboratorium. Scapy zapewnia największą elastyczność dzięki pełnej programowalności w Pythonie – można w kilku linijkach kodu zbudować skaner portów, narzędzie do ARP spoofingu czy symulator protokołu. hping3 jest najlżejszym i najszybszym narzędziem CLI do pojedynczych testów, idealnym do sprawdzenia reguły firewalla z poziomu terminala SSH. W praktyce inżynierskiej warto znać wszystkie trzy narzędzia i wybierać je w zależności od zadania: Ostinato do złożonych testów wielostrumieniowych, Scapy do prototypowania i automatyzacji, hping3 do szybkiej weryfikacji.

Scapy to nie tylko generator pakietów, ale pełnoprawna platforma do manipulacji ruchem sieciowym, która zdobyła ogromną popularność w środowisku akademickim i wśród specjalistów ds. bezpieczeństwa. Napisana w Pythonie przez Philippe'a Biona, Scapy umożliwia tworzenie, wysyłanie, odbieranie i analizowanie pakietów dowolnego typu bez konieczności pisania niskopoziomowego kodu w C. Biblioteka obsługuje kilkaset protokołów sieciowych – od najpopularniejszych (Ethernet, IP, TCP, UDP) po niszowe (IS-IS, MPLS, STP, BGP). Scapy jest często wykorzystywana w kursach bezpieczeństwa sieciowego do demonstracji ataków (ARP spoofing, SYN flood, DNS amplification) oraz w narzędziach takich jak Nmap (skrypty NSE mogą używać Scapy). Jej główną zaletą jest możliwość szybkiego prototypowania – to, co w C zajęłoby setki linijek kodu, w Scapy można zrealizować w kilkunastu.

Instalacja Scapy jest prosta i standardowa dla bibliotek Pythona, ale wymaga spełnienia kilku warunków wstępnych w zależności od systemu operacyjnego. Na Linux instalacja przez pip wymaga uprawnień root, ponieważ wysyłanie surowych pakietów wymaga dostępu do gniazda AF_PACKET. Na Windows niezbędny jest sterownik Npcap (nie WinPcap), który zapewnia obsługę przechwytywania pakietów w trybie użytkownika – Npcap można pobrać ze strony npcap.com. Po zainstalowaniu Npcap Scapy działa w trybie Administrator (Run as Administrator). W przypadku problemów z instalacją na Windows warto sprawdzić, czy Python i pip są w jednej architekturze (32-bit lub 64-bit) oraz czy zmienna PATH zawiera ścieżkę do katalogu Scripts. Komenda python -c "from scapy.all import *; print('OK')" pozwala zweryfikować poprawność instalacji. Jeśli import kończy się błędem, należy sprawdzić komunikaty o brakujących zależnościach, takich jak pycryptodome czy matplotlib.

Tryb interaktywny Scapy (REPL) to doskonałe narzędzie do nauki i eksperymentowania z protokołami sieciowymi. Po uruchomieniu sudo scapy użytkownik otrzymuje konsolę Pythona z zaimportowanymi wszystkimi klasami Scapy, co pozwala na natychmiastowe tworzenie pakietów. Autouzupełnianie przez Tab znacząco przyspiesza pracę – wystarczy wpisać IP( i nacisnąć Tab, aby zobaczyć listę dostępnych parametrów. W trybie interaktywnym można testować komendy przed włączeniem ich do skryptu, co jest zgodne z metodyką prób i błędów. Funkcja ls() wyświetla listę dostępnych warstw protokołów, a lsc() listę dostępnych komend Scapy. Metoda .show() na utworzonym pakiecie wyświetla jego strukturę z wartościami domyślnymi, co pomaga zrozumieć, jakie pola ma dany protokół. Tryb interaktywny jest szczególnie polecany studentom rozpoczynającym przygodę z Scapy, ponieważ umożliwia natychmiastową informację zwrotną.

Klasy protokołów w Scapy (IP, TCP, UDP, Ether) są fundamentem, na którym opiera się cała biblioteka. Każda klasa odpowiada jednemu protokołowi i zawiera definicje wszystkich jego pól wraz z wartościami domyślnymi. Operator / (slash) służy do składania warstw w stos – na przykład Ether()/IP()/TCP() tworzy kompletny pakiet z ramką Ethernet, nagłówkiem IP i nagłówkiem TCP. Scapy automatycznie oblicza długości, sumy kontrolne (checksum) i inne pola zależne od wartości niższych warstw. Parametry klas można ustawić przez nazwę – na przykład IP(dst="8.8.8.8", ttl=64) lub TCP(dport=80, flags="S"). Wartości domyślne są rozsądne (broadcast MAC, losowy adres źródłowy), ale w praktyce zawsze należy jawnie ustawić adres docelowy. Każda klasa oferuje metodę show(), która wyświetla strukturę pakietu, oraz summary() do zwięzłego opisu.

Przykład złożonego pakietu pokazuje, jak w kilku linijkach Pythona można zbudować realistyczne zapytanie HTTP GET i wyświetlić jego strukturę. Operator / łączy warstwę Ethernet (z domyślnymi adresami MAC), warstwę IP z docelowym adresem 93.184.216.34 (example.com), warstwę TCP z portem docelowym 80 i flagą ACK (A) oraz surowy payload z treścią żądania HTTP. Scapy automatycznie obliczy długość nagłówka IP, długość całego pakietu, sumę kontrolną IP oraz sumę kontrolną TCP. Metoda show() wyświetla wszystkie pola każdej warstwy, w tym wartości wyliczone automatycznie (np. chksum). Jest to doskonały sposób na zrozumienie struktury pakietów – student widzi, jak poszczególne warstwy nakładają się na siebie i jakie pola są wypełniane automatycznie. W praktyce zamiast ręcznego budowania pakietów HTTP można użyć warstwy HTTP.Request, która jest dostępna w nowszych wersjach Scapy.

Funkcje send() i sendp() w Scapy różnią się warstwą, na której wysyłają pakiety. send(pkt) działa na warstwie 3 (IP) – oznacza to, że pakiet przekazywany jest do stosu sieciowego systemu operacyjnego, który zajmuje się routingiem, czyli wyborem odpowiedniego interfejsu i enkapsulacją w ramkę Ethernet. send(pkt) nie pozwala na kontrolę nad adresami MAC ani nad wyborem interfejsu – routing odbywa się automatycznie na podstawie tablicy routingu. sendp(pkt) działa na warstwie 2 (Ethernet) – wysyła surową ramkę bezpośrednio na wskazany interfejs, z pominięciem stosu sieciowego. Wymaga podania parametru iface, który określa interfejs sieciowy. sendp() jest niezbędna przy testach ARP, DHCP (ponieważ te protokoły działają przed uzyskaniem adresu IP) oraz wszędzie tam, gdzie potrzebujemy pełnej kontroli nad adresami MAC. Parametry count i inter pozwalają na wysłanie wielu pakietów z zadanym odstępem czasowym.

Sniffowanie pakietów w Scapy odbywa się za pomocą funkcji sniff(), która przechwytuje pakiety z interfejsu sieciowego i zwraca je jako obiekt PacketList. Parametr count określa liczbę pakietów do przechwycenia – po osiągnięciu tej liczby funkcja kończy działanie. Parametr timeout pozwala na ograniczenie czasu nasłuchu. Filtr BPF (Berkeley Packet Filter) umożliwia zawężenie przechwytywania do pakietów spełniających określone kryteria, na przykład filter="tcp port 80" przechwyci tylko pakiety TCP na porcie 80. Funkcja callback (parametr prn) pozwala na wykonanie własnej funkcji dla każdego przechwyconego pakietu w czasie rzeczywistym, bez czekania na zakończenie sniffowania. Jest to przydatne przy monitorowaniu ruchu na żywo i generowaniu alertów. Sniffowanie w Scapy wymaga uprawnień administratora lub root, ponieważ wymaga dostępu do surowych gniazd (raw sockets).

Funkcje sr() i sr1() w Scapy realizują wzorzec wysyłania i oczekiwania na odpowiedź, który jest fundamentem wielu narzędzi sieciowych, takich jak ping czy traceroute. Funkcja sr(pkt, timeout=2) wysyła pakiet i oczekuje na wszystkie odpowiedzi w zadanym czasie. Zwraca krotkę (answered, unanswered), gdzie answered to lista par (pakiet wysłany, pakiet odebrany), a unanswered to lista pakietów, na które nie otrzymano odpowiedzi. Funkcja sr1(pkt, timeout=2) działa podobnie, ale zwraca tylko pierwszą odebraną odpowiedź, co jest wygodne, gdy spodziewamy się dokładnie jednej odpowiedzi (jak w przypadku ping). Parametr verbose=0 wyłącza wyświetlanie komunikatów postępu, co jest przydatne w skryptach. Funkcje sr() i sr1() są implementacją synchroniczną – program czeka na odpowiedź i blokuje dalsze wykonanie. Dla zastosowań asynchronicznych Scapy oferuje funkcje srloop() oraz async sniffer.

Przykład użycia sr1() w praktyce pokazuje, jak w kilku linijkach Pythona zaimplementować funkcję ping z odczytem TTL (Time To Live). Wysyłamy pakiet ICMP Echo Request do hosta 8.8.8.8 i czekamy na odpowiedź maksymalnie 3 sekundy. Jeśli odpowiedź nadejdzie, odczytujemy adres źródłowy odpowiadającego hosta (reply.src) oraz wartość TTL (reply.ttl). Wartość TTL jest użyteczna do identyfikacji systemu operacyjnego – domyślne TTL dla Linux to 64, dla Windows 128, dla routerów Cisco 255. Funkcja ta może być rozszerzona o obsługę wielu hostów, zapis wyników do pliku CSV oraz wizualizację czasu odpowiedzi. W skryptach monitorujących sr1() jest często używana w pętli do cyklicznego sprawdzania dostępności serwerów. Należy pamiętać o odpowiednio dobranym timeout – zbyt krótki spowoduje fałszywe negatywy, zbyt długi spowolni działanie skryptu.

Funkcja srloop() w Scapy to wygodny sposób na prowadzenie ciągłych pomiarów czasu odpowiedzi, analogicznie do działania narzędzia ping w systemie Linux. srloop() wysyła pakiet wielokrotnie z zadanym odstępem czasu i zbiera odpowiedzi, wyświetlając statystyki w czasie rzeczywistym. Parametry count określa liczbę wysłanych pakietów, inter odstęp w sekundach, a timeout maksymalny czas oczekiwania na odpowiedź. Po zakończeniu pętli srloop() wyświetla podsumowanie: liczbę wysłanych pakietów, odebranych odpowiedzi oraz procentową skuteczność. Funkcja ta jest przydatna do monitorowania jakości łącza w czasie – można uruchomić ją w tle na kilka minut i obserwować zmiany opóźnienia i utraty pakietów. W odróżnieniu od systemowego ping, srloop() pozwala na pełną kontrolę nad strukturą wysyłanego pakietu, co umożliwia testowanie zachowania firewalla dla różnych typów pakietów ICMP.

Generowanie zapytań ARP w Scapy to doskonały przykład praktycznego wykorzystania biblioteki do skanowania sieci lokalnej. Klasa ARP reprezentuje protokół ARP (Address Resolution Protocol) z polami takimi jak pdst (docelowy adres IP), hwdst (docelowy adres MAC), psrc (źródłowy adres IP) i hwsrc (źródłowy adres MAC). Wysyłając zapytanie ARP do pojedynczego hosta, otrzymujemy w odpowiedzi jego adres MAC – jest to odpowiednik polecenia arp -a. Skanowanie całej podsieci (/24) za pomocą sr() wysyła zapytania ARP do wszystkich 254 adresów i zbiera odpowiedzi, co pozwala na szybkie zmapowanie wszystkich aktywnych urządzeń w sieci LAN. Ta technika jest wykorzystywana przez narzędzia takie jak arp-scan i Nmap (opcja -PR). W laboratorium dydaktycznym skanowanie ARP z Scapy służy do demonstracji, jak działa protokół ARP i jak łatwo można zautomatyzować skanowanie sieci.

Implementacja ping w Scapy pokazuje, jak w kilku linijkach kodu odtworzyć działanie klasycznego narzędzia diagnostycznego. Wysłanie pakietu ICMP type 8 (Echo Request) i odebranie odpowiedzi type 0 (Echo Reply) to podstawa testowania łączności IP. Scapy pozwala na dodanie własnego payloadu do pakietu ICMP, co może być przydatne do testowania firewalla – niektóre zapory blokują pakiety ICMP z niestandardowym payloadem. W odróżnieniu od systemowego ping, implementacja w Scapy daje pełną kontrolę nad wszystkimi polami pakietu ICMP: typem, kodem, identyfikatorem i numerem sekwencyjnym. Można również zmieniać wartości pól IP (TTL, DSCP, pole fragmentacji) i obserwować, jak wpływają na odpowiedź. Ping w Scapy jest często używany jako pierwszy krok w nauce biblioteki, ponieważ łączy w sobie tworzenie pakietów, wysyłanie i odbieranie – trzy fundamentalne operacje Scapy.

Generowanie zapytań DNS w Scapy umożliwia testowanie serwerów DNS i analizę odpowiedzi bez konieczności używania zewnętrznych narzędzi, takich jak dig czy nslookup. Klasa DNS w Scapy reprezentuje protokół DNS, a DNSQR (DNS Question Record) pozwala na określenie zapytania: nazwy domeny (qname) i typu rekordu (qtype, domyślnie A). Oprócz zapytań o rekordy A (adres IPv4), Scapy obsługuje wszystkie typy DNS: AAAA (IPv6), MX (serwer pocztowy), CNAME (alias), NS (serwer nazw), TXT (tekst) i wiele innych. Odpowiedź DNS jest analizowana przez dostęp do warstwy DNS i iterację po rekordach odpowiedzi (dns.an). Scapy potrafi również generować zapytania o transfer strefy DNS (AXFR), co jest przydatne w testach bezpieczeństwa – jeśli serwer DNS pozwala na transfer strefy, atakujący może poznać pełną mapę domen wewnętrznych. W laboratorium zapytania DNS z Scapy służą do nauki budowania nagłówka DNS i analizy odpowiedzi.

Filtrowanie pakietów w Scapy można realizować na dwóch poziomach: podczas przechwytywania (sniff) za pomocą filtrów BPF oraz po przechwyceniu za pomocą wyrażeń Pythona. Filtry BPF są bardziej wydajne, ponieważ odrzucają niepotrzebne pakiety już w jądrze systemu operacyjnego, zanim trafią do przestrzeni użytkownika. Filtrowanie po przechwyceniu w Pythonie jest wolniejsze, ale oferuje znacznie większą elastyczność – można łączyć warunki dotyczące różnych warstwy protokołów, korzystać z wyrażeń regularnych i tworzyć złożone logiki filtrujące. Metoda haslayer() sprawdza, czy pakiet zawiera określoną warstwę, a dostęp do pól odbywa się przez indeksowanie: p[IP].src. Scapy oferuje również możliwość tworzenia własnych funkcji filtrujących, które można przekazać do parametru lfilter w sniff(). Dla zaawansowanych zastosowań dostępne są filtry kompozytowe, łączące warunki za pomocą operatorów logicznych Pythona (and, or, not).

Funkcje wrpcap() i rdpcap() w Scapy umożliwiają zapis i odczyt plików w formatach pcap i pcapng, które są standardem w analizie ruchu sieciowego. Dzięki temu pakiety przechwycone przez Scapy mogą być analizowane w Wireshark i odwrotnie – pliki pcap z Wireshark mogą być wczytywane do Scapy do dalszej programowej obróbki. wrpcap() zapisuje listę pakietów (PacketList) do pliku, zachowując znaczniki czasowe. rdpcap() odczytuje plik i zwraca obiekt PacketList z wszystkimi pakietami. Można również użyć funkcji PcapReader() do sekwencyjnego odczytu dużych plików bez ładowania ich w całości do pamięci – jest to zalecane przy plikach pcap o rozmiarze setek megabajtów lub gigabajtów. Połączenie sniff() → wrpcap() → rdpcap() → analyze() to typowy przepływ pracy w analizie sieciowej z użyciem Scapy, pozwalający na przechwycenie ruchu, zapis do pliku, a następnie szczegółową analizę.

Skrypt testujący Scapy pokazuje, jak w kilkunastu linijkach Pythona zbudować narzędzie do monitorowania dostępności wielu hostów. Funkcje test_ping() i test_port() implementują odpowiednio test ICMP i test TCP SYN, a pętla główna iteruje po liście hostów i wyświetla wyniki. Taki skrypt można uruchomić z poziomu cron (Linux) lub Task Scheduler (Windows) i zbierać wyniki do pliku CSV, tworząc historyczne dane o dostępności serwerów. Skrypt można rozbudować o obsługę timeout, wielowątkowość (dla szybszego testowania wielu hostów równocześnie) oraz generowanie alertów w przypadku braku odpowiedzi. W środowisku laboratoryjnym podobne skrypty są używane do automatycznej weryfikacji poprawności konfiguracji sieci po wprowadzeniu zmian. Scapy sprawdza się w tej roli lepiej niż systemowy ping, ponieważ pozwala na testowanie dowolnych portów TCP i generowanie różnych typów pakietów w ramach jednego skryptu.

Skaner portów w Scapy to klasyczny przykład wykorzystania biblioteki do testowania bezpieczeństwa sieci. Implementacja TCP SYN scan (half-open scan) wysyła pakiety z flagą SYN i analizuje odpowiedź: SYN-ACK oznacza port otwarty, RST oznacza port zamknięty, a brak odpowiedzi może oznaczać filtr lub stan. W przeciwieństwie do pełnego połączenia TCP (connect scan), SYN scan nie nawiązuje pełnej sesji, przez co jest trudniejszy do wykrycia przez systemy IDS/IPS. W podanym przykładzie skanowane są porty 22 (SSH), 80 (HTTP), 443 (HTTPS), 8080 (HTTP proxy) i 3306 (MySQL) na hoście 192.168.1.1. Skaner można rozszerzyć o skanowanie zakresu portów w pętli, obsługę timeout i wyświetlanie wyników w czytelnej tabeli. Należy bezwzględnie pamiętać, że skanowanie bez zgody właściciela sieci jest nielegalne i może być uznane za przygotowanie do ataku. Scapy w kursach bezpieczeństwa służy wyłącznie do demonstracji w kontrolowanym środowisku laboratoryjnym.

Demonstracja ARP spoofing z użyciem Scapy to zaawansowany przykład ilustrujący, jak działa atak typu man-in-the-middle (MITM) w sieci LAN. Skrypt wysyła sfałszowane odpowiedzi ARP (gratuitous ARP), w których adres IP bramy (gateway_ip) jest przypisany do adresu MAC atakującego (attacker_mac). Oszukany host docelowy (target_ip) zaczyna wysyłać cały ruch do bramy przez atakującego, który może przechwytywać i modyfikować pakiety. Skrypt działa w pętli nieskończonej, wysyłając sfałszowane ARP co sekundę, aby utrzymać zatrutą tabelę ARP ofiary. Po zatrzymaniu skryptu (Ctrl+C) tabela ARP wróci do normy po kilkudziesięciu sekundach lub po ręcznym wyczyszczeniu (arp -d). ARP spoofing jest skuteczny tylko w sieciach LAN, gdzie protokół ARP nie ma żadnych mechanizmów uwierzytelniania. W nowoczesnych sieciach stosuje się techniki ochrony takie jak Dynamic ARP Inspection (DAI) na przełącznikach zarządzalnych.

Testowanie reguł firewalla za pomocą Scapy pozwala na precyzyjną weryfikację każdej reguły dostępu w sposób zautomatyzowany. Skrypt wysyła pakiety testowe do firewalla i analizuje odpowiedzi, aby określić, które porty i protokoły są przepuszczane. Test ICMP sprawdza, czy firewall odpowiada na ping – wiele organizacji blokuje ICMP w celach bezpieczeństwa, co utrudnia diagnostykę, ale jest zalecane. Test SSH (port 22) sprawdza dostępność usługi administracyjnej. Testowanie podejrzanych portów (21-FTP, 23-Telnet, 25-SMTP, 135-RPC, 445-SMB) pozwala na wykrycie niebezpiecznych, otwartych usług, które mogą stanowić wektor ataku. Skrypt można rozszerzyć o testowanie wszystkich 65535 portów TCP i UDP, ale wymaga to odpowiedniego czasu i może być odebrane jako atak. W praktyce testowanie firewalla z Scapy wykonuje się w ramach audytów bezpieczeństwa i testów penetracyjnych po uzyskaniu pisemnej zgody.

Porównanie Scapy z innymi narzędziami podkreśla unikalną pozycję tej biblioteki w ekosystemie narzędzi sieciowych. Podczas gdy Wireshark i tcpdump są przede wszystkim analizatorami (snifferami) o bardzo wysokiej wydajności i bogatych możliwościach dekompozycji protokołów, Scapy oferuje dodatkowo możliwość generowania dowolnych pakietów. hping3 i Ostinato również generują pakiety, ale nie oferują programowalności Pythona i możliwości łatwego łączenia generowania z analizą. Scapy jest więc narzędziem uniwersalnym, które w jednym skrypcie może wygenerować ruch, przechwycić odpowiedzi, przeanalizować je i zapisać wyniki. Wadą jest wydajność – Python narzuca ograniczenia szybkościowe, które dla testów powyżej 100 Mb/s stają się problematyczne. W takich przypadkach należy sięgnąć po Ostinato (do 10 Gb/s z DPDK) lub dedykowane generatory sprzętowe (400 Gb/s+).

Ograniczenia Scapy wynikają głównie z natury języka Python, który jest językiem interpretowanym z wątkiem globalnej blokady interpreteru (GIL). Przy generowaniu powyżej 1000 pakietów na sekundę Scapy zaczyna tracić pakiety i nie jest w stanie utrzymać zadanej szybkości. Dla testów wydajnościowych, gdzie wymagane są dziesiątki tysięcy pakietów na sekundę, należy użyć Ostinato lub hping3. Kolejnym ograniczeniem są uprawnienia – Scapy wymaga dostępu do surowych gniazd (raw sockets), co na Linux oznacza uprawnienia root, a na Windows wymaga uruchomienia jako Administrator i zainstalowanego Npcap. Duże pakiety (powyżej 65535 B) mogą powodować błędy w Scapy, szczególnie w przypadku IPv6 jumbogramów. Dokładność czasowa jest również ograniczona – Python nie gwarantuje precyzyjnych odstępów między pakietami, co ma znaczenie w testach wymagających mikrosekundowej precyzji. Rozwiązaniem tych problemów jest użycie Scapy w połączeniu z PyPy (szybszy interpreter) lub Cython (kompilacja do C).

Wybór odpowiedniego narzędzia do generowania ruchu zależy przede wszystkim od celu testu i dostępnych zasobów. RouterOS Traffic Generator jest idealny do szybkich testów w infrastrukturze MikroTik, szczególnie gdy nie mamy dostępu do komputera z generatorami programowymi. Ostinato sprawdza się w laboratoriach wymagających wielu jednoczesnych strumieni, precyzyjnej kontroli szybkości i przyjaznego interfejsu graficznego. Scapy jest niezastąpiony w edukacji, prototypowaniu i automatyzacji – student może w jednym skrypcie połączyć generowanie, przechwytywanie i analizę. hping3 to narzędzie z wyboru dla administratorów pracujących w terminalu, którzy potrzebują szybko sprawdzić regułę firewalla bez uruchamiania GUI. iperf3 ma bardzo wąskie zastosowanie – wyłącznie pomiar przepustowości TCP/UDP, ale robi to lepiej niż jakiekolwiek inne narzędzie. W praktyce warto mieć w swoim arsenale co najmniej dwa-trzy narzędzia i wybierać je stosownie do potrzeb.

Szczegółowa tabela porównawcza uwidacznia różnice między czterema głównymi generatorami ruchu omawianymi w tej części. RouterOS Traffic Generator wyróżnia się brakiem kosztów (zawarty w RouterOS) i prostotą konfiguracji, ale jest ograniczony do jednej platformy i oferuje podstawową kontrolę pakietów. Ostinato zapewnia najlepszy balans między wydajnością a łatwością użycia, wspiera wiele protokołów i oferuje zarówno GUI, jak i API Drone do automatyzacji. Scapy daje największą elastyczność dzięki Pythonowi, ale kosztem wydajności – maksymalnie około 100 Mb/s. hping3 jest najszybszym narzędziem CLI, ale ograniczonym do protokołów TCP, UDP, ICMP i raw IP. Wszystkie cztery narzędzia są darmowe i open source, co czyni je dostępnymi dla każdego studenta i inżyniera. Dla testów wymagających przepustowości powyżej 10 Gb/s niezbędne są komercyjne generatory sprzętowe IXIA lub Spirent.

Pytania kontrolne sprawdzają zrozumienie kluczowych koncepcji omówionych w tej części. Ograniczenia Traffic Generator (CPU-bound, tylko RouterOS, brak warstwy 2 i zapisu pcap) są istotne przy planowaniu testów w sieciach MikroTik. Różnica między send() a sendp() w Scapy (warstwa 3 vs warstwa 2) jest fundamentalna dla zrozumienia, jak działa wysyłanie pakietów w Scapy. Różnica między sr() a sr1() (wszystkie odpowiedzi vs pierwsza odpowiedź) wpływa na sposób implementacji narzędzi sieciowych. Rola Drone w Ostinato jako serwera odpowiedzialnego za fizyczne wysyłanie i odbieranie pakietów jest kluczowa dla zrozumienia architektury klient-serwer tego narzędzia. Dodatkowe pytania mogą dotyczyć formatu plików .ost (XML), filtrów BPF w Scapy oraz różnic między protokołami UDP i TCP w kontekście generowania ruchu testowego.

Zadania praktyczne zostały tak dobrane, aby student samodzielnie przećwiczył omawiane narzędzia w działaniu. Zadanie 1 (ping w Scapy) wymaga użycia sr1() i odczytu TTL, co jest podstawową umiejętnością przy pracy z biblioteką. Zadanie 2 (skaner portów) rozszerza umiejętności o pracę z warstwą TCP i analizę flag odpowiedzi. Zadanie 3 (Ostinato) wymaga zapoznania się z GUI, edytorem warstw i konfiguracją strumienia – kluczowe umiejętności przy testowaniu firewalli. Zadanie 4 (RouterOS) łączy konfigurację VLAN z Traffic Generator i wymaga znajomości konsoli MikroTik. Wszystkie zadania można wykonać w laboratorium z podstawowym sprzętem sieciowym i komputerem z Pythonem. Zachęca się do eksperymentowania z różnymi parametrami i porównywania wyników, co rozwija umiejętność analitycznego myślenia i rozwiązywania problemów sieciowych.

Generowanie ruchu sieciowego to niezbędna umiejętność każdego inżyniera sieciowego, pozwalająca na kontrolowane testowanie infrastruktury przed wdrożeniem i podczas diagnostyki. W tej części poznaliśmy trzy główne narzędzia: RouterOS Traffic Generator do szybkich testów w ekosystemie MikroTik, Ostinato do zaawansowanych testów wielostrumieniowych z interfejsem graficznym oraz Scapy do programowej manipulacji pakietami w Pythonie. Każde z tych narzędzi ma swoje mocne strony i ograniczenia, a umiejętność wyboru odpowiedniego narzędzia do zadania jest cechą dobrego inżyniera. W kolejnej części przejdziemy do praktycznej analizy przechwyconego ruchu z użyciem Wireshark, tshark oraz narzędzi do generowania wykresów i statystyk. Zachęcamy do samodzielnego eksperymentowania z poznanymi narzędziami – praktyka jest najlepszym sposobem na utrwalenie wiedzy.