w PiDSK - Część 12: Narzędzia pomiarowe – przegląd i podsumowanie
1/55
Przegląd narzędzi pomiarowych sieci
Cel slajdu: Przedstawienie architektury współczesnego ekosystemu narzędzi pomiarowych, analitycznych i telemetrycznych w inżynierii sieci teleinformatycznych.

Prezentacja stanowi podsumowanie całego cyklu, przedstawiając przegląd narzędzi pomiarowych: ping, iperf, Wireshark, tcpdump, netstat (w Linux przestarzały – następca ss) i traceroute. Omówiono podział narzędzi na GUI i CLI, narzędzia dla LAN i WLAN, a także kryteria wyboru odpowiedniego narzędzia. Przedstawiono studium przypadku diagnostyki sieci firmowej oraz dobre praktyki pomiarowe.

Aparatura pomiarowa sieci: zintegrowany zbiór narzędzi sprzętowych i programowych (analizatory protokołów, sniffery pakietów, generatory obciążenia L4–L7, systemy telemetrii przepływów) umożliwiający obiektywną, ilościową i jakościową ocenę parametrów transmisji danych.
Narzędzia pomiarowe

Nowoczesna teleinformatyka jest dziedziną ściśle empiryczną: żadna decyzja o projektowaniu, optymalizacji czy uszczelnianiu zabezpieczeń sieci nie może opierać się na domysłach, lecz musi wynikać z precyzyjnych pomiarów fizycznych i logicznych. W dobie infrastruktury wieloterabitowej, centrów danych w chmurze oraz sieci o wysokiej dostępności (High Availability 99,999%), aparatura pomiarowa stanowi oczy i uszy inżyniera sieciowego.

Ekosystem narzędzi pomiarowych dzieli się na dwie komplementarne kategorie: 1. Narzędzia pasywne (Passive Monitoring / Packet Inspection): oprogramowanie i sondy rejestrujące ruch produkcyjny bez jakiejkolwiek ingerencji w medium transmisyjne. Należą do nich flagowe analizatory protokołów, takie jak Wireshark oraz konsolowy tcpdump, a także systemy analizy przepływów telemetrycznych NetFlow / IPFIX (RFC 7011). 2. Narzędzia aktywne (Active Probing / Traffic Generation): narzędzia wstrzykujące do sieci kontrolowany ruch syntetyczny w celu zbadania zachowania łączy pod maksymalnym obciążeniem, pomiaru realnej przepustowości (Goodput), opóźnień i strat, na czele ze standardem iperf3.

W niniejszym, finałowym module kursu szczegółowej analizie poddane zostaną zaawansowane filtry wyświetlania i przechwytywania (BPF), rekonstrukcja sesji TCP, interpretacja wskaźników generowanych przez iperf3, a także syntetyczna, przekrojowa powtórka wszystkich kluczowych zagadnień poruszonych w jedenastu poprzednich częściach cyklu PiDSK.

2/55
Plan wykładu o narzędziach
Cel slajdu: Przedstawienie zintegrowanego planu modułu dwunastego, łączącego zaawansowane narzędzia pomiarowe z całościową syntezą kursu Podstaw i Diagnostyki Sieci Komputerowych.

Plan części 12 – Narzędzia i Wielkie Repetytorium

  • Wireshark – podstawy
  • Tcpdump – podstawy
  • Iperf3 – podstawy
  • Podział narzędzi: GUI vs CLI
  • Narzędzia dla LAN
  • Narzędzia dla WLAN
  • Narzędzia do analizy protokołów
  • Narzędzia do generowania ruchu
  • Porównanie narzędzi (tabela)
  • Kryteria wyboru narzędzia
  • Studium przypadku: diagnostyka sieci firmowej
  • Podsumowanie całego cyklu
  • Pytania końcowe
Struktura modułu finałowego: dwuczęściowy układ obejmujący: 1) zaawansowaną analizę pakietową i generator iperf3, oraz 2) kompleksowe repetytorium wiedzy z części 1–11 kursu PiDSK prowadzące do syntezy inżynierskiej.
Plan prezentacji

Dwunasta część kursu stanowi kulminację całego procesu dydaktycznego. Została zaprojektowana w taki sposób, aby z jednej strony wyposażyć inżyniera w najbardziej zaawansowane techniki posługiwania się analizatorem Wireshark i generatorem iperf3, a z drugiej strony scalić wiedzę z całego cyklu w jednolity, spójny system pojęciowy.

W pierwszym segmencie modułu zgłębimy zaawansowane funkcje analizatora Wireshark: składnię filtrów wyświetlania (Display Filters), analizę wykresów przepływności (IO Graphs), rekonstrukcję strumieni aplikacyjnych (Follow TCP Stream) oraz detekcję anomalii TCP (retransmisje, duplikaty ACK, zerowe okna odbiorcze). Zestawimy te funkcje z konsolowym narzędziem tcpdump oraz omówimy metodologię testów przepustowości za pomocą iperf3 w protokołach TCP i UDP.

Drugi, fundamentalny segment modułu to Wielkie Repetytorium PiDSK: usystematyzowana powtórka jedenastu filarów wiedzy sieciowej: od okablowania strukturalnego i sieci bezprzewodowych Wi-Fi, przez modele warstwowe OSI i TCP/IP, protokoły routingu i adresację IPv4/IPv6, aż po narzędzia konsolowe CLI oraz prawo i etykę cyberbezpieczeństwa. Całość wieńczą praktyczne zadania laboratoryjne, matryce decyzyjne oraz formuła złotych zasad profesjonalnego inżyniera teleinformatyki.

3/55
Wireshark – analizator protokołów sieciowych
Cel slajdu: Przedstawienie architektury, historii i zasady działania wiodącego na świecie analizatora pakietów Wireshark oraz jego trójpanelowego interfejsu analitycznego.

Wireshark – flagowy analizator protokołów sieciowych

  • Przechwytywanie pakietów w czasie rzeczywistym
  • Analiza offline plików pcap/pcapng
  • Dekodowanie setek protokołów (HTTP, TCP, DNS, TLS…)
  • Filtry: capture (BPF) i display (Wireshark filter)
  • Statystyki: IO Graph, Protocol Hierarchy, Conversations
Wireshark (d. Ethereal): wieloplatformowy analizator protokołów sieciowych o otwartym kodzie źródłowym, wykorzystujący bibliotekę libpcap/Npcap do przechwytywania ramek w trybie promiscuous i deasemblacji ponad 3000 protokołów sieciowych.
Zrzut ekranu Wireshark

Program Wireshark (stworzony w 1998 roku przez Geralda Combsa pod pierwotną nazwą Ethereal) jest niekwestionowanym, globalnym standardem w dziedzinie niskopoziomowej analizy protokołów sieciowych (Packet Sniffing & Deep Packet Inspection). Umożliwia wgląd w surową strukturę binarną każdej ramki przesyłanej przez fizyczny lub wirtualny interfejs sieciowy, dekodując pola nagłówków od warstwy 2 aż po warstwę 7.

Architektura programu opiera się na bibliotece przechwytywania: libpcap w systemach uniksowych/linuksowych oraz Npcap (zastępującej historyczny WinPcap) w systemie Windows. Biblioteki te przełączają kartę sieciową w tryb nasłuchiwania (Promiscuous Mode), co pozwala na rejestrowanie wszystkich ramek pojawiających się na danym segmencie L2, a nie tylko tych skierowanych na własny adres MAC stacji.

Interfejs graficzny Wiresharka zorganizowany jest w klasyczny, ergonomiczny układ trójpanelowy: 1. Packet List (Górny panel): numerowana lista przechwyconych ramek ze znacznikami czasu (Timestamp), adresami źródłowymi i docelowymi, protokołem nadrzędnym oraz zwięzłą informacją diagnostyczną (Info). 2. Packet Details (Środkowy panel): hierarchiczne drzewo dekapsulacji protokołowej odpowiadające warstwom ISO/OSI (Frame L1, Ethernet II L2, IPv4/IPv6 L3, TCP/UDP L4, protokół aplikacji L7). 3. Packet Bytes (Dolny panel): surowy podgląd szesnastkowy (Hex Dump) i tekstowy (ASCII) zawartości bufora ramki.

4/55
Filtry wyświetlania w Wireshark
Cel slajdu: Opanowanie składni i operatorów logiki filtrów wyświetlania w Wiresharku w celu natychmiastowej izolacji poszukiwanych pakietów w wielogigabajtowych zrzutach.

Filtry wyświetlania (Display Filters) w Wireshark

# Filtry protokołów
http
dns
tcp.port eq 443

# Filtry adresów
ip.src == 192.168.1.1
ip.dst == 8.8.8.8
eth.addr == 00:1A:2B:3C:4D:5E

# Filtry złożone
http and ip.src == 192.168.1.100
tcp.analysis.flags # retransmisje, ACK zagubione
Filtry wyświetlania Wireshark: mechanizm post-processingowy umożliwiający filtrowanie już przechwyconych pakietów na podstawie pól protokołów przy użyciu operatorów relacyjnych (==, !=, >, <) i logicznych (and, or, not).
Filtry Wireshark

Podczas rejestracji ruchu w obciążonym segmencie sieci w ciągu zaledwie kilkunastu sekund analizator może zgromadzić dziesiątki tysięcy ramek. Odnalezienie pojedynczego błędu retransmisji lub problematycznego zapytania DNS bez znajomości filtrów wyświetlania (Display Filters) jest zadaniem niewykonalnym. W przeciwieństwie do filtrów przechwytywania BPF, filtry wyświetlania nie odrzucają pakietów trwale, lecz maskują widok na ekranie w czasie rzeczywistym.

Kluczowe przykłady filtrów inżynieryjnych w Wiresharku: - Filtrowanie warstwy sieciowej L3: - ip.addr == 192.168.1.50 (wyświetla ruch, w którym badany adres jest źródłem LUB celem), - ip.src == 10.0.0.1 and ip.dst == 10.0.0.2 (izoluje ruch jednokierunkowy), - ipv6.dst == ff02::1 (wyświetla ruch multicastowy do wszystkich węzłów IPv6). - Filtrowanie warstwy transportowej L4: - tcp.port == 443 (wyświetla sesje HTTPS), - tcp.flags.syn == 1 and tcp.flags.ack == 0 (izoluje wyłącznie pakiety inicjujące 3-Way Handshake).

- Diagnostyka anomalii transmisyjnych TCP: - tcp.analysis.retransmission (ujawnia retransmisje pakietów spowodowane stratami na łączu), - tcp.analysis.duplicate_ack (wykrywa potrójne duplikaty ACK zwiastujące utratę segmentu), - tcp.analysis.zero_window (alarmuje o wyczerpaniu bufora odbiornika i paraliżu przepływu). - Filtrowanie usług aplikacyjnych L7: - dns.flags.response == 1 and dns.time > 0.1 (ujawnia powolne odpowiedzi DNS przekraczające 100 ms), - http.response.code >= 400 (izoluje błędy HTTP po stronie klienta lub serwera).

5/55
Analiza strumieni TCP w Wireshark
Cel slajdu: Przedstawienie techniki rekonstrukcji konwersacji warstwy aplikacji poprzez desegmentację i łączenie strumienia bajtów TCP.

Analiza strumieni TCP (Follow TCP Stream) w Wireshark

Wireshark umożliwia złożenie całej sesji TCP w jeden widok (kliknij prawym → Follow → TCP Stream).

Widzisz całe żądanie HTTP, odpowiedź, lub sesję SMTP/FTP.

Przydatne w diagnostyce: „co dokładnie wysłała aplikacja?"

Follow TCP Stream: funkcja analizatora Wireshark rekonstruująca pełną, dwukierunkową konwersację warstwy aplikacji ze strumienia pakietów TCP (RFC 793), prezentująca dane wymienione pomiędzy klientem a serwerem w czytelnej formie tekstowej lub binarnej.
Follow TCP Stream

Protokół TCP (RFC 793) jest protokołem zorientowanym na strumień bajtów (Byte-Stream Protocol), co oznacza, że dane aplikacji użytkownika są dzielone na fragmenty (segmenty TCP) o wielkości nieprzekraczającej MSS (Maximum Segment Size) i przesyłane w wielu oddzielnych pakietach IP. Przeglądanie takiego ruchu pakiet po pakiecie uniemożliwia ocenę treści transakcji biznesowej.

Funkcja Follow TCP Stream w programie Wireshark dokonuje automatycznej desegmentacji, porządkowania numerów sekwencyjnych (Sequence Numbers) oraz odrzucenia retransmisji, prezentując analitykowi spójny dialog aplikacyjny w osobnym oknie:

- Dane wysłane przez klienta do serwera (np. zapytanie GET /index.html HTTP/1.1 wraz z nagłówkami) wyróżnione są kolorem czerwonym. - Dane odesłane przez serwer do klienta (np. odpowiedź HTTP/1.1 200 OK wraz z zawartością dokumentu HTML) oznaczone są kolorem niebieskim. - Wireshark automatycznie tworzy filtr wyświetlania indeksu strumienia: tcp.stream eq <numer>, izolując wszystkie pakiety danej sesji od reszty zrzutu.

Warto pamiętać, że w przypadku nowoczesnych protokołów szyfrowanych (HTTPS TLS 1.3 wg RFC 8446) zawartość strumienia prezentuje nieczytelny szyfrogram. W celu jego odczytania analityk musi załadować do Wiresharka plik z kluczami sesyjnymi (tzw. SSLKEYLOGFILE generowany przez przeglądarkę), co pozwala na transparentne odszyfrowanie i analizę komunikacji.

6/55
tcpdump – sniffer wiersza poleceń
Cel slajdu: Przedstawienie architektury i zastosowania programu tcpdump jako niezastąpionego narzędzia analizy pakietowej na serwerach bez interfejsu graficznego.

tcpdump – konsolowy sniffer wiersza poleceń

# Przechwyć na interfejsie eth0
sudo tcpdump -i eth0

# Zapisz do pliku pcap
sudo tcpdump -i eth0 -w capture.pcap

# Odczytaj z pliku
tcpdump -r capture.pcap

# Filtry BPF
tcpdump -i eth0 host 192.168.1.1
tcpdump -i eth0 port 80
tcpdump -i eth0 icmp
Polecenie tcpdump: potężny analizator pakietów CLI dla systemów Unix/Linux, bazujący na bibliotece libpcap i jądrze BPF (Berkeley Packet Filter), służący do niskopoziomowego przechwytywania, filtrowania i zrzucania ruchu sieciowego do plików PCAP.
tcpdump w terminalu

Chociaż Wireshark oferuje potężny i wygodny interfejs graficzny, w środowiskach serwerowych, chmurach obliczeniowych, kontenerach Docker/Kubernetes oraz na routerach brzegowych środowisko graficzne (X11 / Wayland) nie występuje. W takich warunkach podstawowym, niezastąpionym narzędziem diagnostyki pakietowej jest program tcpdump, rozwijany od 1988 roku przez Van Jacobsona, Craiga Leresa i Stevena McCanne'a.

Sercem narzędzia tcpdump jest mechanizm BPF (Berkeley Packet Filter), zintegrowany bezpośrednio z jądrem systemu Linux. BPF działa wewnątrz przestrzeni jądra (Kernel Space), kompilując zdefiniowane przez administratora reguły filtrowania do wysoce zoptymalizowanego mikrokodu maszynowego. Dzięki temu pakiety, które nie pasują do filtra, są odrzucane natychmiast na poziomie sterownika karty sieciowej, bez konieczności kosztownego kopiowania ich do przestrzeni użytkownika (User Space), co pozwala na bezstratne monitorowanie łączy wielogigabitowych.

Typowy inżynierski model pracy polega na użyciu tcpdump do rejestracji ruchu w środowisku produkcyjnym i zapisaniu surowego strumienia do pliku binarnego (opcja -w zrzut.pcap), a następnie pobraniu pliku na stację inżynierską i jego wygodnej analizie w graficznym interfejsie Wiresharka. Połączenie tych dwóch narzędzi stanowi absolutny kanon sztuki diagnostycznej.

7/55
Przydatne opcje narzędzia tcpdump
Cel slajdu: Zapoznanie z kanonem parametrów konfiguracyjnych tcpdump oraz składnią filtrów Berkeley Packet Filter.

Kluczowe przełączniki i filtry BPF w tcpdump

# Liczba pakietów
tcpdump -c 100

# Szczegółowy output (więcej protokołów)
tcpdump -v

# Pokazuj tylko nagłówki (bez payloadu)
tcpdump -s 64

# Hex + ASCII output
tcpdump -X
Składnia inżynierska tcpdump: parametry CLI kontrolujące wybór interfejsu (-i), notację numeryczną (-nn), rozmiar przechwytywania (-s), zapis/odczyt (-w / -r) oraz wyrażenia filtrów BPF (host, net, port, proto).
Opcje tcpdump

Biegle posługujący się narzędziem tcpdump inżynier sieciowy potrafi w ciągu kilku sekund skomponować precyzyjne polecenie wyłapujące dokładnie ten jeden pakiet, który paraliżuje działanie usługi. Domyślne wywołanie bez parametrów próbuje rozwiązywać nazwy DNS dla każdego pakietu, co przy awarii DNS może całkowicie zawiesić terminal.

Złoty kanon parametrów wywołania tcpdump: - -i <interfejs>: wybór badanego interfejsu (np. -i eth0, -i any – nasłuch na wszystkich interfejsach jednocześnie). - -nn: bezwzględnie zalecana opcja! Wyłącza translację adresów IP na nazwy domenowe oraz numerów portów na nazwy usług (prezentuje czyste wartości liczbowe, np. 192.168.1.1.443 zamiast gateway.https), co diametralnie przyspiesza działanie narzędzia. - -s <rozmiar> (Snaplen): określa liczbę bajtów przechwytywanych z każdej ramki (np. -s 96 rejestruje tylko nagłówki, chroniąc prywatność użytkowników; -s 0 rejestruje pełną ramkę bez obcinania).

- -w plik.pcap: bezpośredni zapis surowych ramek do formatu binarnego PCAP bez formatowania tekstowego na ekranie terminala. - -r plik.pcap: odczyt i analiza wcześniej zapisanego pliku. - -v / -vv / -vvv: zwiększa szczegółowość dekodowania nagłówków protokołów. - Wyrażenia filtrów BPF: umieszczane na końcu polecenia w apostrofach: - 'tcp port 80 and not host 192.168.1.10', - 'icmp or icmp6', - 'src net 10.0.0.0/8 and dst port 53'.

8/55
iperf3 – pomiar przepustowości sieci
Cel slajdu: Przedstawienie architektury klient-serwer narzędzia iperf3 oraz metodyki precyzyjnego pomiaru przepustowości warstwy transportowej.

