Diagnostyka sieci krok po kroku: ping, traceroute, mtr i analiza logów routera w realnych scenariuszach awarii

Dlaczego sieć „nie działa”? Ramy myślenia i podstawowe pojęcia

Co to znaczy, że sieć jest „zepsuta”

Stwierdzenie „nie działa internet” jest dla diagnostyki sieci tak samo pomocne, jak komunikat „samochód nie jedzie”. Żeby naprawdę coś naprawić, trzeba rozbić problem na mniejsze kawałki i nazwać, co dokładnie nie działa. Inaczej będziemy błądzić, tracąc czas na losowe próby.

Najprostszy pierwszy krok to rozróżnienie: czy nie działa żaden ruch sieciowy, czy tylko konkretna usługa. Inaczej diagnozuje się sytuacje, gdy:

• nie ładują się żadne strony WWW, nie działa poczta, komunikatory – wygląda na awarię ogólną,
• działają wszystkie strony poza jedną konkretną – problem najpewniej jest po stronie tej usługi lub trasy do niej,
• działają strony, a nie działa VPN lub gra online – kłopot może dotyczyć portów, NAT albo opóźnień/jittera.

Ćwicząc diagnostykę, warto zmienić pierwszy odruch z „co nie działa?” na „co jeszcze działa poprawnie?”. To jak szukanie przerwanego łańcucha – najpierw trzeba znaleźć miejsce, w którym sygnał „jeszcze dochodzi”, a potem następne ogniwo, gdzie już go nie ma.

Jeżeli na jednym komputerze w sieci wszystko szwankuje, a na innym działa, to z dużym prawdopodobieństwem problem jest lokalny (karta sieciowa, sterownik, firewall systemowy). Jeśli jednak wszyscy użytkownicy narzekają w tym samym czasie, zaczyna się podejrzenie: router, łącze WAN, dostawca.

Warstwy, na których naprawdę diagnozujemy

Większość codziennych awarii sieci rozgrywa się w okolicy kilku konkretnych warstw modelu sieciowego. W praktyce – przy ping, traceroute, mtr i analizie logów routera – najczęściej dotykasz:

• Warstwy fizycznej – kable, wtyczki, światłowód, sygnał radiowy Wi-Fi,
• Warstwy łącza danych – Ethernet, adresy MAC, ramki, VLANy,
• Warstwy sieciowej (IP) – adresacja IP, routing, trasa pakietów,
• Warstwy transportowej – TCP/UDP, porty, utrzymywanie połączeń.

Ping i mtr bazują na protokole ICMP (warstwa sieciowa), więc mówią głównie o tym, czy pakiety IP w ogóle przechodzą i z jakim opóźnieniem. Traceroute zagląda w trasę pakietu przez kolejne routery. Logi routera z kolei dotykają zarówno fizycznej strony (up/down interfejsu), jak i poziomu protokołów dostępowych (PPPoE, DHCP, VPN, firewall).

Za każdym razem, gdy wykonujesz ping lub traceroute, warto zadać sobie pytanie: na której warstwie mogę mieć problem? Czy chodzi o to, że kabel jest wypięty, router nie dostał adresu od dostawcy, a może firewall blokuje konkretny port?

Kluczowe pojęcia: opóźnienie, jitter, utrata pakietów, MTU, NAT

Diagnostyka sieci krok po kroku wymaga zrozumienia kilku pojęć, które ciągle wracają w testach i logach:

• Opóźnienie (latency) – czas w milisekundach od wysłania pakietu do otrzymania odpowiedzi (RTT – round-trip time). W ping jest to wartość „time=… ms”. Im mniejsze opóźnienie, tym bardziej „responsywne” połączenie.
• Jitter – zmienność opóźnienia. Jeśli raz masz 20 ms, potem 80 ms, potem znowu 18 ms, to jitter jest duży. Jitter jest krytyczny dla VoIP i gier online – powoduje „przycinanie” i lagowanie, nawet gdy średnie opóźnienie jest znośne.
• Utrata pakietów (packet loss) – procent pakietów, które w ogóle nie dotarły do celu lub odpowiedź nie wróciła w określonym czasie. Nawet kilka procent utraty może zabić komfort rozmów głosowych i grania.
• MTU (Maximum Transmission Unit) – maksymalny rozmiar pakietu IP, jaki może przejść przez dane łącze bez fragmentacji. Zbyt duży MTU przy nieprawidłowo skonfigurowanym Path MTU Discovery potrafi powodować bardzo trudne do wychwycenia problemy (niektóre strony nie ładują się, inne działają).
• NAT (Network Address Translation) – mechanizm „tłumaczenia” adresów prywatnych (w LAN) na publiczny adres routera. W diagnostyce objawia się np. jako problem z otwieraniem portów, zanikającymi sesjami lub błędami w logach firewall’a.

Znajomość tych pojęć pozwala spojrzeć na wyniki ping, traceroute czy mtr nie jak na magiczne cyferki, ale jak na konkretną informację o stanie łącza i trasy pakietów.

Myślenie o awarii: szukanie działającego ogniwa

Najskuteczniejszy schemat przy awarii to nieprzypadkowe „resetuj wszystko”, tylko systematyczne sprawdzanie łańcucha:

• czy działa połączenie komputer → router (ping do bramy lokalnej),
• czy router ma dostęp do sieci dostawcy (logi WAN, ping do bramy operatora, ping do DNS),
• czy działa rozwiązywanie nazw (nslookup/dig, ping po IP i po nazwie),
• czy problem dotyczy tylko konkretnej trasy lub usługi (traceroute/mtr do problematycznego hosta).

