IT ogólnie

Wszystkie tematy związane z IT :)

Model AAA – Rozliczanie (część 1)

Napisane przez Igor Brzeżek on 23 października 2025
Napisane w: Model AAA.

Contents
  1. AAA: Rozliczanie (Accounting)
  2. Dlaczego Rozliczanie jest tak kluczowe? Główne cele
  3. Anatomia logu: Co tak naprawdę zapisujemy?
  4. Wyzwania i dobre praktyki: Syslog, NTP i Centralizacja
  5. Problem: Logi lokalne są bezużyteczne w razie włamania
  6. Rozwiązanie: Centralny serwer logów (Syslog)
  7. Problem: Niespójny czas uniemożliwia korelację zdarzeń
  8. Rozwiązanie: Synchronizacja czasu (NTP)
  9. Koncepcje Rozliczania w Cisco, Linux i RouterOS
  10. Podsumowanie

AAA: Rozliczanie (Accounting)

Dotarliśmy do ostatniego etapu naszej podróży po fundamentalnym modelu bezpieczeństwa AAA. W poprzednich częściach nauczyliśmy się weryfikować tożsamość za pomocą Uwierzytelniania („Kim jesteś?”) oraz nadawać uprawnienia dzięki Autoryzacji („Co wolno Ci zrobić?”). Ale co, jeśli coś pójdzie nie tak? Skąd będziemy wiedzieć, kto i kiedy dokonał krytycznej zmiany w konfiguracji firewalla tuż przed awarią? Jak udowodnić audytorowi, że nasze polityki bezpieczeństwa działają? Odpowiedzi na te pytania dostarcza trzeci filar: Rozliczanie (Accounting).

Rozliczanie, często nazywane również Audytem (Auditing), odpowiada na kluczowe pytanie: „Co zrobiłeś?”. To proces systematycznego zbierania, rejestrowania i analizowania zdarzeń w systemie. Jeśli Uwierzytelnianie jest strażnikiem przy bramie, a Autoryzacja systemem kart dostępu, to Rozliczanie jest wszechobecną siecią kamer przemysłowych i skrupulatnie prowadzoną księgą gości. Bez niego działamy po omacku, niezdolni do wyciągania wniosków z przeszłości i reagowania na incydenty.

Dlaczego Rozliczanie jest tak kluczowe? Główne cele

Skuteczny system rozliczania to znacznie więcej niż tylko zbieranie logów „na wszelki wypadek”. To aktywne narzędzie, które służy wielu krytycznym celom w każdej organizacji:

  • Analiza powłamaniowa (Forensics): To podstawowy cel. Gdy dojdzie do incydentu bezpieczeństwa, logi są cyfrowymi śladami, które pozwalają odtworzyć przebieg ataku: jak włamywacz dostał się do systemu, jakie komendy wykonał, jakie dane wykradł i jakie ślady po sobie zostawił.
  • Wykrywanie incydentów: Analiza logów w czasie rzeczywistym przez systemy takie jak SIEM (Security Information and Event Management) pozwala na wykrywanie anomalii i wzorców wskazujących na trwający atak, np. setki nieudanych prób logowania z jednego adresu IP.
  • Zgodność z regulacjami (Compliance): Wiele regulacji prawnych i standardów branżowych (np. RODO/GDPR, PCI-DSS, ISO 27001) wprost wymaga posiadania i przechowywania szczegółowych dzienników zdarzeń jako dowodu na stosowanie odpowiednich kontroli bezpieczeństwa.
  • Rozwiązywanie problemów (Troubleshooting): Kiedy usługa przestaje działać, często to właśnie logi pozwalają zdiagnozować problem. Pokazują błędy aplikacji, zmiany w konfiguracji czy problemy sprzętowe, które doprowadziły do awarii.
  • Planowanie i rozliczanie zasobów: W środowiskach komercyjnych logi pozwalają śledzić zużycie zasobów (czasu CPU, transferu danych, liczby zapytań API) w celu naliczania opłat klientom lub planowania rozbudowy infrastruktury.
+---------------------+
| Zdarzenie w systemie|
| (np. login admina)  |
+---------------------+
           |
           V
+---------------------+      +-----------------------------+
|    Mechanizm        |      |      Analiza i Reakcja      |
|    logowania        |      |-----------------------------|
| (Accounting)        |----->| - Wykrywanie włamań (SIEM)  |
+---------------------+      | - Analiza po fakcie         |
                             | - Raporty dla audytora      |
                             | - Diagnoza awarii           |
                             +-----------------------------+

Anatomia logu: Co tak naprawdę zapisujemy?

Aby logi były użyteczne, muszą zawierać odpowiedni zestaw informacji. Dobry wpis w dzienniku zdarzeń powinien odpowiadać na kilka podstawowych pytań, które można podsumować jako „5W” (lub więcej):

  • Kto (Who): Identyfikator podmiotu, który wykonał akcję. Najczęściej jest to nazwa użytkownika (`admin`, `jkowalski`), ale może to być też nazwa procesu systemowego (`cron`) lub usługa.
  • Co (What): Opis wykonanej czynności. Może to być nazwa wykonanego polecenia (`configure terminal`), typ zdarzenia (`successful login`, `failed password`) lub zasób, do którego uzyskano dostęp (`/etc/shadow`).
  • Kiedy (When): Precyzyjny znacznik czasu (timestamp) wystąpienia zdarzenia. Bez tego logi są niemal bezużyteczne.
  • Gdzie (Where): Kontekst źródłowy zdarzenia. Zazwyczaj jest to adres IP, z którego przyszło połączenie, nazwa hosta, czy terminal, na którym pracował użytkownik (`tty1`, `pts/0`).
  • Jak (How): Wynik operacji – czy zakończyła się sukcesem, czy porażką. Jest to kluczowe dla wykrywania np. prób odgadnięcia hasła.

Przykład wpisu z logu SSH w systemie Linux:

Oct 16 21:15:30 server01 sshd[2150]: Failed password for invalid user hacker from 203.0.113.55 port 48212 ssh2
  • Kiedy: Oct 16 21:15:30
  • Gdzie (Host logujący): server01
  • Kto (Proces): sshd[2150]
  • Co: Nieudana próba logowania hasłem
  • Kto (Próbujący): Nieistniejący użytkownik ‚hacker’
  • Gdzie (Źródło): IP 203.0.113.55, port 48212
  • Jak: Porażka

Wyzwania i dobre praktyki: Syslog, NTP i Centralizacja

Samo włączenie logowania na urządzeniu to dopiero początek. Aby system audytu był skuteczny i odporny na manipulacje, musimy sprostać kilku wyzwaniom.

Problem: Logi lokalne są bezużyteczne w razie włamania

Pierwszą rzeczą, jaką zrobi doświadczony atakujący po uzyskaniu dostępu do systemu, jest zatarcie swoich śladów. Oznacza to usunięcie lub zmodyfikowanie lokalnych plików z logami. Co więcej, jeśli urządzenie ulegnie awarii, wszystkie logi przechowywane w jego pamięci RAM przepadną na zawsze.

Rozwiązanie: Centralny serwer logów (Syslog)

Standardowym rozwiązaniem tego problemu jest centralizacja logów. Wszystkie urządzenia w sieci (routery, przełączniki, serwery, firewalle) są konfigurowane tak, aby wysyłały kopie swoich logów w czasie rzeczywistym na jeden, dedykowany i specjalnie zabezpieczony serwer. Najczęściej używanym do tego protokołem jest Syslog.

+--------------+
| Serwer Linux | --
+--------------+   \
                    \
+--------------+    /`
| Router Cisco | --+----[ Logi Syslog (UDP/514) ]---> +---------------------+
+--------------+   \                                  | Centralny Serwer    |
                    /`                                | Logów (Syslog/SIEM) |
+--------------+   /                                  | (Bezpieczna Strefa) |
| MikroTik     | --                                   +---------------------+
+--------------+

Centralny serwer logów jest maszyną o zaostrzonych rygorach bezpieczeństwa. Dostęp do niego jest ściśle ograniczony, a same logi są często archiwizowane w niezmienialnej formie (np. na nośnikach WORM – Write Once Read Many), aby zapewnić ich integralność na potrzeby dowodowe.

Problem: Niespójny czas uniemożliwia korelację zdarzeń

Wyobraź sobie, że analizujesz atak, który przeszedł przez firewall, serwer WWW i bazę danych. Log z firewalla mówi, że podejrzany ruch miał miejsce o 21:05:10. Log z serwera WWW pokazuje włamanie o 21:07:30, a z bazy danych wyciek danych o 21:04:00. Chronologia jest zaburzona, bo zegary na urządzeniach nie były zsynchronizowane. Analiza staje się koszmarem.

Rozwiązanie: Synchronizacja czasu (NTP)

Absolutną koniecznością w każdej sieci jest wdrożenie protokołu NTP (Network Time Protocol). Wszystkie urządzenia muszą synchronizować swoje zegary z jednym, wiarygodnym źródłem czasu. Dzięki temu znaczniki czasu we wszystkich logach w całej infrastrukturze są spójne, co pozwala na precyzyjną korelację zdarzeń minuta po minucie, sekunda po sekundzie.

+---------------------+
| Serwer Czasu NTP    |
| (np. z puli publicznej)|
+---------------------+
      ^     ^     ^
      |     |     | [Synchronizacja czasu]
      |     |     |
+-----+-----+-----+-----+
| Firewall    | Serwer WWW    | Baza Danych |
+-------------+---------------+-------------+
      |             |               |
      V             V               V
    [Log z poprawnym czasem] [Log z ... ] [Log z ... ]

Koncepcje Rozliczania w Cisco, Linux i RouterOS

Chociaż cel jest ten sam, każde środowisko ma swoją specyfikę logowania:

  • W Cisco IOS kluczowe jest operowanie na poziomach ważności (severity levels 0-7), które pozwalają filtrować „szum informacyjny” i logować tylko to, co istotne. Unikalną cechą jest możliwość integracji z serwerami TACACS+, które potrafią logować każdą pojedynczą komendę wpisaną przez administratora.
  • W Linux mamy do czynienia z tradycyjnymi plikami tekstowymi w /var/log oraz nowszym, ustrukturyzowanym dziennikiem systemd-journald. Dodatkowo potężne narzędzie auditd pozwala na tworzenie bardzo szczegółowych reguł audytu, np. „loguj każdą próbę odczytu pliku /etc/secret.conf”.
  • W RouterOS logowanie opiera się na elastycznym systemie tematów (topics) i akcji (actions). Możemy bardzo granularnie zdecydować, że np. logi z firewalla (temat) mają być wysyłane na zdalny serwer (akcja), a błędy krytyczne (inny temat) zapisywane lokalnie na dysku (inna akcja).

Podsumowanie

Rozliczanie (Accounting) to cichy bohater modelu AAA. Może nie blokuje ataków w czasie rzeczywistym jak Uwierzytelnianie i Autoryzacja, ale jest naszą cyfrową pamięcią i systemem wczesnego ostrzegania. Zapewnia odpowiedzialność (wiemy, kto co zrobił), widoczność (rozumiemy, co się dzieje w naszej sieci) i zdolność do reakcji (mamy dane, by przeanalizować incydent). Prawidłowo wdrożony system audytu, oparty na centralizacji logów i synchronizacji czasu, jest oznaką dojrzałości każdej organizacji dbającej o bezpieczeństwo.

W ostatnim artykule z tej serii przejdziemy do praktyki: skonfigurujemy centralny serwer Syslog na Linuksie i nauczymy nasze urządzenia Cisco i MikroTik, jak posłusznie raportować mu o każdym swoim kroku.

Model AAA – Rozliczanie (część 2)

Napisane przez Igor Brzeżek on 23 października 2025
Napisane w: Model AAA.

Contents
  1. AAA: Rozliczanie w Praktyce – Centralne Logowanie
  2. Część 1: Budowa fundamentu – Centralny Serwer Syslog na Linux
  3. Krok 1: Instalacja i podstawowa konfiguracja `rsyslog`
  4. Krok 2: Automatyczna segregacja logów
  5. Krok 3: Finalizacja konfiguracji serwera
  6. Część 2: Konfiguracja urządzenia Cisco IOS
  7. Krok 1: Synchronizacja czasu (NTP) – Krok zerowy!
  8. Krok 2: Konfiguracja wysyłania logów Syslog
  9. Krok 3 (Zaawansowany): Rozliczanie każdej komendy z TACACS+
  10. Część 3: Konfiguracja urządzenia MikroTik RouterOS
  11. Krok 1: Synchronizacja czasu (NTP)
  12. Krok 2: Definiowanie zdalnej akcji Syslog
  13. Krok 3: Tworzenie reguł logowania
  14. Krok 4: Konfiguracja Firewalla do logowania
  15. Część 4: Analiza zebranych logów
  16. Podsumowanie Serii

AAA: Rozliczanie w Praktyce – Centralne Logowanie

Witaj w wielkim finale naszej serii o modelu AAA! W poprzednim artykule teoretycznym zrozumieliśmy, dlaczego Rozliczanie (Accounting) jest cyfrową pamięcią naszej infrastruktury, która odpowiada na kluczowe pytanie: „Co się wydarzyło?”. Dzisiaj zamieniamy tę wiedzę w działający, solidny system. Zbudujemy od podstaw centralny serwer logów na Linuksie, a następnie nauczymy nasze urządzenia sieciowe Cisco i MikroTik, jak posłusznie meldować mu o każdym swoim działaniu.

Ten artykuł to czysta esencja praktyki. Przejdziemy przez każdy krok instalacji i konfiguracji, od synchronizacji czasu po filtrowanie i analizę logów. Po ukończeniu tego tutorialu będziesz posiadać fundament pod profesjonalny system monitoringu i audytu, który jest absolutnie niezbędny do zapewnienia widoczności i odpowiedzialności w każdej sieci. Zakaszmy rękawy, bo czeka nas sporo konkretnej, technicznej pracy!

Część 1: Budowa fundamentu – Centralny Serwer Syslog na Linux

Naszym celem jest stworzenie jednego, bezpiecznego miejsca, do którego będą spływać logi ze wszystkich urządzeń. Użyjemy do tego demona rsyslog, który jest standardem w większości dystrybucji Linuksa (np. Debian, Ubuntu, CentOS).

Krok 1: Instalacja i podstawowa konfiguracja `rsyslog`

Zakładamy, że masz świeżo zainstalowany serwer Linux (np. Ubuntu Server 22.04). `rsyslog` jest zazwyczaj preinstalowany. Jeśli nie, instalacja jest prosta:

# sudo apt update && sudo apt install rsyslog

Teraz musimy skonfigurować rsyslog, aby nasłuchiwał na logi przychodzące z sieci. Edytujemy główny plik konfiguracyjny:

# sudo nano /etc/rsyslog.conf

Znajdź i odkomentuj (usuń znak `#` na początku) następujące linie, aby włączyć nasłuchiwanie na porcie 514 dla protokołów UDP i TCP.

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

UDP czy TCP? UDP jest szybszy i mniej obciąża zasoby (fire-and-forget), ale nie gwarantuje dostarczenia logów. TCP jest niezawodne (potwierdza dostarczenie), ale generuje większy narzut. Na początek i dla większości zastosowań UDP jest wystarczające. Włączenie obu opcji daje nam elastyczność.

Krok 2: Automatyczna segregacja logów

Nie chcemy, aby logi ze wszystkich urządzeń mieszały się w jednym wielkim pliku. Skonfigurujemy `rsyslog`, aby automatycznie tworzył osobne pliki dla każdego urządzenia na podstawie jego nazwy hosta lub adresu IP. Dodaj poniższy szablon na początku pliku /etc/rsyslog.conf, zaraz po sekcji modułów.

# Szablon do segregacji logów z urządzeń zdalnych
$template RemoteLogs,"/var/log/remotelogs/%HOSTNAME%.log"
*.* ?RemoteLogs
& ~
  • $template RemoteLogs,...: Definiuje szablon o nazwie „RemoteLogs”, który jako ścieżkę pliku wykorzystuje katalog /var/log/remotelogs/ i dynamicznie wstawia nazwę hosta urządzenia wysyłającego log (%HOSTNAME%).
  • *.* ?RemoteLogs: Ta reguła mówi: „Wszystkie logi (`*.*`) z urządzeń zdalnych przekieruj do szablonu `RemoteLogs`”.
  • & ~: To bardzo ważna linia! Oznacza ona „zatrzymaj przetwarzanie tej wiadomości tutaj”. Bez tego, logi trafiłyby zarówno do naszego nowego pliku, jak i do domyślnych plików systemowych (np. /var/log/syslog), powodując duplikację.

Krok 3: Finalizacja konfiguracji serwera

Musimy jeszcze stworzyć katalog na logi i otworzyć port w firewallu.

# sudo mkdir /var/log/remotelogs
# sudo chown syslog:adm /var/log/remotelogs
# sudo ufw allow 514/udp
# sudo ufw allow 514/tcp
# sudo systemctl restart rsyslog

Nasz serwer jest gotowy! Możemy śledzić, co się dzieje, za pomocą polecenia:

# sudo tail -f /var/log/remotelogs/*

Na razie nic się nie pojawi, ale okno z tym poleceniem zostawiamy otwarte. Będziemy obserwować, jak spływają do niego logi z naszych urządzeń.