iperf3 – pomiar przepustowości i generowanie ruchu

# Serwer (na hoście docelowym)
iperf3 -s

# Klient (test 30 sekund)
iperf3 -c 192.168.1.100 -t 30

# Test UDP
iperf3 -c 192.168.1.100 -u -b 100M

# Test dwukierunkowy
iperf3 -c 192.168.1.100 --bidir
Narzędzie iperf3: standardowy generator ruchu sieciowego i miernik przepustowości działający w modelu klient-serwer, pozwalający na badanie maksymalnej przepustowości łączy w protokołach TCP, UDP i SCTP pod kontrolowanym obciążeniem.
iperf3 w terminalu

Narzędzia takie jak ping mierzą opóźnienie (RTT) dla małych pakietów kontrolnych, lecz nie są w stanie określić, czy łącze jest zdolne do przesłania gigabitowego strumienia danych z deklarowaną prędkością. Do obiektywnego, inżynierskiego pomiaru rzeczywistej wydajności łącza warstwy transportowej L4 służy program iperf3, rozwijany przez konsorcjum naukowe ESnet (Energy Sciences Network).

Program pracuje w architekturze klient-serwer i wymaga uruchomienia na dwóch krańcach badanego łącza: 1. Strona serwera (Odbiornik): nasłuchuje na zdefiniowanym porcie (domyślnie TCP/UDP 5201): iperf3 -s 2. Strona klienta (Nadajnik): inicjuje transfer danych do serwera, domyślnie nasycając łącze przez 10 sekund w protokole TCP: iperf3 -c 192.168.1.100

Warto odróżnić dwa pojęcia: Throughput (Przepustowość brutto) – całkowita liczba bitów przesyłanych w medium fizycznym z uwzględnieniem narzutu nagłówków L2–L4, oraz Goodput (Przepustowość netto / użytkowa) – liczba czystych bajtów danych aplikacji przetransportowanych w jednostce czasu. iperf3 mierzy właśnie Goodput, dając inżynierowi realistyczny obraz wydajności dostępnej dla aplikacji biznesowych.

Warto również zwrócić uwagę na zaawansowane parametry testowe: przełącznik -P <liczba> (Parallel Streams) pozwala na uruchomienie wielu równoległych strumieni TCP, co jest niezbędne do pełnego nasycenia łączy wielogigabitowych z wysokim opóźnieniem (tzw. Long Fat Networks wg RFC 7323). Z kolei parametr -w <rozmiar> umożliwia ręczne dostrojenie wielkości okna bufora TCP (TCP Window Size), co pozwala badać ograniczenia stosu sieciowego badanego systemu.

9/55
Interpretacja wyników iperf3
Cel slajdu: Wykształcenie umiejętności profesjonalnej analizy raportów wyjściowych iperf3 dla protokołów TCP i UDP.

Interpretacja wyników pomiarowych programu iperf3

[ ID] Interval Transfer Bitrate
[ 5] 0.00-30.00 sec 3.35 GBytes 960 Mbits/sec

960 Mb/s – rzeczywista przepustowość na łączu 1 Gb/s.

Różnica (~40 Mb/s) to narzuty TCP/IP, nagłówki, ACK.

Raport pomiarowy iperf3: tabelaryczne zestawienie parametrów transmisji: przedział czasu (Interval), przesłane dane (Transfer), przepustowość (Bandwidth), retransmisje (Retr), wielkość okna TCP (Cwnd), a w UDP: fluktuacja opóźnień (Jitter) i procentowa utrata pakietów (Lost/Total Datagrams).
Interpretacja wyniku iperf3

Prawidłowe odczytanie wyjścia programu iperf3 pozwala natychmiast zidentyfikować przyczynę niewystarczającej wydajności sieci. Raport generowany jest w regularnych jednosekundowych interwałach oraz podsumowany zbiorczo na końcu testu.

Kluczowe metryki w teście TCP: - Bandwidth (Przepustowość): wyrażana w Mbits/sec lub Gbits/sec (np. 941 Mbits/sec na łączu 1 Gbps Gigabit Ethernet oznacza niemal perfekcyjne wysycenie pasma po odliczeniu narzutów ramek). - Retr (Retransmisje): liczba utraconych segmentów TCP, które musiały zostać przesłane ponownie. Każda retransmisja w sieci LAN świadczy o usterce sprzętowej (błędy CRC, zły dupleks) lub buforowej switcha. - Cwnd (Congestion Window): bieżąca wielkość okna przeciążenia; dynamiczny wzrost i nagły spadek Cwnd świadczy o działaniu algorytmu kontroli przeciążenia (np. CUBIC lub BBR wg RFC 5681).

Kluczowe metryki w teście UDP (iperf3 -c <IP> -u -b 100M): Ponieważ UDP nie retransmituje pakietów ani nie reguluje okna, iperf3 raportuje dwa krytyczne wskaźniki jakościowe: - Jitter (Fluktuacja opóźnień): zmienność czasu nadejścia kolejnych pakietów (dla głosu VoIP wartość powyżej 20-30 ms jest niedopuszczalna). - Lost/Total Datagrams (% utraty): rzeczywista stopa utraty pakietów przy zadanym obciążeniu (np. 0.12%).

10/55
Wybór GUI czy CLI w pomiarach
Cel slajdu: Przedstawienie kryteriów inżynierskiego doboru pomiędzy narzędziami graficznymi (GUI) a wierszem poleceń (CLI).

Wybór interfejsu pomiarowego: GUI czy CLI?

GUICLI
Analiza interaktywnaAutomatyzacja (skrypty)
Łatwiejsze dla początkującychSzybsze dla zaawansowanych
Więcej pamięci RAMMało zasobów
Przykład: WiresharkPrzykład: tcpdump, tshark
Kryteria wyboru interfejsu: analiza komparatywna uwzględniająca narzut zasobowy, środowisko wykonawcze (serwer headless vs stacja robocza), możliwości automatyzacji skryptowej oraz potrzebę wizualizacji i korelacji danych.
GUI vs CLI

Jednym z częstych dylematów początkujących adeptów sieci jest pytanie: czy powinienem używać narzędzi z interfejsem graficznym (GUI), takich jak Wireshark, czy narzędzi konsolowych (CLI), takich jak tcpdump lub tshark? Doświadczony inżynier teleinformatyki wie, że oba podejścia są komplementarne i należy dobierać je ściśle do kontekstu zadania.

Kiedy bezwzględnie wybieramy CLI (Wiersz poleceń): - Zdalna administracja serwerami i urządzeniami sieciowymi: sesje SSH przez wolne łącza WAN lub łącza komórkowe LTE/5G; narzut grafiki uniemożliwiłby płynną pracę. - Środowiska zminimalizowane: kontenery Docker, klastry Kubernetes, systemy embedded i routery (OpenWrt, MikroTik, Cisco IOS), na których instalacja bibliotek graficznych jest niemożliwa ze względów bezpieczeństwa i ograniczeń pamięciowych. - Automatyzacja i przetwarzanie wsadowe: skrypty powłoki Bash / PowerShell, potoki systemowe (grep, awk, sed) oraz integracja z systemami CI/CD i zadaniami cron.

Kiedy bezwzględnie wybieramy GUI (Interfejs graficzny): - Głęboka analiza mikroskopowa pojedynczych transakcji: rozwijanie skomplikowanych drzew nagłówków protokołów (np. certyfikaty x509 w TLS, zapytania SAML/OAuth). - Wizualizacja statystyczna i wykresy: analiza wykresów przepływności (IO Graphs), wykresów sekwencji TCP (Stevenson / tcptrace graph) oraz map konwersacji (Conversations Table). - Edukacja i prezentacja wyników: przygotowywanie czytelnych raportów audytowych dla zarządu i klientów biznesowych.

11/55
Narzędzia pomiarowe dla sieci LAN
Cel slajdu: Przegląd wyspecjalizowanych narzędzi pomiarowych i mechanizmów diagnostycznych dedykowanych dla infrastruktury Ethernet i okablowania strukturalnego.

Aparatura pomiarowa w sieciach lokalnych LAN

  • ethtool: parametry karty sieciowej (prędkość, dupleks)
  • iperf3: przepustowość między hostami w LAN
  • ping: opóźnienie w sieci lokalnej
  • tcpdump: przechwytywanie ruchu na interfejsie
  • SNMP: monitorowanie przełączników i routerów
Diagnostyka sieci LAN: zestawienie narzędzi warstwy fizycznej (reflektometry TDR, mierniki certyfikacyjne) oraz protokołów diagnostycznych warstwy 2 (LLDP/CDP, MLD/IGMP snooping, port mirroring SPAN).
Narzędzia LAN

Środowisko sieci lokalnych LAN (oparte na standardach IEEE 802.3 Ethernet) charakteryzuje się wysoką przepustowością i niskimi opóźnieniami, co stawia specyficzne wymagania przed aparaturą diagnostyczną. Problemy w sieci LAN najczęściej lokalizują się w warstwie fizycznej L1 (okablowanie) lub warstwie łącza danych L2 (przełączanie ramek, VLAN, pętle STP).

Kluczowe narzędzia i techniki pomiarowe w sieci LAN: - Reflektometry TDR (Time Domain Reflectometry): wbudowane w procesory nowoczesnych przełączników zarządzalnych mechanizmy weryfikacji okablowania (polecenie w Cisco: test cable-diagnostics tdr interface ...), pozwalające bez używania miernika zewnętrznego wykryć przerwę w kablu lub zwarcie z dokładnością do 1 metra. - Certyfikatory okablowania miedzianego i światłowodowego: zaawansowane mierniki polowe (np. Fluke Networks DSX-8000), weryfikujące parametry fizyczne toru transmisyjnego (tłumienność Insertion Loss, przesłuch zbliżny NEXT/FEXT, straty odbiciowe Return Loss) zgodnie z normami ISO/IEC 11801 i TIA-568.

- Protokoły wykrywania sąsiadów L2: LLDP (IEEE 802.1AB) oraz CDP (Cisco Discovery Protocol); polecenie linuksowe lldpctl ujawnia, do którego portu którego przełącznika podłączony jest nasz kabel sieciowy, wraz z numerem VLAN i adresem zarządzającym switcha. - Mechanizmy lustrzane portów (SPAN / RSPAN / ERSPAN): sprzętowe kopiowanie całego ruchu z wybranego portu lub VLAN-u do dedykowanego portu monitorującego, do którego podłączona jest stacja z programem Wireshark.

12/55
Narzędzia pomiarowe dla sieci WLAN
Cel slajdu: Przedstawienie narzędzi do analizy widma radiowego, pomiaru parametrów sygnału Wi-Fi oraz wykonywania badań propagacyjnych Site Survey.

Aparatura pomiarowa w sieciach bezprzewodowych WLAN

  • iw, iwconfig: parametry karty WLAN
  • airodump-ng: skanowanie sieci Wi-Fi
  • Kismet: sniffer WLAN
  • Wi-Fi Analyzer: analiza kanałów (Android)
  • iperf3: przepustowość WLAN
Diagnostyka WLAN: zbiór narzędzi radiowych (analizatory widma RF, skanery Wi-Fi, oprogramowanie Site Survey, pakiety monitor mode) badających pasma 2.4/5/6 GHz pod kątem RSSI, SNR, zakłóceń i interferencji ko-kanałowych.
Narzędzia WLAN

Sieci bezprzewodowe Wi-Fi (standardy rodziny IEEE 802.11a/b/g/n/ac/ax/be) wykorzystują jako medium transmisyjne współdzielony i niekoncesjonowany eter radiowy, co czyni je wysoce podatnymi na tłumienie przez przeszkody budowlane oraz interferencje elektromagnetyczne. Diagnostyka WLAN wymaga od inżyniera posługiwania się aparaturą zdolną do badania warstwy radiowej (RF).

Kluczowe kategorie aparatury pomiarowej w sieciach bezprzewodowych: 1. Analizatory widma radiowego (RF Spectrum Analyzers): sprzętowe sondy radiowe (np. Oscium WiPry, Metageek Wi-Spy), które analizują surowe natężenie fal elektromagnetycznych w pasmach 2.4 GHz, 5 GHz oraz 6 GHz bez dekodowania ramek 802.11. Pozwalają wykryć źródła zakłóceń niepochodzące z sieci Wi-Fi, takie jak kuchenki mikrofalowe, kamery bezprzewodowe czy transmisyjne systemy radarowe (wymuszające procedury DFS).

2. Skanery Wi-Fi i monitory parametrów sygnału: narzędzia programowe (np. Wi-Fi Analyzer, inSSIDer, linuksowe polecenia iw dev wlan0 scan lub wavemon), prezentujące kluczowe metryki jakościowe: - RSSI (Received Signal Strength Indicator): poziom odbieranego sygnału wyrażany w dBm (wartość optymalna od -50 do -65 dBm; poniżej -75 dBm łącze ulega degradacji), - SNR (Signal-to-Noise Ratio): odstęp sygnału od szumu tła wyrażany w dB (wartość powyżej 25 dB gwarantuje wysoką przepustowość). 3. Oprogramowanie do planowania i audytu Site Survey: profesjonalne pakiety (np. Ekahau AI Pro, NetSpot), generujące mapy ciepła (Heatmaps) pokrycia sygnałem obiektu budowlanego.

13/55
Narzędzia do analizy ruchu sieci
Cel slajdu: Przedstawienie wielkoskalowych systemów analizy ruchu opartej na statystykach przepływów (NetFlow, IPFIX, sFlow) oraz systemów klasy NMS.

Zaawansowana analiza ruchu i telemetria sieciowa

  • Wireshark: GUI, dekodowanie setek protokołów
  • tshark: terminalowa wersja Wireshark
  • tcpdump: klasyk wiersza poleceń
  • ngrep: grep dla pakietów
  • Scapy: Python – generowanie i analiza
Telemetria przepływów sieciowych: technologia zbierania zagregowanych metadanych o sesjach sieciowych (RFC 7011 IPFIX) realizowana bezpośrednio przez routery i przełączniki szkieletowe, zasilająca systemy analityczne bez konieczności rejestrowania pełnych pakietów.
Narzędzia analizy protokołów

Przechwytywanie pełnych pakietów narzędziem Wireshark jest nieocenione przy lokalizowaniu usterki na pojedynczej stacji lub serwerze, lecz w skali sieci korporacyjnej o przepustowości dziesiątek gigabitów na sekundę pełny zrzut ruchu wygenerowałby setki terabajtów danych w ciągu godziny, całkowicie zapychając macierze dyskowe. W skali makro inżynierowie stosują telemetrię przepływów sieciowych (Flow Telemetry).

Architektura rozwiązań opiera się na standardach branżowych: - NetFlow v9 (Cisco) oraz IPFIX (RFC 7011, IETF): routery i przełączniki śledzą unikalne sesje zdefiniowane przez tzw. 5-tkę parametrów (5-tuple: źródłowy i docelowy adres IP, port źródłowy i docelowy, protokół transportowy). Zamiast pakietów urządzenie wysyła do centralnego kolektora zwięzłe rekordy statystyczne: czas trwania sesji, liczbę przesłanych bajtów i pakietów oraz flagi TCP. - sFlow (Sampled Flow): technika próbkowania statystycznego (np. co 1000. pakiet), odciążająca procesory przełączników szkieletowych.

Kolektory i analizatory przepływów (np. ntopng, Elastiflow, Scrutinizer) przekształcają te dane w dynamiczne pulpity nawigacyjne (Dashboards), prezentując administratorom w czasie rzeczywistym: kto generuje największy ruch (Top Talkers), które aplikacje wysycają łącze oraz wykrywając anomalie behawioralne świadczące o atakach wolumetrycznych DDoS lub aktywności złośliwego oprogramowania.

14/55
Generatory ruchu sieciowego
Cel slajdu: Przegląd specjalistycznego oprogramowania i platform sprzętowych do generowania syntetycznego ruchu sieciowego L2–L7.

Generatory ruchu i narzędzia testów obciążeniowych

  • iperf3: TCP/UDP, pomiar przepustowości
  • hping3: zaawansowane generowanie pakietów
  • packeth: generowanie ramek Ethernet
  • Ostinato: GUI + CLI, wiele strumieni
  • Scapy: Python – dowolne pakiety
  • RouterOS Traffic Generator: wbudowany w MikroTik
Generatory ruchu (Traffic Generators): wyspecjalizowane aplikacje (iperf3, Ostinato, Cisco TRex, hping3, Scapy) służące do symulacji obciążenia, weryfikacji wydajności zapór ogniowych i badania zachowania protokołów w warunkach granicznych.
Generatory ruchu

Przed wdrożeniem do produkcji nowej architektury sieciowej, klastra zapór ogniowych NGFW czy przełączników rdzeniowych, inżynier sieciowy ma obowiązek przeprowadzenia rygorystycznych testów obciążeniowych (Stress Testing / Benchmark). Wprowadzenie niesprawdzonego sprzętu do obsługi ruchu biznesowego grozi katastrofalnym paraliżem firmy. Do kontrolowanego nasycania łączy służą generatory ruchu.

Przegląd kluczowych generatorów syntetycznych: - iperf3: najpopularniejszy, prosty w użyciu miernik przepustowości L4 dla protokołów TCP, UDP i SCTP. - Ostinato: potężny pakiet programowy z interfejsem graficznym, nazywany „Wiresharkiem w odwrotną stronę”. Pozwala na manualne konstruowanie dowolnych, niestandardowych ramek sieciowych w każdej warstwie (L2–L7), modyfikację nagłówków i wysyłanie ich z precyzyjnie zadanym tempem pakietowym (PPS). - Cisco TRex: profesjonalny generator ruchu o otwartym kodzie źródłowym, wykorzystujący akcelerację sprzętową DPDK (Data Plane Development Kit). Działa na standardowych serwerach x86, potrafiąc generować ruch realistyczny (Stateful Traffic) o natężeniu rzędu 200–400 Gb/s, symulując miliony jednoczesnych użytkowników przeglądających strony WWW, oglądających wideo i pobierających pliki.

- Scapy: biblioteka języka Python pozwalająca na programistyczne tworzenie, manipulowanie, wysyłanie i przechwytywanie pakietów sieciowych, powszechnie stosowana w testach penetracyjnych i badaniach naukowych.

15/55
Tabela porównawcza narzędzi sieciowych
Cel slajdu: Syntetyczne zestawienie właściwości technicznych najważniejszych programów diagnostycznych w ujęciu wielokryterialnym.

Tabela porównawcza narzędzi diagnostycznych