Zamiast szukać „magicznego przełącznika”, szukasz konkretnego odcinka, gdzie przestaje być dobrze. Taki sposób myślenia dobrze współgra z narzędziami CLI: ping, traceroute, mtr prowadzą cię krok po kroku, a logi routera potwierdzają, co się działo w tle.

Ping – młotek diagnostyczny, bez którego trudno zacząć

Co ping naprawdę mierzy, a czego nie pokaże

Ping to najprostsze i jednocześnie najczęściej używane narzędzie do diagnozowania sieci. Korzysta z protokołu ICMP, wysyłając pakiety typu echo request i oczekując na echo reply. Służy do odpowiedzi na podstawowe pytanie: „czy ten host jest w ogóle osiągalny na poziomie IP i z jakim opóźnieniem?”.

Co dokładnie mierzy ping?

• czy pakiety ICMP docierają do celu i wracają,
• jaki jest czas RTT (round-trip time) – w milisekundach,
• jaki jest procent utraconych pakietów w serii testów.

Na końcu serii ping (Linux/macOS) dodatkowo pojawia się podsumowanie: minimalne, średnie, maksymalne opóźnienie i odchylenie standardowe. To szybki obraz jakości połączenia.

Ping nie pokaże jednak wszystkiego. Nie dowiesz się z niego:

• jaką dokładnie trasą idzie pakiet (od tego jest traceroute i mtr),
• czy działają wyższe warstwy, np. HTTP, TLS – host może odpowiadać na ICMP, ale mieć problem z serwerem WWW,
• czy firewall po drodze nie traktuje ICMP inaczej niż „normalnych” pakietów TCP/UDP – co czasem daje fałszywie dobre lub złe wyniki.

Niektórzy administratorzy blokują ICMP, uznając go za potencjalny wektor ataku. W efekcie host odpowiada np. na HTTP, ale ping nie działa. To typowa pułapka: brak odpowiedzi na ping nie zawsze oznacza pełną niedostępność hosta, tylko brak odpowiedzi ICMP.

Podstawowe przykłady użycia ping w systemach Windows, Linux, macOS

Na każdej platformie ping wygląda nieco inaczej, ale idea jest identyczna.

Ping w Windows

Podstawowa składnia:

ping 8.8.8.8
ping www.google.com

Przydatne przełączniki:

• -n <liczba> – liczba wysyłanych pakietów, np. ping -n 20 8.8.8.8,
• -l <rozmiar> – rozmiar pakietu w bajtach, np. test MTU ping -f -l 1472 8.8.8.8,
• -t – ping ciągły, aż do przerwania (Ctrl+C),
• -4 / -6 – wymuszenie IPv4 lub IPv6.

Ping w Linux i macOS

Na systemach uniksowych ping działa w trybie ciągłym domyślnie. Zatrzymuje się go Ctrl+C.

ping 8.8.8.8
ping -c 20 8.8.8.8   # -c: liczba pakietów
ping -s 1472 8.8.8.8 # -s: rozmiar danych ICMP

Podstawowe różnice:

• Linux: domyślnie pakiet jest wysyłany co 1 sekundę,
• macOS: podobnie, składnia przełączników zbliżona do Linuksa,
• wynik końcowy zawiera statystyki i informacje o jitterze (na bazie odchylenia standardowego).

Jak interpretować wyniki ping: RTT, utrata, stabilność

Output ping to nie tylko „działa/nie działa”, ale małe laboratorium jakości łącza. Kilka wskazówek interpretacyjnych:

• Brak odpowiedzi na wszystkie pakiety – jeśli ping do bramy lokalnej (np. 192.168.1.1) nie odpowiada, problem jest lokalny: kabel, Wi‑Fi, konfiguracja IP, firewall w routerze. Jeżeli brama odpowiada, a internet nie – szukamy dalej na zewnątrz.
• Wysokie i zmienne czasy RTT – jeśli czas odpowiedzi skacze np. 20 ms, 200 ms, 50 ms, 300 ms, oznacza to przeciążenie lub kolejkowanie gdzieś na trasie. Warto wtedy użyć mtr, aby zobaczyć, na którym hopie pojawia się problem.
• Częściowa utrata pakietów – 1–2 zgubione pakiety na 100 mogą wynikać z chwilowych przeciążeń, ale jeśli tracisz np. 10–20%, to realny problem z jakością łącza lub błędną konfiguracją sieci.
• Wyniki zależne od celu – do lokalnego routera RTT rzędu 1 ms jest naturalne; do serwera w innym kraju – kilkadziesiąt ms. Jeżeli do każdego zewnętrznego hosta masz opóźnienia rzędu kilkuset ms i straty, a do bramy lokalnej jest idealnie, to kłopot leży poza twoją siecią LAN.

Dobrym nawykiem jest zrobienie sekwencji ping: najpierw do 127.0.0.1 (loopback), potem do własnego adresu IP, następnie do bramy (routera), a na końcu do zewnętrznego adresu (np. 8.8.8.8). Taki mini-schemat szybko pokazuje, gdzie kończy się poprawność.

Zaawansowane użycie ping: rozmiar pakietu, MTU i blokowanie ICMP

Ping może też pomóc ujawnić problemy z MTU. Scenariusz z życia: część stron WWW się ładuje, część wisi bez końca. Ping do hostów działa, ale pobieranie większych danych już nie. Jedną z przyczyn bywa nieprawidłowo działający Path MTU Discovery.

W Windows można przetestować maksymalny działający rozmiar pakietu bez fragmentacji:

ping 8.8.8.8 -f -l 1472

Jeśli otrzymasz komunikat o konieczności fragmentacji, zmniejszasz rozmiar, aż znajdziesz wartość, która przechodzi. Do niej dodajesz 28 bajtów (nagłówek IP + ICMP) – to przybliżone MTU na trasie.