Część 2: Konfiguracja urządzenia Cisco IOS

Teraz nauczymy nasz router Cisco, jak ma się meldować na serwerze. Zakładamy, że serwer Syslog ma adres IP 192.168.1.100.

Krok 1: Synchronizacja czasu (NTP) – Krok zerowy!

Jak wspominaliśmy w teorii, bez spójnego czasu analiza logów jest niemożliwa. To absolutna podstawa.

Router# configure terminal
Router(config)# ! Używamy publicznego serwera czasu w Polsce
Router(config)# ntp server pl.pool.ntp.org
Router(config)# ! Ustawiamy strefę czasową
Router(config)# clock timezone CET 1
Router(config)# clock summer-time CEST recurring

Krok 2: Konfiguracja wysyłania logów Syslog

To serce konfiguracji. Wskazujemy routerowi, gdzie ma wysyłać logi i jak bardzo ma być „gadatliwy”.

Router(config)# ! Wskazujemy adres naszego serwera
Router(config)# logging host 192.168.1.100
Router(config)# ! Ustawiamy poziom logowania. 'informational' (6) to dobry kompromis.
Router(config)# ! Poziomy: 0-Emergencies, 1-Alerts, 2-Critical, 3-Errors, 4-Warnings, 5-Notifications, 6-Informational, 7-Debugging
Router(config)# logging trap informational
Router(config)# ! Upewniamy się, że logi zawsze mają ten sam adres IP źródłowy (np. interfejsu LAN)
Router(config)# logging source-interface GigabitEthernet0/0
Router(config)# ! Dodajemy znaczniki czasu do logów
Router(config)# service timestamps log datetime msec
Router(config)# end
Router# write memory

W tym momencie w oknie konsoli serwera Syslog powinieneś zobaczyć pierwsze logi napływające z routera Cisco, zapisywane do pliku o nazwie hosta Twojego routera!

Krok 3 (Zaawansowany): Rozliczanie każdej komendy z TACACS+

Uwaga: Poniższy przykład ma charakter poglądowy. Wymaga on działającego serwera TACACS+ (innego niż Syslog), ale doskonale ilustruje potęgę mechanizmów rozliczania.

Protokół TACACS+ pozwala na audyt każdej pojedynczej komendy wykonanej przez administratora. To najwyższy poziom odpowiedzialności.

Router(config)# ! Najpierw definiujemy serwer TACACS+
Router(config)# tacacs server MOJ_TACACS
Router(config-server-tacacs)# address ipv4 192.168.1.101
Router(config-server-tacacs)# key SekretDoTacacs
Router(config)# exit
Router(config)# ! Włączamy model AAA
Router(config)# aaa new-model
Router(config)# ! Włączamy rozliczanie dla wszystkich komend na poziomie 15
Router(config)# aaa accounting commands 15 default start-stop group MOJ_TACACS

Od teraz, każde polecenie wpisane w trybie `enable` (np. `show running-config`, `reload`) zostanie odnotowane na serwerze TACACS+ wraz z informacją o użytkowniku i dokładnym czasem.

Część 3: Konfiguracja urządzenia MikroTik RouterOS

RouterOS oferuje bardzo elastyczny system logowania oparty na tematach i akcjach. Skonfigurujemy go tak, aby wysyłał logi o bezpieczeństwie i firewallu na nasz serwer.

Krok 1: Synchronizacja czasu (NTP)

Podobnie jak w Cisco, zaczynamy od zegara.

[admin@MikroTik] > /system ntp client set enabled=yes primary-ntp=212.2.4.2 secondary-ntp=194.146.251.100
# Używamy polskich serwerów czasu
[admin@MikroTik] > /system clock set time-zone-name=Europe/Warsaw

Krok 2: Definiowanie zdalnej akcji Syslog

Tworzymy „cel”, do którego będziemy wysyłać nasze logi.

[admin@MikroTik] > /system logging action add name=send_to_syslog target=remote remote=192.168.1.100

Krok 3: Tworzenie reguł logowania

Teraz decydujemy, które „tematy” wiadomości mają trafić do naszej zdalnej akcji. To potęga RouterOS – możemy wysyłać różne logi w różne miejsca.

[admin@MikroTik] > # Reguła 1: Wysyłaj wszystkie ważne komunikaty systemowe (błędy, ostrzeżenia)
[admin@MikroTik] > /system logging add topics=critical,error,warning action=send_to_syslog
[admin@MikroTik] > # Reguła 2: Wysyłaj informacje o logowaniu i wylogowaniu użytkowników
[admin@MikroTik] > /system logging add topics=account action=send_to_syslog
[admin@MikroTik] > # Reguła 3: Wysyłaj informacje z firewalla
[admin@MikroTik] > /system logging add topics=firewall action=send_to_syslog

Krok 4: Konfiguracja Firewalla do logowania

Aby temat `firewall` generował jakiekolwiek logi, musimy włączyć logowanie w konkretnych regułach. Stwórzmy regułę, która będzie logować wszystkie próby połączenia z zewnątrz na porcie SSH (22) naszego routera.

[admin@MikroTik] > /ip firewall filter add chain=input protocol=tcp dst-port=22 connection-state=new \
action=add-src-to-address-list address-list="SSH Scanners" address-list-timeout=1d \
log=yes log-prefix="SSH_ATTACK_ATTEMPT"
[admin@MikroTik] > /ip firewall filter add chain=input connection-state=new src-address-list="SSH Scanners" action=drop

Od teraz każda nowa próba połączenia SSH z internetu zostanie zapisana w logu z prefiksem „SSH_ATTACK_ATTEMPT”, a następnie log ten zostanie wysłany na nasz serwer Syslog!

Część 4: Analiza zebranych logów

Wracamy do konsoli naszego serwera Syslog. Po chwili w katalogu /var/log/remotelogs/ powinny pojawić się dwa nowe pliki (lub więcej, jeśli dodałeś inne urządzenia), np. CiscoRouter.log i MikroTik.log.

Możemy teraz obserwować napływające dane i wyszukiwać interesujące nas zdarzenia.

# tail -f /var/log/remotelogs/CiscoRouter.log
Oct 16 22:10:15 CiscoRouter %SYS-5-CONFIG_I: Configured from console by admin on vty0 (192.168.1.50)

# tail -f /var/log/remotelogs/MikroTik.log
Oct 16 22:12:30 MikroTik firewall,info input: in:ether1 out:(none), proto TCP (SYN), 203.0.113.88:54321->192.168.88.1:22, len 52

# grep "Failed" /var/log/remotelogs/CiscoRouter.log
Oct 16 22:15:01 CiscoRouter %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: root] [Source: 10.1.1.1]

Mamy to! Działający, centralny system zbierania logów, który daje nam bezcenny wgląd w to, co dzieje się w naszej sieci. To fundament, który można dalej rozbudowywać, np. integrując go z systemami SIEM (ELK/OpenSearch, Splunk, Graylog) do automatycznej korelacji zdarzeń, analizy i alarmowania.

Podsumowanie Serii

Dotarliśmy do końca naszej podróży przez świat Authentication, Authorization i Accounting. Zaczęliśmy od teorii, a skończyliśmy na działającej, praktycznej implementacji, która jest kręgosłupem bezpieczeństwa każdej profesjonalnej sieci.

  • Uwierzytelnianie pozwoliło nam pewnie odpowiedzieć na pytanie „Kim jesteś?”.
  • Autoryzacja dała nam narzędzia do precyzyjnego zarządzania odpowiedzią na pytanie „Co Ci wolno?”.
  • Rozliczanie, które właśnie wdrożyliśmy, zapewnia nam trwały zapis odpowiedzi na pytanie „Co zrobiłeś?”.

Te trzy filary, działając razem, tworzą solidną, wielowarstwową obronę. Zapewniają kontrolę, widoczność i odpowiedzialność – trzy cechy, bez których niemożliwe jest zbudowanie bezpiecznej i zarządzalnej infrastruktury IT. Mam nadzieję, że ta seria artykułów była dla Ciebie wartościowym i praktycznym przewodnikiem. Dziękuję za wspólną podróż!

Anatomia ramki Ethernet i kwestia MTU

Napisane przez Igor Brzeżek on 21 października 2025
Napisane w: Pomiary w sieciach LAN.

Contents
  1. Budowa ramki Ethernet 802.3 (MAC)
  2. Warianty ramki i rola IEEE 802.2 (LLC)
  3. Serce ładunku – MTU (Maximum Transmission Unit)
  4. MTU, fragmentacja i narzut administracyjny
  5. Problem Fragmentacji
  6. Obliczanie narzutu administracyjnego
  7. Analiza Tabeli
  8. Konfiguracja MTU w praktyce (Linux i RouterOS)
  9. Linux (iproute2)
  10. RouterOS (MikroTik)
  11. Wnioski
  12. Pojęcia pojawiające się w materiale:
  13. Wypełnienie
  14. Wpływ na wydajność sieci

Ethernet jest fundamentem niemal każdej współczesnej sieci lokalnej (LAN). Od dziesięcioleci stanowi dominującą technologię warstwy łącza danych (Warstwa 2 modelu OSI). Kluczowym elementem tej technologii jest „ramka” (frame) – jednostka danych, która enkapsuluje pakiety z wyższych warstw (jak pakiety IP) w celu przesłania ich przez medium transmisyjne (np. kabel miedziany lub światłowód). Zrozumienie budowy tej ramki, a w szczególności pojęcia MTU (Maximum Transmission Unit), jest kluczowe dla diagnostyki sieci, optymalizacji wydajności i projektowania infrastruktury. W tym artykule przyjrzymy się szczegółowo budowie ramek Ethernet 802.3 i 802.2 oraz przeanalizujemy, jak rozmiar pola danych wpływa na wydajność i tzw. „narzut administracyjny”.

Budowa ramki Ethernet 802.3 (MAC)

Standard IEEE 802.3 definiuje podstawową strukturę ramki na poziomie podwarstwy MAC (Media Access Control). Jest to najczęściej spotykana forma ramki w dzisiejszych sieciach. Jej struktura, choć prosta, jest niezwykle efektywna.

<-- Warstwa Fizyczna (L1) --><--------------- Warstwa Łącza Danych (L2) ---------------->
+-----------+-----+-----------------+-----------------+---------------+----------------+----------+
| PREAMBUŁA | SFD | ADRES DOCELOWY  |  ADRES ŹRÓDŁOWY | DŁUGOŚĆ / TYP |    POLE DANYCH   |   FCS    |
| (7 bajtów)| (1B)|  (MAC, 6 bajtów)|  (MAC, 6 bajtów)|   (2 bajty)   | (46-1500 bajtów) | (4 bajty)|
+-----------+-----+-----------------+-----------------+---------------+----------------+----------+

Omówmy każde z tych pól:

  • Preambuła (Preamble) (7 bajtów): Ciąg naprzemiennych bitów (10101010…) służący do synchronizacji zegara odbiornika z nadajnikiem. Jest to element warstwy fizycznej, choć formalnie opisany w standardzie 802.3.
  • SFD (Start Frame Delimiter) (1 bajt): Znacznik początku ramki. Ma stałą wartość (10101011) i informuje odbiornik, że „synchronizacja się skończyła, teraz zaczyna się właściwa ramka”.
  • Adres Docelowy (Destination MAC) (6 bajtów): 48-bitowy adres MAC karty sieciowej, do której ramka jest adresowana. Może to być adres Unicast (do jednego odbiorcy), Multicast (do grupy) lub Broadcast (do wszystkich w danej domenie rozgłoszeniowej, FF:FF:FF:FF:FF:FF).
  • Adres Źródłowy (Source MAC) (6 bajtów): 48-bitowy adres MAC karty sieciowej nadawcy.
  • Długość / Typ (Length / EtherType) (2 bajty): To pole ma podwójne znaczenie, co jest historyczną spuścizną:
    • Długość: Jeśli wartość tego pola jest mniejsza lub równa 1500 (0x05DC), oznacza ona długość pola danych (ładunku) w bajtach. Jest to charakterystyczne dla ramki typu IEEE 802.3 „Novell”.
    • Typ (EtherType): Jeśli wartość jest większa lub równa 1536 (0x0600), oznacza ona typ protokołu warstwy wyższej, który jest przenoszony w polu danych. Jest to cecha ramki Ethernet II (DIX). Przykłady: 0x0800 dla IPv4, 0x0806 dla ARP, 0x86DD dla IPv6. Dziś jest to najczęściej używany wariant.
  • Pole Danych (Payload) (od 46 do 1500 bajtów): To jest „serce” ramki, przenoszące dane z wyższych warstw, np. cały pakiet IP. Minimalny rozmiar tego pola to 46 bajtów. Jeśli pakiet IP jest mniejszy, musi zostać dodane tzw. wypełnienie (padding), aby ramka osiągnęła minimalny dopuszczalny rozmiar (64 bajty łącznie z nagłówkami i FCS).
  • FCS (Frame Check Sequence) (4 bajty): Suma kontrolna (CRC32) obliczana na podstawie wszystkich pól od Adresu Docelowego do Pola Danych włącznie. Odbiornik oblicza własną sumę FCS i porównuje ją z otrzymaną. Jeśli się nie zgadzają, ramka jest uznawana za uszkodzoną i odrzucana (Ethernet nie posiada mechanizmu retransmisji na tej warstwie).

Warianty ramki i rola IEEE 802.2 (LLC)

Jak wspomniano, pole Długość/Typ historycznie rozdzieliło ramki na dwa główne typy. Aby pogodzić te dwa światy i umożliwić współistnienie wielu protokołów warstwy 3 na jednej karcie sieciowej (co było problemem przed popularyzacją IP), wprowadzono standard IEEE 802.2 Logical Link Control (LLC).

Ramka 802.2 LLC „chowa się” wewnątrz pola danych ramki 802.3. W tym scenariuszu pole Długość/Typ zawiera *długość*, a pierwsze bajty pola danych stają się nagłówkiem LLC.

    Ramka 802.3 z nagłówkiem LLC (802.2) i SNAP:
    
    +---------+---------+-----------+-------------------------------------------------+---------+
    |  NAGŁÓWEK ETHERNET 802.3 ...  | POLE DANYCH (zawiera teraz LLC)                 |   FCS   |
    +---------+---------+-----------+-------------------------------------------------+---------+
                        | DŁUGOŚĆ   | <-------------- Pole Danych 802.3 ------------> |
                        | (≤ 1500)  | +---------+---------+---------+---------------+ |
                        |           | |   DSAP  |   SSAP  | KONTROLA| DANE (np. SNAP)| |
                        |           | | (1 bajt)| (1 bajt)| (1-2B)  | ...           | |
                        |           | +---------+---------+---------+---------------+ |
                        |           | <------- Nagłówek 802.2 LLC ---->               |

Nagłówek LLC składa się z:

  • DSAP (Destination Service Access Point) i SSAP (Source Service Access Point): Działają jak „porty” dla warstwy 2, wskazując, który protokół wyższego rzędu ma obsłużyć dane (np. 0x06 dla IP wczesnych implementacji).
  • Kontrola (Control): Definiuje typ usługi (np. bezpołączeniowa).

Aby zachować kompatybilność z polem EtherType (którego nie ma w „czystej” ramce 802.3+LLC), wprowadzono rozszerzenie SNAP (Subnetwork Access Protocol). Nagłówek SNAP jest umieszczany wewnątrz pola danych LLC.

    Szczegół pola danych z LLC i SNAP:

    +---------+---------+---------+-------------------+---------------+-------------------+
    |   DSAP  |   SSAP  | KONTROLA|        OUI        |      PID      |    DANE... (np. IP) |
    | (0xAA)  | (0xAA)  | (0x03)  |     (3 bajty)     |   (2 bajty)   |                   |
    +---------+---------+---------+-------------------+---------------+-------------------+
    <------- LLC (3B) ------> <--------- SNAP (5B) -------->
  • Gdy DSAP i SSAP mają wartość 0xAA, a Kontrola 0x03, oznacza to obecność nagłówka SNAP.
  • OUI (Organizationally Unique Identifier) (3 bajty): Zazwyczaj 0x00-00-00 dla protokołów EtherType.
  • PID (Protocol ID) (2 bajty): To jest właśnie „odzyskane” pole EtherType! Np. 0x0800 dla IPv4.
Współczesne Zastosowanie: W praktyce, w 99.9% współczesnych sieci TCP/IP, dominuje format ramki Ethernet II (DIX). Oznacza to, że pole Długość/Typ jest używane jako EtherType (np. 0x0800), a nagłówki LLC/SNAP nie są stosowane dla ruchu IP. Ramki 802.2 LLC można jeszcze spotkać w niektórych specyficznych protokołach sieciowych (np. w sieciach przemysłowych lub starszych standardach jak IPX/SPX), ale dla codziennego ruchu internetowego, Ethernet II jest standardem.

Serce ładunku – MTU (Maximum Transmission Unit)

Przejdźmy do kluczowego zagadnienia: rozmiaru pola danych. MTU (Maximum Transmission Unit) to parametr definiujący maksymalny rozmiar pakietu warstwy 3 (np. IP), który może być przeniesiony w polu danych (ładunku) ramki warstwy 2.