NarzędziePlatformaGUI/CLIZastosowanie
WiresharkWindows/Linux/macOSGUIAnaliza protokołów
tcpdumpLinux/macOSCLISniffing w terminalu
tsharkWindows/Linux/macOSCLIAnaliza z konsoli
iperf3Windows/Linux/macOSCLIPomiar przepustowości
hping3LinuxCLIGenerowanie pakietów
airodump-ngLinuxCLISkanowanie WLAN
ethtoolLinuxCLIParametry karty sieciowej
Komparatywna matryca narzędziowa: przekrojowa tabela zestawiająca Wireshark, tcpdump, iperf3, Nmap, mtr oraz ntopng pod kątem warstwy OSI, typu pomiaru, interfejsu i obciążenia sieci.
Tabela porównawcza

Poniższa tabela stanowi kompendium inżynierskie, pozwalające na błyskawiczne zorientowanie się we właściwościach, warstwie operacyjnej oraz charakterystyce narzutu sieciowego wiodących narzędzi teleinformatycznych:

Zestawienie komparatywne narzędzi pomiarowych: 1. Wireshark: Warstwy L2–L7; Tryb pasywny (sniffing); Interfejs GUI; Wpływ na sieć: zerowy (pasywny nasłuch); Główne zastosowanie: szczegółowa inspekcja protokołów, analiza błędów sesji, forensic. 2. tcpdump: Warstwy L2–L7; Tryb pasywny; Interfejs CLI; Wpływ na sieć: zerowy; Główne zastosowanie: przechwytywanie ruchu na serwerach headless, routerach, generowanie plików PCAP. 3. iperf3: Warstwa L4 (TCP/UDP/SCTP); Tryb aktywny (traffic generation); Interfejs CLI; Wpływ na sieć: bardzo wysoki (pełne nasycenie pasma); Główne zastosowanie: pomiar maksymalnej przepustowości i jittera.

4. Nmap: Warstwy L3–L7; Tryb aktywny (probing); Interfejs CLI/GUI (Zenmap); Wpływ na sieć: niski/średni (zależny od timing template); Główne zastosowanie: inwentaryzacja sieci, skanowanie portów i podatności. 5. MTR: Warstwa L3 (ICMP/UDP); Tryb aktywny; Interfejs CLI/GUI; Wpływ na sieć: znikomy; Główne zastosowanie: ciągłe śledzenie trasy, lokalizacja strat pakietów w czasie rzeczywistym. 6. ntopng: Warstwy L2–L7; Pasywny/telemetryczny (Flows); Interfejs Web GUI; Wpływ na sieć: zerowy/znikomy; Główne zastosowanie: stały monitoring ruchu, Top Talkers, wykrywanie anomalii.

16/55
Kryteria wyboru narzędzia pomiarowego
Cel slajdu: Przedstawienie formalnego drzewa decyzyjnego dobierającego optymalną metodologię i aparaturę do specyfiki problemu sieciowego.

Kryteria inżynierskiego wyboru narzędzia pomiarowego

  • Cel pomiaru: przepustowość? Opóźnienie? Analiza protokołów?
  • Środowisko: LAN, WLAN, WAN?
  • Platforma: Windows, Linux, macOS?
  • Poziom zaawansowania: GUI dla początkujących, CLI dla automatyzacji
  • Zasoby: pamięć, CPU, miejsce na dysku
  • Budżet: darmowe (Wireshark, iperf) vs komercyjne (PRTG, Ekahau)
Inżynierskie kryteria wyboru: zbiór zasad selekcji aparatury pomiarowej w oparciu o: 1) cel badania, 2) dopuszczalny wpływ na ruch produkcyjny, 3) lokalizację punktu pomiarowego oraz 4) wymagany poziom szczegółowości danych.
Kryteria wyboru

Wybór narzędzia diagnostycznego w realnym środowisku produkcyjnym jest decyzją inżynierską, która musi uwzględniać nie tylko możliwości techniczne programu, lecz również ryzyko operacyjne. Uruchomienie agresywnego narzędzia aktywnego w godzinach szczytu biznesowego może doprowadzić do niedostępności usług i poważnych strat finansowych.

Kryteria decyzyjne w procesie wyboru: - Kryterium 1: Wpływ na sieć produkcyjną (Inwazyjność): - Jeśli sieć obsługuje krytyczne transakcje biznesowe, bezwzględnie stosuj metody pasywne (port mirroring SPAN, odczyt statystyk SNMP lub telemetrię NetFlow/IPFIX). - Testy aktywne generatorami nasycającymi łącze (np. iperf3) przeprowadzaj wyłącznie w uzgodnionym oknie serwisowym (Maintenance Window).

- Kryterium 2: Skala i horyzont czasowy problemu: - Do natychmiastowej lokalizacji pojedynczej usterki na stacji roboczej: narzędzia ad-hoc (ping, traceroute, Wireshark). - Do monitorowania trendów długoterminowych i planowania rozbudowy pojemności sieci (Capacity Planning): systemy telemetryczne NMS i kolektory przepływów. - Kryterium 3: Poziom warstwowy usterki: - Uszkodzenie kabla lub błędy fizyczne: reflektometr TDR, miernik Fluke, liczniki ethtool. - Błędy w logice aplikacji lub negocjacji szyfrowania: zrzut pakietowy i Wireshark.

17/55
Diagnostyka wolnego łącza internetowego
Cel slajdu: Drobiazgowa analiza wieloetapowej procedury diagnostyki degradacji przepustowości w sieci przedsiębiorstwa.

Studium przypadku: użytkownicy zgłaszają wolne działanie sieci

Krok 1: ping do bramy – LAN OK (0,5 ms)

Krok 2: ping do 8.8.8.8 – 500 ms, 30% utraty – problem na WAN

Krok 3: traceroute – problem na 3. hopie (dostawca ISP)

Krok 4: iperf3 do serwera w innym biurze – 2 Mb/s zamiast 100 Mb/s

Wniosek: zgłoszenie do ISP, SLA weryfikacja.

Metodyka rozwiązywania problemu powolnego łącza: sekwencyjna weryfikacja liczników błędów L2, pomiar przepustowości narzędziem iperf3, analiza wykresów Wireshark IO Graphs oraz weryfikacja zjawiska MTU Black Hole.
Schemat sieci firmowej

Rozważmy klasyczny scenariusz inżynierski: użytkownicy w oddziale firmy zgłaszają, że transfer plików z centralnego serwera trwa wielokrotnie dłużej niż zwykle, a praca w systemie ERP jest uciążliwa z powodu opóźnień. Doświadczony inżynier sieciowy wdraża ustrukturyzowaną procedurę diagnostyczną:

Kroki realizacji procedury inżynierskiej: 1. Weryfikacja liczników błędów na interfejsach L2: w konsoli przełącznika lub poleceniem ip -s link sprawdzamy liczniki errors i crc. Jeśli błędy nie przyrastają, wykluczamy usterkę okablowania miedzianego. 2. Pomiar przepustowości L4 narzędziem iperf3: uruchamiamy test iperf3 -c <serwer>. Jeśli wynik wykazuje zaledwie 12 Mb/s na łączu 1 Gb/s oraz dużą liczbę retransmisji (Retr > 500), potwierdzamy problem z utratą pakietów.

3. Głęboka analiza w programie Wireshark: przechwytujemy ruch podczas transferu. Otwieramy wykres Statistics -> I/O Graphs oraz filtrujemy tcp.analysis.flags. Wykrywamy potrójne duplikaty ACK oraz gwałtowne spadki okna nadawczego (Congestion Window Collapse). 4. Weryfikacja MTU i tuneli (PMTUD Black Hole): wykonujemy test ping -f -l 1472 <serwer>. Okazuje się, że pakiety powyżej 1420 bajtów giną bezpowrotnie w tunelu IPsec łączącym oddział z centralą z powodu zablokowania komunikatów ICMP Fragmentation Needed na zaporze. 5. Rozwiązanie: konfiguracja mechanizmu TCP MSS Clamping (np. ip tcp adjust-mss 1360) na routerze brzegowym natychmiast przywraca pełną prędkość transferu.

18/55
Diagnostyka wolnej sieci Wi-Fi
Cel slajdu: Przedstawienie metodyki diagnostyki degradacji sieci bezprzewodowej spowodowanej interferencjami ko-kanałowymi i przeciążeniem pasma.

Studium przypadku: sieć Wi-Fi działa wolno w godzinach popołudniowych

Krok 1: iperf3 przy AP – 400 Mb/s (dobrze)

Krok 2: iperf3 w odległym pokoju – 30 Mb/s (źle)

Krok 3: Wi-Fi Analyzer – wszystkie sieci na kanale 6, jedna sieć na 1, zero na 11

Krok 4: zmiana AP na kanał 11 – 120 Mb/s w odległym pokoju

Wniosek: interferencja współkanałowa (CCI).

Diagnostyka anomalii WLAN: procedura badania fluktuacji wydajności Wi-Fi w czasie obejmująca analizę nakładania kanałów (CCI/ACI), pomiar czasu zajętości medium (Channel Utilization) oraz detekcję obcych źródeł sygnału.
Plan biura z heatmapą

Drugi realistyczny scenariusz dotyczy biura typu Open Space: rano sieć bezprzewodowa Wi-Fi funkcjonuje bez zarzutu, lecz w godzinach popołudniowych pracownicy doświadczają drastycznego spadku prędkości, zrywania wideokonferencji i wysokich czasów RTT. Prosty restart punktu dostępowego (AP) nie rozwiązuje problemu.

Inżynierska analiza przyczyn źródłowych krok po kroku: 1. Pomiar czasu zajętości pasma (Channel Utilization / Airtime): w kontrolerze WLAN sprawdzamy parametr utylizacji medium. Rano wynosił 20%, po południu wzrasta do 88%. Ponieważ medium radiowe jest środowiskiem półdupleksowym (Half-Duplex CSMA/CA), wysoka utylizacja oznacza, że stacje bezustannie czekają na wolne medium (zjawisko Contention).

2. Analiza widma i interferencji ko-kanałowych (CCI - Co-Channel Interference): uruchamiamy skaner Wi-Fi oraz analizator widma. Wykrywamy dwa kluczowe czynniki: - Po południu w biurowcu włączają się punkty dostępowe sąsiednich firm na tych samych kanałach w paśmie 2.4 GHz (kanały 1, 6, 11 wzajemnie się zakłócają). - Wiele stacji roboczych pracowników posiada słabe karty sieciowe łączące się w przestarzałym paśmie 2.4 GHz z niskimi prędkościami kodowania (Legacy Data Rates), co drenuje dostępny czas antenowy (Airtime Hogs). 3. Wdrożenie optymalizacji inżynierskiej: - Włączenie mechanizmu Band Steering, wymuszającego przełączanie stacji dwuzakresowych do pasma 5 GHz / 6 GHz, - Wyłączenie najniższych prędkości podstawowych (poniżej 12 Mb/s) w kontrolerze, co zmusza stacje do szybszego zwalniania medium, - Wdrożenie dynamicznego zarządzania mocą (TPC) i kanałami (RRM / ARM).

19/55
Diagnostyka niedziałającej aplikacji WWW
Cel slajdu: Drobiazgowa dekompozycja procedury diagnostyki niedostępności usługi webowej w ujęciu wielowarstwowym (L3 vs L4 vs L7).

Studium przypadku: aplikacja WWW nie działa

Krok 1: Wireshark – przechwyć ruch HTTP

Krok 2: filtr http – widzimy GET, odpowiedź 500 Internal Server Error

Krok 3: Follow TCP Stream – w treści odpowiedzi błąd bazy danych

Wniosek: problem po stronie serwera WWW/backend, nie sieci.

Metodyka diagnostyki aplikacji webowej: ustrukturyzowana procedura eliminacji obejmująca weryfikację DNS, test trasy IP, badanie trójstopniowego uzgadniania TCP SYN (L4), negocjacji TLS oraz kodów błędów HTTP (L7).
Wireshark z odpowiedzią 500

Trzeci scenariusz to krytyczny incydent biznesowy: użytkownicy zgłaszają, że firmowy portal intranetowy lub sklep internetowy przestał odpowiadać. Zgłoszenie „aplikacja nie działa” może oznaczać usterkę w dowolnej z warstw stosu TCP/IP. Inżynier przeprowadza rygorystyczną, warstwową procedurę eliminacji:

Dekompozycja diagnostyczna krok po kroku: 1. Weryfikacja warstwy DNS (L7): wykonujemy dig app.firma.local +short. Czy otrzymujemy poprawny adres IP serwera? Jeśli brak rekordu A lub serwer zwraca SERVFAIL, naprawiamy strefę DNS. 2. Weryfikacja warstwy sieciowej (L3): wykonujemy ping -c 2 <IP_serwera>. Jeśli routery odpowiadają, łączność sieciowa i routing funkcjonują bezbłędnie.

3. Weryfikacja warstwy transportowej (L4 - TCP Handshake): badamy port TCP 443 poleceniem curl -Iv https://app.firma.local lub Test-NetConnection -Port 443: - Objaw A: Connection refused (flaga TCP RST): pakiet dotarł do serwera, lecz demon serwera WWW (Nginx/Apache) jest wyłączony lub uległ awarii. - Objaw B: Connection timed out: pakiety TCP SYN są po cichu porzucane przez zaporę sieciową (firewall) lub brak trasy powrotnej. 4. Weryfikacja warstwy aplikacji (L7 - HTTP/TLS): - Jeśli TCP Handshake i TLS Client Hello kończą się sukcesem, lecz serwer zwraca kod HTTP 502 Bad Gateway lub HTTP 504 Gateway Timeout, problem tkwi w komunikacji pomiędzy serwerem proxy a aplikacją backendową (np. kontenerem Node.js / bazy danych).

Zastosowanie tej ścisłej sekwencji pozwala inżynierowi w mniej niż 3 minuty wskazać, czy awaria leży po stronie sieci, zapory, certyfikatu TLS czy kodu programistycznego aplikacji.

20/55
Powtórka metryk pomiarów sieciowych
Cel slajdu: Przekrojowe przypomnienie fundamentalnych metryk pomiarowych, jednostek wielkości oraz pojęć zdefiniowanych w module pierwszym kursu.

Repetytorium – Część 1: Wprowadzenie do pomiarów sieciowych

Pytanie: Wymień 5 metryk pomiarowych.

Odpowiedź: Przepustowość (bandwidth), opóźnienie (latency), jitter (jitter), utrata pakietów (packet loss), przepływność (throughput).

Synteza modułu 1: powtórzenie kluczowych metryk teleinformatycznych: przepustowość (Throughput/Goodput vs Bandwidth), opóźnienie (Latency RTT), fluktuacja opóźnień (Jitter), stopa błędów (BER) oraz stopa utraty pakietów (Packet Loss).
5 ikon metryk

Rozpoczynając wielkie repetytorium kursu PiDSK, powracamy do fundamentów zdefiniowanych w części pierwszej: precyzyjnego aparatu pojęciowego i metryk, bez których niemożliwa jest jakakolwiek inżynierska ocena stanu sieci teleinformatycznej.

Przypomnijmy najważniejsze aksjomaty modułu pierwszego: - Pasmo (Bandwidth) vs Przepustowość (Throughput) vs Goodput: Pasmo to maksymalna teoretyczna pojemność kanału transmisyjnego (np. 1 Gb/s w 1000BASE-T). Przepustowość to rzeczywista liczba bitów przesyłanych w jednostce czasu. Goodput to czysta prędkość przesyłania danych użytkownika (ładunku aplikacyjnego) po odliczeniu wszystkich narzutów nagłówków warstw L2–L4 oraz retransmisji. - Opóźnienie (Latency) i RTT (Round-Trip Time): Czas podróży pakietu w obie strony, składający się z opóźnienia propagacji w medium, opóźnienia serializacji (transmisji bitów na interfejsie), opóźnienia kolejkowania w buforach routerów oraz opóźnienia przetwarzania w węzłach.

- Fluktuacja opóźnień (Jitter): Zmienność opóźnienia pomiędzy kolejnymi pakietami w strumieniu danych; krytyczny parametr dla transmisji głosu VoIP i wideo w czasie rzeczywistym. - Stopa utraty pakietów (Packet Loss Rate): Procent pakietów wysłanych, które nie dotarły do celu z powodu błędów bitowych lub przepełnienia buforów kolejkowych. - Stopa błędów bitowych (BER - Bit Error Rate): Stosunek liczby błędnie odebranych bitów do całkowitej liczby przesłanych bitów, wyznaczający fizyczną jakość toru transmisyjnego.

21/55
Powtórka interfejsów LAN i ethtool
Cel slajdu: Syntetyczne przypomnienie standardów mediów transmisyjnych Ethernet, kategorii okablowania miedzianego, światłowodów i technologii Power over Ethernet.

Repetytorium – Część 2: Okablowanie strukturalne i interfejsy LAN

Pytanie: Do czego służy ethtool?

Odpowiedź: Wyświetla i zmienia parametry karty sieciowej (prędkość, duplex, auto-negocjacja, statystyki).

Synteza modułu 2: okablowanie strukturalne miedziane (skrętka kat. 5e/6/6A wg ANSI/TIA-568 do 100 m), światłowody jednomodowe SMF i wielomodowe MMF, standardy Ethernetu IEEE 802.3 oraz zasilanie PoE (802.3af/at/bt).
Zrzut ekranu z ethtool

W module drugim przeanalizowaliśmy fundamenty warstwy fizycznej sieci przewodowych LAN. Bez sprawnego, certyfikowanego medium transmisyjnego żaden protokół wyższych warstw nie jest w stanie funkcjonować poprawnie. Standardy okablowania strukturalnego definiują normy ANSI/TIA-568 oraz międzynarodowa norma ISO/IEC 11801.

Kluczowe zagadnienia modułu drugiego: - Miedziana skrętka czteroparowa (Twisted Pair): kategorie od kat. 5e (1 Gb/s do 100 MHz), przez kat. 6 (1 Gb/s i 10 Gb/s do 55 m przy 250 MHz), aż po ekranowaną kat. 6A (pełne 10 Gb/s na 100 m przy 500 MHz). Maksymalny zasięg łącza stałego w standardzie wynosi dokładnie 90 m (Permanent Link) plus 10 m kabli krosowych, dając limit 100 m (Channel). - Światłowody (Optical Fiber): wielomodowe MMF (grubszy rdzeń 50 µm, lasery VCSEL 850 nm, standardy OM3/OM4 do kilkuset metrów w Data Center) oraz jednomodowe SMF (rdzeń 9 µm, lasery 1310/1550 nm, standard OS2 do dziesiątek kilometrów w sieciach kampusowych i MAN).