Pojawia się też problem blokowania ICMP przez firewall. Jeżeli:

• nie ma odpowiedzi na ping do jakiegoś hosta,
• ale ten host odpowiada na HTTP/HTTPS (strona się ładuje),

wtedy brak odpowiedzi na ICMP nie oznacza awarii sieci, tylko politykę bezpieczeństwa. Przy diagnozie łącz operatora zwykle używa się adresów, które „tradycyjnie” odpowiadają na ping (np. serwery DNS, gatewaye ISP), ale i to nie jest regułą. Stąd konieczność łączenia ping z traceroute i mtr oraz z testami konkretnych usług (np. curl, przeglądarka).

Traceroute – rentgen trasy pakietów

TTL, ICMP, UDP – jak powstaje mapa drogi

Traceroute (w Windows: tracert) pokazuje kolejne skoki (hopy) na trasie pakietu do wybranego hosta. Działa dzięki mechanizmowi TTL (Time To Live). Każdy pakiet IP ma w nagłówku TTL, który jest zmniejszany o 1 na każdym routerze po drodze. Gdy TTL spadnie do zera, router odrzuca pakiet i zwykle odsyła nadawcy komunikat ICMP „Time Exceeded”.

Traceroute wykorzystuje to zachowanie w sprytny sposób:

1. Wysyła pierwszy pakiet z TTL=1. Pierwszy router zmniejsza TTL do 0, odrzuca pakiet i wysyła ICMP „Time Exceeded”. Mamy pierwszy hop.
2. Drugi pakiet wysyłany jest z TTL=2. Zostanie zjedzony przez drugi router po drodze, który znów odeśle ICMP „Time Exceeded”. Mamy drugi hop.

Różnice implementacyjne: traceroute w Windows, Linux i macOS

Narzędzie robi w gruncie rzeczy to samo, ale na różnych systemach korzysta z innych typów pakietów i ma odmienną składnię. Dobrze to rozumieć, szczególnie gdy efekt na Linuksie i Windowsie wydaje się „sprzeczny”.

• Windows (tracert) – używa głównie pakietów ICMP Echo Request z rosnącym TTL. Dla wielu routerów jest to „uprzejmiejszy” ruch, bo ICMP i tak by przepuszczały.
• Linux/macOS (traceroute) – klasycznie używa pakietów UDP na wysokie porty (domyślnie nieużywane), które na końcu trasy są odrzucane z komunikatem „port unreachable”. Coraz częściej dostępne są też tryby ICMP (-I) lub TCP (-T).

To oznacza, że na trasie z ostrą filtracją UDP możesz widzieć gwiazdki w traceroute na Linuksie, ale pełne odpowiedzi w tracert z Windowsa. Nie jest to „magia operatora”, tylko różne typy ruchu.

Podstawowa składnia i najważniejsze przełączniki

Przy prostych problemach wystarczy wywołać traceroute z jednym parametrem – adresem docelowym. Warto jednak poznać kilka flag, które uratują skórę przy bardziej kapryśnych trasach.

tracert w Windows

tracert 8.8.8.8
tracert www.google.com

Często przydające się przełączniki:

• -d – wyłącza reverse DNS (szybsze, pokazuje tylko IP),
• -h <liczba> – maksymalna liczba hopów (domyślnie 30),
• -w <ms> – timeout odpowiedzi w milisekundach, np. -w 2000,
• -4 / -6 – wymuszenie IPv4 lub IPv6.

traceroute w Linux/macOS

traceroute 8.8.8.8
traceroute -n 8.8.8.8        # bez reverse DNS
traceroute -I 8.8.8.8        # tryb ICMP
traceroute -T -p 443 1.1.1.1 # TCP na port 443 (symulacja ruchu HTTPS)

Kilka istotnych opcji:

• -n – nie rozwiązuje nazw, przyspiesza i upraszcza wynik,
• -m <hopy> – maksymalny TTL (czyli liczba hopów),
• -I – używaj ICMP Echo zamiast UDP,
• -T – używaj pakietów TCP, np. do diagnozowania drogi pod konkretną usługę (port -p).

Jak czytać wynik traceroute: hop, opóźnienie, gwiazdki

Na pierwszy rzut oka wynik traceroute wygląda jak gęsta lista numerów i adresów. Jeśli jednak przełożysz to sobie na geograficzną „mapę”, wszystko staje się bardziej intuicyjne.

• Pierwszy hop – zwykle twój router domowy/firmowy. Jeżeli już tutaj są gwiazdki lub kosmiczne opóźnienia, nie ma sensu winić operatora.
• Kilka pierwszych hopów – sieć dostawcy (ISP). Widać tu często nazwy typu gw.city.isp.pl, core1, edge2.
• Środkowe hopy – sieć szkieletowa, punkty wymiany ruchu (IX), routery tranzytowe.
• Ostatnie hopy – sieć docelowego operatora / data center / CDN.

Przy każdym hopie masz zwykle do trzech czasów opóźnień (dla trzech kolejnych pakietów). Jeśli chcesz znaleźć „wąskie gardło”, patrz nie na absolutną wartość, ale na gwałtowne skoki.

Gdzie naprawdę jest „korek”? Analiza skoków opóźnienia

Typowy błąd interpretacyjny: „na hopie 5 mam 200 ms, czyli ten router jest popsuty”. Niekoniecznie. Czas, który pokazuje traceroute, to droga do danego hopa, a nie „czas przelotu przez router”. Kluczowy jest krokowy przyrost:

• jeżeli między hopem 1 a 2 opóźnienie rośnie z 1 ms na 3 ms, a między hopem 2 a 3 na 4 ms – wszystko w normie,
• jeżeli między hopem 5 a 6 skacze z 30 ms na 150 ms i od tego miejsca wszystkie dalsze hopy mają ~150 ms – korek jest między 5 a 6 (lub na 6),
• jeżeli na hopie 5 widzisz 150 ms, ale na 6 masz znów 30 ms – router z hopu 5 po prostu wolno odpowiada na ICMP, ale przekazuje ruch dalej normalnie.

Praktyczny przykład z życia: użytkownicy skarżą się, że połączenia do serwera w Niemczech czasem „zamulają”. Traceroute pokazuje stabilne czasy do sieci operatora, a potem skok z 20 ms na 80 ms przy przejściu przez punkt wymiany ruchu w innym kraju. Od tego miejsca wszystko trzyma ~80 ms. To nie awaria, tylko inna ścieżka trasowania, czasem mniej optymalna (np. inna trasa BGP).

Gwiazdki, brak odpowiedzi i asymetria tras

Gwiazdki w traceroute wyglądają złowieszczo, ale nie zawsze są tragedią. Mogą oznaczać kilka rzeczy:

• router nie odsyła komunikatów ICMP „Time Exceeded” (polityka bezpieczeństwa),
• odpowiedź ICMP mieści się poza ustawionym timeoutem,
• trasa zwrotna (od routera do ciebie) jest inną ścieżką i po drodze coś blokuje ICMP.

Jeżeli gwiazdki pojawiają się na jednym-dwóch środkowych hopach, a dalsze hopy normalnie odpowiadają – najczęściej nic złego się nie dzieje. Router po prostu nie ma ochoty odpowiadać, ale pakiety „produkcyjne” lecą.

Asymetria tras bywa jeszcze ciekawsza: pakiety do celu idą jedną drogą, wracają inną. Traceroute pokazuje tylko ścieżkę „tam”, więc problemy na drodze „z powrotem” mogą nie być widoczne bezpośrednio. Gdy widzisz wysokie RTT, ale nie widzisz „typowego” miejsca skoku w traceroute, na ogół właśnie to się dzieje.

Przykładowe scenariusze użycia traceroute

Traceroute błyszczy wtedy, gdy ping mówi tylko „czasem jest źle”. Kilka typowych historii:

• Strona klienta w innej części kraju ładuje się bardzo wolno – traceroute pokazuje, że do sieci twojego operatora czasy są dobre, ale skaczą dopiero po wyjściu do innego dostawcy (peering/tranzyt). Masz wtedy argument, żeby zgłosić sprawę do ISP z konkretną trasą i hopem.
• Problem tylko z jednym dostawcą chmury – ping do 8.8.8.8 i innych serwerów jest OK, ale klient wchodzi na aplikację w danym regionie AWS/Azure i ma kilkusekundowe lagi. Traceroute ujawnia, że ruch do tego operatora idzie okrężną drogą przez inny kraj.

Traceroute sam z siebie nie naprawi trasy, ale daje konkretną mapę, na której widać, gdzie kończy się twoja odpowiedzialność, a zaczyna cudza.



mtr – połączenie ping i traceroute w jednym strumieniu

Na czym polega przewaga mtr nad „statycznym” traceroute

mtr (My Traceroute, dawniej Matt’s Traceroute) łączy funkcje ping i traceroute w jedno narzędzie. Zamiast jednorazowego „zdjęcia trasy” pokazuje jej zachowanie w czasie. Można to porównać do filmu zamiast fotografii.

mtr wysyła serie pakietów do kolejnych hopów i na bieżąco liczy statystyki: procent strat, średnie i maksymalne RTT, odchylenie. Widząc to w tabeli, dostajesz od razu odpowiedź na pytanie: „czy problem jest chwilowy, czy powtarzalny?”.

Instalacja i uruchamianie mtr w praktyce

Na większości dystrybucji Linuksa mtr jest w standardowych repozytoriach:

# Debian/Ubuntu
sudo apt install mtr

# CentOS/RHEL/AlmaLinux
sudo yum install mtr

# Arch
sudo pacman -S mtr

Na macOS można skorzystać z Homebrew:

brew install mtr

W Windows nie ma klasycznego mtr, ale podobne funkcje zapewniają WinMTR (wersja z GUI) oraz różne porty konsolowe. Zasada działania pozostaje taka sama.

Tryb interaktywny i raportowy

mtr ma dwa podstawowe tryby.

Tryb interaktywny – uruchamiasz, oglądasz „na żywo”:

sudo mtr 8.8.8.8
sudo mtr -n 8.8.8.8   # bez reverse DNS

W terminalu pokazuje się tabela z listą hopów, gdzie co sekundę (lub co kilka sekund) odświeżają się statystyki.

Tryb raportowy – użyteczny przy zrzutach dla supportu:

sudo mtr -r -c 200 -n 8.8.8.8 > raport.txt

• -r – tryb raportu (po zakończeniu wypisuje podsumowanie i wychodzi),
• -c 200 – liczba wysłanych pakietów na hop.

Co oznaczają kolumny w mtr

Typowy output mtr zawiera m.in. takie kolumny:

• Loss% – procent utraconych pakietów do danego hopa,
• Snt – liczba wysłanych pakietów,
• Last – czas ostatniej odpowiedzi,
• Avg – średni czas RTT,
• Best – najlepszy (najniższy) czas,
• Wrst – najgorszy (najwyższy) czas,
• StDev – odchylenie standardowe (miara „skakania” opóźnień).

Zestawiając Loss% i StDev, widać, czy problem jest sporadyczny (np. kilka strat w długim okresie) czy permanentny (ciągłe 20–30% strat na danym odcinku).

Jak odróżnić „fałszywe” straty od realnego problemu