Kluczowe fakty na temat MTU w kontekście Ethernetu:

  1. Standardowe MTU: Dla klasycznego Ethernetu (i Fast Ethernet, Gigabit Ethernet) standardowe MTU wynosi 1500 bajtów. Oznacza to, że maksymalny pakiet IP, jaki „zmieści się” w ramce, to 1500 bajtów.
  2. MTU a Rozmiar Ramki: MTU (1500 B) + Nagłówek Ethernet (14 B: 6B MAC Dst + 6B MAC Src + 2B Typ) + Stopka Ethernet (4 B: FCS) = 1518 bajtów. To jest maksymalny rozmiar *całej* ramki Ethernet (nie licząc preambuły i SFD).
  3. Minimalny Rozmiar Ładunku: Jak wspomniano, minimalny rozmiar *pola danych* to 46 bajtów. Jeśli pakiet IP jest mniejszy (np. sama odpowiedź ICMP Echo lub pakiet TCP ACK), warstwa łącza danych automatycznie doda wypełnienie (padding), aby osiągnąć ten próg. Minimalny rozmiar całej ramki to 64 bajty (14B nagłówek + 46B ładunku + 4B FCS).
  4. Jumbo Frames (Wielkie Ramki): W sieciach o wysokiej przepustowości (głównie Gigabit Ethernet i szybszych), szczególnie w centrach danych i sieciach SAN (Storage Area Network), standardowe MTU 1500 bajtów jest nieefektywne. Wprowadzono więc „Jumbo Frames”, które pozwalają na MTU większe niż 1500, zazwyczaj 9000 bajtów. Wymaga to jednak, aby *wszystkie* urządzenia na ścieżce (karty sieciowe, switche, routery) obsługiwały i miały skonfigurowany ten sam, większy rozmiar MTU.

MTU, fragmentacja i narzut administracyjny

Rozmiar MTU ma bezpośredni wpływ na wydajność sieci. Kluczowym pojęciem jest tutaj narzut administracyjny (overhead). Narzutem nazywamy wszystkie te bajty, które musimy wysłać, a które nie są właściwymi danymi użytkownika (np. nagłówki TCP, IP i Ethernet).

Załóżmy, że chcemy wysłać dane przez TCP/IP w standardowej ramce Ethernet:

  • Narzut Warstwy 2 (Ethernet): 14 bajtów nagłówka + 4 bajty FCS = 18 bajtów.
  • Narzut Warstwy 3 (IP): Standardowy nagłówek IPv4 = 20 bajtów.
  • Narzut Warstwy 4 (TCP): Standardowy nagłówek TCP = 20 bajtów.

Całkowity „podstawowy” narzut na przesłanie jakichkolwiek danych TCP wynosi więc 58 bajtów (18 + 20 + 20).

Problem Fragmentacji

MTU określa maksymalny rozmiar *jednego* pakietu. Co się stanie, jeśli router (Warstwa 3) otrzyma pakiet o rozmiarze 1500 bajtów i musi go przesłać przez łącze o MTU 1400 bajtów (np. tunel VPN lub łącze PPPoE)?

Router musi dokonać fragmentacji. Dzieli on pakiet IP o rozmiarze 1500 bajtów na dwa mniejsze pakiety (np. jeden 1400B i drugi 100B + nagłówek IP). Fragmentacja jest bardzo niepożądana:

  • Obciąża CPU: Router musi aktywnie przetwarzać i dzielić pakiety.
  • Zwiększa narzut: Drugi (i każdy kolejny) fragment musi mieć własny nagłówek IP.
  • Problemy z retransmisją: Jeśli zginie choćby jeden fragment, cała oryginalna paczka danych musi być retransmitowana.
  • Odbiorca składa pakiety: To host docelowy musi złożyć fragmenty w całość, co również zużywa zasoby.

Dlatego kluczowe jest utrzymanie spójnego MTU na całej ścieżce (tzw. Path MTU) lub używanie mechanizmów jak MSS Clamping, które instruują hosty, aby wysyłały mniejsze segmenty TCP, mieszczące się w MTU ścieżki.

Obliczanie narzutu administracyjnego

Sprawdźmy, jak procentowo wygląda narzut administracyjny w zależności od rozmiaru MTU. W naszych obliczeniach zakładamy przesyłanie danych TCP/IP, gdzie całkowity narzut na pakiet wynosi 58 bajtów (18B L2 + 20B L3 + 20B L4).

Wzór na efektywność: Efektywność = (Dane Użytkownika) / (Całkowity Rozmiar Ramki)

Wzór na narzut: Narzut % = (Całkowity Narzut) / (Całkowity Rozmiar Ramki) * 100%

Scenariusz MTU (Rozmiar Pakietu IP) Dane Użytkownika (TCP Payload) Całkowity Narzut (L2+L3+L4) Całkowity Rozmiar Ramki (L2) Narzut % Efektywność %
Standardowy Ethernet 1500 B 1500 – 20 (IP) – 20 (TCP) = 1460 B 58 B 1460 (Dane) + 58 (Narzut) = 1518 B (58 / 1518) * 100% = ~3.82% (1460 / 1518) * 100% = ~96.18%
Jumbo Frame 9000 B 9000 – 20 (IP) – 20 (TCP) = 8960 B 58 B 8960 (Dane) + 58 (Narzut) = 9018 B (58 / 9018) * 100% = ~0.64% (8960 / 9018) * 100% = ~99.36%
Stare Łącza (np. Dial-up) 576 B 576 – 20 (IP) – 20 (TCP) = 536 B 58 B 536 (Dane) + 58 (Narzut) = 594 B (58 / 594) * 100% = ~9.76% (536 / 594) * 100% = ~90.24%
Minimalna Ramka (np. ACK) 40 B (IP 20B + TCP 20B) 0 B 40 B (IP+TCP) + 18 B (Ethernet) = 58 B 64 B (Ramka musi mieć min. 64B, więc L2 dodaje 6B wypełnienia) (64 / 64) * 100% = 100% (0 / 64) * 100% = 0%

Analiza Tabeli

Wnioski są bardzo wyraźne:

  • Przejście ze standardowego MTU 1500 na Jumbo Frame 9000 zmniejsza procentowy narzut administracyjny ponad 6-krotnie (z 3.82% do 0.64%). W przypadku przesyłania terabajtów danych w sieci SAN ma to gigantyczne znaczenie – mniej ramek do przetworzenia przez switche i karty sieciowe, mniejsze obciążenie CPU.
  • Małe pakiety (jak te z MTU 576 B) są bardzo nieefektywne – prawie 10% transferu to same nagłówki.
  • Pakiety kontrolne (jak TCP ACK bez danych) mają 100% narzutu, ale są niezbędne do działania protokołu. Na szczęście są małe i nie stanowią większości ruchu.

Konfiguracja MTU w praktyce (Linux i RouterOS)

Zmiana MTU jest prostą operacją administracyjną, ale należy ją wykonywać ostrożnie. Niespójne MTU w ramach jednego segmentu sieci (VLAN) może prowadzić do poważnych problemów z komunikacją (tzw. „MTU black hole”).

Linux (iproute2)

W nowoczesnych systemach Linux do zarządzania siecią służy pakiet iproute2 (polecenie ip).

# Sprawdzenie aktualnego MTU dla interfejsu eth0
ip addr show eth0
# Przykładowy output:
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc ...

# Ustawienie MTU na 9000 (Jumbo Frame) dla interfejsu eth0
# Wymagane uprawnienia roota (użyj sudo)
sudo ip link set dev eth0 mtu 9000

# Weryfikacja zmiany
ip addr show eth0
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc ...

# (Starsza, przestarzała metoda używająca 'ifconfig')
# sudo ifconfig eth0 mtu 9000

Aby zmiana była trwała, należy ją zapisać w odpowiednich plikach konfiguracyjnych dystrybucji (np. /etc/network/interfaces w Debian/Ubuntu lub pliki w /etc/sysconfig/network-scripts/ w RHEL/CentOS).

RouterOS (MikroTik)

W systemie RouterOS firmy MikroTik konfiguracji dokonujemy w terminalu lub przez interfejs WinBox/WebFig. Składnia terminalowa jest bardzo intuicyjna.

# Sprawdzenie aktualnego MTU dla wszystkich interfejsów ethernet
/interface ethernet print
# Przykładowy output:
#  Flags: X - disabled, R - running, S - slave 
#  #    NAME      MTU   L2MTU  MAX-L2MTU  MAC-ADDRESS
#  0 R  ether1    1500   1518   10226      D4:CA:6D:XX:XX:XX
#  1 R  ether2    1500   1518   10226      D4:CA:6D:XX:XX:XY

# Zmiana MTU na 9000 dla interfejsu 'ether1'
/interface ethernet set [find name="ether1"] mtu=9000

# Weryfikacja zmiany
/interface ethernet print
#  #    NAME      MTU   L2MTU  MAX-L2MTU  MAC-ADDRESS
#  0 R  ether1    9000   9018   10226      D4:CA:6D:XX:XX:XX

Warto zauważyć, że RouterOS rozróżnia MTU (MTU warstwy 3, czyli rozmiar pakietu IP) oraz L2MTU (maksymalny rozmiar całej ramki Ethernet L2). Zmiana MTU automatycznie dostosowuje L2MTU (9000 + 18 = 9018, jeśli karta wspiera Jumbo Frames, co widać po `MAX-L2MTU`).

Wnioski

Ramka Ethernet, choć jej koncepcja ma dekady, pozostaje cichym bohaterem nowoczesnej komunikacji. Jej struktura (802.3 i historyczna 802.2) została zaprojektowana z myślą o prostocie i wydajności. Kluczowy parametr, jakim jest MTU, definiuje kompromis między wydajnością a opóźnieniami.

  • Standardowe MTU 1500 jest złotym środkiem, zapewniającym świetną wydajność w większości zastosowań i kompatybilność z globalnym Internetem.
  • Jumbo Frames (MTU 9000) oferują drastyczne zmniejszenie narzutu administracyjnego, co jest kluczowe w sieciach o ultrawysokiej przepustowości (np. 10/40/100 GbE) dedykowanych do specyficznych zadań, jak składowanie danych (iSCSI, NFS) czy obliczenia klastrowe.

Zrozumienie, jak MTU wpływa na fragmentację i narzut, pozwala administratorom sieci świadomie projektować infrastrukturę, która jest nie tylko szybka, ale przede wszystkim stabilna i wydajna.

Pojęcia pojawiające się w materiale:

Wypełnienie

Jest mechanizmem używanym w ramce Ethernet 802.3 w celu zapewnienia, że pole danych (ładunek) osiągnie minimalny wymagany rozmiar

Oto kluczowe informacje dotyczące wypełnienia:
1. Lokalizacja i funkcja: Wypełnienie to dane dodawane do Pola Danych (Payload) ramki Ethernet, jeśli. Lokalizacja i funkcja: Wypełnienie to dane dodawane do Pola Danych (Payload) ramki Ethernet, jeśli pakiet z wyższej warstwy (np. pakiet IP) jest zbyt mały

2. Minimalny rozmiar ładunku: Standard Ethernet 802.3 określa, że minimalny rozmiar samego Pola Danych musi wynosić 46 bajtów

3. Minimalny rozmiar ramki: Cała ramka Ethernet (nagłówek, ładunek i stopka), nie licząc preambuły i SFD, musi osiągnąć minimalny rozmiar 64 bajtów

◦ Składniki stałe ramki to 14 bajtów nagłówka (Adres Docelowy, Adres Źródłowy, Długość/Typ) plus 4 bajty stopki (FCS)
◦ Suma ta wynosi 18 bajtów (14 + 4)
◦ Aby ramka osiągnęła 64 bajty, ładunek musi wynosić 46 bajtów (64 – 18 = 46)

4. Kiedy jest używane: Jeśli pakiet IP przeznaczony do enkapsulacji w polu danych jest mniejszy niż 46 bajtów (np. pakiet kontrolny TCP ACK bez danych, który w sumie ma 40 bajtów nagłówków L3 i L4), warstwa łącza danych automatycznie dodaje wypełnienie, aby osiągnąć próg minimalnych 46 bajtów

5. Przykład minimalnej ramki: Ramka kontrolna (np. TCP ACK) może mieć 0 bajtów danych użytkownika (TCP Payload)

◦ Składniki L3 i L4 wynoszą 40 bajtów (20B IP + 20B TCP)
◦ Ramka musi mieć 64 bajty, co oznacza, że 6 bajtów (46B minimum minus 40B nagłówków L3/L4) jest dodawane jako wypełnienie, aby całkowity rozmiar ramki osiągnął 64 bajty

Wpływ na wydajność sieci

Budowa ramki Ethernet 802.3 oraz pojęcie MTU (Maximum Transmission Unit) są kluczowe dla optymalizacji i diagnostyki wydajności sieci, ponieważ wpływają bezpośrednio na efektywność transmisji danych, obciążenie urządzeń sieciowych oraz ryzyko fragmentacji pakietów. Poniżej przedstawiono szczegółowy wpływ budowy ramki Ethernet i MTU na wydajność sieci, zgodnie z dostępnymi źródłami.

> 1. Wpływ Budowy Ramki Ethernet 802.3 na Narzut Administracyjny
Ramka Ethernet (Warstwa 2 modelu OSI) jest jednostką danych, która enkapsuluje pakiety z wyższych warstw (np. IP) w celu przesłania ich przez medium transmisyjne.
Stały Narzut Ramki (L2 Overhead)
Standard IEEE 802.3 definiuje strukturę ramki. Elementy tej struktury, które nie są danymi użytkownika, stanowią narzut administracyjny (overhead). W ramce Ethernet 802.3, która jest najczęściej spotykaną formą w dzisiejszych sieciach:
1. Nagłówek Ethernet: Zawiera adresy MAC (docelowy i źródłowy, po 6 bajtów) oraz pole Długość/Typ (2 bajty)
2. Stopka Ethernet: Zawiera Sumę Kontrolną (FCS – Frame Check Sequence, 4 bajty)
Całkowity narzut związany wyłącznie z Warstwą 2 (Ethernet, bez Preambuły i SFD) wynosi 18 bajtów (14 bajtów nagłówka + 4 bajty FCS). Jest to narzut stały dla każdej wysyłanej ramki
> 2. Rola MTU (Maximum Transmission Unit)
MTU to parametr definiujący maksymalny rozmiar pakietu warstwy 3 (np. IP), który może być przeniesiony w polu danych (ładunku) ramki warstwy 2
Standard MTU a Rozmiar Ramki
Dla klasycznego Ethernetu (Fast i Gigabit Ethernet) standardowe MTU wynosi 1500 bajtów.
• Maksymalny rozmiar pakietu IP, który zmieści się w ładunku, to 1500 bajtów
• Maksymalny rozmiar całej ramki Ethernet ze standardowym MTU wynosi 1518 bajtów (1500 B ładunku + 18 B nagłówka i stopki)
• Minimalny rozmiar pola danych to 46 bajtów, co wymusza dodanie wypełnienia (padding), jeśli pakiet IP jest mniejszy, aby cała ramka osiągnęła minimalny rozmiar 64 bajtów
> 3. MTU a Efektywność Transmisji (Narzut Procentowy)
Rozmiar MTU ma bezpośredni wpływ na wydajność sieci, określając procentową część transferu poświęconą na dane administracyjne (narzut) w stosunku do właściwych danych użytkownika
Obliczanie Całkowitego Narzutu
Zakładając przesyłanie danych za pośrednictwem TCP/IP, całkowity narzut na jeden pakiet wynosi:
• Narzut L4 (TCP): 20 bajtów
• Narzut L3 (IP IPv4): 20 bajtów
• Narzut L2 (Ethernet): 18 bajtów
• Całkowity narzut: 58 bajtów
Wpływ MTU na Efektywność
Wydajność sieci (Efektywność %) rośnie wraz ze wzrostem MTU, ponieważ stały narzut 58 bajtów jest rozkładany na większą ilość danych:
Scenariusz
MTU
Dane Użytkownika (TCP Payload)
Całkowity Rozmiar Ramki
Narzut %
Efektywność %
Standardowy Ethernet
1500 B
1460 B
1518 B
~3.82%
~96.18%
Jumbo Frame
9000 B
8960 B
9018 B
~0.64%
~99.36%
Stare Łącza
576 B
536 B
594 B
~9.76%
~90.24%
Wnioski dotyczące wydajności:
1. Jumbo Frames: Przejście na MTU 9000 B (Jumbo Frame) zmniejsza procentowy narzut administracyjny ponad 6-krotnie (z 3.82% do 0.64%). W sieciach o wysokiej przepustowości (np. centrach danych, SAN) oznacza to mniejszą liczbę ramek do przetworzenia przez switche i karty sieciowe oraz mniejsze obciążenie CPU.
2. Małe MTU: Małe pakiety (np. MTU 576 B) są nieefektywne, gdyż prawie 10% transferu stanowią same nagłówki
> 4. Problem Fragmentacji Pakietów
Jeśli router (Warstwa 3) odbierze pakiet, który jest większy niż MTU następnego łącza, musi dokonać fragmentacji – podziału pakietu IP na dwa lub więcej mniejszych pakietów, 
Fragmentacja jest bardzo niepożądana i negatywnie wpływa na wydajność sieci:1. Obciążenie CPU: Router musi aktywnie przetwarzać i dzielić pakiety, co obciąża jego procesor
2. Zwiększenie Narzutu: Każdy kolejny fragment musi mieć własny nagłówek IP, zwiększając tym samym całkowity narzut administracyjny
3. Problemy z Retransmisją: Jeśli choćby jeden fragment zaginie w trakcie transmisji, host docelowy nie będzie w stanie złożyć oryginalnego pakietu, co prowadzi do konieczności retransmisji całej oryginalnej paczki danych
4. Obciążenie Odbiorcy: To host docelowy (a nie routery pośrednie) musi zużyć zasoby, aby złożyć fragmenty w całość
Dlatego kluczowe dla wydajności jest utrzymanie spójnego MTU na całej ścieżce (Path MTU)
> 5. Podsumowanie Wpływu
Budowa ramki Ethernet ustala stały, minimalny narzut dla każdej jednostki danych. Pojęcie MTU pozwala administratorom na optymalizację tego narzutu
• Standardowe MTU 1500 B jest „złotym środkiem”, zapewniającym kompatybilność i świetną wydajność w większości zastosowań, zwłaszcza w połączeniach z globalnym Internetem
• Większe MTU (Jumbo Frames) drastycznie zmniejsza narzut administracyjny i jest kluczowe w sieciach dedykowanych o ultrawysokiej przepustowości, gdzie najważniejsza jest maksymalna efektywność (np. iSCSI, klastry)
• Niespójne MTU lub zbyt małe MTU prowadzą do fragmentacji lub zwiększonego narzutu procentowego, co negatywnie wpływa na stabilność i wydajność

 