- Technologia Power over Ethernet (PoE): standardy IEEE: PoE (802.3af, 15.4 W), PoE+ (802.3at, 30 W) oraz najnowszy 4-parowy 4PPoE / PoE++ (IEEE 802.3bt, dostarczający do 60 W Typ 3 lub 90 W Typ 4) zasilający kamery PTZ, punkty dostępowe Wi-Fi 6/7 oraz terminale IoT. - Diagnostyka narzędziem ethtool: weryfikacja parametrów wynegocjowanych przez układ PHY karty sieciowej (Speed, Duplex, Auto-negotiation).

22/55
Powtórka kanałów Wi-Fi 2,4 GHz
Cel slajdu: Syntetyczne przypomnienie architektury sieci radiowych IEEE 802.11, pasm częstotliwości, metod dostępu CSMA/CA oraz ewolucji standardów Wi-Fi.

Repetytorium – Część 3: Sieci bezprzewodowe WLAN i Wi-Fi

Pytanie: Jakie są trzy nie nakładające się kanały w paśmie 2,4 GHz?

Odpowiedź: Kanały 1, 6, 11 (w Europie dla szerokości 20 MHz).

Synteza modułu 3: sieci bezprzewodowe IEEE 802.11 (Wi-Fi 4/5/6/6E/7), pasma 2.4 GHz, 5 GHz i 6 GHz, protokół dostępu CSMA/CA, modulacje OFDMA, technologia MU-MIMO oraz bezpieczeństwo WPA2/WPA3.
Widmo 2,4 GHz z kanałami 1, 6, 11

W module trzecim szczegółowo zbadaliśmy specyfikę komunikacji radiowej w sieciach bezprzewodowych WLAN. W przeciwieństwie do dedykowanego kabla miedzianego, medium radiowe jest środowiskiem współdzielonym i półdupleksowym (Half-Duplex), co wymusza stosowanie zaawansowanych mechanizmów koordynacji transmisji.

Kluczowe pojęcia i reguły inżynierskie WLAN: - Pasma częstotliwości i kanały: - Pasmo 2.4 GHz: daleki zasięg, lecz zaledwie 3 nienakładające się kanały o szerokości 20 MHz w Europie (kanały 1, 6, 11). Silne przeciążenie i zakłócenia zewnętrzne. - Pasmo 5 GHz: wysoka przepustowość, szerokie kanały (40/80/160 MHz), podział na podpasma UNII-1 do UNII-3 oraz kanały DFS (Dynamic Frequency Selection) współdzielone z radarami meteorologicznymi. - Pasmo 6 GHz (Wi-Fi 6E / Wi-Fi 7): aż 1200 MHz czystego, niezakłóconego widma, kanały do 320 MHz w standardzie IEEE 802.11be.

- Dostęp do medium CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance; stacje nie potrafią wykrywać kolizji w trakcie nadawania (jak w CSMA/CD), dlatego stosują losowe odczekanie (Random Backoff) oraz opcjonalne ramki rezerwacji RTS/CTS eliminujące problem ukrytego węzła (Hidden Node). - Ewolucja technologiczna: od prostego SISO w 802.11b, przez wieloantenowe MIMO w 802.11n (Wi-Fi 4), po ortogonalny podział częstotliwości OFDMA w 802.11ax (Wi-Fi 6) oraz wielołączowość MLO (Multi-Link Operation) w Wi-Fi 7. - Bezpieczeństwo: migracja z WPA2-PSK do WPA3-SAE (Simultaneous Authentication of Equals) eliminującego ataki słownikowe offline.

23/55
Powtórka siedmiu warstw modelu OSI
Cel slajdu: Przekrojowe powtórzenie koncepcji warstwowej ISO/OSI, funkcji poszczególnych warstw L1–L7 oraz jednostek danych protokołu (PDU).

Repetytorium – Część 4: Siedmiowarstwowy model ISO/OSI

Pytanie: Wymień 7 warstw modelu OSI.

Odpowiedź: Fizyczna, Łącza danych, Sieciowa, Transportowa, Sesji, Prezentacji, Aplikacji.

Mnemotechnika: Fajnie Łowić Sielawę, Trzeba Się Postarać Aby
Synteza modułu 4: 7-warstwowy referencyjny model Open Systems Interconnection (ISO/IEC 7498-1): Fizyczna (bity), Łącza danych (ramki), Sieciowa (pakiety), Transportowa (segmenty/datagramy), Sesji, Prezentacji, Aplikacji (dane).
Wieża 7 warstw OSI

W module czwartym poznaliśmy fundamentalny język pojęciowy inżynierii teleinformatycznej: 7-warstwowy model odniesienia ISO/OSI (Open Systems Interconnection), skodyfikowany w międzynarodowej normie ISO/IEC 7498-1. Model ten zapewnia modułowość, standaryzację interfejsów i interoperacyjność pomiędzy rozwiązaniami różnych producentów sprzętu.

Dekompozycja siedmiu warstw i jednostek danych protokołu (PDU): 1. Warstwa 1 (Fizyczna) - PDU: Bit: kodowanie sygnałów elektrycznych, optycznych i radiowych, złącza, napięcia i taktowanie zegara. 2. Warstwa 2 (Łącza danych) - PDU: Ramka (Frame): fizyczne adresowanie MAC, kontrola dostępu do medium (MAC), framing oraz detekcja błędów sumą kontrolną CRC/FCS (Ethernet, Wi-Fi, przełączniki L2). 3. Warstwa 3 (Sieciowa) - PDU: Pakiet (Packet): logiczne adresowanie hierarchiczne (IPv4/IPv6), wyznaczanie tras (routing) i przekazywanie pakietów pomiędzy różnymi sieciami (routery L3).

4. Warstwa 4 (Transportowa) - PDU: Segment (TCP) / Datagram (UDP): komunikacja proces-proces (End-to-End), multipleksacja portów, kontrola przepływu i retransmisje. 5. Warstwa 5 (Sesji): nawiązywanie, synchronizacja punktami kontrolnymi i zamykanie sesji dialogowych. 6. Warstwa 6 (Prezentacji): formatowanie, konwersja kodowania (ASCII, UTF-8), kompresja oraz szyfrowanie i deszyfrowanie danych (TLS). 7. Warstwa 7 (Aplikacji): bezpośredni interfejs dla procesów użytkownika (HTTP, DNS, DHCP, SSH, SMTP). - Mechanizm enkapsulacji i dekapsulacji: dodawanie nagłówków kolejnych warstw podczas schodzenia w dół stosu oraz ich zdejmowanie w drodze powrotnej.

24/55
Powtórka różnic TCP i UDP
Cel slajdu: Przekrojowe przypomnienie 4-warstwowej architektury protokołów internetowych TCP/IP (RFC 1122), zasady Best-Effort oraz kontrastu pomiędzy protokołami TCP i UDP.

Repetytorium – Część 5: Model TCP/IP i routing Best-Effort

Pytanie: Czym różni się TCP od UDP?

Odpowiedź: TCP – połączeniowy, niezawodny, z potwierdzeniami. UDP – bezpołączeniowy, szybki, bez gwarancji dostarczenia.

Synteza modułu 5: architektura TCP/IP (Warstwy: Dostęp do sieci, Internetowa, Transportowa, Aplikacji), routing Best-Effort (brak gwarancji w L3) oraz podział ról: niezawodny, połączeniowy TCP (3-Way Handshake) vs szybki, bezpołączeniowy UDP.
TCP vs UDP

Moduł piąty poświęcony był praktycznej architekturze, na której zbudowany jest globalny Internet: modelowi TCP/IP, zdefiniowanemu w standardach IETF, w szczególności w dokumencie RFC 1122 („Requirements for Internet Hosts”). W przeciwieństwie do teoretycznego 7-warstwowego modelu OSI, model TCP/IP konsoliduje funkcje w czterech warstwach operacyjnych.

Główne filary architektury TCP/IP: - Struktura 4 warstw: 1) Warstwa dostępu do sieci (Network Access / Link - łączy L1 i L2 OSI), 2) Warstwa internetowa (Internet - IPv4, IPv6, ICMP, odpowiada L3 OSI), 3) Warstwa transportowa (Transport - TCP, UDP, odpowiada L4 OSI), 4) Warstwa aplikacji (Application - konsoliduje L5, L6 i L7 OSI). - Filozofia Best-Effort w warstwie IP: protokół IP dostarcza pakiety z „najwyższą starannością”, lecz nie gwarantuje, że pakiet dotrze do celu, nie zostanie zduplikowany ani że dotrze we właściwej kolejności. Celowo uproszczono warstwę sieciową, aby umożliwić budowę potężnych, skalowalnych routerów rdzeniowych.

- Dychotomia warstwy transportowej: - TCP (RFC 793): połączeniowy, niezawodny, gwarantujący dostarczenie danych w nienaruszonej kolejności za pomocą numerów sekwencyjnych SEQ/ACK, mechanizmu retransmisji, kontroli przepływu (Sliding Window) oraz procedury nawiązywania połączenia 3-Way Handshake (SYN -> SYN-ACK -> ACK). - UDP (RFC 768): bezpołączeniowy, bezstanowy, o minimalnym narzucie zaledwie 8 bajtów nagłówka; idealny dla zapytań transakcyjnych DNS oraz strumieniowania multimediów i gier sieciowych.

25/55
Powtórka protokołów i portów sieciowych
Cel slajdu: Syntetyczna powtórka numeracji portów warstwy L4 (IANA) oraz mechanizmów działania kluczowych usług aplikacyjnych (DNS, DHCP, HTTP/HTTPS, SSH, SMTP/IMAP).

Repetytorium – Część 6: Protokoły aplikacji i porty transportowe

Pytanie: Port 443 – który protokół?

Odpowiedź: HTTPS (HTTP + TLS/SSL).

Synteza modułu 6: multipleksacja portów transportowych L4 (Well-Known 0–1023, Registered 1024–49151, Dynamic 49152–65535) oraz usługi aplikacyjne L7: DNS (port 53), DHCP (porty 67/68), HTTP/HTTPS (porty 80/443), SSH (port 22), SMTP/IMAP.
Ikona HTTPS z portem 443

W module szóstym zbadaliśmy, jak warstwa transportowa L4 realizuje multipleksację wielu niezależnych aplikacji działających na jednym systemie operacyjnym za pomocą 16-bitowych numerów portów (od 0 do 65 535), skodyfikowanych przez organizację IANA. Para: adres IP i numer portu tworzy unikalny w skali sieci punkt końcowy komunikacji, czyli gniazdo sieciowe (Socket).

Kluczowe usługi aplikacyjne i ich właściwości: - DNS (Domain Name System, RFC 1034/1035): port UDP/TCP 53; hierarchiczna, rozproszona baza danych tłumacząca nazwy symboliczne FQDN na adresy IP (rekordy A, AAAA, MX, CNAME, PTR, NS, SOA). - DHCP (Dynamic Host Configuration Protocol, RFC 2131): porty UDP 67 (serwer) i 68 (klient); dynamiczne przydzielanie konfiguracji IP stacjom końcowym w 4-fazowym cyklu DORA (Discover, Offer, Request, Acknowledge).

- HTTP i HTTPS: port TCP 80 (HTTP/1.1 tekstowy nieszyfrowany) oraz port TCP 443 (HTTPS z szyfrowaniem TLS 1.3 wg RFC 8446); protokół HTTP/2 (multipleksacja strumieni binarnych) oraz HTTP/3 (bazujący na protokole QUIC i UDP wg RFC 9000). - Zarządzanie i poczta: SSH (Secure Shell, port TCP 22 – bezpieczny dostęp konsolowy zastępujący Telnet port 23), SMTP (port TCP 25/587 – przesyłanie poczty), IMAP (port TCP 143/993 – synchronizacja skrzynek pocztowych).

26/55
Powtórka protokołu ARP w sieci LAN
Cel slajdu: Przekrojowe przypomnienie struktury ramki Ethernet II, adresacji fizycznej MAC, protokołu ARP, diagnostyki ICMP oraz eliminacji pętli L2 przez protokoły drzewa rozpinającego STP/RSTP.

Repetytorium – Część 7: Protokoły warstwy sieci i łącza danych

Pytanie: Do czego służy ARP?

Odpowiedź: Address Resolution Protocol – mapuje adres IP na adres MAC w sieci LAN.

Synteza modułu 7: ramka Ethernet II (preambuła, adresy MAC z OUI, EtherType, payload, FCS), protokół rozwiązywania adresów ARP (RFC 826) i ochrona DAI, protokół kontrolny ICMP (RFC 792) oraz protokoły STP (IEEE 802.1D) i RSTP (IEEE 802.1w).
ARP Request/Reply

W module siódmym zbadaliśmy mechanizmy sterujące przepływem danych w lokalnych domenach kolizyjnych i rozgłoszeniowych oraz powiązania pomiędzy adresacją fizyczną L2 a logiczną L3. Biegłość w interpretacji tych mechanizmów jest fundamentem rozwiązywania problemów w sieciach komutowanych.

Kluczowe zagadnienia modułu siódmego: - Format ramki Ethernet II: 48-bitowy fizyczny adres MAC (składający się z 24-bitowego identyfikatora producenta OUI oraz 24-bitowego numeru karty), pole EtherType wskazujące protokół wyższej warstwy (0x0800 dla IPv4, 0x86DD dla IPv6, 0x0806 dla ARP) oraz 4-bajtowa suma kontrolna FCS (CRC-32). - Protokół ARP (RFC 826): dynamiczne mapowanie adresów IPv4 na adresy MAC za pomocą rozgłoszeń ARP Request (broadcast) i odpowiedzi ARP Reply (unicast); tablica ARP w systemach operacyjnych; ochrona przed podsłuchem poprzez funkcję Dynamic ARP Inspection (DAI) na przełącznikach.

- Protokół ICMP (RFC 792): raportowanie błędów sieciowych (Destination Unreachable typ 3, Time Exceeded typ 11, Redirect typ 5) oraz testy echa (Echo Request typ 8 / Echo Reply typ 0). - Protokoły drzewa rozpinającego STP i RSTP: standardy IEEE 802.1D (klasyczny STP z czasami konwergencji 30–50 s) oraz IEEE 802.1w (Rapid STP konwergujący w czasie poniżej 1 s); blokowanie nadmiarowych portów w celu eliminacji pętli przełączania L2 i burz rozgłoszeniowych (Broadcast Storms).

27/55
Powtórka adresacji prywatnej IPv4
Cel slajdu: Przekrojowe przypomnienie matematycznych zasad adresacji IPv4, kalkulacji masek podsieci za pomocą operacji bitowej AND, bezklasowego routingu CIDR, techniki VLSM oraz translacji NAT/PAT.

Repetytorium – Część 8: Adresacja IPv4, podsieci i translacja NAT

Pytanie: Podaj trzy zakresy adresów prywatnych (RFC 1918).

Odpowiedź: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

Synteza modułu 8: 32-bitowy adres IPv4 (RFC 791), notacja kropkowo-dziesiętna, maska podsieci i operacja logiczna AND, CIDR (RFC 1519), zmienna długość maski VLSM (RFC 1878), wzory na liczbę hostów (2h - 2), pule prywatne RFC 1918 oraz translacja NAT/PAT (RFC 3022).
Trzy bloki adresów prywatnych

Moduł ósmy stanowił matematyczny fundament inżynierii sieciowej: opanowanie 32-bitowej adresacji protokołu IPv4, zdefiniowanej w standardzie RFC 791. Chociaż przestrzeń ta uległa wyczerpaniu, IPv4 wciąż obsługuje ogromną część globalnego ruchu internetowego.

Kluczowe aksjomaty obliczeniowe i inżynierskie modułu ósmego: - Maska podsieci i operacja AND: adres IP składa się z 32 bitów podzielonych na 4 oktety. Router wyznacza adres sieci docelowej poprzez wykonanie koniunkcji bitowej (logicznej operacji AND) pomiędzy adresem IP a maską podsieci. - Wzory inżynierskie: - Całkowita liczba adresów w podsieci: 2h (gdzie h to liczba bitów części hosta, h = 32 - prefiks CIDR). - Liczba użytecznych adresów dla stacji roboczych: 2h - 2 (odejmujemy adres sieci – same zera w części hosta, oraz adres rozgłoszeniowy broadcast – same jedynki w części hosta). Wyjątek stanowi prefiks /31 wg RFC 3021 stosowany na łączach punkt-punkt między routerami, udostępniający dokładnie 2 adresy bez adresu broadcastu.

- Hierarchia podziału CIDR i VLSM: odejście od sztywnych klas A, B, C na rzecz bezklasowego routingu CIDR (RFC 1519) oraz podziału podsieci o zmiennej długości maski VLSM (RFC 1878), pozwalającego na precyzyjne dopasowanie wielkości puli do potrzeb segmentu bez marnowania adresów. - Przestrzenie prywatne i NAT: pule RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) oraz translacja NAPT / PAT (RFC 3022), mapująca tysiące prywatnych połączeń na pojedynczy publiczny adres IP za pomocą unikalnych portów warstwy L4.

28/55
Powtórka budowy adresu IPv6
Cel slajdu: Syntetyczne przypomnienie architektury 128-bitowej adresacji IPv6, reguł kanonicznego zapisu RFC 5952, autokonfiguracji SLAAC, protokołu NDP oraz eliminacji broadcastu.

Repetytorium – Część 9: Protokół IPv6 i nowoczesna adresacja

Pytanie: Ile bitów ma adres IPv6?

Odpowiedź: 128 bitów (8 grup po 16 bitów).

Synteza modułu 9: 128-bitowy adres IPv6 (RFC 8200), notacja heksadecymalna (8 hekstetów), reguły kompresji RFC 5952 (usuwanie zer wiodących, podwójny dwukropek :: dokładnie raz), stała granica LAN /64 (RFC 7421), typologia GUA/ULA/LLA, mechanizmy SLAAC (RFC 4862) i NDP (RFC 4861).
128 bitów w 8 grupach

Moduł dziewiąty wprowadził nas w architekturę pełnoprawnego standardu internetowego nowej generacji: protokołu IPv6 (RFC 8200, Internet Standard STD 86). Zapewnia on astronomiczną przestrzeń 2128 unikalnych adresów (ok. 3,4 × 1038), eliminując bariery skalowalności Internetu i przywracając bezpośrednią łączność end-to-end bez translacji NAT.