w mtr często pojawia się 50% czy 80% strat na jakimś hopie, po czym na kolejnych hopach straty wynoszą 0%. To pułapka, którą trzeba umieć obejść.

Mechanizm jest prosty: niektóre routery prioretyzują ruch przechodzący, a odpowiedzi ICMP traktują jako „zło konieczne”. Odpowiadają więc tylko na część zapytań, albo w ogóle rezygnują, gdy mają co innego do roboty. Pakiety do dalszych hopów jednak przechodzą normalnie.

Jak rozpoznać realny problem?

• jeśli Loss% jest duże na hopie N i na wszystkich kolejnych – prawdopodobnie wąskie gardło leży między N-1 a N lub na N,
• jeśli Loss% jest duże na hopie N, ale na N+1, N+2 masz 0% strat – router po prostu nie lubi odpowiadać na ICMP, ale przekazuje ruch dalej.

Diagnostyka „przerywającego” łącza z mtr

Problem, który najbardziej męczy użytkowników, to nie pełny zanik, ale zrywanie VPN, VoIP, gier. Zwykły ping w momencie, gdy „trafi”, pokaże straty. mtr potrafi uchwycić charakter tego problemu.

Praktyka:

1. Uruchom mtr do kilku celów naraz (np. brama operatora, serwer DNS, problematyczny host).
2. Pozostaw na kilkanaście–kilkadziesiąt minut, w czasie gdy występuje problem.
3. Sprawdź, czy straty pojawiają się już na pierwszych hopach (LAN/Wi‑Fi), czy dopiero „w chmurze”.

Jeżeli mtr do bramy lokalnej pokazuje Loss% > 0 i duże StDev, problem leży w twojej sieci (Wi‑Fi, zasilanie routera, kabel). Jeśli do bramy jest perfekcyjnie, a straty zaczynają się na pierwszym hopie u operatora – wtedy telefon do ISP jest całkiem zasadne poprzeć załączonym raportem.

mtr i ruch TCP – diagnozowanie problemów z konkretną usługą

Tak jak traceroute, mtr również potrafi używać TCP zamiast ICMP/UDP (zależnie od wersji). To przydaje się przy problemach z konkretną usługą (np. HTTPS na porcie 443), gdy podejrzewasz, że firewall traktuje różne typy ruchu inaczej.

sudo mtr -T -P 443 1.1.1.1

• -T – używaj TCP,
• -P 443 – docelowy port TCP.

Taki test zbliża się bardziej do realnych warunków połączenia użytkownika, szczególnie w sieciach z rygorystyczną filtracją.

Logi routera – ciche archiwum wszystkich dziwnych zachowań

Jakie zdarzenia zwykle zapisuje router

Router – nawet ten prosty domowy – widzi więcej niż jakiekolwiek narzędzie z pojedynczego komputera. Z poziomu logów można wyłapać rzeczy, których ping ani mtr nigdy nie pokażą, bo po prostu dzieją się „przed” wysłaniem pakietu.

Typowe kategorie wpisów w logach

Każdy producent nazywa to trochę inaczej, ale schemat bywa podobny. W logach zwykle przewijają się takie grupy zdarzeń:

• System / kernel / hardware – start urządzenia, restart, błędy pamięci, przegrzewanie, utrata zasilania, aktualizacje firmware.
• WAN / połączenie do dostawcy – negocjacja PPPoE, DHCP, zmiany adresu IP, zerwanie sesji, ponowne łączenie.
• DHCP lokalny – przydzielanie adresów klientom, konflikty adresów, odnowienia dzierżaw.
• Wi‑Fi – dołączanie i odłączanie klientów, błędne hasła, problemy z autoryzacją.
• Firewall / NAT – zablokowane pakiety, próby skanów portów, przekierowania, wygaśnięcia sesji NAT.
• VPN – zestawianie tuneli, błędy szyfrowania, rozłączenia, nieudane logowania użytkowników.
• Routing – zmiany tras statycznych/dynamicznych, problemy z protokołami OSPF/BGP (w sieciach bardziej zaawansowanych).

Na prostym routerze domowym zobaczysz głównie WAN, DHCP, Wi‑Fi i firewall. W większej sieci operatora czy firmy logi potrafią zająć osobny serwer – i tam dopiero zaczyna się prawdziwa archeologia.

Jak włączyć i zebrać logi z routera

Jeśli router leży w szafie, a w panelu webowym migocze gdzieś skromne „System Log”, to dobry moment, żeby to kliknąć. W wielu urządzeniach logowanie jest domyślnie ograniczone lub mocno obcięte.

Najczęstsze scenariusze:

• Prosty router SOHO – log dostępny tylko z GUI, często bez trwałego zapisu (po restarcie znika). Warto przed restartem zrobić zrzut ekranu lub eksport do pliku, jeśli jest taka opcja.
• Sprzęt „półprofesjonalny” (MikroTik, Ubiquiti, DrayTek) – możliwość wysyłania logów na zewnętrzny serwer syslog, filtrowanie kategorii, poziomów ważności.
• Routery operatorskie/enterprise – syslog to standard, logi lądują na centralnym serwerze logów, często dodatkowo indeksowane (np. przez ELK, Graylog, Splunk).

Na linuksowym routerze (np. OpenWrt) logi można podejrzeć również lokalnie:

logread             # bieżące logi systemowe
dmesg               # log jądra (sprzęt, sterowniki)

Gdy sieć kaprysi, a router „wygląda na zdrowego”, pierwsza rzecz to ściągnąć aktualne logi przed dalszymi eksperymentami – później może już ich nie być.

Co logi mówią o problemach z WAN

Z punktu widzenia użytkownika objaw jest prosty: „nie ma Internetu”. Dla logów to zwykle seria bardzo konkretnych komunikatów. Przykładowe wzorce:

• PPPoE rozłącza się co kilka minut – w logu pojawiają się wpisy typu: pppd: LCP terminated by peer, PADT received, komunikaty o negocjacji sesji. Sekwencja: „up → kilka minut → down → retry”. To już sygnał, że coś jest nie tak na linii operator–modem–router, a nie w twoim Wi‑Fi.
• DHCP od ISP gubi adres – pojawiają się powtarzające się prośby o odnowienie dzierżawy (REQUEST/RENEW), brak odpowiedzi (timeout), w końcu „fallback” do 0.0.0.0. W takim przypadku ping do bramy ISP nawet nie wystartuje, bo router fizycznie nie ma IP na WAN.
• Światłowód / modem kablowy „mruga” – w logach: Link down, Link up, flapping interfejsu, błędy fizycznej warstwy (CRC errors, loss of signal). Ping pokaże przerwy, mtr pokaże straty, ale dopiero log powie: „kabel się rozłącza co 30 sekund”.

Dobrym nawykiem jest sprawdzenie, czy czas w routerze jest poprawny (NTP). Bez tego analiza logów zamienia się w zgadywanie, czy „13:02” w logu to w ogóle dzisiaj.

Logi a problemy z DHCP i adresacją w LAN

Sytuacja klasyczna: jeden komputer „nie ma Internetu”, reszta działa. Ping do routera czasem idzie, czasem nie. W logach DHCP często da się znaleźć przyczynę dosłownie w dwóch linijkach.

Najczęstsze przypadki:

• Konflikt IP – jeden z hostów ma ręcznie ustawione IP z puli DHCP, drugi dostaje to samo z serwera. W logu DHCP pojawi się komunikat o konflikcie, czasem z MAC adresami. W systemach typu Windows bywa też wpis: „IP address conflict detected” po stronie klienta.
• Brak wolnych adresów – pula DHCP ma 20 adresów, w sieci funkcjonuje już 20 urządzeń, 21. klient czeka na adres i „kręci się” w nieskończoność. Log pokaże nieudane próby przydziału lub ostrzeżenia typu „no free leases”.
• Błędna konfiguracja podsieci – np. zmieniono maskę na routerze, a część urządzeń ma jeszcze starą konfigurację statyczną. Log DHCP niby przydziela poprawne adresy, ale stary host i tak nie widzi bramy. Po MAC-u i czasie logowania da się ustalić, które urządzenia są „nowe”, a które uparte.

Czasem wystarczy spojrzeć na listę aktualnych dzierżaw DHCP: jeśli w logu routera widzisz, że karty tego samego laptopa dostają adresy co kilka minut, to znak, że Wi‑Fi lub kabel się rwie, a nie że „Internet znów padł”.

Firewall i NAT w logach – kiedy „Internet działa, ale usługa nie”

Firewall routera to pierwsza linia frontu. Gdy użytkownik mówi: „strona otwiera się, ale VPN do firmy nie łączy”, logi firewalla są często złotem.

Typowe sygnały w logach:

• Blokowane przychodzące połączenia – wpisy typu IN=wan0 OUT= MAC=... SRC=... DST=... PROTO=TCP SPT=... DPT=... z akcją DROP lub REJECT. Jeśli eksperymentujesz z przekierowaniem portów (port forwarding), to właśnie tu zwykle widać, że ruch dochodzi, ale polityka bezpieczeństwa go ucina.
• Limitowanie / rate‑limit – gdy ktoś zrobi test „jak szybko odpyta mój router 1000 razy na sekundę”, firewall zacznie logować wpisy o przekroczonym limicie połączeń, SYN floodach, itp. Z punktu widzenia użytkownika: „czasem strona panelu się nie otwiera”, z punktu widzenia logu: „router celowo zrzuca nadmiar połączeń”.
• Sesje NAT wygasają – szczególnie przy długich, ale mało aktywnych połączeniach (SSH, niektóre VPN). W logach widać czyszczenie starych wpisów NAT. Jeśli w danym momencie użytkownik zgłasza „zawieszenie” sesji, a log pokazuje gwałtowne kasowanie dużej liczby mapowań, można podejrzewać zbyt krótki timeout lub przepełnienie tablicy NAT.

W bardziej rozbudowanych routerach można logować tylko część zdarzeń – np. tylko pakiety odrzucane albo tylko te, które pasują do danej reguły. To często jedyny rozsądny sposób, żeby nie utonąć w tysiącach linii tekstu.

Wi‑Fi w logach – rozłączenia, słabe hasła, „niewidzialni” klienci

Problemy z Wi‑Fi rzadko widać z perspektywy pingu do Internetu. Logi routera za to widzą, kiedy klient przychodzi, odchodzi, myli hasło albo próbuje się podłączyć z bardzo słabym sygnałem.

Na co zwrócić uwagę:

• Częste asocjacje / deasocjacje – ten sam MAC pojawia się jako „connected” i „disconnected” co kilkadziesiąt sekund. To zwykle zrywanie sygnału (zasięg, zakłócenia, słaba karta) albo problemy z zasilaniem routera/punktu dostępowego.
• Błędne hasła – wpisy typu authentication failed, WPA-PSK auth fail. Jeśli ktoś „przyniósł nowy telefon i Internet mu nie działa”, tu od razu widać, czy to kwestia konfiguracji, czy czegoś bardziej złożonego.
• Odmowy z powodu filtrów – np. gdy włączony jest filtr MAC lub ograniczenie liczby klientów. Klient usiłuje się podłączyć, log mówi: „odrzucone przez ACL”, a użytkownik twierdzi, że „hasło na pewno dobre”.