Wstęp do iptraf-ng

Napisane przez Igor Brzeżek on 24 października 2025
Napisane w: iptraf-ng.

Contents
  1. Część I: Wprowadzenie do iptarf-ng
  2. Instalacja i Wymagania
  3. Cel, Przeznaczenie i Możliwości
  4. Ograniczenia Narzędzia
  5. Najważniejsze Opcje i Interfejs (TUI)
  6. Zaawansowane Filtry Ruchu
  7. Część II: Treść Właściwa: Praktyczne Zastosowania
  8. Przykład 1: Skanowanie Sieci w Poszukiwaniu Adresów MAC i IP
  9. Przykład 2: Wyławianie i Badanie Konkretnej Transmisji
  10. Przykład 3: Efektywne Użycie Filtrów do Izolacji Ruchu DNS
  11. Część III: Podsumowanie

Część I: Wprowadzenie do iptarf-ng

Instalacja i Wymagania

iptraf-ng (Next Generation) to fundamentalne narzędzie diagnostyczne, którego instalacja w większości dystrybucji systemu Linux jest procesem trywialnym, wymagającym jedynie dostępu do standardowych repozytoriów oprogramowania. W systemach opartych na Debianie, takich jak Ubuntu, proces sprowadza się do wykonania pojedynczej komendy w terminalu: sudo apt-get update && sudo apt-get install iptraf-ng. Dla dystrybucji z rodziny Red Hat, w tym Fedory czy CentOS, analogiczną operację realizuje polecenie sudo dnf install iptraf-ng lub sudo yum install iptraf-ng. Kluczowym wymaganiem do pełnoprawnego działania programu jest posiadanie uprawnień superużytkownika (roota), co wynika z jego architektury; narzędzie musi uzyskać dostęp do niskopoziomowych gniazd sieciowych (raw sockets) oraz mieć możliwość przełączania interfejsów w tryb nasłuchu (promiscuous mode), aby przechwytywać cały ruch w danym segmencie sieci, a nie tylko pakiety adresowane bezpośrednio do hosta. Bez tych uprawnień, funkcjonalność programu byłaby drastycznie ograniczona, uniemożliwiając realizację jego podstawowych zadań diagnostycznych.

Pod względem zasobów systemowych, iptraf-ng jest narzędziem niezwykle oszczędnym, co stanowi jedną z jego głównych zalet, szczególnie w kontekście pracy na serwerach produkcyjnych lub urządzeniach o ograniczonej mocy obliczeniowej. Jego działanie opiera się na bibliotece ncurses, która umożliwia tworzenie interfejsów tekstowych (TUI – Text-based User Interface) wprost w emulatorze terminala, eliminując tym samym potrzebę posiadania jakiegokolwiek środowiska graficznego. Wymagania co do pamięci RAM i obciążenia procesora są minimalne, co pozwala na jego ciągłe działanie w tle bez zauważalnego wpływu na wydajność systemu, nawet podczas monitorowania interfejsów o dużym natężeniu ruchu. Ta lekkość czyni go idealnym wyborem do zdalnej diagnostyki poprzez sesje SSH, gdzie przepustowość łącza jest ograniczona, a transfer graficznego interfejsu byłby niepraktyczny. Program nie posiada również skomplikowanych zależności, co dodatkowo upraszcza jego wdrożenie i utrzymanie w różnorodnych środowiskach systemowych, od serwerów po systemy wbudowane.

Cel, Przeznaczenie i Możliwości

Głównym celem i przeznaczeniem iptraf-ng jest dostarczenie administratorom sieciowym i systemowym interaktywnego, przejrzystego widoku na ruch sieciowy w czasie rzeczywistym. W odróżnieniu od narzędzi dokonujących głębokiej inspekcji pakietów, jak Wireshark, które skupiają się na analizie post-mortem, iptraf-ng specjalizuje się w prezentowaniu zagregowanych statystyk i dynamicznych list połączeń, co pozwala na natychmiastową ocenę bieżącej sytuacji w sieci. Jego siła leży w zdolności do szybkiego odpowiadania na fundamentalne pytania: „kto z kim rozmawia?”, „jakie protokoły są używane?”, „które połączenia generują największy ruch?” oraz „jakie urządzenia są aktywne w mojej sieci lokalnej?”. Dzięki temu staje się narzędziem pierwszego kontaktu podczas diagnozowania problemów z wydajnością, podejrzanej aktywności mogącej wskazywać na naruszenie bezpieczeństwa, czy weryfikacji poprawności konfiguracji reguł zapory sieciowej. Jego TUI organizuje te złożone dane w kilku wyspecjalizowanych modułach, takich jak monitor ruchu IP, ogólne i szczegółowe statystyki interfejsów czy monitor stacji LAN.

Szerokie spektrum możliwości iptraf-ng czyni go wszechstronnym narzędziem diagnostycznym. Centralnym punktem jest monitor ruchu IP, który wyświetla aktywne sesje TCP oraz przepływy UDP, wraz z kluczowymi metrykami, takimi jak liczba pakietów, ilość przesłanych danych i flagi stanu TCP. Uzupełniają go moduły statystyk interfejsów, które oferują zarówno ogólny obraz obciążenia (całkowity ruch, bitrate), jak i szczegółowy podział na protokoły (IP, TCP, UDP, ICMP, ARP) oraz rozkład wielkości pakietów. Niezwykle użyteczny monitor stacji LAN pasywnie odkrywa aktywne urządzenia w sieci lokalnej, identyfikując ich adresy MAC i zliczając generowany przez nie ruch. Każdy z tych modułów może być dodatkowo zawężony przez system filtrów, pozwalający na izolację ruchu według adresu IP, portu, protokołu czy rozmiaru pakietu. Ta kombinacja funkcjonalności pozwala na realizację szerokiej gamy zadań, od identyfikacji „wąskich gardeł” w sieci, przez wykrywanie nieautoryzowanych usług, aż po audytowanie komunikacji sieciowej aplikacji.

Ograniczenia Narzędzia

Pomimo swojej wszechstronności, kluczowe jest zrozumienie ograniczeń iptraf-ng, aby efektywnie wykorzystywać jego potencjał i wiedzieć, kiedy sięgnąć po inne narzędzia. Przede wszystkim, iptraf-ng nie jest analizatorem protokołów z funkcją głębokiej inspekcji pakietów (DPI). W przeciwieństwie do programów takich jak tcpdump czy Wireshark, nie pozwala on na analizę zawartości (payload) przesyłanych danych; jego działanie koncentruje się na metadanych i statystykach, czyli informacjach z nagłówków pakietów. Oznacza to, że możemy zobaczyć, iż host A wysłał 1 MB danych do hosta B przez HTTPS, ale nie dowiemy się, jakie konkretnie zasoby zostały pobrane. Jest to świadomy kompromis projektowy, który zapewnia wysoką wydajność i czytelność prezentowanych informacji w czasie rzeczywistym, kosztem głębi analitycznej. Dlatego w sytuacjach wymagających analizy konkretnych żądań aplikacyjnych czy odtworzenia sesji, iptraf-ng powinien być używany do wstępnej identyfikacji problematycznego strumienia, który następnie można przechwycić za pomocą bardziej wyspecjalizowanych narzędzi.

Kolejnym istotnym ograniczeniem jest fakt, że iptraf-ng jest narzędziem przeznaczonym do monitoringu w czasie rzeczywistym, a nie do analizy historycznej. Chociaż oferuje możliwość logowania statystyk do pliku, jego główny interfejs jest efemeryczny – dane znikają po zamknięciu programu. Nie posiada on wbudowanych mechanizmów do przechowywania danych w bazie, generowania trendów czy tworzenia zaawansowanych raportów historycznych, co jest domeną systemów monitoringu sieciowego, takich jak Zabbix, Nagios czy rozwiązań opartych na NetFlow/sFlow. Ponadto, iptraf-ng jest narzędziem stricte diagnostycznym i obserwacyjnym, a nie konfiguracyjnym. Nie można za jego pomocą zmieniać adresów IP, modyfikować tablic routingu, ani w żaden sposób aktywnie wpływać na ruch sieciowy. Jego rolą jest pasywne dostarczanie informacji, na podstawie których administrator może podjąć decyzje i wdrożyć zmiany przy użyciu odpowiednich narzędzi systemowych, takich jak ip, iptables czy nmcli. Zrozumienie tej pasywnej natury jest fundamentalne, aby uniknąć błędnych oczekiwań co do jego funkcjonalności.

Najważniejsze Opcje i Interfejs (TUI)

Interakcja z iptraf-ng odbywa się głównie poprzez jego intuicyjny interfejs tekstowy (TUI), który prezentuje się użytkownikowi zaraz po uruchomieniu polecenia sudo iptraf-ng. Główne menu stanowi centrum nawigacyjne, z którego można uzyskać dostęp do wszystkich kluczowych modułów. Opcje takie jak „IP traffic monitor”, „General interface statistics”, „Detailed interface statistics” oraz „LAN station monitor” uruchamiają poszczególne ekrany analityczne, pozwalając na dynamiczne przełączanie się między różnymi perspektywami monitoringu. Menu „Filters” jest bramą do potężnego systemu filtrowania, a sekcja „Configure…” pozwala na dostosowanie globalnych ustawień programu, takich jak włączenie rozpoznawania nazw DNS, definicja kolorów czy zachowanie logowania. Nawigacja w TUI odbywa się za pomocą klawiszy strzałek i klawisza Enter, a wyjście z poszczególnych modułów lub całego programu realizowane jest najczęściej klawiszem ‚q’ lub ‚x’, co jest standardową i wygodną konwencją w aplikacjach konsolowych.

Oprócz interaktywnego TUI, iptraf-ng oferuje szereg opcji konsolowych, które pozwalają na uruchomienie programu bezpośrednio w określonym trybie, co jest niezwykle przydatne w skryptach automatyzacyjnych lub dla zaawansowanych użytkowników preferujących pracę w linii poleceń. Flaga -i <interfejs> (np. -i eth0) pozwala na natychmiastowe rozpoczęcie monitorowania wskazanego interfejsu, a jej specjalna wartość -i all obejmuje wszystkie dostępne interfejsy. Można ją łączyć z flagami określającymi tryb pracy: -g uruchamia ogólne statystyki, -d szczegółowe statystyki dla danego interfejsu, -s monitor połączeń TCP/UDP, a -l monitor stacji LAN. Przykładowo, polecenie sudo iptraf-ng -s -i eth0 natychmiast wyświetli monitor połączeń TCP i UDP dla interfejsu eth0. Flaga -t <minuty> pozwala na automatyczne zakończenie pracy programu po określonym czasie, a -B uruchamia go w trybie tła (daemon), zapisując logi do domyślnego pliku. Opcja -f pozwala na natychmiastowe wyczyszczenie wszystkich statystyk i liczników, co jest przydatne przy rozpoczynaniu nowej sesji diagnostycznej.

Zaawansowane Filtry Ruchu

Sekcja filtrów w iptraf-ng jest jednym z najpotężniejszych, a często niedocenianych, elementów tego narzędzia, przekształcając je z ogólnego monitora w precyzyjne narzędzie chirurgiczne do analizy sieci. Filtry pozwalają administratorowi na drastyczne zredukowanie ilości prezentowanych informacji, skupiając się wyłącznie na tym ruchu, który jest w danym momencie przedmiotem dochodzenia. Zamiast przeglądać setki lub tysiące jednoczesnych połączeń na obciążonym serwerze, można zdefiniować regułę, która wyświetli tylko te sesje, które spełniają określone kryteria. Dostęp do konfiguracji filtrów uzyskuje się poprzez opcję „Filters” w menu głównym, co otwiera dedykowany menedżer, w którym można tworzyć, edytować, usuwać i aktywować nowe reguły. Takie podejście jest nieocenione podczas diagnozowania problemów z konkretną aplikacją, analizowania komunikacji z określonym hostem lub monitorowania użycia specyficznego protokołu, ponieważ eliminuje „szum informacyjny” i pozwala na klarowną obserwację interesujących nas zjawisk.

Tworzenie nowego filtru w iptraf-ng jest procesem wysoce elastycznym. Użytkownik może zdefiniować regułę opartą na wielu parametrach, które można ze sobą łączyć. Podstawowe kryteria obejmują adres IP hosta źródłowego i docelowego (wraz z maską sieci, co pozwala filtrować całe podsieci), numer portu źródłowego i docelowego dla protokołów TCP i UDP oraz typ protokołu warstwy transportowej. Dodatkowo, można filtrować ruch na podstawie całkowitego rozmiaru pakietu, co jest użyteczne przy poszukiwaniu nietypowo małych lub dużych pakietów, mogących wskazywać na anomalie. Co ważne, dla każdego parametru można zdefiniować regułę „uwzględnij” (include) lub „wyklucz” (exclude), co daje ogromną kontrolę nad wyświetlanymi danymi. Przykładowo, można stworzyć filtr, który pokaże cały ruch z podsieci 10.0.1.0/24, ale jednocześnie wykluczy z tego widoku komunikację na porcie 22 (SSH), pozwalając skupić się na pozostałej aktywności sieciowej tych maszyn. Po zdefiniowaniu, filtr musi zostać aktywowany (applied), aby zaczął obowiązywać w aktywnych modułach monitorujących.

Część II: Treść Właściwa: Praktyczne Zastosowania

Przykład 1: Skanowanie Sieci w Poszukiwaniu Adresów MAC i IP

Jednym z najczęstszych zadań administratora jest inwentaryzacja urządzeń w sieci lokalnej, szczególnie w celu wykrycia nieautoryzowanych hostów. iptraf-ng, dzięki modułowi „LAN station monitor”, realizuje to zadanie w sposób pasywny i niezwykle efektywny. Po uruchomieniu tego modułu na wybranym interfejsie (np. podłączonym do firmowego przełącznika), program przechodzi w tryb nasłuchu i zaczyna analizować cały ruch w warstwie drugiej modelu OSI. Na podstawie źródłowych adresów MAC z przechwytywanych ramek Ethernet, dynamicznie buduje listę wszystkich aktywnych urządzeń w danym segmencie sieci, zliczając dla każdego z nich liczbę wysłanych i odebranych pakietów. Jest to metoda znacznie dyskretniejsza niż aktywne skanowanie za pomocą narzędzi takich jak nmap, ponieważ nie generuje żadnego dodatkowego ruchu i jest niewykrywalna dla systemów zabezpieczeń. Po chwili, gdy program przechwyci ruch wyższych warstw (np. komunikaty ARP lub pakiety IP), powiąże wykryte adresy MAC z odpowiadającymi im adresami IP, dostarczając kompletnego obrazu aktywnych hostów.

Ilustracja 1: Widok modułu „LAN station monitor” pokazujący listę wykrytych hostów wraz z ich adresami MAC, adresami IP oraz statystykami pakietów.

Przykład 2: Wyławianie i Badanie Konkretnej Transmisji

Wyobraźmy sobie scenariusz, w którym użytkownik zgłasza, że jego sesja SSH do zdalnego serwera działa bardzo wolno, a wpisywane znaki pojawiają się z dużym opóźnieniem. Aby zbadać ten problem, administrator może użyć modułu „IP traffic monitor” do wyizolowania i obserwacji tej konkretnej transmisji. Uruchamiając monitor na odpowiednim interfejsie, widzi listę wszystkich aktywnych połączeń, jednak aby skupić się na problemie, definiuje prosty filtr, który pokaże tylko ruch TCP na porcie 22 (domyślny port SSH) między adresem IP stacji roboczej użytkownika a adresem serwera. Po aktywacji filtru, na ekranie pozostaje tylko jedna, interesująca nas sesja. Administrator może teraz w czasie rzeczywistym obserwować liczniki pakietów i bajtów w obu kierunkach; jeśli zauważy, że pakiety od klienta do serwera przyrastają normalnie, ale odpowiedzi z serwera pojawiają się sporadycznie lub wcale, może to wskazywać na problem z siecią po stronie serwera lub samego serwera. Analiza flag TCP może dodatkowo ujawnić retransmisje lub inne anomalie wskazujące na gubienie pakietów na trasie.