Kluczowe reguły inżynierskie IPv6: - Zapis i kompresja (RFC 5952): 8 grup po 16 bitów w zapisie szesnastkowym rozdzielonych dwukropkami. Bezwzględne pomijanie zer wiodących w hekstecie oraz jednokrotne użycie podwójnego dwukropka :: dla zastąpienia najdłuższego ciągu zer. - Nienaruszalna granica prefiksu LAN /64: podział adresu na dokładnie 64 bity prefiksu sieciowego i 64 bity identyfikatora interfejsu (Interface ID), stanowiący twardy wymóg specyfikacji autokonfiguracji SLAAC (RFC 7421).

- Typologia adresów Unicast (RFC 4291): Global Unicast (GUA, 2000::/3 – trasowane w Internecie), Unique Local (ULA, fc00::/7 / fd00::/8 – prywatne korporacyjne wg RFC 4193), Link-Local (LLA, fe80::/10 – obowiązkowe, lokalne dla pojedynczego łącza L2) oraz Loopback (::1/128). - Protokół NDP (RFC 4861) i SLAAC (RFC 4862): całkowite wyeliminowanie broadcastu; mapowanie adresów za pomocą zapytań Neighbor Solicitation (NS) na adresy Solicited-Node Multicast; bezstanowa samokonfiguracja hosta w oparciu o ramki Router Advertisement (RA) bez udziału serwera DHCP.

29/55
Powtórka narzędzi CLI sieciowych
Cel slajdu: Przekrojowe przypomnienie kanonu poleceń konsolowych dla systemów Linux i Windows oraz formalnej metodyki rozwiązywania problemów sieciowych.

Repetytorium – Część 10: Narzędzia konsolowe CLI i metodyka diagnostyki

Pytanie: Jakie narzędzie pokazuje trasę pakietów?

Odpowiedź: traceroute (Linux/macOS) lub tracert (Windows). Wysyła pakiety z rosnącym TTL.

Synteza modułu 10: narzędzia konsolowe CLI: ping (ICMP), ipconfig/iproute2 (konfiguracja L3), ss/netstat (gniazda L4), traceroute/pathping/mtr (śledzenie ścieżki i pomiar strat), nslookup/dig (DNS) oraz metodyki warstwowe (Bottom-Up, Top-Down, Divide-and-Conquer).
Zrzut ekranu z traceroute

W module dziesiątym usystematyzowaliśmy warsztat praktyczny każdego inżyniera sieciowego: biegłość w posługiwaniu się narzędziami wiersza poleceń (CLI) oraz ustrukturyzowane procedury usuwania awarii (Troubleshooting Methodologies).

Zestawienie najważniejszych narzędzi i ich ról: - Weryfikacja osiągalności L3: polecenie ping operujące na komunikatach ICMP Echo (RFC 792), raportujące czas RTT i wartość licznika TTL, pozwalającego ocenić liczbę przeskoków powrotnych i zidentyfikować system operacyjny celu. - Konfiguracja logiczna interfejsu: ipconfig /all, /release, /renew, /flushdns w Windows oraz nowoczesny pakiet iproute2 (polecenia ip link, ip addr, ip route, ip neigh) w Linux, który całkowicie wyparł przestarzały pakiet net-tools (ifconfig, route, arp).

- Śledzenie trasy i lokalizacja strat: traceroute (UDP w Linux) / tracert (ICMP w Windows) oparte na manipulacji polem TTL i błędach ICMP Time Exceeded; narzędzia ciągłej analizy statystycznej pathping i mtr. - Inspekcja gniazd L4: linuksowe ss -tulpn (pobierające dane przez Netlink) oraz windowsowe netstat -ano, prezentujące porty nasłuchujące (LISTEN), stany TCP (RFC 793) oraz powiązane procesy PID. - Diagnostyka DNS: klasyczny nslookup oraz profesjonalny dig z flagą +trace, prezentujący surowe flagi odpowiedzi i rekordy zasobów.

30/55
Powtórka bezpieczeństwa i RODO
Cel slajdu: Syntetyczne przypomnienie ram prawnych (Kodeks Karny, RODO, Kodeks Pracy), zasad etyki zawodowej oraz technik zabezpieczania danych pomiarowych.

Repetytorium – Część 11: Bezpieczeństwo pomiarów, prawo i etyka

Pytanie: Czy adres IP to dana osobowa?

Odpowiedź: TAK. Adres IP umożliwia identyfikację urządzenia i użytkownika – podlega RODO.

Synteza modułu 11: przepisy karne (art. 267 KK – zakaz podsłuchu bez uprawnienia), RODO i status IP jako danej osobowej (TSUE C-582/14), zasady monitoringu pracowniczego (art. 22^2 KP), formalna autoryzacja testów penetracyjnych (Rules of Engagement) oraz anonimizacja PCAP (tcprewrite).
Adres IP z etykietą dana osobowa

W module jedenastym zdefiniowaliśmy prawne i moralne granice działalności inżyniera sieciowego. Zaawansowane narzędzia diagnostyczne i audytowe w rękach osoby nieodpowiedzialnej stają się narzędziami przestępstwa, narażając specjalistę na surową odpowiedzialność karną i cywilną.

Kluczowe imperatywy prawne i etyczne: - Kodeks Karny: art. 267 KK penalizuje nieuprawnione uzyskanie informacji, w tym uruchamianie snifferów pakietów w trybie nasłuchiwania w cudzej sieci (kara do 2 lat więzienia). Art. 269b KK zakazuje posiadania i udostępniania narzędzi hakerskich bez legalnego upoważnienia. - RODO (Rozporządzenie UE 2016/679): adresy IP to dane osobowe (wyrok TSUE w sprawie Patrick Breyer C-582/14). Pomiary i logowanie podlegają zasadom minimalizacji danych, ograniczenia celu oraz ograniczenia przechowywania (retencja).

- Kodeks Pracy: legalny monitoring sieci pracownika (art. 222 KP) wymaga 14-dniowego uprzedzenia w regulaminie pracy, uzasadnionego celu biznesowego oraz bezwzględnego poszanowania tajemnicy korespondencji prywatnej. - Etyka pentestingu: testy penetracyjne wymagają formalnego, pisemnego kontraktu Rules of Engagement (RoE) podpisanego przez zarząd (Get-Out-of-Jail Card). - Ochrona zrzutów PCAP: pliki zrzutów muszą być anonimizowane (narzędzie tcprewrite, obcinanie ładunku Snaplen) oraz szyfrowane algorytmami symetrycznymi AES-256 (GnuPG) lub asymetrycznymi.

31/55
Zadania praktyczne z narzędziami CLI
Cel slajdu: Samodzielne przećwiczenie sekwencji poleceń diagnostycznych w celu weryfikacji konfiguracji własnej stacji roboczej.

Laboratorium: Zadania praktyczne z narzędziami CLI

  1. Wykonaj ping do google.pl (10 pakietów) – zapisz średnie opóźnienie
  2. Wykonaj traceroute do google.pl – ile hopów?
  3. Wykonaj nslookup google.pl – jaki adres IP?
  4. Porównaj wyniki z inną domeną (np. wp.pl)
Zadanie laboratoryjne: kompleksowe wykonanie sekwencji testów konsolowych: odczyt parametrów IP, weryfikacja bramy domyślnej, rozwiązanie rekordu DNS, test MTU bez fragmentacji oraz audyt portów nasłuchujących.
Zrzuty ekranu z wynikami

W ramach niniejszego modułu warsztatowego studenci przystępują do samodzielnego wykonania pięciu zadań praktycznych w terminalu systemowym, dokumentując wyniki w pliku tekstowym zgodnie ze sztuką inżynierską:

Zestaw zadań laboratoryjnych do wykonania: 1. Zadanie 1 (Identyfikacja konfiguracji): Wyświetl pełną konfigurację interfejsów sieciowych (poleceniem ip a w Linux lub ipconfig /all w Windows). Odczytaj adres MAC, adres IPv4, maskę, adres Link-Local IPv6 oraz adresy przypisanych serwerów DNS. 2. Zadanie 2 (Test bramy domyślnej): Sprawdź adres bramy domyślnej z tablicy routingu (ip r lub route print). Wyślij serię 10 pakietów ping do bramy i oblicz średni czas RTT oraz ewentualną stratę pakietów.

3. Zadanie 3 (Badanie MTU ścieżki): Wyznacz maksymalny rozmiar ładunku bez fragmentacji (DF=1) do serwera 8.8.8.8, wykonując testy: ping -M do -s <rozmiar> 8.8.8.8 (Linux) lub ping -f -l <rozmiar> 8.8.8.8 (Windows). Zacznij od 1472 bajtów i znajdź dokładną wartość graniczną. 4. Zadanie 4 (Diagnostyka DNS): Narzędziem nslookup lub dig odpytaj bezpośrednio serwer 1.1.1.1 o rekord MX domeny uj.edu.pl. 5. Zadanie 5 (Audyt portów): Wyświetl listę wszystkich portów TCP nasłuchujących w stanie LISTEN wraz z identyfikatorami procesów (ss -tulpn w Linux lub netstat -ano w Windows).

32/55
Identyfikacja warstw OSI w Wireshark
Cel slajdu: Praktyczne powiązanie teoretycznego 7-warstwowego modelu ISO/OSI z rzeczywistymi nagłówkami pakietów przechwyconymi w programie Wireshark.

Laboratorium: Identyfikacja warstw OSI w Wireshark

  1. Uruchom Wireshark, przechwyć pakiet HTTP
  2. Rozwiń kolejno: Ethernet II (warstwa 2), IPv4 (warstwa 3), TCP (warstwa 4), HTTP (warstwa 7)
  3. Zidentyfikuj, jakie informacje niesie każda warstwa
  4. Zapisz zrzut ekranu z rozwiniętymi warstwami
Mapowanie pakietu na model OSI: ćwiczenie laboratoryjne polegające na dekompozycji pojedynczej ramki HTTP/DNS w drzewie Packet Details Wiresharka na odpowiadające jej warstwy L1–L7 modelu odniesienia.
Wireshark z rozwiniętymi warstwami OSI

Celem niniejszego ćwiczenia jest ostateczne zatarcie granicy pomiędzy abstrakcyjną teorią modeli sieciowych a namacalną strukturą binarną transmitowaną w kablu. W analizatorze Wireshark otwieramy zrzut ruchu zawierający transakcję pobrania strony internetowej HTTP i analizujemy pojedynczą ramkę w panelu Packet Details:

Mapowanie drzewa protokołów Wiresharka na warstwy ISO/OSI: - Warstwa 1 (Fizyczna) -> Poziom Frame: Wireshark prezentuje metadane ramki odebranej z karty sieciowej: numer ramki, długość na łączu (Bytes on wire, np. 1514 bytes), znacznik czasu przechwycenia z mikrosekundową precyzją oraz identyfikator interfejsu. - Warstwa 2 (Łącza danych) -> Poziom Ethernet II: nagłówek ramki zawierający 6-bajtowy docelowy adres MAC, 6-bajtowy źródłowy adres MAC (z rozwiniętą nazwą producenta OUI) oraz 2-bajtowe pole EtherType (0x0800 wskazujące na IPv4).

- Warstwa 3 (Sieciowa) -> Poziom Internet Protocol Version 4: nagłówek pakietu IPv4: wersja, długość nagłówka IHL, pole DSCP, całkowita długość pakietu, flagi fragmentacji (DF/MF), wartość TTL, suma kontrolna oraz źródłowy i docelowy 32-bitowy adres IP. - Warstwa 4 (Transportowa) -> Poziom Transmission Control Protocol: nagłówek segmentu TCP: port źródłowy (ephemeral) i docelowy (np. 80), numery sekwencyjne SEQ i potwierdzenia ACK, flaga ACK/PSH, wielkość okna bufora (Window Size) oraz suma kontrolna. - Warstwy 5, 6 i 7 (Aplikacji) -> Poziom Hypertext Transfer Protocol: zdekodowany nagłówek metody GET, nagłówki Host, User-Agent oraz ładunek danych HTML.

33/55
Pomiar przepustowości sieci LAN
Cel slajdu: Przeprowadzenie profesjonalnego testu wydajnościowego łącza Gigabit Ethernet, zbadanie wpływu liczby strumieni równoległych oraz analiza narzutu protokołów.

Laboratorium: Pomiar przepustowości sieci LAN za pomocą iperf3

# Na komputerze A (serwer)
iperf3 -s
# Na komputerze B (klient)
iperf3 -c 192.168.1.100 -t 30

Jaka jest rzeczywista przepustowość między komputerami?

Procedura benchmarkingu LAN: test wydajnościowy architektury klient-serwer narzędziem iperf3 weryfikujący czy rzeczywista przepustowość Goodput osiąga teoretyczny limit 940–950 Mb/s dla łącza 1000BASE-T.
Wynik iperf3

W tym zadaniu laboratoryjnym studenci zestawiają testowe środowisko pomiarowe pomiędzy dwoma komputerami połączonymi kablem kat. 6 przez gigabitowy przełącznik zarządzalny. Celem jest weryfikacja, dlaczego łącze o nominalnej prędkości 1000 Mb/s (1 Gb/s) nigdy nie osiąga w aplikacjach równego 1000 Mb/s transferu danych.

Kroki realizacji pomiaru laboratoryjnego: 1. Uruchomienie serwera: na komputerze A uruchamiamy iperf3 -s. 2. Test podstawowy pojedynczego strumienia TCP: na komputerze B wykonujemy iperf3 -c <IP_komputera_A> -t 10. Rejestrujemy uzyskany wynik przepustowości (zazwyczaj ok. 941 Mb/s). 3. Analiza matematyczna narzutu protokołowego (Overhead Analysis): - Maksymalny rozmiar ramki Ethernet MTU = 1500 bajtów. - Narzuty: nagłówek IPv4 (20 bajtów) + nagłówek TCP z opcjami timestamp (32 bajty) = 52 bajty narzutu warstw wyższych. - Maksymalny rozmiar danych aplikacji w segmencie: MSS = 1500 - 52 = 1448 bajtów. - Efektywność danych na poziomie IP/TCP: 1448 / 1500 = 96,53%. - Narzut warstwy L2: preambuła (8 B) + nagłówek Ethernet (14 B) + FCS (4 B) + Interpacket Gap (12 B) = 38 bajtów na każdą ramkę 1500 B. - Ostateczna maksymalna teoretyczna przepustowość czystych danych wynosi: 1000 Mb/s × (1448 / 1538) ≈ 941,5 Mb/s!

4. Test wielostrumieniowy: wykonujemy polecenie iperf3 -c <IP_A> -P 4. Obserwujemy zachowanie kolejkowania w przełączniku i równomierność podziału pasma pomiędzy strumienie.

34/55
Sprawdzanie parametrów karty sieciowej
Cel slajdu: Praktyczne badanie stanu warstwy fizycznej i łącza danych karty sieciowej w systemie Linux oraz weryfikacja sprzętowych funkcji odciążania (Offloading).

Laboratorium: Weryfikacja parametrów karty sieciowej narzędziem ethtool

ethtool eth0# Linux – Speed, Duplex, Auto-neg, Link

Sprawdź: jaka prędkość? Jaki duplex? Czy auto-negocjacja włączona?

Windows: we właściwościach karty sieciowej → Speed & Duplex.

Audyt parametrów kontrolera NIC: inspekcja właściwości układu PHY karty sieciowej za pomocą ethtool: prędkość, tryb dupleksu, stan autonegocjacji, obsługa ramek Jumbo Frames oraz funkcje TSO/GSO.
Zrzut ekranu z ethtool

Narzędzie ethtool stanowi najpotężniejsze linuksowe narzędzie do bezpośredniej komunikacji ze sterownikiem i układem scalonym kontrolera sieciowego (NIC). Pozwala na odczyt i zmianę parametrów, które są całkowicie niewidoczne dla zwykłych narzędzi takich jak ip czy ifconfig.

Kluczowe procedury audytowe z użyciem ethtool: 1. Odczyt stanu fizycznego łącza: Wykonujemy ethtool eth0. Weryfikujemy: - Speed: aktualna prędkość (np. 1000Mb/s, 10000Mb/s), - Duplex: tryb dupleksu (musi być Full; stan Half na gigabitowym porcie świadczy o poważnym błędzie negocjacji), - Auto-negotiation: stan autonegocjacji (zalecane on), - Link detected: stan fizycznej nośnej (yes potwierdza sprawność kabla i portu switcha).

2. Inspekcja liczników błędów sprzętowych (Hardware Statistics): Polecenie ethtool -S eth0 wyświetla surowe rejestry kontrolera NIC: błędy sum kontrolnych (rx_crc_errors), przepełnienia buforów kolejkowych (rx_dropped, rx_fifo_errors) oraz błędy wyrównania ramek (rx_align_errors). 3. Weryfikacja funkcji odciążania sprzętowego (Hardware Offloading): Polecenie ethtool -k eth0 prezentuje stan akceleracji sprzętowej: TCP Segmentation Offload (TSO), Generic Segmentation Offload (GSO) oraz sumowania kontrolnego (rx-checksumming, tx-checksumming). Funkcje te zdejmują z procesora głównego (CPU) konieczność dzielenia segmentów TCP, co radykalnie zwiększa przepustowość serwera.

35/55
Skanowanie dostępnych sieci Wi-Fi
Cel slajdu: Przećwiczenie pasywnego i aktywnego wykrywania sieci bezprzewodowych WLAN za pomocą narzędzi konsolowych iw, nmcli oraz wavemon w systemie Linux.

Laboratorium: Skanowanie środowiska radiowego Wi-Fi z konsoli

iw dev wlan0 scan# Linux – listę dostępnych sieci Wi-Fi

Znajdź sieć z najsilniejszym sygnałem (signal dBm). Jaki kanał? Jakie zabezpieczenia?

Skanowanie otoczenia radiowego WLAN: procedura zbierania ramek Beacon i Probe Response punktów dostępowych w celu identyfikacji identyfikatorów SSID, adresów BSSID, numerów kanałów, szerokości pasma oraz standardów szyfrowania.
Zrzut ekranu z iw scan

W ramach niniejszego ćwiczenia studenci dokonują profesjonalnego audytu otoczenia radiowego WLAN bez użycia narzędzi graficznych, wykorzystując niskopoziomowe polecenia systemowe w środowisku Linux:

Procedura laboratoryjna analizy sieci Wi-Fi: 1. Szybki skan za pośrednictwem NetworkManagera: Wykonujemy polecenie: nmcli dev wifi list Konsola generuje czytelną tabelę zawierającą: aktualnie połączoną sieć (oznaczoną gwiazdką), identyfikatory BSSID (adresy MAC punktów dostępowych AP), nazwy SSID, tryb pracy, numery kanałów radiowych, maksymalną przepustowość (np. 540 Mbit/s), poziom sygnału (procentowo i w słupkach) oraz standard bezpieczeństwa (np. WPA2 WPA3).

