Polecenia diagnostyczne sieci Linux – jak korzystać z ping traceroute i netstat

Jeśli korzystasz z systemu Linux i chcesz skutecznie rozwiązywać problemy z łącznością, polecenia diagnostyczne sieci Linux będą Twoimi najlepszymi sprzymierzeńcami. Dzięki nim prześledzisz, gdzie gubi się ruch w sieci, jak działa routing i czy Twoje DNS-y prawidłowo rozwiązują nazwy. Dobra wiadomość: to prostsze, niż się wydaje. Wystarczy poznać podstawowe komendy, takie jak ping, traceroute, netstat, ip czy mtr, a następnie krok po kroku przeanalizować problemy. W tym przewodniku przejdziemy przez każde z tych narzędzi, przytoczymy przykłady i wskażemy, na co zwrócić uwagę w praktyce.
Zacznij od podstaw
Zanim zagłębisz się w szczegóły, warto mieć pod ręką kilka terminów oraz wiedzieć, gdzie w Linuxie znajdują się najważniejsze ustawienia:
- Plik /etc/resolv.conf przechowuje informacje o serwerach DNS, z których korzysta Twój system. Jeśli masz problemy z rozwiązywaniem nazw, zajrzyj tu w pierwszej kolejności.
- Polecenie ip (pakiet iproute2) jest nowoczesnym narzędziem do konfiguracji sieci. Zastępuje starsze komendy takie jak ifconfig czy route.
- W systemach opartych na Debianie czy Ubuntu konfigurację sieci możesz znaleźć w /etc/network/interfaces lub w plikach konfiguracyjnych netplan (np. /etc/netplan/01-netcfg.yaml).
- W Red Hat, CentOS oraz Fedora swoją sieć zwykle skonfigurujesz w /etc/sysconfig/network-scripts/ lub w nowszych narzędziach, takich jak NetworkManager.
Pamiętaj, że ogólna zasada w Linuxie jest taka: najpierw sprawdzasz rzeczy oczywiste (czy kabel jest podłączony, czy sieć Wi-Fi działa, czy masz poprawny adres IP), a potem sięgasz po kolejne “warstwy” diagnostyki. Wielu administratorów potwierdza, że ponad połowa problemów sieciowych to drobne błędy konfiguracyjne (np. brak poprawnego DNS lub pomylone adresy).
Poznaj narzędzie ping
Ping to podstawowe polecenie, które pozwala Ci sprawdzić, czy dany host jest osiągalny w sieci. Wysyłasz do niego serię pakietów ICMP Echo Request i czekasz na ICMP Echo Reply. Jeśli otrzymujesz odpowiedź, wiesz, że trasa sieciowa między Twoim komputerem a serwerem jest przynajmniej częściowo sprawna.
Jak działa ping
Ping wysyła pakiety “zapytania” i czeka na ich odbicie (Reply). W wyniku otrzymujesz informację o:
- Liczbie przesłanych i odebranych pakietów.
- Czasie RTT (Round-Trip Time), czyli ile milisekund zajmuje pakietowi podróż tam i z powrotem.
- Statystykach strat (packet loss).
W systemach Linux i macOS trwa to w pętli ciągłej. Aby przerwać ping, naciśnij Ctrl + C (w Macu także Command + C może zadziałać przez terminal).
Główne opcje ping
- ping -c 4 8.8.8.8 wysyła 4 pakiety do adresu 8.8.8.8 (serwer DNS Google).
- ping -i 0.2 example.com ustawia interwał między wysyłanymi pakietami na 0,2 sekundy.
- ping -4 example.com wymusza IPv4.
- ping -6 example.com wymusza IPv6.
Dzięki tym opcjom sprawdzisz różne scenariusze: krótszy odstęp między pakietami, test IPv4 albo IPv6 czy ograniczenie liczby żądań, gdy chcesz uzyskać szybki test bez długiego czekania.
Przykładowe zastosowanie
Wyobraź sobie, że nie możesz połączyć się z ulubioną witryną. Pierwszy krok to ping example.com. Jeśli pakiety wracają, połączenie prawdopodobnie działa, a ewentualny problem leży gdzie indziej (np. w konfiguracji przeglądarki czy protokołu HTTPS). Brak odpowiedzi na ping może oznaczać, że:
- Serwer jest wyłączony lub przyblokowany przez firewall.
- Twój lokalny router nie przekazuje pakietów.
- Jesteś poza zasięgiem sieci (dla Wi-Fi) lub kabel sieciowy jest odłączony.
Dzięki ping szybko zorientujesz się, czy trasa podstawowej łączności jest otwarta.
Zbadaj trasę z traceroute
Jeśli ping mówi “host nie odpowiada,” ale nie wiesz, gdzie dokładnie następuje problem, skorzystaj z traceroute (w niektórych dystrybucjach Linuxa komenda to tracepath).
Traceroute wyświetla kolejne węzły (routery) na drodze do docelowego serwera, razem z czasem odpowiedzi. W ten sposób namierzysz, w której lokalizacji pakiety są gubione. Na przykład, jeśli brakuje odpowiedzi między trzecim a czwartym przeskokiem, możesz podejrzewać usterkę u danego operatora.
Kiedy używać traceroute
- Gdy Twój ping do zdalnego serwera nie dochodzi, a chcesz wiedzieć, czy problem leży w Twojej sieci lokalnej, u operatora czy u docelowego usługodawcy.
- Gdy testujesz routing w internecie i szukasz potencjalnych opóźnień.
- Gdy chcesz zdiagnozować trasę do specyficznej usługi w chmurze.
Typowe składnie traceroute
- traceroute example.com (Linux)
- tracepath example.com (alternatywnie w Linuxie)
- traceroute -I example.com (wymuszenie użycia ICMP Echo Request, a nie UDP).
Ponieważ część routerów może blokować pakiety ICMP lub UDP, warto czasem spróbować parametru -T (użycie TCP), aby uzyskać bardziej miarodajne wyniki.
Przykładowe wyniki
Wyobraź sobie, że traceroute do example.com zwraca kilkanaście linii. W każdej linii zobaczysz węzeł (host) i trzy czasy RTT. Jeśli w którymś punkcie pojawiają się gwiazdki zamiast czasu (***), to znaczy, że router nie odpowiada, co nie zawsze musi oznaczać błąd. Często jest to jedynie konfiguracja bezpieczeństwa operatora. Jednak jeśli gwiazdki pojawiają się od pewnego momentu aż do końca testu, istnieje duża szansa, że tu kończy się droga pakietów.
Analizuj połączenia z netstat
Netstat to kolejne przydatne narzędzie dla diagnostyki sieci w Linuxie. Pozwala obejrzeć aktywne połączenia, tablicę routingu, statystyki interfejsu, a także tzw. masquerade connections (w systemach z NAT). Choć w nowszych systemach wiele osób korzysta z ss (z pakietu iproute2), to netstat wciąż pozostaje w użyciu na wielu serwerach.
Dlaczego warto używać netstat
- Możesz podejrzeć, które porty są otwarte i jaki proces je zajmuje.
- Sprawdzisz, czy Twój serwer nasłuchuje na odpowiednim porcie, a jeśli tak, to czy przychodzą tam połączenia.
- Zweryfikujesz domyślne trasy routingu (netstat -r).
- Zobaczysz statystyki protokołów, np. liczbę błędnych pakietów (netstat -s).
Najczęstsze polecenia netstat
- netstat -tulpn wyświetla procesy nasłuchujące (TCP i UDP), numer PID, nazwę programu oraz port.
- netstat -r pokazuje tablicę routingu, podobnie do ip route show.
- netstat -s wypisuje szczegółowe statystyki protokołów (TCP, UDP, ICMP).
Wersja z parametrami -tulpn jest szczególnie przydatna, kiedy rozwiązuje się konflikt portów (np. gdy jedna usługa zajmuje port 80, a Ty próbujesz włączyć serwer HTTP na tym samym porcie).
Co zamiast netstat?
Jak wspomniano w badaniach, netstat jest częścią pakietu net-tools i jest uznawany za przestarzały w porównaniu z ss. Jednak jeśli masz starszy serwer lub dystrybucję, netstat może być jeszcze jedyną dostępną opcją. Narzędzie ss wyświetla bardzo podobne informacje, często w bardziej szczegółowej formie.
Używaj ip do konfiguracji
Polecenie ip (z pakietu iproute2) jest współczesnym “szwajcarskim scyzorykiem” do zarządzania siecią w Linuxie. Masz tu podpolecenia: ip addr, ip route, ip link, ip neigh i wiele innych. Dzięki nim wyświetlisz i skonfigurujesz wszystkie kluczowe elementy interfejsów, bram, tuneli czy VLAN-ów.
Podstawowe podpolecenia
- ip addr show (lub skrót ip a)
- Wyświetla aktualnie skonfigurowane adresy IP na poszczególnych interfejsach.
- ip link show
- Pokazuje informacje o stanie interfejsów sieciowych (UP/DOWN, MAC, prędkość).
- ip route show
- Prezentuje tablicę routingu, czyli gdzie kierowane są pakiety przy danym adresie docelowym.
- ip addr add 192.168.1.10/24 dev eth0
- Dodaje nowy adres IP do interfejsu eth0.
- ip route add default via 192.168.1.1
- Ustawia domyślną bramę na 192.168.1.1.
Dlaczego ip jest kluczowe
Wielu administratorów lubi ip, ponieważ zapewnia spójny zestaw poleceń do wszystkiego, co związane z siecią. Zamiast sięgać po ifconfig, route i netstat, możesz użyć jednego pakietu narzędzi. Dodatkowy plus to rozwój w ramach iproute2. Współczesne rozwiązania wirtualizacji czy konteneryzacji (np. Docker, LXC) także stawiają na ip do konfiguracji interfejsów wirtualnych i mostów sieciowych.
Przykładowe czynności z ip
- ip link set eth0 down, a następnie ip link set eth0 up: wyłączenie i włączenie interfejsu.
- ip address del 192.168.1.10/24 dev eth0: usunięcie niepotrzebnego adresu IP.
- ip route add 10.0.0.0/24 via 192.168.1.2: dodanie trasy do sieci 10.0.0.0/24 przez router 192.168.1.2.
Krótka tabela popularnych podpoleceń
Podpolecenie | Cel | Przykład użycia |
---|---|---|
ip addr | Zarządzanie adresami IP | ip addr add 10.0.0.2/24 dev eth0 |
ip link | Sterowanie interfejsami | ip link set eth0 up |
ip route | Ustalanie tras | ip route add 10.0.0.0/24 via 192.168.1.1 |
ip neigh | Wgląd w ARP i sąsiadów | ip neigh show |
Dzięki tej tabeli łatwo zapamiętasz, który podrozkaz służy do konkretnego zastosowania.
Przetestuj mtr i tcpdump
Choć ping i traceroute są najpopularniejsze, w pewnych sytuacjach dobra będzie analiza ciągła lub przechwytywanie pakietów. Tutaj przydają się mtr (Matt’s Traceroute) oraz tcpdump.
mtr – połączenie ping i traceroute
Narzędzie mtr łączy funkcje ping i traceroute w jednym poleceniu. mtr example.com wyświetla listę węzłów tak jak traceroute, a jednocześnie liczy statystyki tak jak ping. W efekcie masz bardziej dynamiczny pogląd na to, w których miejscach występuje wysoki czas odpowiedzi lub straty pakietów.
- mtr -c 10 example.com uruchamia 10 testów i wyświetla średnie z każdego przeskoku.
- mtr --tcp example.com wymusza użycie protokołu TCP.
- mtr -r example.com wyświetla wyniki w formie raportu.
Kiedy zobaczysz, że określony węzeł ma duży procent strat (np. 30%), możesz podejrzewać problem z tym konkretnym routerem lub łączem. Czasem jednak routery priorytetyzują przekazywanie pakietów, a ignorują odpowiedzi na ICMP. Wtedy procent strat niekoniecznie wskazuje realny problem, ale jeśli gubisz pakiety również w następnym węźle, to znak, że warto się temu bliżej przyjrzeć.
tcpdump – przechwytywanie pakietów
Tcpdump to “lupa” do analizy ruchu sieciowego. Umożliwia przechwytywanie i wyświetlanie pakietów w czasie rzeczywistym. Możesz więc sprawdzić, czy serwer otrzymuje zapytania na określonym porcie i jak na nie odpowiada.
- tcpdump -i eth0 host 192.168.1.100: wyświetla cały ruch z i do hosta 192.168.1.100 na interfejsie eth0.
- tcpdump port 80: filtruje ruch HTTP.
- tcpdump -w capture.pcap: zapisuje przechwycone pakiety do pliku w formacie pcap, który potem obejrzysz w Wiresharku.
To narzędzie przydatne jest, kiedy musisz dokładnie prześledzić, jakie dane są wysyłane i w jakiej formie. Może Ci pomóc wykryć nieoczekiwany ruch wskazujący na np. ataki sieciowe.
Rozwiąż typowe problemy sieciowe
Skoro znasz już główne polecenia diagnostyczne sieci Linux, przejdźmy przez kilka częstych scenariuszy, w których się przydadzą. Dobre wieści: nawet jeśli coś wygląda na duży kłopot, z pomocą sprawdzonej rutyny szybko znajdziesz rozwiązanie.
1. Brak przydzielonego adresu IP
- Sprawdź stan interfejsu: ip link show eth0 (czy jest UP, czy DOWN?).
- Jeśli jest DOWN, włącz go: ip link set eth0 up.
- Upewnij się, że interfejs ma adres: ip addr show eth0.
- Jeśli nie ma, dodaj go ręcznie lub sprawdź usługę DHCP (np. systemctl status dhclient).
2. Brak komunikacji z internetem, ale lokalna sieć działa
- Pinguj 8.8.8.8 (DNS Google). Jeśli brak odpowiedzi, możliwe, że brama domyślna jest zła.
- Sprawdź trasę: ip route show i zobacz, czy jest default via 192.168.1.1 (lub inny adres routera).
- Dodaj lub popraw trasę: ip route add default via 192.168.1.1 dev eth0.
- Jeśli pingi do 8.8.8.8 działają, a do google.com już nie, problem może leżeć w DNS (zajrzyj do /etc/resolv.conf).
3. Domena się nie rozwiązuje
- Upewnij się, że w /etc/resolv.conf masz poprawny nameserver (np. 8.8.8.8).
- ping google.com – jeśli nie odpowiada, użyj ping 8.8.8.8, żeby sprawdzić, czy to kwestia DNS.
- Skorzystaj z nslookup lub dig: nslookup google.com, dig google.com.
- Jeśli nic nie działa, popraw konfigurację DNS lub użyj innego serwera DNS.
4. Usługa nie odpowiada na danym porcie
- netstat -tulpn | grep 80 sprawdzi, czy port 80 jest zajęty i przez który proces.
- Jeśli Twoja aplikacja jest uruchomiona, ale portu nie widać, sprawdź firewall (iptables -L lub nft list ruleset).
- Upewnij się, że Twój serwer słucha na właściwym interfejsie (0.0.0.0 lub konkretny adres).
5. Duże opóźnienia albo straty pakietów
- ping w trybie ciągłym do problematycznego hosta, by zmierzyć packet loss.
- Użyj traceroute lub mtr, żeby zobaczyć, na którym etapie rośnie opóźnienie.
- Jeśli okaże się, że wina leży po stronie dostawcy, skontaktuj się z nim.
Zadbaj o bezpieczeństwo
W czasie diagnozowania sieci nie można zapomnieć o elementach zabezpieczeń:
- Jeśli ruch sieciowy przechodzi przez kilka routerów, część z nich może blokować określone pakiety (np. ICMP) z powodów bezpieczeństwa.
- Serwery produkcyjne często mają reguły firewall (iptables lub nftables), które limitują ruch przychodzący i wychodzący.
- Przy przechwytywaniu pakietów pamiętaj, aby robić to na zaufanym środowisku i nie przechwytywać danych wrażliwych bez szyfrowania.
Prosty przykład: jeśli Twój ping do zdalnego hosta nie wraca, może to być wynikiem ścisłej konfiguracji zapory ogniowej, a nie realnym problemem z łącznością. Nie zniechęcaj się, bo często wystarczy skorygować wybrane reguły, by wszystko wróciło do normy.
Praktyczne rady i mini-checklista
Spróbuj stosować się do poniższych rad zawsze, gdy diagnozujesz czy naprawiasz łączność:
- Upewnij się, że masz prawa administratora (sudo), dzięki czemu uruchomisz ping, traceroute, tcpdump czy ip bez ograniczeń.
- Zawsze zaczynaj od prostych spraw: czy interfejs jest UP, czy DNS działa.
- Notuj krok po kroku, co sprawdziłeś, aby nie powielać tych samych testów.
- Jeżeli używasz wielu narzędzi (ping, mtr, netstat), porównuj wyniki i szukaj niespójności.
- Jeśli łączność przez IPv4 działa poprawnie, ale IPv6 nie – zbadaj ustawienia IPv6 i sprawdź, czy Twój dostawca oferuje wsparcie dla tego protokołu.
- Dla bardziej złożonych problemów rozważ przechwytywanie pakietów (tcpdump), aby zobaczyć, czy ruch w ogóle dociera do Twojego serwera.
Podsumuj i działaj dalej
Masz za sobą sporo wiedzy na temat podstawowych (ale bardzo ważnych) poleceń diagnostycznych sieci w Linuxie. Wiesz już, że ping weryfikuje podstawową łączność, traceroute śledzi poszczególne przeskoki, a netstat (lub ss) pokazuje otwarte porty i ruch na poziomie systemu. ip z pakietu iproute2 przejął rolę centralnego narzędzia do konfiguracji adresów i tras, a mtr i tcpdump stanowią doskonałe uzupełnienie do bardziej zaawansowanej analizy.
Oto krótkie przypomnienie:
- ping – najprostszy test, czy host odpowiada.
- traceroute (lub tracepath) – ustala trasę i pomaga wykryć, na którym węźle gubisz pakiety.
- netstat (lub ss) – przedstawia aktywne połączenia i statystyki, ułatwia namierzanie problemów z portami.
- ip – nowoczesne narzędzie do zarządzania adresacją i routingiem.
- mtr – łączy funkcjonalność ping i traceroute, pozwala sprawniej ocenić jakość trasy.
- tcpdump – szczegółowa analiza pakietów w ruchu, nieoceniona w wykrywaniu subtelnych usterek i ataków.
Jeśli którykolwiek z tych elementów okaże się wyzwaniem, nie zrażaj się. Wystarczy metoda małych kroków. Najpierw zbierz podstawowe informacje (ip addr, ping, traceroute), potem sięgnij po szczegółową diagnozę (mtr, tcpdump). Dziel się wiedzą z kolegami z zespołu. Być może rozwiązanie, którego szukasz, jest już w ich głowach.
Kolejny krok? Poćwicz w środowisku testowym. Utwórz kilka wirtualnych maszyn, skonfiguruj sieci wirtualne i sprawdź, jak reagują narzędzia przy różnych scenariuszach. Dzięki temu, gdy wystąpi prawdziwa usterka, przywołasz sprawdzone procedury i szybko przywrócisz usługę do działania.
Powodzenia w dalszej przygodzie z Linuxem. Jesteś na dobrej drodze, aby zbudować solidne kompetencje w dziedzinie administracji siecią. A jak pokazuje praktyka wielu firm, umiejętności te przyspieszają rozwiązywanie awarii nawet o 50%. Z Twoją znajomością poleceń diagnostycznych sieci Linux, można spać spokojnie, bo sieć nie ma już tylu tajemnic.
Dobra wiadomość: większość tych narzędzi jest domyślnie dostępna w niemal każdej dystrybucji. W razie braków zainstalujesz je jednym poleceniem (np. sudo apt-get install iproute2 net-tools mtr tcpdump). Następnie przetestuj i ciesz się pewnością, że wiesz, gdzie szukać przyczyn problemów.
Życzę Ci owocnych eksperymentów i szybkich diagnoz. Masz już komplet wskazówek, by zacząć działać. Jeśli natkniesz się na trudniejszy przypadek, nie rezygnuj. Krok po kroku dojdziesz do rozwiązania, bo w Linuxie każda usterka zwykle ma jasną przyczynę możliwą do wykrycia. Trzymam kciuki za Twoją sieć!