Ilustracja 2: Monitor ruchu IP z aktywnym filtrem, pokazujący wyłącznie sesję SSH między hostem 192.168.1.101 a serwerem 10.0.0.5.

Przykład 3: Efektywne Użycie Filtrów do Izolacji Ruchu DNS

Rozważmy sytuację, w której administrator sieci podejrzewa problemy z resolverem DNS w firmie; strony internetowe ładują się wolno, a aplikacje zgłaszają problemy z rozwiązywaniem nazw. Aby zweryfikować, czy wewnętrzny serwer DNS (np. o adresie 192.168.1.53) odpowiada poprawnie i szybko, można użyć iptraf-ng z precyzyjnie skonfigurowanym filtrem. W menedżerze filtrów administrator tworzy nową regułę o nazwie „Analiza DNS”. W definicji filtru ustawia jako protokół UDP i jako port docelowy 53, a jako docelowy adres IP wprowadza 192.168.1.53. Po zastosowaniu tego filtru w module „IP traffic monitor”, na ekranie pojawią się wyłącznie zapytania DNS kierowane do firmowego serwera. Administrator może teraz obserwować napływające zapytania i szukać odpowiedzi. Jeśli dla wielu zapytań nie pojawiają się pakiety zwrotne, lub pojawiają się one ze znacznym opóźnieniem, jest to silny dowód na to, że serwer DNS jest przeciążony, ma problemy z łącznością lub jego usługa nie działa poprawnie. Taka izolacja ruchu pozwala na jednoznaczną diagnozę bez potrzeby przeglądania całego ruchu sieciowego.

Ilustracja 3: Widok monitora ruchu po zastosowaniu filtru na port UDP 53, pokazujący wyłącznie zapytania DNS kierowane do serwera 192.168.1.53.

Część III: Podsumowanie

Podsumowując, iptraf-ng ugruntował swoją pozycję jako nieodzowne, wysoce wyspecjalizowane narzędzie w arsenale każdego profesjonalisty IT, którego praca wymaga dogłębnego zrozumienia dynamiki ruchu sieciowego. Jego wartość nie leży w zdolności do konkurowania z kompleksowymi platformami do analizy pakietów czy systemami monitoringu, lecz w unikalnej niszy, którą zajmuje: dostarczaniu natychmiastowej, interaktywnej i klarownej informacji zwrotnej w środowisku, gdzie zasoby graficzne są niedostępne lub niepożądane. Zdolność do szybkiego przełączania się między widokiem ogólnych statystyk, szczegółową listą połączeń a pasywnym odkrywaniem hostów w sieci LAN, czyni go niezwykle efektywnym narzędziem do wstępnej diagnostyki i „triage’u” problemów sieciowych. Jego lekkość, brak skomplikowanych zależności i praca w oparciu o standardowy interfejs konsolowy zapewniają mu uniwersalność, pozwalając na jego użycie w niemal każdym scenariuszu, od potężnych serwerów w data center po minimalistyczne systemy wbudowane, co podkreśla jego ponadczasową użyteczność.

Kluczem do mistrzowskiego opanowania iptraf-ng jest nie tylko znajomość jego poszczególnych modułów, ale przede wszystkim świadomość jego filozofii działania oraz umiejętność kreatywnego wykorzystania mechanizmu filtrów. Zrozumienie, że jest to narzędzie obserwacyjne, a nie konfiguracyjne, oraz że jego siła tkwi w analizie metadanych w czasie rzeczywistym, pozwala na postawienie właściwych pytań i szybkie uzyskanie na nie odpowiedzi. Administrator, który potrafi precyzyjnie zdefiniować filtr w celu wyizolowania problematycznej transmisji, jest w stanie w ciągu kilku minut zdiagnozować problem, który w przeciwnym razie wymagałby analizy gigabajtów przechwyconych danych. W erze coraz bardziej złożonych i dynamicznych infrastruktur sieciowych, zdolność do szybkiego zawężenia pola poszukiwań i uzyskania czytelnego obrazu sytuacji jest na wagę złota, a iptraf-ng, mimo upływu lat, wciąż pozostaje jednym z najlepszych narzędzi do realizacji tego właśnie celu, stanowiąc doskonałe uzupełnienie dla bardziej zaawansowanych systemów analitycznych.

Użycie programu iperf-ng do testowania przepustowości sieci

Napisane przez Igor Brzeżek on 20 października 2025
Napisane w: Pomiary w sieciach LAN.

Contents
  1. Wstęp: Zrozumienie zmiennych w testowaniu wydajności sieci
  2. Praktyczne przykłady użycia iperf-ng
  3. Testowanie TCP: okno i kierunek
  4. 1. Podstawowy test TCP w jedną stronę
  5. 2. Test TCP z powiększonym rozmiarem okna
  6. 3. Test TCP w dwie strony jednocześnie (Dual Test)
  7. Testowanie UDP: bufor i kierunek
  8. 1. Podstawowy test UDP w jedną stronę
  9. 2. Test UDP z powiększonym rozmiarem bufora
  10. 3. Test UDP w dwie strony jednocześnie
  11. Dobre praktyki

Wstęp: Zrozumienie zmiennych w testowaniu wydajności sieci

Testowanie wydajności sieci jest fundamentalnym procesem diagnostycznym, który wykracza daleko poza proste sprawdzenie „prędkości Internetu”. Aby uzyskać miarodajne i użyteczne wyniki, kluczowe jest zrozumienie, jak różne czynniki i protokoły wpływają na transfer danych. Podstawowym rozróżnieniem jest wybór między protokołem TCP (Transmission Control Protocol) a UDP (User Datagram Protocol). TCP, będący protokołem zorientowanym na połączenie, gwarantuje dostarczenie każdego pakietu w odpowiedniej kolejności, implementując mechanizmy kontroli przepływu, retransmisji utraconych segmentów i unikania zatorów. To sprawia, że jest on idealny do symulowania transferów plików, przeglądania stron internetowych czy działania poczty e-mail, gdzie integralność danych jest priorytetem. Testując za pomocą TCP, mierzymy w rzeczywistości, jak efektywnie systemy końcowe i urządzenia sieciowe potrafią negocjować i utrzymywać stabilny, niezawodny strumień danych. Wynik takiego testu odzwierciedla więc nie tylko „surową” przepustowość łącza, ale także sprawność implementacji stosu TCP/IP w systemach operacyjnych i zdolność sieci do radzenia sobie z narzutem związanym z potwierdzeniami (ACK) i retransmisjami.

Z drugiej strony spektrum znajduje się protokół UDP, który jest bezpołączeniowy i nie gwarantuje ani dostarczenia, ani kolejności pakietów. Jego główną zaletą jest minimalny narzut i niska latencja, co czyni go idealnym dla aplikacji czasu rzeczywistego, takich jak streaming wideo, rozmowy VoIP czy gry online, gdzie utrata pojedynczego pakietu jest mniej problematyczna niż opóźnienie spowodowane oczekiwaniem na jego retransmisję. Testowanie za pomocą UDP wymaga od użytkownika zdefiniowania docelowej przepustowości, z jaką dane mają być wysyłane. Celem takiego testu nie jest sprawdzenie, jaką maksymalną prędkość „wynegocjuje” protokół, lecz ocena jakości łącza pod zadanym obciążeniem. Kluczowymi metrykami w teście UDP są jitter (zmienność opóźnień między pakietami) oraz procent utraconych pakietów. Wysoki jitter może powodować „czkawkę” w dźwięku i obrazie, a duża utrata pakietów prowadzi do całkowitej degradacji jakości transmisji. Dlatego testy UDP są niezbędne do certyfikacji sieci pod kątem obsługi usług multimedialnych i komunikacyjnych w czasie rzeczywistym.

Kolejnym kluczowym parametrem wpływającym na wydajność jest rozmiar danych, który w kontekście testów sieciowych możemy rozpatrywać na kilku poziomach: rozmiaru bloku, bufora oraz okna TCP. Rozmiar bloku (kontrolowany w iperf-ng flagą -l lub --len) określa wielkość pojedynczej porcji danych wysyłanej w ramach jednego wywołania systemowego. Ma to bezpośredni wpływ na stosunek danych użytecznych do narzutu nagłówków protokołów. Małe bloki oznaczają większą liczbę pakietów potrzebnych do przesłania tej samej ilości danych, co prowadzi do większego obciążenia procesora i urządzeń sieciowych, które muszą przetworzyć więcej nagłówków. Z kolei rozmiar bufora (-b dla UDP, -w dla buforów systemowych) odnosi się do ilości pamięci zarezerwowanej przez system operacyjny na przychodzące i wychodzące dane. Zbyt małe bufory mogą prowadzić do odrzucania pakietów (packet drops) w sytuacji, gdy aplikacja nie nadąża z ich odczytywaniem lub sieć dostarcza je szybciej, niż system jest w stanie przetworzyć, co jest częstym problemem w sieciach o dużej przepustowości.

W przypadku protokołu TCP, absolutnie krytycznym parametrem jest rozmiar okna TCP (TCP window size), kontrolowany flagą -w lub --window. Okno TCP definiuje, ile danych nadawca może wysłać bez otrzymania potwierdzenia (ACK) od odbiorcy. Jest to fundamentalny mechanizm kontroli przepływu. W sieciach o wysokim iloczynie przepustowość-opóźnienie (Bandwidth-Delay Product, BDP), czyli np. szybkich łączach na duże odległości, domyślny rozmiar okna jest często zbyt mały. Powoduje to, że nadawca musi wstrzymywać transmisję i czekać na potwierdzenia, mimo że łącze jest w stanie przesłać znacznie więcej danych. Zjawisko to skutecznie dławi przepustowość, uniemożliwiając pełne wykorzystanie potencjału sieci. Poprzez staranne dostrojenie rozmiaru okna TCP do charakterystyki łącza (BDP), można drastycznie zwiększyć osiąganą przepustowość, co pokazuje, jak istotna jest konfiguracja na poziomie protokołu, a nie tylko sama fizyczna jakość połączenia.

Równie ważne jak parametry protokołów jest uwzględnienie kierunku ruchu sieciowego. Większość podstawowych testów wykonuje się w jednym kierunku (unidirectional), od klienta do serwera, co symuluje operację wysyłania pliku. Jednakże wiele nowoczesnych aplikacji generuje ruch w obu kierunkach jednocześnie. Urządzenia sieciowe, takie jak przełączniki i routery, pracują w trybie pełnego dupleksu (full-duplex), co teoretycznie pozwala na jednoczesne wysyłanie i odbieranie danych z pełną prędkością portu. Testy dwukierunkowe (bidirectional), realizowane w iperf-ng za pomocą flagi -d lub --dualtest, pozwalają zweryfikować, czy infrastruktura sieciowa jest w stanie sprostać takiemu obciążeniu. Problemy z wydajnością w trybie dwukierunkowym mogą ujawnić nieprawidłową negocjację dupleksu, ograniczenia w architekturze wewnętrznej przełącznika (np. niewystarczająca wydajność matrycy przełączającej) lub problemy ze sterownikami kart sieciowych. Testowanie w obu kierunkach jest zatem kluczowe dla pełnej oceny zdolności sieci do obsługi złożonych, interaktywnych obciążeń.

Na koniec należy wspomnieć o specyfice testowania w środowiskach zwirtualizowanych. Uruchamianie testów z maszyn wirtualnych (VM) zamiast z fizycznych hostów wprowadza dodatkową warstwę abstrakcji, która może znacząco wpłynąć na wyniki. Ruch sieciowy z VM musi przejść przez wirtualny przełącznik (vSwitch) hypervisora, co generuje dodatkowy narzut na CPU hosta. Wydajność jest uzależniona od konfiguracji vSwitcha, typu wirtualnej karty sieciowej (np. E1000 vs. VMXNET3 w VMware) oraz od aktualnego obciążenia fizycznego serwera. Jeśli inne maszyny wirtualne na tym samym hoście intensywnie korzystają z zasobów CPU, pamięci lub dysków, może to negatywnie wpłynąć na zdolność testowanej VM do generowania i odbierania ruchu sieciowego, prowadząc do zaniżonych wyników. Co więcej, zaawansowane funkcje sieciowe, takie jak SR-IOV (Single Root I/O Virtualization), które pozwalają na bezpośredni dostęp VM do fizycznej karty sieciowej, mogą drastycznie poprawić wydajność, ale ich brak może stanowić wąskie gardło. Dlatego interpretując wyniki z maszyn wirtualnych, należy zawsze brać pod uwagę kontekst całej platformy wirtualizacyjnej.

Praktyczne przykłady użycia iperf-ng

Uwaga: Wszystkie poniższe przykłady zakładają, że na maszynie docelowej (serwerze) o adresie IP 192.168.1.100 zostało uruchomione polecenie iperf-ng -s, które uruchamia serwer nasłuchujący na domyślnym porcie.

Testowanie TCP: okno i kierunek

1. Podstawowy test TCP w jedną stronę

To jest standardowy test wyjściowy, który mierzy przepustowość od klienta do serwera przy użyciu domyślnych ustawień systemu dla rozmiaru okna TCP.

iperf-ng -c 192.168.1.100
———————————————————————————-
[ 1] 0.00-10.00 sec 1.09 GBytes 938.45 Mbits/sec

Analiza: Wynik 938 Mbit/s jest typowy dla dobrze działającej sieci Gigabit Ethernet. Test ten stanowi punkt odniesienia dla dalszych pomiarów.

2. Test TCP z powiększonym rozmiarem okna

Zwiększamy rozmiar okna TCP do 1 MB (-w 1M), aby sprawdzić, czy pozwoli to na lepsze wykorzystanie łącza, zwłaszcza jeśli występują minimalne opóźnienia.

iperf-ng -c 192.168.1.100 -w 1M
———————————————————————————-
[ 1] 0.00-10.00 sec 1.10 GBytes 942.15 Mbits/sec

Analiza: Niewielki wzrost przepustowości sugeruje, że domyślne okno było już bliskie optymalnemu dla tej sieci LAN o niskim opóźnieniu. W sieciach WAN (o większych opóźnieniach) różnica byłaby znacznie bardziej dramatyczna.

3. Test TCP w dwie strony jednocześnie (Dual Test)

Flaga -d (--dualtest) uruchamia jednoczesny transfer w obu kierunkach: klient -> serwer oraz serwer -> klient. Pozwala to na ocenę wydajności w trybie pełnego dupleksu.

iperf-ng -c 192.168.1.100 -d
[ 1] 0.00-10.00 sec 560.12 MBytes 469.88 Mbits/sec
[ 2] 0.00-10.00 sec 545.88 MBytes 457.94 Mbits/sec

Analiza: Przepustowość w każdym kierunku wynosi około 460 Mbit/s. Suma obu wartości (ok. 927 Mbit/s) jest zbliżona do maksymalnej przepustowości łącza, co potwierdza prawidłowe działanie w trybie full-duplex. Każdy strumień otrzymuje mniej więcej połowę dostępnego pasma.

Testowanie UDP: bufor i kierunek

1. Podstawowy test UDP w jedną stronę

Test UDP wymaga zdefiniowania docelowej przepustowości. Ustawiamy ją na 100 Mbit/s (-b 100M), aby sprawdzić jakość łącza pod tym obciążeniem.

iperf-ng -c 192.168.1.100 -u -b 100M
[ 1] 0.00-10.00 sec 119.21 MBytes 100.00 Mbits/sec 0.015 ms 0/84949 (0.00%)

Analiza: Wynik jest idealny. Jitter na poziomie 0.015 ms i zerowa utrata pakietów (0/84949) oznaczają, że sieć bez problemu radzi sobie z takim strumieniem danych.

2. Test UDP z powiększonym rozmiarem bufora

Wysyłamy dane z bardzo dużą prędkością (950 Mbit/s) i zwiększamy rozmiar bufora systemowego do 2 MB (-w 2M), aby zapobiec gubieniu pakietów po stronie odbiorcy z powodu przepełnienia domyślnego, mniejszego bufora.

iperf-ng -c 192.168.1.100 -u -b 950M -w 2M
[ 1] 0.00-10.00 sec 1.11 GBytes 949.98 Mbits/sec 0.025 ms 12/815432 (0.0015%)

Analiza: Mimo wysokiej przepustowości i powiększonego bufora, zanotowano niewielką utratę pakietów (0.0015%). Może to wskazywać na granice wydajności stosu sieciowego systemu operacyjnego lub samego sprzętu. Zwiększenie bufora pomogło jednak utrzymać straty na minimalnym poziomie.

3. Test UDP w dwie strony jednocześnie

Uruchamiamy jednoczesny test UDP w obu kierunkach, każdy ze strumieniem 450 Mbit/s, aby obciążyć łącze symetrycznie blisko jego limitu.

iperf-ng -c 192.168.1.100 -u -b 450M -d
[ 1] 0.00-10.00 sec 536.55 MBytes 450.08 Mbits/sec 0.088 ms 432/382898 (0.11%)
[ 2] 0.00-10.00 sec 536.49 MBytes 450.03 Mbits/sec 0.091 ms 498/382850 (0.13%)