2. Głęboki zrzut parametrów radiowych poleceniem iw: Wykonujemy z uprawnieniami roota: sudo iw dev wlan0 scan | grep -E '(SSID|signal|DS Parameter|primary channel|RSN)' Pozwala to na precyzyjny odczyt poziomu sygnału RSSI w decybelach względem miliwata (np. signal: -58.00 dBm), dokładnego numeru kanału podstawowego oraz informacji o obsługiwanych zestawach szyfrów (AES-CCMP, GCMP-256). 3. Dynamiczny monitor jakości sygnału wavemon: Uruchomienie programu wavemon prezentuje w terminalu pseudograficzny, odświeżany na żywo wykres poziomu sygnału, poziomu szumu, jakości łącza (Link quality) oraz liczników błędów pakietowych podczas przemieszczania się po budynku, co stanowi idealne narzędzie do wstępnego badania zasięgu (Walkabout Survey).

36/55
Sprawdzanie tablicy routingu systemu
Cel slajdu: Przećwiczenie zaawansowanej interpretacji wpisów tablicy trasowania IPv4 i IPv6 oraz symulacja wyboru trasy zgodnie z zasadą Longest Prefix Match.

Laboratorium: Szczegółowa analiza tablicy routingu

route print# Windows
ip route show# Linux

Znajdź trasę domyślną (0.0.0.0/0). Jaki jest gateway? Jaki interfejs?

Analiza Forwarding Information Base (FIB): badanie reguł wyznaczania trasy w systemach operacyjnych za pomocą ip route show, weryfikacja tras połączonych bezpośrednio, tras statycznych, bramy domyślnej oraz metryk.
Zrzut ekranu z route print

W tym zadaniu laboratoryjnym studenci poddają szczegółowej wiwisekcji tablicę trasowania (FIB) na stacji roboczej, symulując działanie algorytmu routingu jądra systemu operacyjnego dla przychodzących pakietów o różnych adresach docelowych.

Procedura laboratoryjna analizy routingu w systemie Linux: 1. Odczyt pełnej tablicy trasowania: Wykonujemy polecenie ip route show (lub ip -4 r): default via 192.168.1.1 dev eth0 proto dhcp metric 100 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50 metric 100 10.0.0.0/8 via 192.168.1.254 dev eth0 metric 50 10.10.5.0/24 via 192.168.1.253 dev eth0 metric 200

2. Symulacja wyboru trasy przez jądro (Zasada Longest Prefix Match): Zadaniem studenta jest określenie, przez którą bramę i z jakim adresem IP zostanie wysłany pakiet skierowany na adres 10.10.5.88: - Trasa domyślna default dopasowuje 0 bitów (/0). - Trasa 10.0.0.0/8 dopasowuje pierwsze 8 bitów adresu. - Trasa 10.10.5.0/24 dopasowuje aż 24 bity adresu! Zgodnie z regułą najdłuższego dopasowania prefiksu (LPM), pakiet zostanie bezwzględnie skierowany do bramy 192.168.1.253, mimo że trasa /8 ma znacznie korzystniejszą metrykę (50 wobec 200). Długość maski ma zawsze bezwzględne pierwszeństwo przed metryką! 3. Weryfikacja decyzji jądra poleceniem diagnostycznym: Wykonujemy: ip route get 10.10.5.88. Jądro natychmiast potwierdza wybraną trasę, interfejs wyjściowy oraz adres źródłowy.

37/55
Dopasowanie narzędzia do zadania
Cel slajdu: Utrwalenie umiejętności błyskawicznego przyporządkowania optymalnego programu do konkretnego scenariusza awarii w warunkach presji czasu.

Ćwiczenie decyzyjne: Dopasuj narzędzie do zadania diagnostycznego

ZadanieNarzędzie
Pomiar opóźnienia?
Analiza protokołów?
Pomiar przepustowości?
Konfiguracja IP?
Zapytanie DNS?

Odpowiedzi: ping, Wireshark, iperf3, ipconfig/ip, nslookup/dig.

Matryca dopasowania narzędzi: ćwiczenie inżynierskie weryfikujące trafność wyboru pomiędzy ping, traceroute, iperf3, Wireshark, ethtool, dig oraz ss w 5 realnych problemach produkcyjnych.
Tabela z ikonami narzędzi

W ramach niniejszego ćwiczenia seminaryjnego studenci analizują 5 typowych problemów zgłoszonych do helpdesku i wybierają dokładnie jedno, optymalne narzędzie pierwszego rzutu, uzasadniając swój wybór pod kątem warstwy modelu OSI i specyfiki usterki:

Scenariusze problemowe do dopasowania: - Scenariusz 1: Użytkownicy w oddziale skarżą się, że połączenie z bazą danych SQL w centrali zrywa się co kilkadziesiąt sekund. Podejrzewasz fluktuacje opóźnień lub utratę pakietów na łączu operatorskim w sieci WAN. -> Optymalne narzędzie: mtr (lub pathping) – pozwala na ciągłą, równoległą obserwację utraty pakietów na każdym skoku routerowym w czasie rzeczywistym. - Scenariusz 2: Chcesz sprawdzić, czy nowo zestawione łącze światłowodne 10 Gb/s pomiędzy dwoma serwerami rzeczywiście osiąga deklarowaną prędkość transferu danych. -> Optymalne narzędzie: iperf3 – nasyca łącze syntetycznym strumieniem TCP/UDP i mierzy rzeczywisty Goodput.

- Scenariusz 3: Nowy serwer WWW został uruchomiony, lecz klienci zgłaszają błąd 'Połączenie odrzucone' (Connection Refused). Chcesz sprawdzić na serwerze, czy proces Nginx w ogóle nasłuchuje na porcie 443. -> Optymalne narzędzie: ss -tulpn – natychmiast wyświetla stan gniazd TCP LISTEN i powiązany numer PID. - Scenariusz 4: Aplikacja kliencka zawiesza się podczas negocjacji szyfrowania z serwerem. Podejrzewasz błąd w certyfikacie x509 lub niezgodność wersji protokołu TLS. -> Optymalne narzędzie: Wireshark – pozwala na mikroskopową deasemblację pakietów Client Hello, Server Hello i badanie rozszerzeń kryptograficznych. - Scenariusz 5: Podejrzewasz, że kabel sieciowy w ścianie został uszkodzony podczas prac remontowych, powodując lawinowy przyrost błędów na porcie przełącznika. -> Optymalne narzędzie: ethtool -S (lub diagnostyka TDR w switchu) – odczyt rejestrów błędów CRC.

38/55
Podsumowanie całego cyklu wprowadzającego
Cel slajdu: Całościowe, panoramiczne spojrzenie na fundamenty inżynierii sieciowej przyswojone w trakcie dwunastu części kursu wprowadzającego.

Wielka Synteza – co poznaliśmy w całym cyklu PiDSK?

  • Część 1: Wprowadzenie do pomiarów
  • Część 2: Interfejsy LAN
  • Część 3: Interfejsy WLAN
  • Część 4: Model ISO/OSI
  • Część 5: Model TCP/IP
  • Część 6: Protokoły aplikacji i transportu
  • Część 7: Protokoły sieci i łącza
  • Część 8: IPv4
  • Część 9: IPv6
  • Część 10: Narzędzia CLI
  • Część 11: Bezpieczeństwo i etyka
  • Część 12: Narzędzia i podsumowanie
Synteza cyklu PiDSK: całościowy bilans kompetencji inżynierskich obejmujący warstwę fizyczną (LAN/WLAN), modele odniesienia (OSI i TCP/IP), protokoły sieciowe i transportowe, adresację IPv4/IPv6, diagnostykę CLI oraz ramy prawne i etyczne.
Mapa myśli z 12 gałęziami

Kurs „Podstawy i Diagnostyka Sieci Komputerowych” przeprowadził Państwa przez kompletną ścieżkę inżynierską: od fizycznej natury fali elektromagnetycznej w kablu miedzianym i światłowodzie, aż po zaawansowane aplikacje chmurowe, bezpieczeństwo prawne i analizę pakietową.

Panoramiczny bilans opanowanych filarów inżynierskich: 1. Medium i transmisja fizyczna (Części 1–3): metryki teleinformatyczne (RTT, Jitter, Throughput), okablowanie strukturalne kat. 5e/6/6A, światłowody SMF/MMF, technologia PoE oraz sieci bezprzewodowe Wi-Fi w pasmach 2.4, 5 i 6 GHz z mechanizmem CSMA/CA. 2. Architektura warstwowa (Części 4–5): 7 warstw modelu ISO/OSI oraz 4 warstwy stosu TCP/IP; proces enkapsulacji PDU; filozofia Best-Effort w warstwie IP oraz dychotomia pomiędzy niezawodnym TCP a lekkim UDP.

3. Protokoły komunikacyjne (Części 6–7): porty IANA, usługi DNS, DHCP, HTTP/HTTPS, SSH; ramka Ethernet II, tablica MAC przełącznika, rozwiązywanie adresów ARP, kontrola ICMP oraz stabilizacja topologii przez STP/RSTP. 4. Adresacja i routing (Części 8–9): pełna matematyka 32-bitowego IPv4 (maska AND, CIDR, VLSM, pule prywatne RFC 1918, translacja NAT/PAT) oraz architektura 128-bitowego IPv6 (notacja RFC 5952, podwójny dwukropek, granica LAN /64, adresy Link-Local, bezstanowa autokonfiguracja SLAAC i protokół NDP). 5. Warsztat diagnostyczny i bezpieczeństwo (Części 10–12): narzędzia konsolowe CLI, analizatory Wireshark i tcpdump, generator iperf3, metodyka troubleshootingu oraz rygory prawne Kodeksu Karnego i RODO.

39/55
Test prędkości internetu online
Cel slajdu: Przedstawienie inżynierskich zasad poprawnego wykonywania pomiarów przepustowości łącza WAN oraz eliminacji błędów metodologicznych.

Metodyka profesjonalnego testu prędkości łącza internetowego

  1. Wykonaj test prędkości na speedtest.net lub fast.com
  2. Zapisz: download, upload, ping
  3. Porównaj z deklarowaną prędkością od ISP
  4. Wykonaj 3 testy o różnych porach dnia – porównaj wyniki
Pomiary przepustowości WAN: reguły poprawnego testowania łącza dostępowego (Speedtest / Ookla, nperf, iperf3 publiczne) eliminujące zakłócenia lokalne (Wi-Fi, obciążenie procesora, aplikacje tła) w celu weryfikacji parametrów umowy SLA.
Zrzut ekranu z speedtest.net

Wielu użytkowników i początkujących techników wykonuje testy prędkości łącza internetowego za pośrednictwem internetowych testerów przeglądarkowych (np. Speedtest.net, fast.com), popełniając kardynalne błędy metodologiczne, a następnie bezpodstawnie reklamując łącze u dostawcy ISP. Doświadczony inżynier sieciowy przestrzega ścisłych rygorów procedury pomiarowej:

Zasady inżynierskiego pomiaru prędkości łącza: 1. Eliminacja medium radiowego: NIGDY nie wykonuj wiążącego testu prędkości przez sieć Wi-Fi! Fluktuacje sygnału radiowego, interferencje i ograniczenia karty bezprzewodowej sprawiają, że test mierzy jakość lokalnego eteru, a nie przepustowość łącza dostępowego. Podłącz komputer testowy bezpośrednio do portu LAN routera brzegowego certyfikowanym kablem kat. 6 o długości 1–2 m. 2. Izolacja stacji pomiarowej: wyłącz wszystkie aplikacje działające w tle (klienty torrent, synchronizację dysków w chmurze Google Drive / OneDrive, automatyczne aktualizacje Windows Update). W konsoli sprawdź ss -tulpn lub netstat -ano, czy żadna usługa nie generuje ruchu.

3. Weryfikacja parametrów karty sieciowej: sprawdź poleceniem ethtool lub we właściwościach karty, czy karta zestawiła łącze z prędkością 1000 Mb/s Full-Duplex. Uszkodzony kabel 4-żyłowy zestawia łącze na 100 Mb/s, co ogranicza wynik do 94 Mb/s niezależnie od prędkości światłowodu! 4. Wybór narzędzia pomiarowego: zamiast przeglądarki obciążającej procesor skryptami JavaScript, stosuj oficjalne narzędzie konsolowe speedtest-cli (Ookla CLI) lub dedykowane serwery iperf3 udostępniane przez operatorów tranzytowych.

40/55
Automatyczny monitoring ping
Cel slajdu: Przedstawienie architektury kompletnego, zautomatyzowanego skryptu diagnostycznego w języku Python / Bash monitorującego stan sieci i logującego incydenty.

Projekt inżynierski: Automatyczny skrypt monitorowania stabilności łącza

# Bash – zapis ping do pliku z datą
ping -c 10 8.8.8.8 | while read line; do
 echo "$(date) $line" >> ping_log.txt
done

Uruchom skrypt i sprawdź, jak zmienia się opóźnienie w czasie.

Projekt monitoringu CLI: autonomiczny skrypt diagnostyczny cyklicznie badający czasy RTT, utratę pakietów oraz dostępność DNS, rejestrujący dane do bazy lub pliku CSV na potrzeby wykrywania mikroawarii.
Wykres opóźnienia z logu

W ramach zwieńczenia warsztatu narzędziowego przedstawiamy architekturę profesjonalnego skryptu monitorującego stabilność infrastruktury sieciowej w czasie rzeczywistym. Narzędzie to pozwala inżynierowi udowodnić dostawcy usług występowanie sporadycznych przerw w łączności (tzw. mikroawarii trwających kilka sekund), które umykają standardowym testom manualnym.

Struktura inżynierskiego skryptu diagnostycznego (architektura Bash/Python): 1. Próbkowanie wielopunktowe (Multi-Target Probing): skrypt nie ogranicza się do badania jednego adresu, lecz równolegle monitoruje trzy punkty kontrolne: - Punkt A (Segment LAN): adres bramy domyślnej (np. 192.168.1.1) – weryfikuje lokalny przełącznik i okablowanie, - Punkt B (Węzeł WAN/ISP): adres pierwszego routera operatora za naszą bramą – weryfikuje łącze dostępowe, - Punkt C (Globalny Internet): publiczny serwer referencyjny Anycast (1.1.1.1 lub 8.8.8.8) – weryfikuje tranzyt międzynarodowy.

2. Korelacja logiczna w pętli pomiarowej: - Jeśli giną pakiety do punktu A, B i C: awaria lokalna w firmie (kabel/switch), - Jeśli punkt A odpowiada, a punkty B i C milczą: awaria łącza operatora telekomunikacyjnego ISP, - Jeśli punkty A i B odpowiadają, a punkt C nie działa: awaria w węźle wymiany ruchu (IXP) lub awaria tranzytu Tier-1. 3. Formatowanie wyjścia do ustandaryzowanego pliku CSV: Skrypt rejestruje każdy pomiar w formacie: Timestamp;Target;RTT_ms;PacketLoss_pct;Status, co umożliwia natychmiastowy import danych do arkusza kalkulacyjnego i wygenerowanie wykresów trendów do formalnego zgłoszenia reklamacyjnego SLA.

41/55
Lista poznanych narzędzi sieciowych
Cel slajdu: Całościowe zestawienie całego arsenału narzędzi inżynierskich poznanych i przećwiczonych w trakcie kursu.

Kompendium narzędzi diagnostycznych kursu PiDSK

  • Diagnostyka CLI: ping, traceroute, pathping (tylko Windows), mtr
  • Konfiguracja: ipconfig, ip (ifconfig przestarzały), route, arp
  • DNS: nslookup, dig
  • Połączenia: ss (netstat przestarzały), telnet
  • Sniffery: Wireshark, tshark, tcpdump
  • Generatory: iperf3, hping3, packeth
  • Karty sieciowe: ethtool, iw, iwconfig
  • WLAN: airodump-ng, Kismet, Wi-Fi Analyzer
Kanon narzędziowy inżyniera PiDSK: zbiór 17 programów diagnostycznych i analitycznych (od warstwy fizycznej po aplikację) stanowiący kompletny warsztat pracy administratora i specjalisty cyberbezpieczeństwa.
Kolaż ikon wszystkich narzędzi

W trakcie dwunastu części kursu „Podstawy i Diagnostyka Sieci Komputerowych” poznali i przećwiczyli Państwo w praktyce kompletny zestaw narzędzi telemetrycznych, pomiarowych i audytowych, pokrywający wszystkie warstwy modeli ISO/OSI oraz TCP/IP. Zestaw ten stanowi profesjonalny niezbędnik każdego inżyniera:

Katalog narzędzi opanowanych w cyklu PiDSK: - Warstwa fizyczna i łącza (L1/L2): ethtool (parametry PHY, Speed, Duplex, błędy CRC), wavemon / iw / nmcli (parametry sygnału Wi-Fi RSSI/SNR), reflektometria TDR, protokoły wykrywania sąsiadów LLDP / CDP. - Warstwa sieciowa (L3): ping (weryfikacja ICMP Echo, RTT, TTL), iproute2 (zarządzanie interfejsami, adresacją i routingiem w Linux), ipconfig (zarządzanie IP i DHCP w Windows), traceroute / tracert (śledzenie ścieżki tranzytowej), pathping oraz mtr (pomiar strat pakietów w czasie rzeczywistym).

- Warstwa transportowa i aplikacje (L4/L7): ss oraz netstat (inspekcja gniazd TCP/UDP, portów LISTEN i procesów PID), nslookup i dig (odpytywanie i śledzenie delegacji DNS), curl (testowanie protokołów HTTP/HTTPS). - Analiza pakietowa i benchmark (Deep Inspection): Wireshark (graficzna deasemblacja protokołów, filtry wyświetlania, Follow TCP Stream), tcpdump (konsolowy sniffer BPF) oraz iperf3 (generator obciążenia i miernik Goodput L4). - Bezpieczeństwo i etyka: tcprewrite (anonimizacja PCAP), GnuPG (szyfrowanie zrzutów AES-256) oraz Nmap (audyt portów i inwentaryzacja zasobów).

42/55
Porównanie narzędzi diagnostycznych
Cel slajdu: Przedstawienie krytycznej oceny mocnych i słabych stron wiodących narzędzi diagnostycznych w warunkach wielkoskalowej infrastruktury.

Porównanie narzędzi diagnostycznych – wady, zalety i ograniczenia

