Prezentacja powstała jako praktyczne uzupełnienie wykładów z sieci komputerowych.

Zamiast suchej teorii, każdy slajd koncentruje się na konkretnym poleceniu, jego składni i interpretacji wyników.

Wszystkie przykłady są testowane na rzeczywistych systemach operacyjnych.

Znajomość narzędzi diagnostycznych jest jedną z kluczowych umiejętności administratora sieci.

W sytuacji awarii to właśnie te narzędzia pozwalają szybko zlokalizować problem: czy to problem z kablem (ping na bramę), z routingiem (traceroute do zdalnego hosta), z DNS (nslookup), czy z zaporą ogniową (nmap, telnet).

Prezentacja zakłada podstawową znajomość adresacji IP i modelu OSI/TCP/IP.

Narzędzia są uporządkowane według warstw: od warstwy 3 (ping, traceroute) przez warstwę 4 (netstat, ss, nmap) do warstwy 7 (nslookup, curl, wget).

Prezentacja podzielona jest na trzy bloki.

Blok pierwszy (slajdy 4-10) obejmuje narzędzia warstwy 3: ping i ARP.

Blok drugi (slajdy 11-17) to narzędzia warstwy 4 i trasowania: netstat, ss, traceroute, mtr, pathping.

Blok trzeci (slajdy 18-30) to narzędzia wyższych warstw i pomocnicze: nslookup/dig, ipconfig/ip, route, nmap, telnet/nc, curl/wget, tcpdump.

Każde narzędzie jest przedstawione według schematu: składnia + opis opcji, przykład na Linux, przykład na Windows, interpretacja wyników.

W przypadkach gdy narzędzie jest dostępne tylko na jednej platformie (np. ss tylko Linux, pathping tylko Windows), jest to wyraźnie zaznaczone.

Literatura dotycząca narzędzi sieciowych jest bogata.

Nmap Reference Guide to oficjalna dokumentacja najpopularniejszego skanera portów.

Książka Tanenbauma oferuje teoretyczne podstawy protokołów, które są niezbędne do zrozumienia działania narzędzi.

Publikacje Pytla i Szymanka koncentrują się na praktycznych aspektach diagnostyki.

Biblia administratora Linux to kompendium wiedzy o poleceniach systemowych.

Dokumentacja Microsoft i Linux (man pages) są podstawowym źródłem informacji o składni i opcjach.

Wireshark User Guide to obszerny podręcznik analizy ruchu sieciowego.

Metoda bottom-up (od L1 w górę) jest bezpieczniejsza dla początkujących - zaczynasz od fizycznego połączenia i stopniowo sprawdzasz wyższe warstwy.

Metoda top-down (od L7 w dół) jest szybsza dla doświadczonych - jeśli aplikacja nie działa, sprawdzasz najpierw DNS i port, a potem schodzisz niżej.

Większość narzędzi pokazanych w tej prezentacji jest dostępna w każdym systemie operacyjnym bez dodatkowej instalacji.

Uwaga: nmap, tcpdump, mtr, traceroute, iperf3, ethtool wymagają instalacji (pakiety w Linux, pobranie w Windows).

W systemie Linux narzędzia znajdują się w pakietach: iproute2 (ip, ss), net-tools (netstat, ifconfig), dnsutils (dig, nslookup), traceroute, nmap, tcpdump, mtr, ethtool.

Nie wszystkie z tych pakietów są domyślnie zainstalowane - często trzeba je doinstalować przez menedżera pakietów.

ICMP jest zdefiniowany w RFC 792.

Znajomość typów ICMP pomaga w interpretacji komunikatów błędów.

W Windows domyślnie wysyła 4 pakiety i kończy działanie.

TTL (Time to Live) to liczba skoków (hopów), jakie pakiet może przebyć.

Oprócz Echo Request/Reply (typ 8/0) ICMP zawiera także: Destination Unreachable (typ 3, kody 0-15), Time Exceeded (typ 11, używany przez traceroute), Redirect (typ 5), Parameter Problem (typ 12).

Niektóre zapory ogniowe blokują ICMP, uznając go za zagrożenie bezpieczeństwa.

W takim przypadku ping nie działa, ale inne usługi (HTTP, SSH) mogą działać poprawnie.

W sieci produkcyjnej ICMP powinien być odblokowany selektywnie - blokowanie go utrudnia diagnostykę.

Z drugiej strony atak ping flood (ICMP flood) może przeciążyć sieć, dlatego firewalle często limitują ICMP.

W Linux ping domyślnie wysyła pakiety w nieskończoność (aż do Ctrl+C).

Jeśli ping zwraca 'Time to live expired', oznacza to, że pakiet przekroczył maksymalną liczbę skoków - można zwiększyć TTL opcją -t (Linux) lub -i (Windows).