Jeżeli logi pokazują, że Wi‑Fi jest w wiecznym ruchu (dziesiątki klientów rozłączających się co chwilę), to skutki widać jako „mulenie” całej sieci – ale źródło leży w eterze, nie na łączu do Internetu.

Scenariusz: „Internet pada, gdy tylko zaczniemy wideokonferencję”

Wyobraźmy sobie małe biuro. Przez większość dnia wszyscy są zadowoleni, ale w chwili, gdy kilka osób jednocześnie włącza wideokonferencję, cała sieć „stoi”. Ping do 8.8.8.8 skacze do setek milisekund, mtr pokazuje straty już na pierwszym hopie.

Co mówią logi routera?

• W sekcji systemowej: ostrzeżenia o przegrzewaniu CPU, chwilowe restarty procesów (np. serwisów QoS), czasem nawet krótkie „rebooty” routera.
• W logach NAT/firewalla: tysiące nowych sesji w krótkim czasie, komunikaty o przepełnieniu tablicy, błędy alokacji.

W takiej sytuacji ping i mtr pokazują tylko objaw – przeciążenie pierwszego hopa. Log wyjaśnia, że przy dużym ruchu wideo router nie wyrabia sprzętowo albo ma za ciasno ustawione limity tablic NAT. Rozwiązaniem bywa zmiana sprzętu, wyłączenie części „fajerwerków” (np. DPI) albo sensowna konfiguracja QoS, zamiast szukania „awarii po stronie operatora”.

Scenariusz: losowe rozłączenia VPN i tajemnicze przerwy w pracy

Drugi, bardzo typowy przypadek: użytkownicy pracują zdalnie przez VPN IPsec lub SSL. Co jakiś czas tunel się zrywa, czasem co 30 minut, czasem po kilku godzinach. Ping do serwera w firmie po zewnętrznym IP bywa stabilny, ale klienci stanowczo twierdzą, że „VPN cały czas wyrzuca”.

Jak pogodzić te dwie rzeczy?

• W logach routera końcowego (u użytkownika) można zobaczyć wpisy o wygasaniu SA (Security Association), nieudanej renegocjacji kluczy, czasem informacje o braku odpowiedzi peer‑a na pakiety keepalive.
• Po stronie firmy w logu firewalla/VPN gateway pojawiają się „orphaned session”, „received packet with wrong SPI”, wpisy o braku pasującej polityki ruchu lub przekroczeniu maksymalnego czasu sesji.

Jeśli w dodatku w logach sieci domowej użytkownika widać, że router ISP okresowo zmienia publiczny adres IP (rozłączanie PPPoE, odnowienia DHCP), to zagadka się składa: VPN zrywa się nie dlatego, że „serwer się psuje”, ale dlatego, że po drodze zmienia się adres klienta lub jego NAT. Często pomaga wymuszenie keepalive, inny tryb NAT‑Traversal albo zestawienie tunelu z routera, nie z pojedynczego komputera.

Scenariusz: „strony się ładują, ale niektóre aplikacje mobilne nie działają”

To jeden z bardziej irytujących błędów dla użytkowników: www jest, YouTube śmiga, ale aplikacja bankowa albo komunikator w telefonie uparcie twierdzi, że „brak połączenia”. Ping do ogólnych adresów jest OK, mtr też nie pokazuje dramatu.

W logach routera można dostrzec:

• Wpisy z firewalla o blokowaniu ruchu do konkretnych adresów/portów – np. reguła rodzicielska, filtr treści, stary wpis w ACL, który nieświadomie obejmuje nowe zakresy IP danego dostawcy chmurowego.
• Reguły blokujące ruch UDP na nietypowych portach lub dropujące ruch IPv6, podczas gdy aplikacja próbuje łączyć się właśnie po IPv6.
• W sieciach z filtracją DNS: próby użycia zewnętrznych serwerów DNS (np. 8.8.8.8) odrzucane przez firewall – aplikacja nie dostaje odpowiedzi DNS, więc „Internetu nie ma”, mimo że reszta systemu poprawnie używa lokalnego DNS.

Bez logów łatwo zwalić winę na „kapryśną aplikację”. Z logami da się jasno pokazać: ruch jest blokowany w takim a takim miejscu, dokładnie w chwili uruchomienia programu.

Jak nie utonąć w logach – praktyczne filtrowanie

Surowe logi z routera, szczególnie w większej sieci, to tysiące wpisów na godzinę. Szukanie konkretnego problemu „na piechotę” przypomina przeglądanie księgi telefonicznej. Dlatego przydają się proste techniki zawężania:

• Po czasie – notujesz godzinę, gdy użytkownik zgłosił problem, a potem oglądasz logi z okna kilka minut przed i po tym momencie. Dlatego tak ważna jest poprawna synchronizacja czasu (NTP) na routerze.
• Po źródłowym IP/MAC – jeśli wiadomo, którego komputera dotyczy problem, filtrujesz logi po jego adresie. Często nagle z „szumu” wyłania się uporczywie powtarzający wpis.

Najczęściej zadawane pytania (FAQ)

Jak zacząć diagnostykę, gdy „nie działa internet”?

Zacznij od doprecyzowania problemu: co dokładnie nie działa, a co działa. Sprawdź, czy nie ładują się żadne strony, czy tylko jedna konkretna, oraz czy inne usługi (poczta, komunikator, VPN, gra) zachowują się normalnie. To od razu zawęża obszar poszukiwań – inaczej patrzy się na całkowity brak sieci, a inaczej na problem z jedną usługą.