NarzędzieTypZastosowaniePlatforma
WiresharkGUI/CLIAnaliza protokołówWin/Lin/Mac
tcpdumpCLISniffing w terminaluLin/Mac
tsharkCLIAnaliza z konsoliWin/Lin/Mac
iperf3CLIPomiar przepustowościWin/Lin/Mac
hping3CLIGenerowanie pakietówLin
ethtoolCLIParametry karty sieciowejLin
airodump-ngCLISkanowanie WLANLin
Krytyczna ocena aparatury sieciowej: inżynierska analiza porównawcza uwzględniająca ograniczenia wydajnościowe (CPU, pamięć RAM, dropy buforów), narzut sieciowy oraz podatność na blokady ze strony zapór ogniowych.
Tabela z logami narzędzi

Świadomy inżynier teleinformatyki zna nie tylko możliwości poszczególnych narzędzi, lecz przede wszystkim ma pełną świadomość ich ograniczeń technicznych. Zastosowanie niewłaściwego programu może prowadzić do fałszywych wniosków diagnostycznych lub niepotrzebnego zakłócenia pracy sieci.

Zestawienie ograniczeń i specyfiki narzędzi: - Wireshark: niezrównany w głębokiej analizie pojedynczych sesji, lecz wysoce pamięciożerny. Załadowanie pliku PCAP o rozmiarze kilku gigabajtów potrafi wyczerpać pamięć RAM stacji i zawiesić aplikację (w takich przypadkach należy stosować konsolowy tshark lub dzielić pliki narzędziem editcap). - tcpdump: niezwykle wydajny i niezawodny dzięki filtrom BPF w jądrze, lecz brak interfejsu graficznego utrudnia szybką korelację wielowątkowych konwersacji i analizę statystyczną.

- iperf3: doskonały miernik przepustowości, lecz nasyca łącze do 100%, co w sieci produkcyjnej może wywołać chwilowy paraliż usług biznesowych (wymaga uzgodnionego okna serwisowego). Ponadto bada wyłącznie warstwę L4, ignorując narzuty warstwy aplikacji. - ping i traceroute: powszechnie dostępne, lecz ich pakiety ICMP są często traktowane priorytetowo lub celowo odrzucane przez mechanizmy Control Plane Policing (CoPP) w routerach operatorskich, co może dawać fałszywy obraz rzekomej awarii łącza.

43/55
Dalsze kierunki rozwoju wiedzy
Cel slajdu: Przedstawienie perspektyw dalszego kształcenia i zaawansowanych specjalizacji teleinformatycznych po opanowaniu kursu wprowadzającego.

Co dalej? Zaawansowane kierunki rozwoju inżyniera sieciowego

  • Cykl logiczny (p2): Szczegółowa analiza protokołów, Wireshark zaawansowany, tcpdump, tshark, filtry BPF i display, statystyki, IO Graph, sesje TCP
  • Cykl fizyczny (p3): Pomiary tłumienia w światłowodach, OTDR, analizatory widma, mierniki mocy, RSSI, SNR, EIRP, budżet mocy
  • Certyfikacje: CCNA, Network+, Wireshark Certified Analyst, CWNA (WLAN)
Zaawansowane domeny teleinformatyki: kierunki specjalizacji inżynierskiej: protokoły routingu dynamicznego BGP/OSPF, inżynieria ruchu MPLS/SRv6, sieci definiowane programowo (SDN), konteneryzacja sieci w chmurze (Kubernetes CNI) oraz architektura Zero Trust.
Ścieżka rozwoju z 3 gałęziami

Ukończenie cyklu wprowadzającego PiDSK to doskonały fundament, otwierający drzwi do najbardziej fascynujących i poszukiwanych na rynku pracy specjalizacji teleinformatycznych. Współczesny świat sieci ewoluuje w kierunku pełnej automatyzacji, chmury obliczeniowej oraz programowalności infrastruktury.

Główne ścieżki zaawansowanego rozwoju: 1. Routing operatorski i inżynieria ruchu (Service Provider / ISP): protokoły bramy wewnętrznej (OSPFv2/v3, IS-IS) oraz protokół routingu globalnego Internetu BGP (Border Gateway Protocol, RFC 4271); technologie etykietowania MPLS oraz nowoczesny Segment Routing (SRv6) zapewniający elastyczne kształtowanie ścieżek transmisyjnych (Traffic Engineering). 2. Sieci Definiowane Programowo (SDN - Software-Defined Networking): separacja warstwy sterowania (Control Plane) od warstwy przekazywania danych (Data Plane) za pomocą protokołów OpenFlow, technologii SD-WAN oraz programowalnych układów ASIC w języku P4.

3. Sieci w Chmurze i Konteneryzacja (Cloud Networking & DevOps): wirtualne sieci chmurowe (AWS VPC, Azure VNet), obsługa wtyczek sieciowych CNI (Container Network Interface) w klastrach Kubernetes (Cilium oparte na eBPF, Calico z protokołem BGP) oraz automatyzacja infrastruktury za pomocą kodu (IaC - Infrastructure as Code: Terraform, Ansible). 4. Cyberbezpieczeństwo i architektura Zero Trust: wdrożenie modelu „Never Trust, Always Verify”, mikrosegmentacja sieciowa, szyfrowanie IPsec/WireGuard oraz bezpieczeństwo tożsamości.

44/55
Złote zasady wykonywania pomiarów
Cel slajdu: Utrwalenie kanonicznych zasad inżynierskich decydujących o rzetelności, powtarzalności i wiarygodności badań teleinformatycznych.

Złote zasady profesjonalnych pomiarów sieciowych

  1. Planuj pomiar – cel, narzędzie, czas, miejsce
  2. Wykonaj baseline – wartość referencyjna dla porównania
  3. Mierz wielokrotnie – statystyka daje prawdę (min, max, avg, odchylenie)
  4. Interpretuj wyniki w kontekście topologii i obciążenia sieci
  5. Dokumentuj i raportuj – wyniki bez kontekstu są bezużyteczne
  6. Bądź etyczny i zgodny z prawem – RODO, zgoda, anonimizacja
„If you can't measure it, you can't manage it" – Peter Drucker. To motto każdego administratora sieci.
Złote zasady inżynierii pomiarowej: zbiór reguł metodologicznych: testy SLA wyłącznie po kablu, rejestracja stanu odniesienia (Baseline), wprowadzanie jednej zmiany na raz, izolacja zmiennych zakłócających i bezwzględna legalność.
6 złotych zasad na tarczy

Doświadczony inżynier sieciowy różni się od amatora nie tylko wiedzą, lecz przede wszystkim dyscypliną metodologiczną. W celu zagwarantowania, że wyniki pomiarów będą bezsporne i uznawane przez audytorów oraz operatorów telekomunikacyjnych, należy bezwzględnie przestrzegać poniższych żelaznych zasad:

Kanon inżyniera pomiarowego: 1. Nigdy nie mierz wydajności łącza przez Wi-Fi, jeśli badasz umowę SLA: medium radiowe jest zmienne i podatne na interferencje. Wiążący test infrastruktury przewodowej i łącza WAN wykonuje się ZAWSZE po bezpośrednim połączeniu kablem Ethernet kat. 6. 2. Zawsze zdefiniuj linię bazową (Baseline): nie jesteś w stanie stwierdzić, czy sieć działa wolno, jeśli nie wiesz, jak działa w warunkach normalnych. Regularnie rejestruj czasy RTT, przepustowość i utylizację łączy w stanie sprawności.

3. Wprowadzaj dokładnie jedną modyfikację na raz: zmiana wielu parametrów jednocześnie uniemożliwia ustalenie przyczyny rozwiązania problemu i może wprowadzić ukryte skutki uboczne. 4. Weryfikuj narzędzia i eliminuj błędy stacji pomiarowej: przed rozpoczęciem pomiaru upewnij się, że komputer pomiarowy nie jest obciążony procesami tła, a jego karta sieciowa zestawiła łącze z pełną prędkością i dupleksem. 5. Działaj zawsze w granicach prawa i etyki: posiadanie uprawnień i wiedzy to odpowiedzialność za ochronę prywatności użytkowników i stabilność powierzonych systemów.

45/55
Dobre praktyki pomiarów sieciowych
Cel slajdu: Przedstawienie standardów inżynierskiego dokumentowania pomiarów, standaryzacji raportów oraz zarządzania wiedzą w zespole IT.

Dobre praktyki prowadzenia dokumentacji i audytu sieci

  • Używaj dedykowanych narzędzi – nie mierz CPU-em przeciążonego serwera
  • Synchronizuj czas – NTP to podstawa wiarygodnych pomiarów
  • Automatyzuj – skrypty, cron, systemy monitorujące
  • Przechowuj wyniki – umożliwi to analizę trendów
  • Weryfikuj wyniki – różne narzędzia powinny dawać zbliżone rezultaty
  • Szkól się – technologie się zmieniają, bądź na bieżąco
Standardy dokumentacji inżynierskiej: sformalizowane procedury rejestrowania incydentów, tworzenia raportów powłamaniowych (Post-Mortem), archiwizacji logów telemetrycznych i zarządzania konfiguracją w bazie CMDB.
Lista kontrolna dobrych praktyk

W inżynierii teleinformatycznej obowiązuje fundamentalna zasada: „Praca niewydokumentowana to praca niewykonana”. Przekazanie wiedzy w zespole, ciągłość operacyjna w przypadku rotacji personelu oraz obrona przed roszczeniami prawnymi wymagają rzetelnego prowadzenia dokumentacji technicznej.

Kluczowe dobre praktyki dokumentacyjne: - Standaryzacja raportów pomiarowych: każdy raport z testów wydajnościowych lub audytu bezpieczeństwa musi zawierać: cel badania, wersje użytego oprogramowania, topologię punktów pomiarowych, surowe dane pomiarowe z sumami kontrolnymi SHA-256 oraz wnioski inżynierskie. - Protokoły Post-Mortem i Root Cause Analysis (RCA): po usunięciu każdej poważnej awarii zespół sporządza dokument analizujący: co się stało, jaka była bezpośrednia przyczyna źródłowa (Root Cause), jak usterka została usunięta oraz jakie działania zapobiegawcze (Action Items) wdrożono, aby awaria nigdy się nie powtórzyła.

- Aktualizacja schematów sieciowych: każda zmiana logiczna (nowy VLAN, zmiana podsieci, nowa trasa routingu) musi zostać natychmiast naniesiona na logiczne i fizyczne schematy sieci (np. w systemie NetBox lub diagramach architektonicznych). - Automatyzacja kopii zapasowych konfiguracji: konfiguracje wszystkich routerów, przełączników i zapór ogniowych muszą być cyklicznie archiwizowane w systemie kontroli wersji (np. Git z narzędziem Oxidized lub RANCID).

46/55
Pytania do dyskusji końcowej
Cel slajdu: Pobudzenie krytycznego myślenia inżynierskiego wokół przyszłości protokołów sieciowych, bezpieczeństwa i automatyzacji.

Dyskusja końcowa: Wyzwania nowoczesnej teleinformatyki

  1. Jakie narzędzie jest twoim zdaniem najważniejsze dla administratora sieci? Dlaczego?
  2. Jak odróżnić problem sieciowy od problemu aplikacji?
  3. Czy AI może zastąpić administratora w diagnostyce sieci?
  4. Jaka była najciekawsza część cyklu wprowadzającego?
Seminarium dyskusyjne PiDSK: debata nad przyszłością Internetu: migracja do IPv6-only, wpływ sztucznej inteligencji na monitorowanie sieci (AIOps), bezpieczeństwo kryptograficzne po wejściu komputerów kwantowych (PQC).
Ikona dyskusji grupowej

W ramach zwieńczenia wykładów zapraszamy do wspólnej dyskusji seminaryjnej nad kluczowymi trendami technologicznymi i wyzwaniami, które ukształtują oblicze inżynierii sieciowej w nadchodzącej dekadzie:

Węzłowe zagadnienia dyskusyjne: 1. Ostateczna śmierć IPv4 – kiedy sieć IPv6-only stanie się normą?: Dlaczego po 30 latach od zdefiniowania IPv6 globalna migracja wciąż nie osiągnęła 100%? Jakie koszty generuje utrzymywanie podwójnego stosu Dual-Stack i translatorów NAT64, i kiedy operatorzy zdecydują się na całkowite wyłączenie trasowania IPv4? 2. Rola sztucznej inteligencji w zarządzaniu siecią (AIOps): Czy zaawansowane modele uczenia maszynowego zastąpią inżynierów w analizie zrzutów ruchu i wykrywaniu anomalii? Gdzie leży granica zaufania do autonomicznych algorytmów rekonfigurujących tablice routingu i reguły firewalli bez udziału człowieka?

3. Kryptografia postkwantowa (PQC) a bezpieczeństwo sieciowe: W jaki sposób przewidywane pojawienie się komputerów kwantowych wpłynie na protokoły wymiany kluczy (Diffie-Hellman) i podpisu cyfrowego w protokołach TLS 1.3, IPsec i SSH? Jak inżynierowie sieciowi przygotowują się do wdrożenia nowych algorytmów standaryzowanych przez NIST? Wymiana perspektyw na te tematy pozwala powiązać opanowane fundamenty z najnowszymi trendami badań naukowych.

47/55
Pytania końcowe sprawdzające wiedzę
Cel slajdu: Przekrojowa weryfikacja wiedzy inżynierskiej z zakresu warstw fizycznej, łącza, sieci i transportu z całego kursu PiDSK.

Wielki Test Końcowy – Część 1 (Warstwy L1–L4)

  1. Wymień 5 narzędzi do diagnostyki sieci i ich zastosowanie.
  2. Jaka jest różnica między pomiarem aktywnym a pasywnym?
  3. Czym różni się OSI od TCP/IP?
  4. Jakie są trzy nie nakładające się kanały w 2,4 GHz?
Wielki test wiedzy inżynierskiej (Część 1): zestawienie syntetycznych pytań egzaminacyjnych weryfikujących zrozumienie kluczowych mechanizmów modeli OSI i TCP/IP, Ethernetu, Wi-Fi oraz kalkulacji podsieci.
Ikona pytań

Przed zakończeniem kursu zapraszamy do zmierzenia się z pierwszą częścią Wielkiego Testu Końcowego, integrującego wiedzę z modułów 1–8:

Zestaw pytań egzaminacyjnych (Część 1): 1. Warstwa fizyczna i łącza danych: Jaki jest maksymalny dopuszczalny dystans toru transmisyjnego dla miedzianej skrętki kat. 6A w standardzie 10GBASE-T, czym różni się kabel krosowy (Patch Cord) od instalacyjnego drutu i jakie zjawisko w przełącznikach eliminuje protokół RSTP (IEEE 802.1w)? 2. Sieci bezprzewodowe Wi-Fi: Dlaczego w paśmie 2.4 GHz dopuszcza się równoległą pracę wyłącznie kanałów 1, 6 i 11, i czym różni się mechanizm detekcji kolizji CSMA/CD od unikania kolizji CSMA/CA? 3. Adresacja i obliczenia IPv4: Dla podsieci o adresie 192.168.10.64/27 oblicz: maskę podsieci w zapisie kropkowo-dziesiętnym, adres sieci, adres rozgłoszeniowy (broadcast) oraz zakres pierwszego i ostatniego użytecznego adresu dla hostów. 4. Warstwa transportowa TCP/UDP: Przedstaw sekwencję flag TCP wymienianych podczas procedury 3-Way Handshake, wyjaśnij rolę numerów sekwencyjnych SEQ/ACK oraz podaj kluczową różnicę architektoniczną pomiędzy TCP a UDP.

Samodzielne rozwiązanie tych pytań bez sięgania do notatek potwierdza pełne opanowanie materiału inżynierskiego.

48/55
Odpowiedzi na pytania końcowe
Cel slajdu: Przedstawienie autorytatywnych, wyczerpujących rozwiązań inżynierskich do pytań testowych ze slajdu 47.

Odpowiedzi do Wielkiego Testu Końcowego – Część 1

  1. ping (RTT), traceroute (trasa), Wireshark (analiza), iperf3 (przepustowość), nslookup (DNS)
  2. Aktywny – generuje ruch testowy, pasywny – obserwuje istniejący
  3. OSI – 7 warstw (teoria), TCP/IP – 4 warstwy (praktyka)
  4. Kanały 1, 6, 11
Klucz rozwiązań egzaminacyjnych (Część 1): precyzyjne odpowiedzi dotyczące limitów Ethernetu (100 m), pasm Wi-Fi, pełnej matematyki podsieci /27 oraz mechaniki 3-Way Handshake TCP.
Ikona odpowiedzi

Poniżej przedstawiono autorytatywne odpowiedzi inżynieryjne na pytania z pierwszej części Wielkiego Testu Końcowego:

Odpowiedź 1 (Warstwa fizyczna i L2): Maksymalny dystans łącza stałego wynosi 90 m (Permanent Link) plus 10 m kabli krosowych, dając łączny limit 100 metrów. Kabel instalacyjny składa się z pojedynczych sztywnych drutów miedzianych (przeznaczony do układania w korytach), a kabel krosowy z elastycznej linki wielodrutowej. Protokół RSTP eliminuje pętle przełączania warstwy 2 i burze rozgłoszeniowe (Broadcast Storms), blokując nadmiarowe łącza.

Odpowiedź 2 (Wi-Fi): Każdy kanał w 2.4 GHz ma szerokość 20 MHz (lub 22 MHz w 802.11b), a odstęp między środkami kanałów wynosi zaledwie 5 MHz. Jedynie kanały 1, 6 i 11 są oddalone o 25 MHz, co gwarantuje brak nakładania się widma (interferencji sąsiedniokanałowych). W radiu stacja nie słyszy sygnałów innych węzłów podczas własnego nadawania, dlatego nie może wykryć kolizji (CSMA/CD), lecz musi stosować unikanie kolizji (CSMA/CA) oparte na losowym odczekaniu Backoff i potwierdzeniach ACK.

Odpowiedź 3 (Obliczenia IPv4 /27): Prefiks /27 oznacza 27 jedynek w masce: 255.255.255.224. Część hosta h = 32 - 27 = 5 bitów. Liczba adresów: 25 = 32. Krok podsieci: 32. - Adres sieci: 192.168.10.64 - Adres rozgłoszeniowy (broadcast): 64 + 32 - 1 = 192.168.10.95 - Pierwszy użyteczny host: 192.168.10.65 - Ostatni użyteczny host: 192.168.10.94 (łącznie 30 hostów, zgodnie ze wzorem 25 - 2).

Odpowiedź 4 (TCP Handshake): Sekwencja 3-Way Handshake: 1) Klient -> Serwer: SYN (SEQ=X), 2) Serwer -> Klient: SYN-ACK (SEQ=Y, ACK=X+1), 3) Klient -> Serwer: ACK (SEQ=X+1, ACK=Y+1). Numery SEQ/ACK porządkują strumień bajtów i potwierdzają odebranie danych. TCP jest połączeniowy i niezawodny z retransmisjami; UDP jest bezpołączeniowy i bezstanowy bez gwarancji dostarczenia.