Standardowy MTU dla Ethernet to 1500 B.

Rozmiar pakietu ping ma znaczenie przy testowaniu MTU (Maximum Transmission Unit).

Nagłówek IP to 20 B, ICMP to 8 B, więc maksymalny rozmiar danych to 1500 - 20 - 8 = 1472 B.

Jeśli ping z rozmiarem 1472 działa, ale 1473 nie, oznacza to problem z fragmentacją pakietów (możliwe, że gdzieś na trasie jest niższe MTU).

Problem ten jest znany jako PMTUD black hole i występuje często w tunelach VPN (PPPoE, IPsec).

W Windows opcja -f (Don't Fragment) ustawia bit DF w nagłówku IP.

W Linux odpowiednikiem jest -M do (don't fragment) lub -M want (z fragmentacją).

Test MTU: ping -f -l 1472 8.8.8.8 (Windows) lub ping -M do -s 1472 8.8.8.8 (Linux).

Jeśli pakiet jest za duży, dostajemy 'Packet needs to be fragmented but DF set' (Windows) lub 'Message too long' (Linux).

Przy analizie wyników ping warto zwracać uwagę na: czas RTT (im niższy tym lepszy, poniżej 20 ms w sieci lokalnej), straty pakietów (packet loss) - każda strata to potencjalny problem z łączem, oraz wariancję (jitter) - duże różnice między kolejnymi pomiarami mogą świadczyć o przeciążeniu łącza.

Uwaga: jeśli pierwszy pakiet ma duży czas, a kolejne małe, to pierwszy pakiet wymagał rozgłoszenia ARP (ARP delay).

Przykład 1 pokazuje normalne działanie ping w sieci LAN.

Czas 1.23 ms to typowy RTT dla sieci lokalnej.

TTL = 64 w odpowiedzi - początkowy TTL zależy od systemu: Linux domyślnie wysyła z TTL=64 (64-64=0 hopów), Windows z TTL=128 (128-64=64 hopów).

Przykład 2 pokazuje ping na adres domenowy. Najpierw system rozwiązuje nazwę google.com na adres IP (142.250.185.78), potem wysyła ICMP.

TTL = 118 - startowe TTL na serwerze Google wynosi prawdopodobnie 128 (128-118 = 10 hopów).

To kluczowa informacja diagnostyczna.

W statystyce: min/avg/max to wartości minimalna, średnia i maksymalna RTT. mdev (population standard deviation - odchylenie standardowe populacji) - im niższe, tym stabilniejsze łącze.

Przykład 3 pokazuje komunikat 'Destination Host Unreachable' od routera.

Oznacza to, że router (192.168.1.1) nie ma trasy do sieci docelowej.

W przeciwieństwie do braku odpowiedzi (timeout), ten komunikat jednoznacznie wskazuje na brak trasy w tablicy routingu.

Po otrzymaniu odpowiedzi ARP, wpis jest dodawany do tablicy.

Tablica ARP jest kluczowym elementem komunikacji w sieci lokalnej.

Każdy host przed wysłaniem pakietu IP sprawdza tablicę ARP, aby poznać adres MAC odbiorcy.

Jeśli wpis nie istnieje, host wysyła ARP Request (broadcast) i czeka na ARP Reply.

Czas życia wpisu ARP (ARP cache timeout) ma istotne znaczenie praktyczne.

Zbyt długi czas (Cisco IOS: 4 godziny) powoduje, że zmiana adresu MAC (np. wymiana karty sieciowej) nie jest wykrywana przez długi czas.

Zbyt krótki czas (Windows: 120 s) generuje zbędny ruch broadcast ARP.

W stabilnych sieciach LAN dłuższy czas jest korzystny (mniej ruchu ARP), w sieciach z częstymi zmianami (Wi-Fi, laptopy) krótszy czas jest lepszy.

Statyczne wpisy ARP (arp -s w Windows, ip neigh add w Linux) są używane do ochrony przed atakami ARP spoofing.

Dodają trwałe mapowanie IP-MAC, które nie może być nadpisane przez fałszywy ARP Reply.

Wadą jest konieczność ręcznej aktualizacji po zmianie sprzętu.

W praktyce produkcyjnej statyczne ARP stosuje się dla serwerów i routerów, a dla stacji roboczych pozostawia wpisy dynamiczne z ochroną ARP (DAI) na przełączniku.

W Windows tablica ARP jest per-interfejs.

Opcja -a bez parametru pokazuje wszystkie tablice.

Jest to pierwszy krok w diagnostyce problemów L2.

Jeśli komputer ma wiele kart sieciowych (LAN, Wi-Fi, VPN), każda ma własną tablicę ARP.

Opcja -N if_addr pokazuje tablicę dla konkretnego interfejsu (według adresu IP).

Różnica między arp -s a netsh dla statycznych wpisów ARP jest istotna. arp -s dodaje wpis tylko w pamięci - po restarcie znika. netsh interface ipv4 set neighbors dodaje wpis do rejestru (HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}), który jest odtwarzany po restarcie.

W systemach serwerowych Windows Server zaleca się używanie netsh zamiast arp -s.

W praktyce diagnostycznej arp -a jest używane głównie do sprawdzenia, czy dany host jest osiągalny w sieci LAN.

Jeśli host widnieje w tablicy ARP, oznacza to, że odpowiedział na ARP Request - jest fizycznie podłączony i ma skonfigurowany adres IP.

Jeśli nie ma wpisu, ping na ten host nie zadziała na poziomie L2 (brak adresu MAC).

Status FAILED oznacza brak odpowiedzi na sondy ARP.

Wpis PERMANENT jest zawsze obecny w tablicy i nie wygasa.

Jego adres MAC nie może być zmieniony przez ARP Reply.

To odpowiednik statycznego wpisu w Windows.

Narzędzie ip neigh jest częścią pakietu iproute2, standardowo zainstalowanego w każdej dystrybucji Linux.

W przeciwieństwie do arp (z net-tools), które jest uznawane za przestarzałe, ip neigh oferuje bogatsze informacje i lepszą integrację z jądrem Linux.

Stare narzędzia (arp, ifconfig, route, netstat) są w wielu dystrybucjach oznaczane jako deprecated.

Statusy w ip neigh odpowiadają stanom NUD (Neighbor Unreachability Detection) z RFC 2461.

REACHABLE oznacza, że wpis został potwierdzony w ciągu ostatnich 30-60 s.

STALE oznacza, że wpis wygasł i przy następnej transmisji system wyśle sondę ARP.

DELAY to krótki stan (5 s) po użyciu STALE wpisu - system czeka, czy nie nadejdzie potwierdzenie z wyższej warstwy (np. TCP).

PROBE to stan, w którym system wysyła sondy ARP (co 1 s, do 3 razy).

Wpis reachable (bez parametru permanent) ma ustawiony czas życia (domyślnie 30 s), po którym przechodzi w STALE.

W przypadku konfiguracji sieciowych na serwerach często dodaje się wpisy PERMANENT dla routera (bramy domyślnej) i kluczowych serwerów.

W systemach Linux nowsze dystrybucje (Debian 10+, Ubuntu 18.04+) nie instalują netstat domyślnie.

Zamiast tego dostępne jest ss z pakietu iproute2.

Aby zainstalować netstat w Linux: apt install net-tools (Debian/Ubuntu) lub yum install net-tools (RHEL/CentOS).

Windows ma netstat wbudowany w system.

Wyjście netstat pokazuje: Proto (protokół), Local Address (adres lokalny), Foreign Address (adres zdalny), State (stan połączenia TCP).

Stany TCP: LISTEN (nasłuchiwanie), ESTABLISHED (ustanowione połączenie), TIME_WAIT (oczekiwanie na zamknięcie), CLOSE_WAIT (oczekiwanie na zamknięcie przez aplikację), SYN_SENT (wysyłanie SYN).

Duża liczba połączeń w stanie TIME_WAIT jest normalna przy krótkich połączeniach HTTP (wiele zapytań).

Duża liczba CLOSE_WAIT oznacza, że aplikacja nie zamyka prawidłowo połączeń - to problem aplikacji, nie sieci.

Duża liczba SYN_RECV może oznaczać atak SYN flood.

Uwaga: w systemie Linux opcja -p w netstat wymaga uprawnień root (sudo), aby pokazać nazwy procesów.

[::]:135 to nasłuch na IPv6.

Przykład pokazuje, jak sprawdzić, które usługi nasłuchują na porcie.

W Windows 0.0.0.0:445 oznacza, że usługa nasłuchuje na wszystkich interfejsach IPv4 na porcie 445 (SMB).

192.168.1.10:139 oznacza nasłuch tylko na konkretnym interfejsie.

PID (Process ID) pozwala zidentyfikować proces za pomocą tasklist (Windows) lub ps aux (Linux).

W Linux opcja -t (TCP), -u (UDP), -l (listening), -p (program), -n (numeryczne) jest standardowym zestawem do diagnostyki.

Opcja -a zamiast -l pokazuje też połączenia ESTABLISHED. netstat -s wyświetla statystyki protokołów - przydatne do wykrywania utraconych pakietów (retransmisje, błędy TCP).

W Windows netstat -b (zamiast -o) pokazuje bezpośrednio nazwę procesu zamiast PID, ale wymaga uprawnień administratora. netstat -e wyświetla statystyki interfejsów Ethernet (wysłane/odebrane pakiety, błędy). netstat -r wyświetla tablicę routingu - użyteczne do szybkiego sprawdzenia tras.

Niższa metryka = wyższy priorytet.

Tablica routingu hosta jest podstawą decyzji o przekazywaniu pakietów.

Każdy pakiet IP jest porównywany z wpisami w tablicy według zasady najdłuższego dopasowania prefiksu (longest prefix match).

Jeśli pasuje do 0.0.0.0/0 (trasa domyślna), system używa bramy domyślnej.

Jeśli pasuje do konkretnej sieci (jak 192.168.1.0/24), system wysyła pakiet bezpośrednio (przez ARP).

W Windows metryka jest obliczana automatycznie na podstawie szybkości interfejsu.

Dla interfejsów przewodowych (1 Gbps) metryka jest niższa niż dla Wi-Fi (ok. 25 vs 55).

Można zmienić metrykę ręcznie w ustawieniach interfejsu (odznacz 'Automatic metric').

Jeśli system ma dwa interfejsy (LAN i Wi-Fi) z trasami do tej samej sieci, użyje tego z niższą metryką.

W Linux routing jest zarządzany przez ip route z pakietu iproute2.

Wpisy 'proto dhcp' oznaczają, że trasa została dodana przez klienta DHCP. 'proto kernel' oznacza trasę dodaną przez jądro (dla sieci bezpośrednio podłączonych). 'scope link' oznacza, że trasa dotyczy tylko bezpośrednio podłączonych hostów (bez routera).

Ręczne dodanie trasy: ip route add 10.0.0.0/24 via 192.168.1.254 dev eth0.

ss jest zalecanym zamiennikiem netstat w systemie Linux.

Uwaga: opcja -p (proces) w ss wymaga uprawnień root (sudo).

W normalnych warunkach Recv-Q i Send-Q powinny być bliskie 0.

Składnia: ss [opcje] [filtr].

ss oferuje zaawansowane filtry: ss state established (dla ustanowionych połączeń), ss state time-wait (oczekujące), ss sport = :80 (źródłowy port 80), ss dport = :443 (docelowy port 443), ss dst 192.168.1.0/24 (docelowa sieć).

Główne zalety: szybsze działanie (szczególnie przy dużej liczbie połączeń), bogatsze informacje (Recv-Q, Send-Q pokazują ilość danych w buforze), możliwość filtrowania według stanu, portu, adresu. netstat był oznaczony jako deprecated w wielu dystrybucjach już od lat.

Recv-Q i Send-Q w ss to ilość danych (w bajtach) czekających w buforze odbiorczym i nadawczym.

Jeśli Recv-Q rośnie, oznacza to, że aplikacja nie odbiera danych wystarczająco szybko (problem z aplikacją).

Jeśli Send-Q rośnie, oznacza to, że druga strona nie potwierdza danych (problem sieciowy lub przeciążenie odbiorcy).

Przykład: ss -tan sport = :80 or dport = :80 - wszystkie połączenia związane z portem 80.

W Windows nie ma ss - odpowiednikiem jest netstat -ano.

ss state time-wait pokazuje połączenia oczekujące na zamknięcie.

Standardowo TIME_WAIT trwa 2*MSL (Maximum Segment Lifetime) = 60 s (Linux).

Jeśli liczba TIME_WAIT jest bardzo duża (tysiące), może wyczerpać pulę portów efemerycznych (32768-60999 w Linux).

W takim przypadku serwer nie będzie mógł nawiązywać nowych połączeń wychodzących.

Rozwiązania: włączenie reuse/tw_reuse w jądrze (sysctl), zwiększenie zakresu portów efemerycznych, lub optymalizacja aplikacji.

W praktyce administracyjnej ss jest najczęściej używane w trzech scenariuszach: (1) sprawdzenie, czy usługa nasłuchuje (ss -tuln | grep :port), (2) sprawdzenie liczby aktywnych połączeń (ss -tan | wc -l), (3) sprawdzenie, który proces używa portu (ss -tulnp | grep :port).

W przypadku podejrzenia ataku DDoS, ss pokazuje liczbę połączeń SYN_RECV z różnych adresów IP.

W systemach embedded (OpenWrt, MikroTik RouterOS) ss może nie być dostępne.

W macOS ss jest dostępny od wersji 10.12+ (Sierra), ale niektóre opcje się różnią.

Uwaga: traceroute nie jest domyślnie zainstalowany w wielu dystrybucjach Linux. Należy go doinstalować: apt install traceroute.

Alternatywnie można użyć tracepath (z iputils-tracepath), który jest lżejszy i często domyślnie dostępny.

Większość tras w Internecie mieści się w 10-20 hopach.

Różnica w domyślnym protokole między Linux (UDP) a Windows (ICMP) ma znaczenie praktyczne.

Niektóre routery i zapory mogą blokować UDP, ale przepuszczać ICMP (lub odwrotnie).

Jeśli traceroute (Linux) nie działa, warto spróbować opcji -I (ICMP) lub -T (TCP SYN).

Jeśli tracert (Windows) nie działa, warto spróbować traceroute z Linux lub zainstalować WinMTR.

Wynik traceroute pokazuje: numer skoku (hop), adres IP routera, nazwę DNS (jeśli -n nie użyto), i trzy czasy RTT dla trzech prób.

Gwiazdki (* * *) oznaczają brak odpowiedzi - router mógł zablokować ICMP Time Exceeded lub pakiet zaginął.

Trzy gwiazdki nie oznaczają koniecznie problemu - niektóre routery celowo nie odpowiadają na pakiety z TTL=0 (ze względów bezpieczeństwa).

Maksymalna liczba skoków to 30 (domyślnie w Windows tracert i Linux traceroute).

Jeśli trasa ma więcej niż 30 hopów, należy zwiększyć limit opcją -m (Linux) lub -h (Windows).

Drugi skok (10.0.0.1) to pierwszy router ISP.

Kolejne skoki to routery szkieletowe dostawcy Internetu.

Ostatni skok to docelowy serwer.

Interpretacja wyników traceroute: pierwszy skok (hop 1) to zawsze brama domyślna (192.168.1.1 w przykładzie).

Czas RTT dla każdego skoku rośnie wraz z odległością, ale nie zawsze - zależy od obciążenia routera i przepustowości łącza.

W przykładzie widzimy: hop 1 (1 ms) - sieć lokalna, hop 2-3 (4-9 ms) - sieć ISP, hop 4 (12 ms) - router szkieletowy (prawdopodobnie węzeł krajowy), hop 5 (8 ms) - docelowy serwer Google (niższy czas niż hop 4, bo to już serwer Google, a nie router pośredni).

Jeśli któryś hop pokazuje czas > 100 ms, oznacza to łącze satelitarne lub transatlantyckie.

W przypadku problemów: jeśli traceroute zatrzymuje się na jednym hopie (kolejne skoki to *** *** ***), oznacza to, że router nie odpowiada na ICMP Time Exceeded (częste w sieciach ISP) lub routing jest przerwany za tym routerem.

Jeśli ping na adres docelowy nie działa, a wcześniejsze skoki są OK, to prawdopodobnie firewall blokuje ruch.

mtr jest nieocenionym narzędziem do diagnostyki problemów z jakością łącza.

Pokazuje nie tylko trasę, ale także procent strat na każdym skoku.

Jeśli na hoście 3 widzisz 10% strat, a na hoście 1 i 2 straty są 0%, oznacza to, że problem jest na łączu między hostem 2 a hostem 3 (lub na samym hoście 3).

Kolumny w mtr: Loss% - procent utraconych pakietów, Snt - liczba wysłanych pakietów, Last - czas ostatniego pomiaru, Avg - średni czas, Best - najlepszy czas, Wrst - najgorszy czas, StDev - odchylenie standardowe.

Wysokie StDev oznacza dużą zmienność opóźnienia (jitter), co jest szkodliwe dla aplikacji czasu rzeczywistego (VoIP, streaming).

W praktyce administracyjnej mtr jest często używane do: (1) sprawdzenia, gdzie na trasie występują straty pakietów, (2) porównania jakości dwóch tras do tego samego celu, (3) monitorowania łącza w czasie rzeczywistym podczas zgłaszania problemu.

W przypadku reklamacji u dostawcy Internetu, wydruk z mtr jest standardowym dowodem problemów z łączem.

pathping działa w dwóch fazach.

Faza 1: śledzenie trasy (jak tracert) - trwa do 30 s.

Całkowity czas działania: ok. 2 minuty.

Opcja -q zmniejsza liczbę pakietów (np. -q 25 = ok. 30 s).

Faza 2: wysyłanie pakietów testowych do każdego skoku - trwa domyślnie 125 s (5 s na skok * 25 hopów).

W tym czasie pathping wysyła 100 pakietów ICMP do każdego routera na trasie i zbiera statystyki.

W kolumnie 'This Node/Link' pathping pokazuje straty pakietów na konkretnym hopie.

Jeśli hop 3 ma 5% strat, a hop 2 ma 0% strat, to problem jest na łączu między hop 2 a hop 3 (lub na samym hop 3).

Kolumna 'Source to Here' pokazuje skumulowane straty od źródła do tego hopu.

Ograniczenia pathping: (1) działa tylko na Windows, niektóre routery nie odpowiadają na ICMP Time Exceeded, (2) długi czas działania (minuta+), (3) nie pokazuje jitteru (tylko straty).

W praktyce administracyjnej pathping jest używane do weryfikacji reklamacji u dostawcy Internetu - wydruk z pathping pokazujący straty na konkretnym hopie jest trudny do zakwestionowania.

dig jest bardziej zaawansowany niż nslookup i zalecany w Linux.

Pokazuje: nagłówek odpowiedzi (status NOERROR, NXDOMAIN, SERVFAIL), czas życia rekordu (TTL = 300 s w przykładzie), typ rekordu (A dla IPv4, AAAA dla IPv6, MX dla mail, CNAME dla aliasu), zapytany serwer (192.168.1.1#53). dig +short pokazuje tylko adres IP (skrócony wynik). dig -x 8.8.8.8 wykonuje reverse DNS lookup (z adresu na nazwę).

W praktyce diagnostycznej: nslookup jest wystarczające do podstawowej diagnostyki (sprawdzenie, czy domena się rozwiązuje). dig jest niezbędne do zaawansowanej diagnostyki DNS (SOA, autorytatywne serwery, transfer strefy). dig axfr @ns1.example.com example.com wykonuje transfer strefy (ale większość serwerów blokuje).

Typowe problemy DNS: (1) NXDOMAIN - domena nie istnieje, (2) SERVFAIL - serwer DNS nie może odpowiedzieć (problem z autorytatywnym serwerem), (3) REFUSED - serwer odrzucił zapytanie (np. zablokowane).

Czas odpowiedzi DNS (Query time w dig) powinien być poniżej 50 ms dla lokalnego serwera DNS.

Długi czas oznacza problem z łączem do serwera DNS lub przeciążenie.

Brak flagi LOWER_UP to najszybszy test warstwy 1.

ipconfig /all to najczęściej używane polecenie w Windows do diagnostyki sieci.

Pokazuje: adres IP (IPv4 i IPv6), maskę podsieci, bramę domyślną, serwery DNS, serwer DHCP, adres MAC (Physical Address), czas dzierżawy DHCP. ipconfig /release zwalnia adres, ipconfig /renew odświeża go. ipconfig /displaydns pokazuje lokalny cache DNS, ipconfig /flushdns czyści go.

W Linux ip (z pakietu iproute2) zastępuje przestarzałe ifconfig, route i arp. ip addr show [interfejs] - adresy IP, ip link show - interfejsy, ip neigh show - tablica ARP, ip route show - tablica routingu.

W przeciwieństwie do Windows, Linux nie ma jednego polecenia pokazującego wszystko - trzeba użyć kilku rozdzielnych komend.

Flagi interfejsu w Linux: UP (aktywny), LOWER_UP (sygnał nośny), BROADCAST (obsługa broadcast), MULTICAST (obsługa multicast).

Jeśli brak LOWER_UP, oznacza to brak fizycznego połączenia (kabel odłączony, switch wyłączony).

W Windows odpowiednikiem jest sprawdzenie diod sieciowych lub statusu karty w Panelu sterowania.

Trasa 0.0.0.0/0.0.0.0 to domyślna.

Trasa 127.0.0.0/255.0.0.0 do 127.0.0.1 to loopback.

Trasy z maską 255.255.255.255 to trasy hosta.

Tablica routingu hosta jest kluczowa dla zrozumienia, jak system przekazuje pakiety.

W Windows route print pokazuje kolumny: Network Destination (sieć docelowa), Netmask (maska), Gateway (brama), Interface (interfejs wyjściowy), Metric (metryka).

W Linux ip route show używa notacji CIDR (192.168.1.0/24) zamiast maski. 'proto dhcp' oznacza trasę z DHCP, 'proto kernel' z jądra, 'proto static' - dodaną ręcznie. 'scope link' oznacza trasę do sieci bezpośrednio podłączonej. 'metric 100' to koszt trasy - przy wielu trasach wybierana jest z niższą metryką.

W praktyce administracyjnej ręczne dodawanie tras na hoście jest rzadko potrzebne (wszystko idzie przez bramę domyślną).

Wyjątki: (1) VPN - trasy do sieci VPN są dodawane przez klienta VPN, (2) wiele interfejsów z trasami do różnych sieci, (3) routing między sieciami na hoście (Linux jako router).

W przypadku Linux jako routera, trzeba włączyć przekazywanie IP: sysctl net.ipv4.ip_forward=1.

nmap oferuje kilkanaście typów skanowania. Uwaga: nmap nie jest domyślnie zainstalowany - wymaga instalacji (apt install nmap).

nmap jest dostępny w Linux (apt install nmap) i Windows (nmap.org).

Wynik nmap pokazuje: port, stan (open/filtered/closed), usługa (wg bazy nmap-services). open = port otwarty i nasłuchuje, filtered = firewall blokuje skanowanie (brak odpowiedzi), closed = port zamknięty (odpowiedź RST). Duża liczba filtered portów sugeruje firewall.

Wersja Windows wymaga WinPcap lub Npcap do surowego dostępu do sieci. nmap -sS w Windows może być ograniczone - zaleca się -sT lub użycie Linux. nmap -A łączy -sV, -O, -sC (skrypty domyślne) i traceroute - najbardziej zaawansowany pojedynczy test.

W nowych wersjach Windows (10 1809+) dostępne jest też narzędzie Test-NetConnection w PowerShell.

telnet jest historycznie protokołem do zdalnego dostępu (port 23), ale ze względu na brak szyfrowania został wyparty przez SSH.

Współcześnie telnet jest używany wyłącznie jako narzędzie do testowania portów TCP. telnet łączy się z dowolnym portem TCP i po połączeniu przekazuje stdin/stdout do gniazda.

Można ręcznie wysłać dowolne zapytanie protokołowe (HTTP, SMTP, POP3) i zobaczyć odpowiedź serwera.

W PowerShell (Windows) odpowiednikiem jest Test-NetConnection (tnc). tnc 8.8.8.8 -Port 443 -Detailed testuje połączenie i pokazuje szczegółowe informacje (Route, Ping, Traceroute). tnc google.com -TraceRoute wykonuje traceroute.

curl jest dostępny w Linux (apt install curl), Windows (od Windows 10 1803 wbudowany w cmd i PowerShell), i macOS (domyślnie). curl -O nazwa_pliku pobiera plik i zapisuje go pod nazwą z URL (lub -o plik.html dla własnej nazwy). curl -u user:pass https://example.com autoryzacja Basic Auth. curl -X POST -d 'klucz=wartosc' https://example.com/api - wysyłanie danych POST.

wget jest prostsze od curl: domyślnie pobiera pliki, obsługuje rekurencyjne pobieranie stron (wget -r), wznawianie przerwanych transferów (-c). wget --spider sprawdza linki bez pobierania treści - użyteczne do testowania, czy strona jest dostępna.

W diagnostyce sieci curl jest używane głównie do: (1) sprawdzenia, czy serwer HTTP odpowiada (kod 200), (2) sprawdzenia nagłówków odpowiedzi (Content-Type, Server, Location przy przekierowaniach), (3) pomiaru czasu odpowiedzi (--write-out '%{time_total}'), (4) testowania IPv4 vs IPv6 (-4, -6), (5) testowania SNI (--resolve). curl -w 'time_total: %{time_total}s\n' -o /dev/null -s https://google.com mierzy całkowity czas odpowiedzi.

W Windows wget nie jest domyślnie dostępny - można go pobrać z gnuwin32, użyć curl lub Invoke-WebRequest w PowerShell.

Składnia filtrów BPF: [proto] [dir] [type] [value].

Przykład: tcpdump -i eth0 src 10.0.0.5 and tcp port 443.

Dla ICMP pokazuje typ i kod.

Przykładowy wynik: 16:30:00.123456 IP 192.168.1.10.54321 > 142.250.185.78.80: Flags [S], seq 123456, win 65535, options [mss 1460]. Oznacza to: TCP SYN (flag S) z portu 54321 na 80, MSS 1460.

Aby znaleźć GUID interfejsu w Windows: tshark -D.

tcpdump używa wyrażeń BPF (Berkeley Packet Filter) do filtrowania pakietów.

Przykłady: host 192.168.1.1 (tylko z/do hosta), src 192.168.1.1 (tylko źródłowy), dst 192.168.1.1 (tylko docelowy), port 80 (HTTP), portrange 1-1024, icmp (tylko ICMP), tcp (tylko TCP), udp (tylko UDP). Łączenie: and, or, not.

Wynik tcpdump pokazuje: znacznik czasu, protokół (IP, ICMP), adresy źródłowy i docelowy, flagi TCP (S=SYN, . =ACK, P=Push), numery sekwencyjne, okno, opcje.

W Windows tshark (część Wireshark) jest odpowiednikiem tcpdump. tshark -i \Device\NPF_{GUID} -f "port 80" -c 10.

Wireshark oferuje graficzny interfejs do analizy ruchu, dekodowanie protokołów, podążanie za strumieniami, filtry wyświetlania.

Wireshark jest zalecany do analizy offline plików pcap, tcpdump do szybkiego podglądu w terminalu.

Uwaga: ethtool, iperf3, whois nie są domyślnie zainstalowane w większości dystrybucji Linux. Wymagają instalacji: apt install ethtool iperf3 whois.

iperf3 to standardowe narzędzie do pomiaru przepustowości.

Tryb serwer: iperf3 -s (nasłuchuje na porcie 5201).

Tryb klient: iperf3 -c 192.168.1.10 (test przepustowości TCP). iperf3 -u -c 192.168.1.10 -b 100M (test UDP z pasmem 100 Mbps).

Wynik pokazuje: transfer (dane przesłane), bandwidth (przepustowość), retransmisje (dla TCP - im więcej, tym gorsze łącze). iperf3 jest niezastąpiony przy testowaniu łączy WAN, VPN i Wi-Fi.

nbtstat -a IP (Windows) pokazuje tablicę nazw NetBIOS zdalnego hosta.

NetBIOS jest starszym protokołem (poprzednik DNS w sieciach Windows), wciąż używanym w starszych sieciach korporacyjnych. nbtstat -n pokazuje lokalną tablicę nazw NetBIOS. nbtstat -c pokazuje zdalne nazwy NetBIOS w cache'u.

ethtool (Linux) pokazuje szczegółowe informacje o karcie sieciowej: ethtool eth0 (podstawowe: speed, duplex, auto-negocjacja), ethtool -S eth0 (statystyki z karty: tx_packets, rx_errors, collisions), ethtool -s eth0 speed 100 duplex full (zmiana ustawień, rzadko potrzebne).

To najszybszy test warstwy 1 - jeśli ethtool pokazuje 'Link detected: yes' i 'Speed: 1000Mb/s', to kabel i switch są OK.

Używaj jednolitego formatu raportów dla zespołu.

Diagnostyka sieci to proces systematycznego eliminowania możliwych przyczyn problemu.

Zaczynając od warstwy fizycznej (L1) i przechodząc wyżej (L2, L3, L4, L7), można szybko zlokalizować usterkę.

Doświadczeni administratorzy często zaczynają od ping na bramę (test L1/L2/L3 jednym poleceniem), potem ping na 8.8.8.8 (test routingu), potem nslookup google.com (test DNS).

Jeśli wszystkie działają - problem jest wyżej (aplikacja, firewall).

Warto pamiętać o rozróżnieniu między 'problemem sieciowym' a 'problemem aplikacji'.

Jeśli ping na serwer działa, ale strona WWW nie ładuje się przez HTTPS (port 443), to nie jest problem sieci L3 - to problem firewalla (blokada portu), certyfikatu TLS, lub samej aplikacji.

Podobnie: jeśli ping na serwer mailowy działa, ale SMTP (port 25) nie - to nie routing, tylko firewall lub usługa.

Zapisuj wyniki ping, traceroute, netstat przed i po zmianach.

W środowisku korporacyjnym warto utrzymywać bazę wiedzy z typowymi problemami i rozwiązaniami.

Narzędzia takie jak SmokePing, Zabbix, LibreNMS mogą automatycznie monitorować opóźnienia i straty pakietów.

Większość narzędzi jest dostępna domyślnie w systemie.

Prezentacja przedstawia kompletny zestaw narzędzi diagnostycznych używanych w codziennej pracy administratora sieci.

Każde narzędzie zostało omówione od strony praktycznej: składnia, opcje, przykłady na Linux i Windows, interpretacja wyników.

Kluczowym wnioskiem jest to, że żadne pojedyncze narzędzie nie wystarcza do pełnej diagnostyki - potrzebny jest zestaw narzędzi i umiejętność łączenia wyników.

Znajomość rutynowej diagnostyki pozwala na szybkie lokalizowanie problemów. Typowy scenariusz: (1) ping 8.8.8.8 (test L3), (2) jeśli nie działa - ping na bramę (test L2), (3) jeśli brama nie odpowiada - arp -a (test L2), (4) jeśli brak wpisu ARP - sprawdź kabel i DHCP.

W ciągu 30 sekund administrator wie, czy problem jest w warstwie 1, 2, czy 3.

Wyjątki (nmap, tcpdump, iperf3, mtr, traceroute, ethtool) wymagają instalacji, ale są standardem w każdym warsztacie administratora.

Warto poświęcić czas na naukę zaawansowanych opcji - szczególnie ss, mtr, dig i tcpdump, które oferują zdecydowanie więcej niż podstawowe użycie.

Pytania 4-5 dotyczą trasowania (traceroute, mtr, pathping).

Pytanie 6 dotyczy DNS.

Pytania kontrolne sprawdzają zrozumienie wszystkich kluczowych narzędzi.

Pytania 1-3 dotyczą podstawowych narzędzi (ping, ARP, netstat/ss).

Pytanie 7 to scenariusz łączący kilka narzędzi - typowy test diagnostyczny w pracy administratora.

Zaleca się wykonanie wszystkich poleceń na rzeczywistym systemie (Linux i Windows) podczas zajęć laboratoryjnych.

W przypadku braku dostępu do Linux, można użyć WSL (Windows Subsystem for Linux) lub Cisco Packet Tracer z urządzeniami CLI.

Packet Tracer ma ograniczone wsparcie dla narzędzi diagnostycznych (ping i traceroute są dostępne).

Odpowiedzi do pytań kontrolnych znajdują się w treści slajdów.

Jeśli student nie może znaleźć odpowiedzi, warto skorzystać z man pages (Linux) lub help (Windows) dla danego narzędzia.