Analiza: Przy tak dużym, dwukierunkowym obciążeniu pojawiła się zauważalna, choć wciąż niewielka utrata pakietów (ok. 0.1%). Jitter również nieznacznie wzrósł. Wynik ten pokazuje, że sieć jest bliska punktu nasycenia, co jest cenną informacją diagnostyczną.

Dobre praktyki

Przeprowadzona analiza i przykłady jednoznacznie pokazują, że testowanie wydajności sieci to proces wymagający metodycznego podejścia i świadomości technologicznej. Narzędzie takie jak iperf-ng dostarcza potężnych mechanizmów do pomiaru, ale to od analityka zależy, jak te mechanizmy zostaną wykorzystane i jak zinterpretowane zostaną wyniki. Kluczem do sukcesu jest zrozumienie, że nie istnieje jeden, uniwersalny „test prędkości”. Wybór protokołu – TCP dla symulacji niezawodnych transferów lub UDP dla oceny jakości łącza pod kątem usług czasu rzeczywistego – fundamentalnie zmienia cel i metryki pomiaru. Dopiero świadome żonglowanie tymi protokołami pozwala na uzyskanie pełnego obrazu możliwości i ograniczeń badanej infrastruktury sieciowej.

Szczegółowa kontrola nad parametrami transmisji, takimi jak rozmiar okna TCP czy wielkość buforów, jest tym, co odróżnia profesjonalną diagnostykę od amatorskich pomiarów. Jak pokazały przykłady, nawet w wydajnej sieci lokalnej subtelne zmiany w konfiguracji mogą przynieść mierzalną poprawę. W bardziej złożonych środowiskach, jak sieci rozległe (WAN) czy infrastruktury centrów danych, umiejętność dostrajania tych parametrów staje się absolutnie krytyczna dla osiągnięcia optymalnej wydajności. Ignorowanie tych aspektów prowadzi często do błędnych wniosków, że sieć jest niewydajna, podczas gdy w rzeczywistości problem leży w nieoptymalnej konfiguracji systemów końcowych.

Analiza ruchu w różnych kierunkach, zwłaszcza jednoczesne testy dwukierunkowe, to kolejny niezbędny element rzetelnej oceny. W dobie aplikacji intensywnie komunikujących się w obie strony, weryfikacja zdolności sieci do pracy w trybie pełnego dupleksu pod dużym obciążeniem jest warunkiem koniecznym do zapewnienia stabilności i responsywności usług. Problemy ujawnione podczas takich testów często wskazują na głębsze kwestie konfiguracyjne lub sprzętowe, które pozostałyby niewykryte podczas prostych, jednokierunkowych pomiarów. Jest to zatem krok, którego nie można pomijać w procesie kompleksowego audytu sieci.

Szczególną ostrożność należy zachować podczas testowania środowisk zwirtualizowanych. Wyniki uzyskane z maszyn wirtualnych są zawsze wypadkową wydajności fizycznej sieci oraz narzutu i konfiguracji platformy wirtualizacyjnej. Należy je traktować jako pomiar wydajności „z perspektywy aplikacji” działającej w VM, a niekoniecznie jako odzwierciedlenie możliwości samego fizycznego łącza. Zrozumienie wpływu hypervisora, vSwitchy i współdzielenia zasobów jest kluczowe, aby uniknąć mylnej interpretacji wyników i nie obwiniać administratorów sieci za problemy leżące po stronie platformy serwerowej.

Podsumowując, iperf-ng jest wszechstronnym i precyzyjnym narzędziem, które w rękach świadomego użytkownika staje się nieocenionym instrumentem diagnostycznym. Efektywne wykorzystanie jego potencjału wymaga jednak systematycznego podejścia: rozpoczęcia od ustalenia punktu odniesienia (baseline), a następnie iteracyjnego modyfikowania poszczególnych zmiennych – protokołu, rozmiaru okna/bufora, kierunku – w celu wyizolowania i zrozumienia ich wpływu na końcową wydajność. Taka metodologia pozwala nie tylko precyzyjnie zidentyfikować „wąskie gardła” w sieci, ale również świadomie optymalizować jej konfigurację w celu osiągnięcia maksymalnej stabilności i przepustowości.

GNS3 – Tworzenie własnych szablonów urządzeń

Napisane przez Igor Brzeżek on 20 października 2025
Napisane w: Symulator sieci GNS3.

Contents
  1. Koncentrator z własną ikoną
  2. System RouterOS od MikroTik
  3. Konsola do systemu Linux

Pakiet GNS3 umożliwia utworzenie własnych szablonów urządzeń.

Koncentrator z własną ikoną

Utworzymy koncentrator z inna ikonką. Pozostałe elementy posiada on standardowe.
– otwieramy klienta GNS3
– z menu po lewej wybieramy ikonę Browse switches i kolejno New templatae

– możemy tu pobrać gotowca z repozytorium GNS3 ale tworzymy swoj więc wybieramy opcję Manualy create a new template
– klikamy next

– w oknie jakie się pojawi możemy utworzyć różne urządzenie my wybieramy Ethernet hubs


– klikamy u dołu New i z kolejnego okna wybieramy opcję gdzie nasze urządzenie ma być uruchomione; może to być inny serwer, maszyna wirtualna lub komputer przy którym pracujemy, wybieramy ostatnią opcję. 


– kolejno nadajemy nazwę naszemu urządzeniu i określamy ile ma mieć portów


– zatwierdzamy a kiedy urządzenie zostanie utworzone klikamy u dołu okna w Edit
– w kolejnym oknie możemy zmienić różne parametry naszego urządzenia, nas interesuje format nazwy (Dafault name format) oraz ikona (Symbol), jako nazwę dajmy Koncentrator{0} co oznacza, że kolejne obiekty tego typu w schemacie będą miały nazwę Koncentrator1, 2 itd


– zmienimy też ikonkę, można wyszukać w Google pod hasłem: „cisco hub 2900 svg transparent background” zostaną znalezione różne fajne ikony
– pobieramy dowolną np.

(fajnie kiedy ikona/obrazek ma przezroczyste tło)
– zapisujemy na dysku i wczytujemy w polu Symbol, wybieramy tam opcję Use a custom symbol

– na liście obiektów pojawi się nowy

– zatwierdzamy klikając OK

– możemy go użyć w projekcie

System RouterOS od MikroTik

Tutaj wykorzystamy uprzednio zainstalowany w VirtualBox RouterOS firmy MikroTik (informacje na temat instalacji znajdziesz w sekcji Do pobrania niniejszego kursu).
– klikamy w sekcję Browse end devices po lewej (jak w poprzednim przykładzie) i kolejno w New template

– kolejno wybieramy Manually create a new template
– no kolejnym oknie klikamy VirtualBox VMs

– a następnie u dołu okna w New
– wybieramy opcję uruchomienia na tym komputerze

– po chwili pojawi się okno z listą maszyn wirtualnych zarejestrowanych w VirtualBox (aby to zadziałało w opcjach GNS3 trzeba włączyć powiązanie z VirtualBox)
– wybieramy nasz wcześniej skonfigurowany RouterOS

– klikamy Finish i OK

– teraz do naszego projektu możemy przeciągnąć nowe urządzenie
– przed uruchomieniem warto zmienić jego parametry zgodnie z potrzebami (prawym klawiszem myszki na urządzeniu i Configure)

– dla podanych tu ustawień pojawi się okno maszyny wirtualnej oraz konsola do niej łącząca

– tego typu rozwiązanie (VBox) można także uruchomić w trybie bez okna maszyny, jest to opcja Headless mode, jednak w tym wypadku uważaj, jeśli maszyna wirtualna nie uruchomi się poprawnie to nic nie zobaczymy, maszyną taką można zarządzać jedynie zdalnie ssh/telnet

Konsola do systemu Linux

Program GNS3 udostępnia nam konsole na routery Cisco i MikroTik. Standardowo jednak nie możemy z niej korzystać celem podpięcia się pod np. Linux. Aby to było możliwe trzeba na systemie Linux dopisać coś do konfiguracji GRUB. Poniższe linie dodajemy na koniec pliku /etc/dafault/grub:

GRUB_CMDLINE_LINUX=”console=tty1 console=ttyS0,115200″
GRUB_TERMINAL=”console serial”
GRUB_SERIAL_COMMAND=”serial –speed=115200 –unit=0 –word=8 –parity=no –stop=1″

Plik zapisujemy i musimy uaktualnić GRUBa poleceniem:

#sudo update-grub

Po przeładowaniu Linux możemy już z GNS3 zalogować się do niego za pomocą konsoli.

GNS3 – Rewelacyjny symulator sieci

Napisane przez Igor Brzeżek on 20 października 2025
Napisane w: Symulator sieci GNS3.

Contents
  1. GNS3 – Graficzny Symulator Sieci
  2. Instalacja
  3. Podstawowa konfiguracja
  4. Urządzenia
  5. Szablony nowych urządzeń
  6. Utworzenie małego projektu
  7. Zapis i eksport projektów
  8. Dostęp do fizycznej sieci LAN

GNS3 – Graficzny Symulator Sieci

Jest to ciekawe i bardzo przydatne oprogramowanie symulatora sieci. Do pobrania z Githuba oraz ze strony projektu.

Pakiet GNS3 składa się z kilku elementów

– serwer zarządzający całością
– dynamips (emulator routerów Cisco)
– dedykowana maszyna wirtualna
– frontend czyli klient, aplikacja do instalacji (GUI)
– frontend jako web-klient czyli przez przeglądarkę

Możesz wszystko zainstalować na jednym komputerze ale możesz też na wielu. W tym wypadku na różnych komputerach instalujemy serwer oraz dynamips a na jednym klienta. Możemy też uruchomić wiele instancji maszyny wirtualnej. Wszystko to aby przyspieszyć pracę i umożliwić budowanie złożonych modeli sieci do symulacji. Możemy także uruchamiać wirtualne maszyny o dowolnej zawartości.

Typowa instalacja to serwer i klient (aplikacja do instalacji). W większości przypadków w zupełności wystarczy. Bardziej rozbudowana konfiguracja oznacza, że GNS3 pracuje na wielu maszynach. Graficznie możemy przedstawić to tak:

Minimalna instalacja to serwer GNS3 oraz klient (aplikacja do instalacji) choć poradzimy sobie równie dobrze za pomocą klienta webowego. Maszynę wirtualna konfigurujemy kiedy na komputerze z MS Windows chcemy uruchamiać emulowane przełączniki Cisco (można to wykonać tylko na Linux, a taki system pracuje w wspomnianej VM)..

Instalacja

Pobieramy ze strony GNS3 pakiet do instalacji dla naszego systemu oraz maszynę wirtualną (opcja)

Plik instalatora ma nazwę jak „GNS3-2.2.44.1-all-in-one-regular.exe”. Instalator uruchamiamy i i kilka razy klikamy Next. W oknie wyboru komponentów zaznaczamy dodatkowo pole „GNS3 WebClient a jeśli chcemy instalować także maszynę wirtualną to także i pole GNS3 VM

Po instalacji możemy uruchomić aplikację klienta.

 Po jej uruchomieniu chwilkę trzeba poczekać na uruchomienie serwera i połączenie się z nim co symbolizuje pojawianie się okna:

Aplikacja gotowa.

Możliwe, że pojawi się kreator jak niżej:

Tutaj musimy zdecydować czy używane rozwiązania (ang. appliances, czyli routery, przełączniki i inne) będą uruchamiane na maszynie wirtualnej, na komputerze lokalnym czy na zdalnym. Jeśli pracujemy na Windows to raczej powinniśmy wybrać opcję z maszyną wirtualną ponieważ pewne rozwiązania pracują tylko na Linux (a ten system jest na maszynie wirtualnej). Jeśli pracujesz na Linux możesz wybrać opcję komputera lokalnego. Maszyna wirtualna może pracować na Twoim komputerze lub na innym. Zajmuje ona oczywiście sporo zasobów i trzeba o tym pamiętać. Wszystko zależy od tego jakie urządzenia chcesz uruchamiać. Jeśli będą to routery Cisco i maszyny wirtualne z Windows czy Linux a pracujesz na Windows to możesz użyć opcji komputera lokalnego, jeśli pracujesz na MS Windows a chcesz uruchomić przełącznik Cisco to musisz wybrać opcję z maszyną wirtualną. Oczywiście wszystko później można konfigurować.

Teraz musimy zacząć od utworzenia nowego projektu (powstanie katalog z różnymi plikami)

Standardowo mamy elementy takie jak koncentrator, przełącznik (nie można ich konfigurować oprócz nazwy i ilości portów czy ikonki) oraz mały symulator komputera PC.

1 – okno schematu naszej sieci
2 – okno topologii czyli co z czym i jak jest połączone
3 – okno uruchomionych urządzeń i zasobów
4 – okno logów

Podstawowa konfiguracja

Znajduje się w Edit/Preferences. W większości przypadków jest domyślna poprawna musimy tylko dodać urządzenia. Moga to być
– routery Cisco (wymagany będzie firmware)
– przełączniki Cisco (j.w. i tylko na Linux lub z użyciem VM)
– dowolny system operacyjny pracujący w maszynie wirtualnej np. VirtualBox, QEmu, VMWare, Docker 