49/55
Dodatkowe pytania końcowe
Cel slajdu: Przekrojowa weryfikacja wiedzy z zakresu protokołu IPv6, narzędzi diagnostycznych Wireshark/tcpdump oraz prawa teleinformatycznego z modułów 9–11.

Wielki Test Końcowy – Część 2 (IPv6, Narzędzia i Bezpieczeństwo)

  1. Ile bitów ma adres IPv6?
  2. Do czego służy ARP?
  3. Co to jest RODO i jak wpływa na pomiary?
  4. Jak działa Three-Way Handshake TCP?
Wielki test wiedzy inżynierskiej (Część 2): zaawansowane pytania sprawdzające zasady skracania IPv6, mechanizmy SLAAC/NDP, filtry Wireshark oraz odpowiedzialność prawną z art. 267 KK i RODO.
Ikona pytań

Przed Państwem druga, finałowa część Wielkiego Testu Końcowego, weryfikująca wiedzę z najbardziej zaawansowanych obszarów współczesnej teleinformatyki:

Zestaw pytań egzaminacyjnych (Część 2): 1. Architektura IPv6: Skróć do postaci kanonicznej zgodnej ze standardem RFC 5952 adres: 2001:0db8:0000:0000:0001:0000:0000:0020. Wyjaśnij, dlaczego symbol :: może wystąpić tylko raz i który ciąg zer należy skompresować w przypadku remisu. 2. Autokonfiguracja SLAAC i NDP: Jakie komunikaty protokołu ICMPv6 zastępują funkcje protokołu ARP w IPv6, na jaki adres multicastowy są wysyłane zapytania o adres MAC sąsiada i jakie flagi w komunikacie Router Advertisement decydują o użyciu serwera DHCPv6? 3. Analiza pakietowa: Jaki filtr wyświetlania w programie Wireshark pozwala wyizolować wyłącznie pakiety retransmisji TCP, i czym różni się filtr wyświetlania (Display Filter) od filtru przechwytywania (Capture Filter BPF) w narzędziu tcpdump? 4. Prawo i etyka IT: Jakie znamiona przestępstwa określa art. 267 Kodeksu Karnego i jakie środki techniczne musi podjąć inżynier przed przesłaniem pliku zrzutu ruchu PCAP do zewnętrznego laboratorium, aby nie naruszyć przepisów RODO?

Prawidłowe udzielenie odpowiedzi na te pytania stanowi ostateczne potwierdzenie uzyskania kwalifikacji inżynierskich.

50/55
Odpowiedzi na dodatkowe pytania
Cel slajdu: Przedstawienie autorytatywnych, wyczerpujących rozwiązań inżynierskich do pytań testowych ze slajdu 49.

Odpowiedzi do Wielkiego Testu Końcowego – Część 2

  1. 128 bitów
  2. Mapuje IP na MAC w sieci LAN
  3. RODO – ochrona danych osobowych, adres IP to dana osobowa
  4. SYN → SYN-ACK → ACK → ESTABLISHED
Klucz rozwiązań egzaminacyjnych (Część 2): precyzyjne odpowiedzi dotyczące kanonicznego zapisu IPv6, protokołu NDP i Solicited-Node Multicast, filtrów Wireshark oraz procedur anonimizacji PCAP.
Ikona odpowiedzi

Poniżej przedstawiono autorytatywne odpowiedzi inżynieryjne na pytania z drugiej części Wielkiego Testu Końcowego:

Odpowiedź 1 (Skracanie IPv6 wg RFC 5952): - Krok 1 (usunięcie zer wiodących): 2001:db8:0:0:1:0:0:20. - Krok 2 (kompresja zer): występują dwa równe ciągi po dwa hekstety zerowe (0:0). Zgodnie z RFC 5952 w przypadku remisu symbol :: MUSI zastąpić PIERWSZY (lewy) ciąg zer. - Prawidłowa postać kanoniczna to bezwzględnie: 2001:db8::1:0:0:20. Symbol :: może wystąpić tylko raz, aby uniknąć wieloznaczności co do liczby brakujących hekstetów zerowych.

Odpowiedź 2 (NDP i SLAAC): Protokół ARP zastępują komunikaty ICMPv6 Neighbor Solicitation (NS, typ 135) oraz Neighbor Advertisement (NA, typ 136). Zapytanie NS wysyłane jest na adres grupy Solicited-Node Multicast (ff02::1:ffxx:xxxx). O trybie konfiguracji decydują flagi w komunikacie Router Advertisement: flaga M (Managed) wymusza stanowy Stateful DHCPv6, a flaga O (Other) steruje bezstanowym Stateless DHCPv6.

Odpowiedź 3 (Filtry Wireshark): Retransmisje TCP izoluje filtr tcp.analysis.retransmission. Capture Filter (BPF) odrzuca pakiety w jądrze przed zapisaniem do bufora (oszczędza zasoby, nieodwracalny); Display Filter działa w przestrzeni użytkownika na już przechwyconych pakietach, ukrywając widok na ekranie bez utraty danych.

Odpowiedź 4 (Prawo i RODO): Art. 267 KK penalizuje nieuprawnione uzyskanie informacji przez podłączenie się do sieci lub posługiwanie się oprogramowaniem podsłuchowym (sniffer w obcej sieci). Zgodnie z RODO (wyrok TSUE C-582/14) adresy IP to dane osobowe – inżynier ma obowiązek zanonimizować zrzut (narzędzie tcprewrite, wycięcie ładunku snaplen 96) oraz zaszyfrować plik algorytmem AES-256 (GnuPG).

51/55
Powtórka wszystkich narzędzi sieciowych
Cel slajdu: Przedstawienie ostatecznej checklisty kompetencji narzędziowych, które student powinien posiadać w swoim podręcznym warsztacie po ukończeniu kursu.

Checklista narzędziowa profesjonalnego inżyniera sieciowego

  • ping, traceroute, pathping (tylko Windows)
  • ipconfig, ip (ifconfig przestarzały)
  • ss (netstat przestarzały), arp, route
  • nslookup, dig
  • Wireshark, tshark, tcpdump
  • iperf3, hping3, packeth
  • ethtool, iw, iwconfig
  • airodump-ng, Kismet
Checklista warsztatowa: zestawienie 15 kluczowych poleceń i aplikacji diagnostycznych wraz z weryfikacją opanowania ich składni i interpretacji.
Kolaż ikon narzędzi

Przed wejściem na rynek pracy lub przystąpieniem do egzaminu inżynierskiego każdy absolwent kursu PiDSK powinien zweryfikować swój warsztat techniczny według poniższej checklisty kompetencji operacyjnych:

Checklista inżynierska PiDSK: - [x] Potrafię wykonać test osiągalności ping z wymuszeniem zakazu fragmentacji (DF=1) i wyznaczyć MTU ścieżki. - [x] Potrafię odczytać i zinterpretować pełną tablicę routingu jądra (ip route show / route print) oraz wyznaczyć trasę LPM. - [x] Potrafię odnaleźć adres MAC bramy domyślnej w pamięci podręcznej ARP (ip neigh / arp -a) i zweryfikować OUI producenta.

- [x] Potrafię zweryfikować stan fizyczny łącza, wynegocjowaną prędkość i dupleks za pomocą ethtool. - [x] Potrafię przeprowadzić test maksymalnej przepustowości Goodput narzędziem iperf3 w protokołach TCP i UDP. - [x] Potrafię przechwycić ruch konsolowym snifferem tcpdump z filtrami BPF i zapisać zrzut do pliku PCAP. - [x] Potrafię załadować plik do programu Wireshark, zastosować filtry wyświetlania i zrekonstruować strumień Follow TCP Stream. - [x] Potrafię zweryfikować stan gniazd sieciowych, portów nasłuchujących LISTEN i procesów PID poleceniem ss -tulpn. - [x] Potrafię zdiagnozować strefę DNS za pomocą narzędzi nslookup i dig +trace. - [x] Potrafię zanonimizować plik PCAP narzędziem tcprewrite oraz zaszyfrować zrzut kluczem AES-256 w GnuPG.

Opanowanie powyższych umiejętności stawia Państwa w gronie wykwalifikowanych specjalistów gotowych do pracy w nowoczesnych centrach operacji sieciowych (NOC/SOC).

52/55
Ścieżka rozwoju po cyklu
Cel slajdu: Przedstawienie mapy certyfikacji przemysłowych i ścieżek rozwoju zawodowego wiodących producentów i organizacji normalizacyjnych.

Ścieżki certyfikacji i kariery zawodowej w branży IT

  • Cykl logiczny (p2): Szczegółowa analiza protokołów, Wireshark zaawansowany, tcpdump, tshark, filtry, statystyki
  • Cykl fizyczny (p3): Pomiary tłumienia, OTDR, analizatory widma, mierniki mocy
  • Certyfikacje: CCNA, Network+, Wireshark Certified Analyst
Mapa certyfikacji inżynierskich: ustrukturyzowana ścieżka rozwoju zawodowego: od certyfikatów entry-level (CompTIA Network+, CCNA), przez specjalistyczne (CCNP, LPIC-2, OSCP), po eksperckie (CCIE, CISSP).
Zapowiedź cyklu logicznego i fizycznego

Wiedza zdobyta podczas dwunastu części kursu „Podstawy i Diagnostyka Sieci Komputerowych” stanowi bezpośrednie przygotowanie teoretyczne i praktyczne do zdobycia najbardziej prestiżowych certyfikatów przemysłowych, które są przepustką do dynamicznej kariery w międzynarodowych korporacjach i firmach integratorskich.

Przegląd rekomendowanych ścieżek certyfikacyjnych: 1. Ścieżka sieciowa Cisco Systems: - Cisco Certified Network Associate (CCNA 200-301): najbardziej poszukiwany certyfikat na rynku pracy; kurs PiDSK pokrywa ponad 80% wymagań egzaminacyjnych w zakresie IPv4, IPv6, Ethernetu, Wi-Fi, routingu i bezpieczeństwa. - Cisco Certified Network Professional (CCNP Enterprise): zaawansowany poziom obejmujący routing BGP/OSPF, sieci SD-Access i automatyzację w języku Python. - CCIE (Cisco Certified Internetwork Expert): elita inżynierii sieciowej na świecie.

2. Ścieżka neutralna producentowo (Vendor-Neutral): - CompTIA Network+ oraz CompTIA Security+: certyfikaty potwierdzające wszechstronną, standaryzowaną wiedzę inżynierską zgodnie z normami ISO/ANSI. - Wireshark Certified Network Analyst (WCNA): elitarna certyfikacja weryfikująca mistrzowskie posługiwanie się analizatorem Wireshark w diagnostyce i informatyce śledczej. 3. Ścieżka systemowa i chmurowa: - LPIC-1 / LPIC-2 (Linux Professional Institute): certyfikacja administracji systemami Linux i pakietem iproute2, - Certyfikacje chmurowe AWS Certified Advanced Networking - Specialty oraz Microsoft Azure Network Engineer Associate.

53/55
Złote zasady pomiarów sieciowych
Cel slajdu: Podsumowanie zasad etosu zawodowego, rzetelności naukowej i odpowiedzialności społecznej inżyniera teleinformatyki.

Kanon profesjonalnego inżyniera sieciowego

  1. Planuj pomiar – cel, narzędzie, czas
  2. Wykonaj baseline (wartość referencyjna)
  3. Mierz wielokrotnie – statystyka daje prawdę
  4. Interpretuj wyniki w kontekście topologii
  5. Dokumentuj i raportuj
  6. Bądź etyczny i zgodny z prawem
Etos inżyniera PiDSK: zbiór nadrzędnych zasad zawodowych: 'Nigdy nie zgaduj – zmierz', poszanowanie prywatności użytkowników, ciągłe doskonalenie i dbałość o odporność infrastruktury cyfrowej.
6 złotych zasad

Zbliżając się do finału całego cyklu kształcenia, warto zdefiniować nadrzędne przesłanie etosu inżynierskiego, które powinno przewodzić każdemu z Państwa w codziennej praktyce zawodowej:

Kanon inżyniera sieciowego PiDSK: - „Nigdy nie zgaduj – ZMIERZ!”: Najczęstszą przyczyną katastrofalnych awarii jest opieranie się na niesprawdzonych założeniach. Prawdziwy inżynier weryfikuje każdą hipotezę za pomocą obiektywnych pomiarów, analizatorów pakietów i weryfikacji logów. - „Prostota jest szczytem wyrafinowania”: Dobrze zaprojektowana sieć jest prosta, modułowa, łatwa w zarządzaniu i oparta na otwartych standardach IETF/IEEE. Unikaj zbędnego komplikowania topologii i stosowania niestandardowych, zamkniętych protokołów.

- „Prywatność jest dobrem najwyższym”: Posiadane uprawnienia administracyjne traktuj jako zobowiązanie do ochrony danych innych ludzi. Zaufanie użytkowników jest najcenniejszym kapitałem w gospodarce cyfrowej. - „Ucz się przez całe życie (Lifelong Learning)”: Teleinformatyka zmienia się nieustannie. Opanowanie fundamentów, które poznali Państwo w tym kursie, daje niezmienną bazę, na której przez dekady będą Państwo budować kompetencje w nowo powstających technologiach.

- „Dziel się wiedzą i wspieraj społeczność”: Ruch wolnego oprogramowania (Open Source), standaryzacja IETF RFC oraz społeczności inżynierskie ukształtowały dzisiejszy Internet. Dzielenie się doświadczeniem z młodszymi adeptami teleinformatyki i aktywny udział w forach technicznych to spłata długu wdzięczności wobec pionierów sieci.

54/55
Pytania do końcowej dyskusji
Cel slajdu: Podsumowująca dyskusja nad miejscem człowieka-inżyniera w zautomatyzowanym świecie sieci autonomicznych i sztucznej inteligencji.

Seminarium finałowe: Sieci przyszłości w dobie sztucznej inteligencji

  1. Jakie narzędzie jest twoim zdaniem najważniejsze dla administratora sieci?
  2. Jak odróżnić problem sieciowy od problemu aplikacji?
  3. Czy AI może zastąpić administratora w diagnostyce sieci?
Finałowa debata seminaryjna: refleksja nad transformacją roli administratora sieci w erze automatyzacji Intent-Based Networking (IBN), uczenia maszynowego i infrastruktury programowalnej.
Ikona dyskusji

Na zakończenie wspólnej podróży przez dwanaście modułów kursu zatrzymajmy się na chwilę refleksji nad przyszłością naszego zawodu. Żyjemy w epoce przełomowej transformacji cyfrowej, w której sieci komputerowe przestają być statycznymi konfiguracjami przełączników, a stają się dynamicznymi, programowalnymi organizmami.

Tematy do dyskusji finałowej: 1. Sieci oparte na intencji (Intent-Based Networking - IBN): W nowoczesnych architekturach inżynier nie konfiguruje już poszczególnych portów na przełącznikach; zamiast tego deklaruje intencję biznesową w systemie centralnym (np. 'Wszystkie stacje księgowości mają mieć bezpieczny dostęp do bazy danych, a goście wyłącznie do Internetu'), a kontroler sieciowy automatycznie generuje i wdraża konfigurację w całej sieci. Jak zmienia to rolę inżyniera sieciowego?

2. Programowalność i automatyzacja vs rzemiosło CLI: Czy era ręcznego wpisywania poleceń w konsoli CLI dobiega końca na rzecz skryptów w języku Python, bibliotek Netmiko/NAPALM oraz deklaratywnych szablonów Ansible i Terraform? Dlaczego dogłębne zrozumienie działania protokołów L2–L4 pozostaje bezwzględnie konieczne nawet przy pełnej automatyzacji? 3. Odpowiedzialność inżyniera: Kto ponosi odpowiedzialność, gdy zautomatyzowany algorytm odetnie łączność z oddziałem ratunkowym szpitala? Dlaczego czynnik ludzki, wiedza inżynierska i etyka pozostaną niezastąpione?

55/55
Zakończenie cyklu wprowadzającego
Cel slajdu: Uroczyste podsumowanie i oficjalne zwieńczenie całego kursu „Podstawy i Diagnostyka Sieci Komputerowych”.

Koniec cyklu wprowadzającego PiDSK – Wielki Finał

Dziękujemy za udział w cyklu „Pomiary i diagnostyka sieci komputerowych – wprowadzenie".

W kolejnych cyklach zgłębimy pomiary logiczne (p2) i fizyczne (p3).

Powodzenia w dalszej nauce!

Zakończenie cyklu dydaktycznego PiDSK: podsumowanie 12 modułów kształcenia inżynierskiego, gratulacje dla studentów oraz formalne otwarcie drogi do zaawansowanych laboratoriów projektowych i certyfikacji branżowych.
Dyplom – symbol ukończenia cyklu

Szanowni Państwo! Z ogromną dumą i satysfakcją ogłaszamy oficjalne zakończenie pełnego cyklu dwunastu modułów kursu „Podstawy i Diagnostyka Sieci Komputerowych” (PiDSK). Wykonali Państwo gigantyczną pracę inżynierską, opanowując materiał stanowiący kręgosłup współczesnej teleinformatyki.

Podsumowanie przebytej drogi dydaktycznej: Przeszli Państwo drogę od elementarnych pojęć przepustowości i fizyki fal radiowych, przez rygorystyczne modele warstwowe ISO/OSI i TCP/IP, pełną mechanikę protokołów Ethernet, ARP, ICMP, TCP, UDP i DNS, matematyczny kunszt adresacji IPv4 i IPv6, aż po profesjonalny warsztat narzędziowy CLI, analizatory Wireshark i tcpdump oraz świadomość prawną i etyczną.

Wiedza, którą Państwo posiedli, nie jest jedynie teorią akademicką; to żywe, praktyczne rzemiosło inżynierskie, które decyduje o bezpieczeństwie i sprawności globalnego społeczeństwa informacyjnego. Niezależnie od tego, czy Państwa dalsza droga zawodowa poprowadzi w kierunku architektury chmurowej, cyberbezpieczeństwa, programowania systemowego czy zarządzania sieciami operatorskimi, fundamenty PiDSK pozostaną trwałym, niezawodnym kompasem.

Dziękuję za Państwa pasję, dociekliwość naukową i setki godzin spędzonych w terminalach i laboratoriach. Życzę spektakularnych sukcesów w karierze zawodowej i na egzaminach certyfikacyjnych. Do zobaczenia na szlakach teleinformatycznych!