Kolejny krok to sprawdzenie „łańcucha”: najpierw ping do bramy lokalnej (routera), potem sprawdzenie, czy router ma internet (ping np. do DNS operatora lub 8.8.8.8), a na końcu test po nazwie (ping www.google.com, nslookup/dig). W ten sposób znajdujesz ogniwo, w którym ruch się urywa, zamiast losowo resetować wszystko po kolei.

Do czego służy ping i co tak naprawdę mierzy?

Ping odpowiada na proste pytanie: „czy ten host jest osiągalny na poziomie IP i z jakim opóźnieniem?”. Mierzy czas RTT (round-trip time) w milisekundach oraz procent utraconych pakietów. Jeśli przez kilka–kilkanaście wysłanych pakietów nie ma żadnych strat, a czasy są stabilne, mamy przynajmniej przyzwoite połączenie IP.

Ping nie pokaże jednak trasy pakietu ani tego, czy poprawnie działa sama usługa (np. strona WWW, VPN). Host może odpowiadać na ICMP, a jednocześnie mieć problem z HTTP lub TLS. Może też być odwrotnie: ping nie odpowiada, bo ICMP jest zablokowane na firewallu, ale strona WWW działa bez zarzutu.

Jak interpretować wyniki ping: jakie opóźnienie i jitter są „normalne”?

W sieci lokalnej (LAN, Wi‑Fi w tym samym mieszkaniu) typowe opóźnienia do routera to pojedyncze milisekundy. Kilkanaście–kilkadziesiąt ms do serwerów w Polsce jest zwykle w porządku, a powyżej 100 ms do odległych lokalizacji (inne kontynenty) też nie musi oznaczać problemu. Niepokojące jest przede wszystkim duże wahanie – raz 20 ms, raz 150 ms – czyli wysoki jitter.

Jeśli ping pokazuje:

• brak odpowiedzi do bramy lokalnej – szukaj problemu w kablu, Wi‑Fi, adresacji IP lub firewallu na routerze,
• stale wysokie czasy do wszystkiego – możliwe przeciążenie łącza lub problem u operatora,
• duży jitter i sporadyczną utratę pakietów – będzie to psuło VoIP i gry online, nawet jeśli średnie opóźnienie wygląda akceptowalnie.

Czym różni się ping od traceroute i mtr przy diagnozowaniu sieci?

Ping mówi, czy cel jest osiągalny i z jakim opóźnieniem, ale nie pokazuje drogi, którą pakiety idą. Traceroute rozbija trasę na „skoki” (hopy) – kolejne routery pośrednie – i pokazuje, gdzie pojawia się opóźnienie lub utrata. To jak sprawdzanie, na którym odcinku autostrady tworzy się korek.

MTR łączy funkcje ping i traceroute w trybie ciągłym. Dla każdego hopa widzisz statystyki: średnie opóźnienie, jitter, procent utraconych pakietów. Dzięki temu możesz złapać problemy, które pojawiają się tylko co jakiś czas, np. przeciążenie jednego z routerów w godzinach szczytu.

Jak rozpoznać w logach routera, czy problem jest po stronie łącza, czy w LAN?

Jeśli logi routera pokazują częste „up/down” interfejsu WAN, ponowne zestawianie PPPoE albo zrywanie połączenia DHCP z operatorem, problem leży zwykle między routerem a dostawcą: kabel do modemu, sygnał światłowodu, linia DSL, konfiguracja po stronie ISP. W takiej sytuacji wszystkie urządzenia w domu odczuwają awarię w tym samym momencie.

Gdy natomiast logi WAN są stabilne, a kłopoty zgłasza pojedynczy komputer, warto sprawdzić jego adresację IP, sterowniki karty sieciowej i lokalny firewall. W logach routera mogą wtedy pojawiać się np. zablokowane pakiety z jednego IP w LAN albo konflikty adresów, ale samo połączenie do operatora pozostaje cały czas „up”.

Co to jest jitter, utrata pakietów i MTU – i jak wpływają na jakość połączenia?

Jitter to zmienność opóźnienia między kolejnymi pakietami. Nawet jeśli średnio masz 30 ms, ale kolejne pakiety skaczą między 20 a 120 ms, rozmowa głosowa czy gra online zacznie się „przycinać”. Utrata pakietów to z kolei procent pakietów, które w ogóle nie dotarły do celu lub odpowiedź nie wróciła na czas. Kilka procent strat potrafi skutecznie popsuć wrażenia z VoIP i gier.

MTU (Maximum Transmission Unit) określa maksymalny rozmiar pakietu IP, jaki może przejść bez fragmentacji. Zbyt duży MTU przy źle działającym mechanizmie Path MTU Discovery bywa podstępną usterką: jedne strony się ładują, inne wiszą lub częściowo nie działają. W takich sytuacjach pomocne są testy ping z większym rozmiarem pakietu i odpowiednią flagą (np. -f w Windows, -M do w Linuksie) oraz korekta MTU na interfejsie routera.

Jak NAT i firewall mogą wpływać na diagnostykę ping, traceroute i mtr?

NAT tłumaczy adresy prywatne z LAN na publiczny adres routera. Dla ping czy traceroute zwykle jest „przezroczysty”, ale przy bardziej złożonych scenariuszach (np. gry, VoIP, VPN) problemy z translacją portów i stanami połączeń potrafią powodować zrywanie sesji lub brak odpowiedzi z konkretnych usług, mimo że ping do hosta działa bez zarzutu.

Firewall może natomiast traktować ruch ICMP inaczej niż TCP/UDP. Często ICMP jest ograniczany lub blokowany, przez co ping lub część hopów w traceroute nie odpowiada, mimo że normalny ruch HTTP/HTTPS przechodzi. W diagnozie trzeba wtedy patrzeć na całość: ping, traceroute/mtr i logi firewalla, a nie opierać się na jednym „zielonym” lub „czerwonym” teście.