Sekcja Server
Najważniejsze opcje to
– czy lokalny serwer GNS3 działa
– port na jakim nasłuchuje, domyślnie 3080
– czy jest chroniony hasłem
(hasło można zmienić w plik konfiguracyjnym w lokalizacji %APPDATA%\GNS3 i tam gdzieś (zależnie od wersji) jest plik gns3_server.ini a w nim login i hasło (domyślnie gns3/gns3)

Jeśli nasza instalacja jest większa to możemy takie serwery uruchomić na innych komputerach i całością zarządzać z jednego klienta rozmieszczając urządzenia na różnych fizycznych maszynach co znacząco podniesie wydajność. Lista takich serwerów znajduje się na zakładce Remote servers.

Sekcja GNS3 VM
Opcje związane z główną maszyną wirtualną (to ta pobrana ze strony GNS3) z pracującym oprogramowaniem GNS3. Taka maszyny z Linux jest wymagany gdy chcemy emulować przełączniki Cisco (tzw. IOU) czego aktualnie nie da się wykonać na Windows.

Najważniejsze opcje
1 – Czy serwer GNS3 łączy się z główną VM
2 – Jaki hyperwizor ją utrzymuje
3 – Nazwa i port (te opcje znajdziemy w danej maszynie w VirtualBox)
4 – Ile przydzielimy jej procesorów i pamięci
5 – Co zrobić z maszyną kiedy zamykamy klienta GNS3

Jeśli maszyna wirtualna była pobrana z serwisu GNS3 i była wczytana do VBox to w jego menadżerze mamy wpis:

 

Urządzenia

Urządzenia znajdują się w sekcjach
-Routers (pojawią się tu routery, które trzeba skonfigurować samodzielnie, początkowo lista jest pusta)

Switches
Czyli hub, przełącznik Ethernet oraz ATM i FR

End devices
Różne urządzenia końcowe takie jak utworzone przez nas maszyny wirtualne.

Połączenie
Czyli „kabelki” łączące nasze urządzenia.

Szablony nowych urządzeń

W menu konfiguracji (Edit/Preferences) widnieje wiele opcji min. tworzenia nowych urządzeń. Poniżej kilka przykładów ważnych na nasze zajęcia:

Sekcja Dynamips (IOS routers):
to emulator routerów Cisco, trzeba „jedynie” posiadać plik z systemem operacyjnym, nie są dołączane do GNS3 ponieważ nie są darmowe.

Aby dodać taki router:
– klikamy w New
– decydujemy czy uruchamiamy go lokalnie czy w VM czy na innym serwerze

– trzeba wybrać obraz systemu operacyjnego dla danego routera
– kolejno wybrać nazwę i platformę sprzętową

– ilość pamięci (zależy od od wybranej platformy)
– karty rozszerzeń umieszczone w slotach routera (tu coś o kartach dla Cisco)
– kolejno należy wyznaczyć parametr Idle-PC, nie wchodzą w szczegóły jest to parametr wyliczany automatycznie i ma wpływ na zmniejszenie zużycia zasobów przez GNS3, klikamy w Idele-PC finder i czekamy grzecznie (zalecane jest w tym czasie nie klepać po klawiaturze o nie majtać myszką po ekranie)
– po pewny czasie pojawi się wartość, klikamy Finish i router gotowy
– jeden taki wpis dla routera możemy w naszym projekcie użyć dowolną ilość razy

Sekcja VirtualBox (VirtualBox VMs)
Tutaj możemy zaimportować uprzednio utworzone maszyny wirtualne
– po kliknięciu w New trzeba chwilę odczekać na połączenie z Vbox
– w poniższym przykładzie używamy gotowej maszyny o nazwie „debianek:

– klikamy
– po kliknięciu w New i Next poczekamy chwilkę na załadowanie list maszyn i możemy wybrać interesującą nas
– wybieramy maszynę i klikamy Finish i kolejno OK

Utworzenie małego projektu

Kiedy mamy symulator GNS3 skonfigurowany możemy uruchomić mały projekt. Wybieramy File / New blank project i na obszar roboczy przeciągamy:

przełącznik:

oraz dwa komputery:

Całość łączymy jak niżej za pomocą wirtualnego przewodu:

W przełączniku wybieramy dowolne porty:

W efekcie otrzymamy siec jak niżej:

Aby uruchomić komputery możemy na każdym z nich kliknąć prawym klawiszem myszki i kolejno Start albo na górnym pasku przycisk Start, co uruchomi wszystkie obiekty w naszym projekcie. Przełącznik zawsze jest uruchomiony.

Uruchomienie wszystkich obiektów:

Zapis i eksport projektów

Generalnie projekty zapisują się automatycznie. Możemy jednak zapisać projekt pod inna nazwą albo go eksportować.  W obu przypadkach wszystkie obiekty projektu muszą najpierw zostać zatrzymane (oprócz wbudowanego przełącznika czy koncentratora. Jeśli projekt eksportujemy celem przeniesienie na inny komputer musimy podać kilka parametrów. Gdzie zapiszemy, pod jaką nazwą, jakie opcje:

W lokalizacji docelowej pojawi się plik z rozszerzeniem: gns3project. Możemy go importować do innej instancji GSN3. Jeśli w projekcie będzie dużo elementów, plik wyjściowy będzie spory.

Dostęp do fizycznej sieci LAN

Dostęp ten zapewniają obiekty typu Cloud oraz fizyczne i logiczne interfejsy sieciowe pracujące na naszym komputerze. Tworzymy nowy projekt i przeciągamy elementy: VPCS, Switch, Cloud. Obiekt VPCS łączymy z przełącznikiem a ten z chmurą.

Kiedy klikniemy w chmurę pojawi się lista interfejsów sieciowych jakie mamy w komputerze. W moim przypadku jest tego sporo ponieważ mam zainstalowane różne wirtualne interfejsy (z VirtualBox, VMWare). Wybieramy ten, który łączy do fizycznej sieci, chyba, że chcemy łączyć projekt GNS z np. maszynami wirtualnymi. Jak sprawdzić, który interfejs jest właściwy? Na kilka sposobów ale chyba najszybszy to polecenie ipconfig wydane z konsoli:

Zastosowałem potok: ipconfig | more aby zatrzymało się po pierwszym ekranie. Tutaj karta sieciowa łącząca do fizycznej sieci LAN nazywa sie Ethernet i ta wykorzystamy w projekcie GNS3. Wracamy do niego: klikamy prawym klawiszem myszki na VPCS, uruchamiamy go klikając Start i przechodzimy na jego konsolę (znowu prawym i klikamy Console). Tutaj wydamy polecenie

>ip dhcp

Pozwala ono na pobranie adresu IP z sieci, w tym wypadku z naaszj sieci LAN, w której zapewne pracuje serwer DHCP.

Teraz sprawdzimy czy działa wydając polecenie ping:

Jeśli dostaniemy odpowiedź jak wyżej to znaczy, że nasz projekt ma dostęp do sieci lokalnej i zapewne dalej do Internetu.

PacketTracer – komunikacja Multi User

Napisane przez Igor Brzeżek on 20 października 2025
Napisane w: IT ogólnie.

PacketTracer i komunikacja typu Multiuser
Program PacketTracer zapewnia połączenie między swoimi instancjami pracującymi na różnych komputerach połączonych siecią LAN. Dzięki temu możemy modelować i symulować wspólnie, w grupie środowiska sieciowe.

Nie daje to jednak możliwości łączenia się z systemu Linux czy Windows do urządzeń pracujących w PT!

W tym przypadku wiele osób może współpracować z różnych komputerów budując wspólną sieć. Poniżej przykład:

Opcje związane z tym trybem znajdziemy w menu Extensions:

Generalnie możemy pracować jako klient sieci PT lub jego serwer (pozycja menu Listen) wykonując połączenie wychodzące do innej osoby lub przyjmując takie połączenia.

Przygotowanie serwera (nasłuchującego, PC1)
– Tworzymy prostą konfigurację

– W menu Extensions / Listen ustawiamy jak niżej hasło np: 123456 oraz automatyczne akceptowanie połączeń przychodzących. Nasz PT nasłuchuje na podanych adresach IP i porcie domyślnym 3800. Ten port musi być oczywiście na naszym lub sieciowym firewall odblokowany.

– Po konfiguracji schematu i ustaleni z jakich urządzeń korzystamy w naszym projekcie trzeba wystawić pewne ich porty dla połączeń przychodzących od klientów PT
– Otwieramy menu Extensions/Multiuser/Port Visibility i zaznaczamy porty, które chcemy udostępnić klientom łączącym się do naszej sieci w PT

Przygotowanie klienta (łączącego się z serwerem, PC2)
– Tworzymy prostą konfigurację

– Dodajemy element Multiuser Connection

– Klikamy weń i ustawiamy opcje:

– Wybieramy Outgoing
– Podajemy adres komputera docelowego (PC1)
– Podajemy port (jeśli inny niż domyślny)
– Podajemy nazwę połączenia, np. swoje imię
– Jeśli łączymy się z większą ilością sąsiadów możemy połączenie nazwać:

– Podajemy hasło ustalone na PacketTracer nasłuchującym
– Klikamy w Connect
– W tym momencie jak PT nasłuchującym pojawi się chmurka z nawą klienta a połączenie jest gotowe

– Aby teraz połączyć przełącznik B z przełącznikiem A (a tym samym oba laptopy) łączymy przełącznik B z chmurką wybierając odpowiedni port danego urządzenia (w tym wypadku port Fa0/1 jest zajęty na podłączenie laptopa A):

 – Od tego momentu można, przez fizyczną sieć komunikować się między instancjami PacketTracera pracującymi na różnych komputerach.

Zrozumienie „szybkości” sieci LAN

Napisane przez Igor Brzeżek on 20 października 2025
Napisane w: Pomiary w sieciach LAN.

Contents
  1. Bandwidth, Throughput, Goodput – Anatomia Prędkości w Sieciach LAN
  2. Bandwidth – Teoretyczny Potencjał Medium Transmisyjnego
  3. Throughput – Rzeczywista Przepustowość Systemu
  4. Goodput – Ilość Użytecznych Danych Aplikacji
  5. Praktyczne Pomiary Wydajności w Sieci LAN
  6. Narzędzia dla Systemu Linux
  7. Narzędzia w RouterOS
  8. Wpływ Rozmiaru Pakietu na Efektywność Transmisji
  9. TCP vs. UDP – Starcie o Przepustowość
  10. Chaos Jednostek – Bity, Bajty i Potęgi Dwójki
  11. Tabela Porównawcza Przedrostków Dziesiętnych i Binarnych
  12. Podsumowując

Bandwidth, Throughput, Goodput – Anatomia Prędkości w Sieciach LAN

W dyskursie dotyczącym technologii sieciowych, termin „prędkość sieci” jest używany nagminnie, lecz często w sposób nieprecyzyjny i mylący. Dla przeciętnego użytkownika jest to po prostu subiektywne odczucie szybkości ładowania stron internetowych czy pobierania plików. Jednak dla inżynierów sieci, administratorów i diagnostów, precyzyjne rozróżnienie pojęć opisujących wydajność medium transmisyjnego jest absolutnie fundamentalne. W rzeczywistości, za potocznym określeniem „prędkości” kryją się trzy odrębne, choć powiązane ze sobą metryki: Bandwidth (przepustowość teoretyczna), Throughput (przepustowość rzeczywista) oraz Goodput (przepustowość użyteczna). Zrozumienie subtelnych różnic między nimi jest kluczowe nie tylko do prawidłowego projektowania i zakupu infrastruktury sieciowej, ale również do efektywnego diagnozowania problemów z wydajnością, które nieuchronnie pojawiają się w każdej, nawet najlepiej zaprojektowanej sieci lokalnej (LAN).

Celem niniejszego artykułu jest dogłębna analiza i demistyfikacja tych trzech kluczowych pojęć. Posłużymy się w tym celu analogiami, które w obrazowy sposób przedstawią ich naturę, a także przeanalizujemy praktyczne aspekty ich pomiaru przy użyciu standardowych narzędzi diagnostycznych. Zgłębimy czynniki, które powodują nieuniknione różnice między wartością teoretyczną a tym, co realnie jesteśmy w stanie osiągnąć w praktyce. Na koniec zajmiemy się równie istotnym, a często pomijanym problemem chaosu jednostek – rozbieżności między systemem dziesiętnym (SI) używanym do określania prędkości transmisji a systemem binarnym, w którym operują systemy operacyjne przechowujące dane. Ta fundamentalna wiedza stanowi podstawę świadomego zarządzania wydajnością sieci i pozwala przejść od ogólnikowych stwierdzeń o „wolnym internecie” do konkretnej, opartej na danych analizy wąskich gardeł w infrastrukturze.

Bandwidth – Teoretyczny Potencjał Medium Transmisyjnego

Pojęcie Bandwidth, tłumaczone na język polski jako przepustowość teoretyczna lub pasmo przenoszenia, odnosi się do maksymalnej, teoretycznej ilości danych, która może zostać przesłana przez dany kanał komunikacyjny w jednostce czasu. Jest to wartość statyczna, określona na etapie projektowania standardu komunikacyjnego oraz fizycznych właściwości medium transmisyjnego i komponentów sieciowych. Najprostszą i najczęściej stosowaną analogią jest tutaj wielopasmowa autostrada – jej przepustowość to maksymalna liczba pojazdów, jaka mogłaby przez nią przejechać w idealnych warunkach. W kontekście sieci LAN, wartość ta jest zdefiniowana przez standardy takie jak IEEE 802.3ab dla Gigabit Ethernet (1 Gbps) i jest nierozerwalnie związana z możliwościami sprzętowymi: kart sieciowych (NIC), przełączników, routerów oraz jakością okablowania (np. Cat 5e vs Cat 6a).

Wartość bandwidth nie jest mierzona w czasie rzeczywistym podczas pracy sieci, lecz wynika bezpośrednio z jej architektury fizycznej i logicznej. O jej wysokości decydują takie czynniki jak częstotliwość sygnału oraz zaawansowane schematy kodowania sygnału (np. PAM-5 w Gigabit Ethernet). Jest to wartość laboratoryjna, osiągalna jedynie w warunkach idealnych. Mimo to, pojęcie bandwidth ma fundamentalne znaczenie, ponieważ ustanawia absolutny, nieprzekraczalny limit dla wszelkich innych metryk wydajności. Niezależnie od tego, jak bardzo zoptymalizujemy oprogramowanie i protokoły, nigdy nie osiągniemy transferu danych szybszego niż pozwala na to fizyczna przepustowość najwolniejszego elementu na całej ścieżce komunikacyjnej.

Throughput – Rzeczywista Przepustowość Systemu

O ile bandwidth jest teoretycznym maksimum, o tyle Throughput, czyli przepustowość rzeczywista, to metryka opisująca faktyczną ilość danych, która została pomyślnie przesłana przez sieć w danym okresie. Wracając do naszej analogii autostrady, throughput to realna liczba samochodów, która minęła określony punkt pomiarowy w ciągu godziny. Ta wartość jest z natury dynamiczna i niemal zawsze niższa od teoretycznej przepustowości. Przyczyną tej różnicy jest nieunikniony narzut protokołów komunikacyjnych (protocol overhead), opóźnienia (latency), kolizje pakietów, retransmisje oraz ograniczenia wydajnościowe samych urządzeń końcowych. Każdy pakiet danych, zanim zostanie wysłany, musi zostać „opakowany” w dodatkowe informacje – nagłówki warstw modelu OSI/ISO, które same w sobie zużywają część dostępnego pasma. To nie tylko poniżej pokazane protokoły UDP czy TCP ale masa innych.

Goodput – Ilość Użytecznych Danych Aplikacji

Idąc o krok dalej w precyzji pomiaru, dochodzimy do pojęcia Goodput, które można przetłumaczyć jako przepustowość użyteczną lub efektywną. Jest to najbardziej restrykcyjna i jednocześnie najbardziej miarodajna z perspektywy użytkownika końcowego metryka, ponieważ mierzy ona wyłącznie objętość danych aplikacji, które zostały pomyślnie dostarczone do docelowego odbiorcy. Goodput jest podzbiorem throughput. Oznacza to, że z wartości przepustowości rzeczywistej odejmujemy wszystko, co nie jest bezpośrednio „ładunkiem” (payload) interesującym dla aplikacji. W praktyce są to wszystkie pakiety kontrolne protokołu TCP (np. potwierdzenia ACK) oraz, co najważniejsze, wszystkie pakiety, które musiały zostać retransmitowane. W naszej analogii autostrady, goodput byłby liczbą pasażerów i towarów, które dotarły do celu, a nie liczbą pojazdów, które minęły punkt kontrolny. Odliczając narzut technologii oraz narzut protokołów zostaje nam jeszcze mniej.

Jednak na realną uzyskaną prędkość wpływ ma jeszcze wiele innych czynników: rodzaj połączenia (LAN/WiFi/GSM/SAT inne), w jaki sposób korzystamy ze źródła, jak obciążone jest źródło itp. Poniżej przykład pomiaru prędkości łącza od dostawcy po światłowodzie. Wykupiony abonament to 450/50 Mbps a wynik pomiaru mamy taki:

Pomiar prędkości łącza

Praktyczne Pomiary Wydajności w Sieci LAN

Teoretyczne rozważania nabierają sensu dopiero w konfrontacji z rzeczywistością. Zarówno w środowisku Linux, jak i RouterOS, dysponujemy szeregiem narzędzi pozwalających na precyzyjne zmierzenie i monitorowanie wydajności sieci, co jest podstawą skutecznej diagnostyki.

Narzędzia dla Systemu Linux

1. iperf3 – To absolutny standard w branży do pomiaru maksymalnego throughput między dwoma punktami. Testuje wydajność, generując ruch w pamięci RAM, minimalizując w ten sposób wpływ wydajności dysków twardych. Jest niezastąpiony przy weryfikacji jakości połączeń fizycznych i wydajności urządzeń sieciowych. Oprócz niego istnieje także nakładka graficzna Jperf, która ułatwia wizualizację wyników i konfigurację testów.

# Na maszynie serwera (np. 192.168.1.10) uruchamiamy iperf3 w trybie serwera
iperf3 -s

# Na maszynie klienta uruchamiamy test w kierunku serwera
iperf3 -c 192.168.1.10 -t 30 # Test TCP przez 30 sekund

# Wynik ~941 Mbits/sec dla sieci 1Gbps jest typowy.

Efekt działania pomiaru prędkości za pomocą iperf:

Podsumowanie pomiaru prędkości za pomocą iperf

Nakładka jperf w elegancki i czytelny sposób pokazuje graficzną reprezentacje naszych pomiarów.

Nakładka jperf na iperf (Linux)

2. iptraf-ng – To interaktywne narzędzie działające w konsoli, które pozwala na monitorowanie ruchu sieciowego w czasie rzeczywistym. Nie jest to narzędzie do benchmarków jak iperf, ale do obserwacji żywego ruchu. Pozwala zobaczyć natychmiastowy throughput dla poszczególnych połączeń, co jest bezcenne przy diagnozowaniu, która aplikacja lub usługa generuje w danym momencie największe obciążenie sieci. Umożliwia filtrowanie i analizę statystyczną ruchu według interfejsów, protokołów czy portów.

# Instalacja (Debian/Ubuntu)
sudo apt-get install iptraf-ng

# Uruchomienie z uprawnieniami roota
sudo iptraf-ng

# W menu wybieramy "Statistical breakdown by interface" -> "eth0"
# Obserwujemy kolumnę "Total Rate" aby zobaczyć aktualny throughput

Narzędzia w RouterOS

1. Bandwidth Test – To wbudowane w RouterOS narzędzie jest jego bezpośrednim odpowiednikiem iperf. Pozwala na precyzyjny pomiar throughput między dwoma urządzeniami Mikrotik lub między urządzeniem Mikrotik a komputerem z zainstalowanym oprogramowaniem Bandwidth Test. Jest to podstawowe narzędzie do weryfikacji wydajności mostów bezprzewodowych, tuneli VPN czy połączeń światłowodowych zarządzanych przez RouterOS.

MiktoTik bandwidth test

# Uruchomienie serwera testu na jednym urządzeniu RouterOS
/tool bandwidth-server

# Uruchomienie testu z drugiego urządzenia (klienta) w kierunku serwera (192.168.1.10)
/tool bandwidth-test address=192.168.1.10 user=admin protocol=tcp direction=both

2. Traffic Generator – To zaawansowane narzędzie służące do generowania bardzo specyficznych strumieni pakietów. W przeciwieństwie do Bandwidth Test, który ma na celu maksymalizację przepustowości, Traffic Generator pozwala na precyzyjne „wstrzykiwanie” do sieci ramek o określonej wielkości, z zadaną prędkością. Używa się go do testów warstwy drugiej (L2), sprawdzania wydajności przełączników pod obciążeniem (stress-testing) oraz weryfikacji, jak urządzenie radzi sobie z nietypowymi lub bardzo małymi pakietami, co jest kluczowe w diagnostyce wydajności VoIP.

# Wstrzyknięcie 1000 pakietów o rozmiarze 64 bajtów do interfejsu ether1
/tool traffic-generator inject interface=ether1 number-of-packets=1000 packet-size=64

Wpływ Rozmiaru Pakietu na Efektywność Transmisji

Jednym z najważniejszych, a często niedocenianych czynników wpływających na goodput, jest średni rozmiar pakietów w sieci. Każda porcja danych przesyłana przez sieć Ethernet musi zostać opakowana w strukturę zwaną ramką (frame). Ramka, oprócz właściwych danych (payload), zawiera szereg pól nagłówkowych koniecznych do jej zaadresowania i dostarczenia. Suma tych pól stanowi stały narzut, niezależny od ilości przesyłanych danych. Można to porównać do wysyłania paczek: niezależnie od tego, czy wysyłamy mały list, czy dużą paczkę, musimy użyć koperty i znaczka (narzut), które mają swoją wagę i koszt. Przesłanie 1 kg towaru w dziesięciu paczkach po 100g będzie znacznie mniej efektywne niż wysłanie go w jednej paczce 1 kg, ponieważ w pierwszym przypadku dziesięciokrotnie poniesiemy koszt „opakowania”. W sieci jest identycznie – transmisja dużej ilości małych pakietów (np. w telefonii VoIP) generuje procentowo znacznie większy narzut niż transfer dużych plików, co prowadzi do niższego goodputu, mimo że throughput może pozostać wysoki.

Ramka Ethernet

Standardowa ramka Ethernet II posiada narzut o łącznej wielkości 18 bajtów (adresy MAC, EtherType, suma kontrolna) plus 8 bajtów na preambułę i ogranicznik początku ramki (SFD), co daje łącznie 26 bajtów narzutu na poziomie fizycznym dla każdej przesyłanej ramki. Minimalna wielkość pola danych (payload) to 46 bajtów. W takim skrajnym przypadku, efektywność transmisji wynosi zaledwie 46 / (46 + 26) = 63.8%. Oznacza to, że ponad 36% pasma jest marnowane na same nagłówki! Z kolei dla maksymalnej standardowej wielkości pola danych, czyli 1500 bajtów (wartość znana jako MTU – Maximum Transmission Unit), efektywność rośnie do 1500 / (1500 + 26) = 98.3%. Ta prosta kalkulacja dobitnie pokazuje, dlaczego dla uzyskania wysokiej przepustowości użytecznej (goodput) kluczowe jest wykorzystywanie jak największych pakietów. Dlatego też technologie takie jak Jumbo Frames (ramki o MTU do 9000 bajtów) są powszechnie stosowane w sieciach SAN (Storage Area Network) i w klastrach obliczeniowych, gdzie liczy się każda cząstka wydajności.

TCP vs. UDP – Starcie o Przepustowość

Na ostateczną wartość throughput i goodput fundamentalny wpływ ma również wybór protokołu w warstwie transportowej modelu OSI – najczęściej jest to TCP (Transmission Control Protocol) lub UDP (User Datagram Protocol). TCP jest protokołem połączeniowym, zorientowanym na niezawodność. Zanim wyśle jakiekolwiek dane, nawiązuje sesję (proces tzw. three-way handshake), a następnie numeruje każdy pakiet i oczekuje od odbiorcy potwierdzenia jego otrzymania (ACK). W przypadku braku potwierdzenia, dane są retransmitowane. Cały ten mechanizm gwarantuje, że dane dotrą do celu w całości i w odpowiedniej kolejności, ale jego koszt jest ogromny: generuje dodatkowy ruch (pakiety ACK zużywają pasmo), wprowadza opóźnienia i wymaga mocy obliczeniowej do zarządzania stanem sesji. Z kolei UDP to jego całkowite przeciwieństwo – protokół bezpołączeniowy i zawodny. Działa na zasadzie „wyślij i zapomnij”. Nie nawiązuje sesji, nie numeruje pakietów, nie czeka na potwierdzenia. Jego nagłówek jest minimalistyczny. Dzięki temu UDP jest ekstremalnie szybki i cechuje się bardzo małym narzutem. Dlatego testy wydajności przeprowadzone za pomocą iperf3 w trybie UDP (iperf3 -c adres -u) niemal zawsze pokażą wyniki bliższe teoretycznemu bandwidth niż testy oparte na TCP. W praktyce UDP stosuje się tam, gdzie szybkość jest ważniejsza od 100% niezawodności, np. w streamingu wideo, grach online czy telefonii VoIP, gdzie okazjonalna utrata pojedynczego pakietu jest akceptowalna.

Chaos Jednostek – Bity, Bajty i Potęgi Dwójki

Precyzyjne omówienie metryk wydajności sieciowej byłoby niekompletne bez poruszenia fundamentalnego problemu, który od lat jest źródłem nieporozumień – niejednoznaczności w stosowaniu jednostek. W telekomunikacji prędkości transmisji podaje się z użyciem przedrostków dziesiętnych (SI), gdzie kilo (k) oznacza 1000, mega (M) to 1 000 000, a jednostką podstawową jest bit (b). Zatem 1 Gbps to jeden miliard bitów na sekundę. Tymczasem systemy operacyjne operują na przedrostkach binarnych, gdzie kilo oznaczało 1024, a podstawową jednostką jest Bajt (B). Aby rozwiązać ten chaos, wprowadzono standardy IEC/ISO, które definiują kibibajt (KiB), mebibajt (MiB) itd. Ta rozbieżność, sięgająca prawie 7.4% na poziomie giga, jest kluczowa przy interpretacji pomiarów i tłumaczeniu „dlaczego mój transfer 120 MB/s nie jest równy łączu 1 Gbps”.

Tabela Porównawcza Przedrostków Dziesiętnych i Binarnych

Przedrostek Dziesiętny (SI) Symbol Wartość (w Bajtach) Przedrostek Binarny (IEC) Symbol Wartość (w Bajtach) Różnica
kilobajt kB 103 = 1 000 kibibajt KiB 210 = 1 024 2.40%
megabajt MB 106 = 1 000 000 mebibajt MiB 220 = 1 048 576 4.86%
gigabajt GB 109 = 1 000 000 000 gibibajt GiB 230 = 1 073 741 824 7.37%
terabajt TB 1012 = 1 000 000 000 000 tebibajt TiB 240 = 1 099 511 627 776 9.95%

Podsumowując

Wyniki pomiaru prędkości łącza sieci zależą od wielu czynników. Omówiliśmy wybrane zagadnienia dotyczące prędkości w sieciach LAN takie jak właściwości fizyczne (bandwidth), kwestię narzutu protokołów i programów (throughput) oraz to, co nam zostaje (goodput). Kwestia samych pomiarów oraz ich sposobów zajmiemy się w innym wpisie.

Elementy bezpieczeństwa IT – Triada CIA

Napisane przez Igor Brzeżek on 20 października 2025
Napisane w: Bezpieczeństwo.

Contents
  1. Triada CIA i Heksada Parkera – Filary Bezpieczeństwa w Świecie IT
  2. Triada CIA – Klasyczne Podejście do Bezpieczeństwa
  3. Poufność (Confidentiality) – Chronić przed Niepowołanym Wzrokiem
  4. Integralność (Integrity) – Gwarancja Niezmienności Danych
  5. Dostępność (Availability) – Systemy Zawsze Gotowe do Pracy
  6. Heksada Parkera – Rozszerzenie Klasycznego Modelu
  7. Posiadanie/Kontrola, Autentyczność i Użyteczność

Triada CIA i Heksada Parkera – Filary Bezpieczeństwa w Świecie IT

W dzisiejszym zinformatyzowanym świecie, gdzie dane stały się najcenniejszą walutą, ich ochrona jest absolutnym priorytetem dla każdej organizacji i indywidualnego użytkownika. Każdego dnia słyszymy o nowych cyberatakach, wyciekach danych czy paraliżach systemów informatycznych, które przynoszą gigantyczne straty finansowe i wizerunkowe. Aby skutecznie bronić się przed tymi zagrożeniami, konieczne jest zrozumienie fundamentalnych zasad, na których opiera się cała dziedzina cyberbezpieczeństwa. Podstawą jest tutaj tak zwana Triada CIA, czyli model składający się z trzech kluczowych filarów: Poufności (Confidentiality), Integralności (Integrity) i Dostępności (Availability). Każdy z tych elementów odgrywa niezastąpioną rolę w budowaniu solidnej i odpornej na ataki infrastruktury IT, a ich zrozumienie jest pierwszym krokiem do świadomego zarządzania bezpieczeństwem.

Początki modelu CIA sięgają lat 70. XX wieku i są nierozerwalnie związane z rozwojem systemów komputerowych w wojsku i agencjach rządowych. To właśnie tam po raz pierwszy zdano sobie sprawę, że ochrona informacji to nie tylko kwestia jej ukrycia, ale także zapewnienia jej poprawności i ciągłej dostępności dla uprawnionych osób. Chociaż od tamtego czasu technologia poszła niesamowicie do przodu, a zagrożenia stały się znacznie bardziej zaawansowane, to właśnie te trzy proste zasady wciąż pozostają fundamentem. Model ten jest na tyle uniwersalny, że można go zastosować do oceny bezpieczeństwa praktycznie każdego systemu – od pojedynczego komputera osobistego, przez skomplikowane sieci korporacyjne, aż po rozległe systemy chmurowe. Zaniedbanie któregokolwiek z tych trzech filarów nieuchronnie prowadzi do powstania luki, która może zostać bezwzględnie wykorzystana przez cyberprzestępców.

Triada CIA – Klasyczne Podejście do Bezpieczeństwa

Triada CIA to koncepcyjny model, który stanowi rdzeń strategii bezpieczeństwa informacji w każdej firmie. Jego siła tkwi w prostocie i jednoczesnej kompleksowości, ponieważ obejmuje trzy najważniejsze aspekty ochrony danych. Bez względu na to, czy mówimy o zabezpieczaniu serwera plików, routera brzegowego w sieci, czy aplikacji webowej, zawsze musimy zadać sobie trzy fundamentalne pytania. Po pierwsze, czy dostęp do danych mają tylko i wyłącznie osoby do tego upoważnione? Po drugie, czy mamy pewność, że dane nie zostały w żaden sposób zmodyfikowane przez nieautoryzowane podmioty? I po trzecie, czy uprawnieni użytkownicy mogą uzyskać dostęp do danych i systemów wtedy, gdy tego potrzebują? Tylko pozytywna odpowiedź na wszystkie te pytania daje nam podstawy do stwierdzenia, że nasz system jest bezpieczny.

Poufność (Confidentiality) – Chronić przed Niepowołanym Wzrokiem

Poufność to nic innego jak zapewnienie, że informacje są dostępne wyłącznie dla autoryzowanych osób, systemów i procesów. W praktyce, w systemie Linux, poufność realizujemy na wielu poziomach. Podstawą są uprawnienia do plików i katalogów, szyfrowanie oraz bezpieczne protokoły komunikacji. Z kolei w środowisku RouterOS od Mikrotik, poufność zapewniamy poprzez silne hasła, wyłączenie niebezpiecznych usług oraz konfigurację bezpiecznych tuneli VPN.

# --- Przykłady poleceń dla Poufności (Linux) ---

# 1. Ustawienie restrykcyjnych uprawnień do pliku (tylko właściciel może czytać i pisać)
chmod 600 /home/user/sekretny_plik.txt

# 2. Szyfrowanie pliku za pomocą GnuPG (GPG)
gpg -c wazny_dokument.pdf

# 3. Bezpieczne łączenie się z serwerem zdalnym za pomocą SSH
ssh uzytkownik@192.168.1.100
# --- Przykłady poleceń dla Poufności (RouterOS) ---

# 1. Ograniczenie dostępu administracyjnego tylko do zaufanych adresów IP
/ip service set ssh address=192.168.88.0/24

# 2. Wyłączenie niezabezpieczonych usług (np. telnet i http)
/ip service disable telnet,www

# 3. Utworzenie użytkownika VPN (PPTP) z hasłem
/ppp secret add name=user_vpn password=BardzoSilneHaslo123 service=pptp

Integralność (Integrity) – Gwarancja Niezmienności Danych

Integralność danych oznacza utrzymanie ich spójności, dokładności i wiarygodności przez cały cykl życia. Chodzi o to, aby mieć pewność, że informacje nie zostały w nieautoryzowany sposób zmienione. W systemach Linux integralność plików systemowych i konfiguracyjnych możemy monitorować za pomocą narzędzi generujących sumy kontrolne. W RouterOS integralność samego systemu operacyjnego jest chroniona przez mechanizmy cyfrowego podpisywania pakietów, a administrator powinien dbać o spójność konfiguracji.

# --- Przykłady poleceń dla Integralności (Linux) ---

# 1. Wygenerowanie sumy kontrolnej SHA256 dla pliku
sha256sum obraz_iso_systemu.iso > obraz_iso_systemu.iso.sha256

# 2. Weryfikacja sumy kontrolnej pobranego pliku
sha256sum -c obraz_iso_systemu.iso.sha256

# 3. Sprawdzenie integralności zainstalowanych pakietów (dla systemów opartych na RPM)
rpm -Va
# --- Przykłady poleceń dla Integralności (RouterOS) ---

# 1. Wygenerowanie skryptu z aktualną konfiguracją w celu porównania zmian
/export file=konfiguracja_do_weryfikacji

# 2. Sprawdzenie, czy zainstalowane pakiety systemowe są poprawne
/system package check

# 3. Utworzenie binarnej, zabezpieczonej kopii zapasowej systemu
/system backup save name=backup_integralny.backup

Dostępność (Availability) – Systemy Zawsze Gotowe do Pracy

Dostępność to ostatni, ale nie mniej ważny element triady. Gwarantuje on, że systemy, aplikacje i dane są dostępne dla uprawnionych użytkowników wtedy, gdy są im potrzebne. Aby zapewnić wysoką dostępność w środowisku Linux, stosuje się szereg technik redundancyjnych oraz monitorowanie. W przypadku RouterOS, dostępność sieci można zwiększyć poprzez konfigurację protokołów routingu dynamicznego oraz stosowanie redundantnych łącz internetowych (failover).

# --- Przykłady poleceń dla Dostępności (Linux) ---

# 1. Sprawdzenie statusu usługi serwera WWW (np. nginx)
systemctl status nginx

# 2. Monitorowanie wykorzystania przestrzeni dyskowej, aby zapobiec awarii
df -h

# 3. Wyświetlenie aktywnego firewalla, aby upewnić się, że ruch nie jest blokowany
iptables -L -n -v
# --- Przykłady poleceń dla Dostępności (RouterOS) ---

# 1. Ustawienie drugiego, zapasowego łącza internetowego (failover)
/ip route add dst-address=0.0.0.0/0 gateway=10.0.2.1 distance=2

# 2. Użycie narzędzia Netwatch do monitorowania hosta i uruchomienia skryptu w razie awarii
/tool netwatch add host=8.8.8.8 down-script="/log info message=\"Brak połączenia z Google DNS\""

# 3. Konfiguracja interfejsu VRRP dla zapewnienia redundancji bramy domyślnej
/interface vrrp add name=VRRP1 interface=ether1 priority=254

Heksada Parkera – Rozszerzenie Klasycznego Modelu

Chociaż Triada CIA jest niezwykle użyteczna, Donn B. Parker zaproponował jej rozszerzenie, tworząc Heksadę Parkera. Dodaje ona do znanej nam już trójki trzy nowe, równie istotne elementy: Posiadanie/Kontrolę (Possession/Control), Autentyczność (Authenticity) oraz Użyteczność (Utility). To rozszerzenie pozwala na bardziej holistyczne spojrzenie na bezpieczeństwo, uwzględniając nie tylko samą informację, ale również kontekst jej przetwarzania i wykorzystania.

Posiadanie/Kontrola, Autentyczność i Użyteczność

Posiadanie/Kontrola odnosi się do fizycznego lub logicznego władania danymi i systemem. Autentyczność gwarantuje, że dane pochodzą z zaufanego źródła i że tożsamość użytkownika jest prawdziwa. Użyteczność odnosi się do tego, czy dane są w formacie, który jest zrozumiały i możliwy do efektywnego wykorzystania. Te trzy dodatkowe elementy pozwalają na pełniejszą analizę ryzyka.

# --- Przykłady poleceń dla Posiadania/Kontroli ---

# Linux: Sprawdzenie, kto jest aktualnie zalogowany do systemu
who -a

# RouterOS: Wyświetlenie aktywnych sesji użytkowników (np. WinBox, SSH)
/user active print

# Linux: Sprawdzenie, który proces używa danego pliku (sprawowanie kontroli)
lsof /var/log/syslog
# --- Przykłady poleceń dla Autentyczności ---

# Linux: Weryfikacja cyfrowego podpisu pliku za pomocą GPG
gpg --verify pobrany_plik.asc pobrany_plik

# RouterOS: Sprawdzenie statusu i autentyczności połączonych klientów VPN
/interface pptp-server print

# Linux: Generowanie pary kluczy SSH w celu uwierzytelniania bezhasłowego
ssh-keygen -t rsa -b 4096
# --- Przykłady poleceń dla Użyteczności ---

# Linux: Rozpakowanie archiwum, aby dane stały się użyteczne
tar -xzvf archiwum.tar.gz

# RouterOS: Wygenerowanie kompaktowego i czytelnego skryptu konfiguracyjnego
/export compact

# Linux: Konwersja kodowania pliku tekstowego na UTF-8, aby był czytelny
iconv -f ISO-8859-2 -t UTF-8 plik_wejsciowy.txt > plik_wyjsciowy.txt