Dla administratora sieci workflow diagnozowania sieci zaczyna się od dobrego modelu mentalnego. Najwygodniejszym i najbardziej praktycznym jest klasyczny model OSI, traktowany nie jako sucha teoria, ale jako mapa prowadząca od objawu do konkretnego miejsca w infrastrukturze.
Krok 1: przypisz problem do warstwy lub zakresu warstw. Zamiast myśleć „nie działa internet”, lepiej przeformułować to na: „nie ma adresu IP”, „nie rozwiązuje się nazwa DNS”, „ping do gatewaya działa, ale HTTP już nie”. Każdy z tych objawów wskazuje na inną część stosu:
Brak IP – warstwa 3, ale często przyczyna leży niżej (L1/L2, DHCP, VLAN).
IP jest, ale nie działa nazwa – zwykle DNS (aplikacyjna / warstwa 7), czasem problem z routingiem do serwera DNS.
Działa ping do bramy, ale nie działa WWW – IP i routing raczej poprawne, problem w warstwie 4–7 (firewall, proxy, aplikacja).
Link się zrywa, interfejsy flappują – warstwa 1/2 (kabel, port, Wi‑Fi, SFP, duplex, prędkość).
Przy każdym zgłoszeniu umysłowo „przejedź” po warstwach OSI od dołu do góry i spróbuj zatrzymać się tam, gdzie objaw ma najwięcej sensu. To nie musi być dokładnie jedna warstwa, ale zawężenie do 2–3 poziomów drastycznie przyspiesza troubleshooting.
Przykład z praktyki: użytkownik mówi „nie mogę wydrukować”. Jeśli drukarka ma interfejs sieciowy, diagnoza drukarki to tak naprawdę diagnoza zwykłego hosta. W głowie od razu zapala się sekwencja: L1 – kabel, L2 – VLAN, L3 – IP / gateway, L4–7 – usługa drukarki (port 9100, SMB, IPP).
Co sprawdzić na tym etapie: czy jesteś w stanie jednym zdaniem opisać problem i przypisać go do orientacyjnej warstwy (lub zakresu warstw) modelu OSI. Jeśli nie – trzeba wrócić do zbierania informacji i doprecyzować objaw.
Od objawu do przyczyny zamiast strzelania na ślepo
Największą stratą czasu w rozwiązywaniu problemów z łącznością jest „strzelanie na ślepo”: restartowanie losowych usług, zmiany w firewallu, przełączanie kabli bez żadnego planu. Profesjonalny krok po kroku troubleshooting zaczyna się od jasno zdefiniowanego objawu i metodycznego zawężania zakresu.
Krok 1: nazwij objaw w sposób mierzalny. Przykłady:
„Host X z VLAN 10 nie może pingować gatewaya 10.0.10.1”.
„Klienci w biurze A nie mogą otworzyć stron po HTTPS, HTTP działa”.
„VPN IPsec zestawia się, ale ruch nie przechodzi do sieci zdalnej 192.168.50.0/24”.
Krok 2: postaw hipotezę roboczą. Na przykład: „host jest w złym VLAN-ie”, „brak trasy zwrotnej na zdalnym routerze”, „blokada portu 443 na firewallu brzegowym”. Hipoteza musi być możliwa do sprawdzenia jednym konkretnym testem lub komendą.
Krok 3: wykonaj jedną zmianę lub jeden test na raz. To kluczowa zasada: jeśli zmienisz trzy rzeczy, a problem zniknie, nie będziesz wiedzieć, co go faktycznie rozwiązało. Po każdym kroku zapisz krótką notatkę: co zostało sprawdzone, jaki był wynik, jak to zawęziło pole poszukiwań.
W praktyce warto uchwycić rytm: obserwacja → hipoteza → test → wniosek → następna hipoteza. Po kilku takich iteracjach źródło awarii zwykle staje się oczywiste.
Co sprawdzić: czy dla bieżącego przypadku masz spisane:
konkretny objaw w jednym zdaniu,
pierwszą hipotezę roboczą,
pierwszy test, który ją potwierdzi lub obali.
Jeśli któryś elementu brakuje, workflow będzie chaotyczny.
Zasada „od prostego do złożonego” i minimalizacja chaosu
Diagnozowanie sieci kusi, żeby od razu zaglądać w logi firewalli, debugować BGP i sprawdzać zrzuty pakietów. W praktycznym workflow diagnozowania sieci dużo szybciej prowadzi podejście „od prostego do złożonego”.
Typowa sekwencja:
Krok 1: sprzęt i fizyka – czy urządzenie jest włączone, wpięte, czy świeci się link na porcie.
Krok 2: podstawowa łączność lokalna – adres IP, ten sam VLAN, ping do gatewaya.
Krok 3: routing i trasy – ping/traceroute do zasobu w innej sieci, tablica routingu.
Pomijanie pierwszych kroków i skakanie od razu do warstw wyższych generuje mnóstwo niepotrzebnej pracy. Prosty przykład: pół godziny spędzone na firewallu, a na końcu okazuje się, że użytkownik wpiął się w gniazdo z innym VLAN-em lub kabel jest uszkodzony.
Co sprawdzić: czy przed wejściem w „głęboką” analizę logów i protokołów:
zweryfikowałeś link fizyczny,
sprawdziłeś konfigurację IP i VLAN,
masz wyniki prostych pingów (localhost, własny IP, gateway).
Źródło: Pexels | Autor: Field Engineer
Zbieranie informacji na start: użytkownik, zakres, wpływ
Dobre pytania do użytkownika zamiast zgadywania
Rozwiązywanie problemów z łącznością zaczyna się od rozmowy z użytkownikiem. Zamiast przyjmować komunikat „nie działa internet” jako pełen opis stanu, trzeba dopytać o konkretne szczegóły i zamienić ogólniki na użyteczne dane.
Krok 1: ustal, od kiedy problem występuje. Dopytaj:
„Od jakiej godziny/dnia zauważyłeś problem?”
„Czy wcześniej tego samego dnia działało poprawnie?”
„Czy w momencie pojawienia się problemu było coś zmieniane? (sprzęt, hasło, lokalizacja, aktualizacje)”
To często pozwala powiązać awarię z konkretną zmianą w środowisku (wdrożenie nowej polityki, zmiana konfiguracji switcha, wymiana routera).
Krok 2: doprecyzuj, co dokładnie nie działa. Zadawaj pytania typu:
„Czy możesz otworzyć jakąkolwiek stronę WWW? Jeśli nie – jaką próbowałeś?”
„Czy działa poczta? Komunikator? Drukarka sieciowa?”
„Problem dotyczy tylko jednej aplikacji, czy wszystkiego, co używa sieci?”
Im więcej konkretów, tym łatwiej przypisać objaw do warstwy OSI i odpowiedniego fragmentu infrastruktury.
Co sprawdzić: czy w notatkach masz:
orientacyjny czas początku problemu,
informację, co działa, a co dokładnie nie działa,
wzmiankę o ewentualnych zmianach w otoczeniu użytkownika.
Szybka ocena skali problemu i zakresu wpływu
Dobry workflow diagnozy sieciowej zaczyna się również od określenia, czy problem jest lokalny, czy globalny. Inaczej wygląda podejście do pojedynczej stacji roboczej, a inaczej do awarii całego VLAN-u lub lokalizacji.
Krok 1: sprawdź, czy inne urządzenia w tej samej lokalizacji mają ten sam problem. Możesz zapytać użytkownika:
„Czy inni w pokoju lub dziale mają podobny problem?”
„Czy próbowałeś na innym komputerze/telefonie w tym samym miejscu?”
Jeśli objaw dotyczy wielu urządzeń w jednym segmencie, prawdopodobnie jest to co najmniej L2/L3 (VLAN, DHCP, routing), a nie tylko konfiguracja jednego hosta.
Krok 2: określ rodzaj połączenia użytkownika. Kluczowe są informacje:
LAN czy Wi‑Fi,
VPN czy bezpośrednio w sieci lokalnej,
z jakiej lokalizacji (biuro, oddział, praca zdalna).
Problem tylko na Wi‑Fi często oznacza kłopoty z zasięgiem, roamingiem, kontrolerem lub VLAN-em przypisanym do SSID. Problem tylko na VPNie sugeruje kłopot z trasami, politykami lub samym tunelem.
lokalizacja (biuro, piętro, gniazdo, punkt dostępu),
informację o typie połączenia (Wi‑Fi/LAN/VPN).
Co sprawdzić: czy wiesz:
czy awaria jest jednostkowa czy grupowa,
którego segmentu sieci dotyczy (VLAN, lokalizacja, SSID),
na jakim typie połączenia objaw się pojawia.
Diagnostyka od warstwy fizycznej: okablowanie, link, Wi‑Fi
Proste testy fizyczne przed wejściem w logikę sieci
Warstwa fizyczna jest nudna do momentu, w którym nie przestaje działać. Zanim zaczniesz analizować logi routera, warto przeprowadzić kilka banalnych, ale skutecznych testów, które często rozwiązują problem w kilka minut.
Krok 1: weryfikacja urządzenia i podłączenia.
Czy komputer/drukarka/switch jest włączony i nie wisi w stanie zawieszenia?
Czy kabel sieciowy jest poprawnie wpięty po obu stronach (host i patchpanel/switch)?
Czy diody na karcie sieciowej świecą (link) i mrugają (aktywność)?
Jeśli diody nie świecą w ogóle – nie ma linku fizycznego. Wtedy najpierw trzeba rozwiązać ten problem, zanim przejdziesz wyżej (L2/L3). Jeśli dioda linku się zapala i gaśnie co chwilę, może to być oznaka flappingu – np. uszkodzony kabel, adapter, zły kontakt.
Krok 2: sprawdzenie portu na switchu. Na urządzeniu dostępowym warto od razu wykonać:
show interface status (Cisco) lub odpowiednik – żeby zobaczyć, czy port jest up, z jaką prędkością, czy jest err-disabled.
Duża liczba błędów CRC lub input errors rosnąca w czasie niemal zawsze oznacza problem fizyczny: słaby kabel, zły patchpanel, źle zaciśnięta wtyczka, uszkodzony port. Wtedy szybka podmiana kabla lub gniazda jest uzasadniona – to nie jest „strzelanie na ślepo”, tylko weryfikacja konkretnej hipotezy.
Krok 3: rozsądna podmiana elementów. Podmiana wszystkich kabli i portów w ciemno to strata czasu, ale wykonana z głową jest bardzo skuteczna:
zamień kabel użytkownika na sprawdzony, działający egzemplarz,
przełącz port z podejrzanego interfejsu switcha na inny, wolny, w tym samym VLAN-ie,
jeśli to możliwe – podepnij komputer do innego gniazda w ścianie.
Jeśli po zmianie kabla i portu link jest stabilny, a błędy na interfejsie znikają, przyczyna jest jasna. Zapamiętaj: fizyczne przyczyny to nie tylko kabel, ale też zasilanie, temperatura, przeciążony switch w szafie bez wentylacji czy wadliwy moduł SFP.
Co sprawdzić: czy:
port na switchu jest up i nie ma rosnących błędów,
kabel był fizycznie przełączony na „dobry” i test zakończył się sukcesem lub porażką,
urządzenie końcowe nie ma oczywistych problemów sprzętowych (brak sterownika, wyłączona karta).
Specyfika Wi‑Fi w porównaniu z połączeniem kablowym
Problemy z siecią bezprzewodową wymagają innego podejścia niż klasyczne kable. Ten sam workflow diagnozowania sieci trzeba tu uzupełnić o parametry radiowe i środowisko.
Krok 1: sprawdź podstawowe parametry radiowe. Na stacji roboczej lub w kontrolerze Wi‑Fi spójrz na:
siłę sygnału (RSSI) – bardzo niski poziom oznacza słaby zasięg,
pasmo (2,4 GHz vs 5 GHz) – 5 GHz ma zwykle lepszą przepustowość, ale gorszy zasięg przez ściany.
Analiza roamingu, autoryzacji i problemów specyficznych dla Wi‑Fi
W sieciach bezprzewodowych sama siła sygnału to dopiero początek. Bardzo często kłopotem nie jest zasięg, lecz roaming, uwierzytelnianie albo polityki przypisane do konkretnego SSID.
Krok 2: sprawdź, do czego klient jest faktycznie podłączony. Użytkownik może widzieć „ten sam” SSID, ale:
może istnieć kilka identycznie nazwanych SSID w różnych VLAN-ach (np. sieć gościnna i korporacyjna),
punkt dostępu może być przypisany do innego profilu (np. inna lokalizacja logiczna na kontrolerze),
klient może „wisieć” na bardzo oddalonym AP, mimo że obok jest inny z dużo lepszym sygnałem (słaby roaming).
Na kontrolerze lub w systemie zarządzającym sprawdź:
na którym AP klient jest zalogowany,
jakie ma przydzielone VLAN ID,
aktualny adres IP i czas trwania sesji.
Krok 3: przeanalizuj proces uwierzytelniania. W sieciach z WPA2‑Enterprise/802.1X częste są błędy typu „wraca prośba o hasło”, „łączenie trwa bardzo długo”. Wtedy:
zweryfikuj, czy zegar klienta i kontrolera nie różni się drastycznie (problem z walidacją certyfikatów),
upewnij się, że porty między kontrolerem a serwerem RADIUS nie są blokowane (najczęściej UDP 1812/1813).
Typowy błąd: długie grzebanie w antenach i kanałach, gdy realnym problemem jest po prostu zablokowane konto w AD.
Krok 4: powiąż Wi‑Fi z resztą sieci. Po stronie warstwy fizycznej Wi‑Fi zastępuje kabel, ale dalej obowiązuje ta sama logika:
dla konkretnego SSID musi być jasno określony VLAN,
VLAN ten musi być poprawnie przeniesiony trunkami do routera/firewalla,
musi istnieć odpowiedni DHCP scope i trasy.
Jeżeli urządzenie po Wi‑Fi dostaje adres z innej puli niż przewodowe, bardzo możliwe, że mówisz o dwóch różnych segmentach sieci – problem może leżeć wtedy wyżej niż fizyka, mimo że objaw „nie działa internet” brzmi identycznie.
Co sprawdzić: czy:
wiesz, do którego AP i SSID podłączony jest klient oraz jaki VLAN został mu przydzielony,
uwierzytelnianie (RADIUS/802.1X) kończy się sukcesem i nie ma błędów w logach,
parametry IP po Wi‑Fi zgadzają się z oczekiwanym VLAN-em i lokalizacją.
Źródło: Pexels | Autor: Field Engineer
Warstwa 2: VLAN‑y, MAC, ARP i tablice przełączników
Spójność VLAN‑ów od gniazdka do routera
Błędy na warstwie 2 często przebierają się za problemy z „internetem” czy „DNS-em”. Zanim zaczniesz grzebać w firewallu, trzeba ustalić, czy ruch w ogóle dociera w odpowiedni VLAN i czy przełączniki zgadzają się co do jego numeru.
Krok 1: sprawdź konfigurację portu dostępowego. Dla klasycznego portu użytkownika interesuje Cię:
tryb access czy trunk (dla hosta zwykle access),
jaki VLAN access jest przypisany,
czy port nie jest zabezpieczony dodatkowymi mechanizmami (Port Security, 802.1X, dynamic VLAN).
Na przełączniku wykonaj coś w stylu:
show interface <port> switchport
show vlan brief
i porównaj, czy VLAN hosta jest zgodny z tym, co powinien mieć według dokumentacji lub standardu dla danego działu/pokoju.
Krok 2: zweryfikuj konfigurację trunków. Jeżeli przełączniki są spięte trunkami, a ruch z danego VLAN-u musi przejść przez kilka urządzeń, upewnij się, że:
VLAN jest dozwolony na wszystkich trunkach po drodze,
nie ma asymetrii (np. na jednym trunku VLAN 20 jest tagowany, a na innym jest filtrowany),
nie występuje mieszanie numerów VLAN do różnych nazw/segmentów w różnych częściach sieci.
Typowy scenariusz: nowy VLAN dodany na przełączniku dostępowym, ale zapomniano go dopuścić na uplinku do przełącznika rdzeniowego.
Krok 3: lokalizacja problemu przy pomocy „znanego działającego” portu. Jeżeli w tym samym pomieszczeniu jest inny użytkownik, u którego wszystko działa, porównaj:
VLAN na jego porcie access,
konfigurację trunków, jeśli obaj są na tym samym przełączniku lub stosie,
ewentualne polityki (Port Security, VoIP VLAN itp.).
Szybka zamiana gniazdek (działający host do problematycznego portu i odwrotnie) potrafi jednoznacznie wskazać, czy wina leży w konfiguracji L2 czy raczej na samej stacji.
Co sprawdzić: czy:
znasz dokładny VLAN użytkownika oraz czy jest on obecny i dozwolony na wszystkich przełącznikach po drodze,
na problematycznym porcie access konfiguracja jest identyczna jak na porcie, gdzie wszystko działa,
port nie jest zablokowany przez mechanizmy bezpieczeństwa L2.
Śledzenie adresów MAC i topologii L2
Kiedy VLAN zgadza się na papierze, kolejnym krokiem jest ustalenie, czy przełączniki widzą dane urządzenie we właściwym miejscu i czy nie ma pętli lub dziur w topologii.
Krok 1: znajdź adres MAC hosta. Na stacji roboczej lub urządzeniu końcowym ustal adres MAC interfejsu sieciowego. Następnie na przełączniku szukaj go w tablicy MAC:
show mac address-table | include <MAC>
Spodziewasz się zobaczyć konkretny port i VLAN. Jeżeli:
MAC nie pojawia się w ogóle – host może nie wysyłać żadnego ruchu (problem z fizyką/sterownikiem) lub ruch jest filtrowany,
MAC jest widoczny, ale na innym porcie/VLAN-ie – pojawia się wskazówka o błędnym podłączeniu, pętli lub błędnej konfiguracji trunku.
Krok 2: śledzenie hosta przez kilka przełączników. Przy większej topologii przejdź „w górę”:
na pierwszym przełączniku znajdź port, na którym widoczny jest MAC,
jeśli to uplink, przejdź do kolejnego przełącznika i powtórz zapytanie,
kontynuuj, aż dojdziesz do przełącznika dystrybucyjnego lub rdzeniowego.
Na którymś etapie tablica MAC może wskazać podejrzany port (np. uplink, który nie powinien przenosić tego VLAN-u). To miejsce, gdzie zwykle kryje się błędna konfiguracja.
Krok 3: kontrola stabilności wpisów MAC. Jeżeli adres MAC „skacze” między portami (widzisz go raz na jednym, raz na innym porcie), może to oznaczać:
pętlę L2 (np. podwójne połączenie między dwoma przełącznikami bez poprawnego STP),
nieprawidłową konfigurację agregacji łączy (LACP/port-channel),
podłączony mini‑switch biurkowy, który wprowadza zamieszanie.
W takiej sytuacji przejrzyj konfigurację STP, stan port‑channeli oraz to, co fizycznie jest podpięte do portów uplink.
Co sprawdzić: czy:
adres MAC hosta jest widoczny w oczekiwanym VLAN-ie i na prawidłowym porcie,
MAC nie zmienia dynamicznie portu (brak „skakania” po interfejsach),
droga MAC‑ów przez kolejne przełączniki prowadzi logicznie w stronę gatewaya.
Diagnostyka ARP jako pomost między L2 i L3
Protokół ARP łączy świat MAC‑ów i IP. Umiejętne korzystanie z tablic ARP na hostach i urządzeniach L3 pozwala szybko sprawdzić, czy komunikacja lokalna w ramach VLAN‑u działa prawidłowo.
Krok 1: sprawdź ARP na stacji roboczej. Na problematycznym hoście wykonaj:
arp -a
ip neigh <!-- Linux
Interesuje Cię wpis dla gatewaya (adres IP bramy domyślnej). Typowe przypadki:
brak wpisu ARP dla gatewaya – host nie był w stanie „odpytać” sieci o MAC bramy; może być problem z L2, zasięgiem lub samą bramą,
wpis ARP jest, ale ping do gatewaya nie działa – problem może być po stronie urządzenia L3 lub filtracji ruchu ICMP,
ARP pokazuje adres MAC innego urządzenia niż brama (sprawdź w dokumentacji) – podejrzenie błędnej konfiguracji, ARP spoofingu lub błędnego podłączenia.
Krok 2: porównaj tablice ARP na routerze/bramie. Na routerze lub L3 switchu sprawdź:
show ip arp | include <IP_hosta>
Oczekujesz, że:
wpis dla IP hosta jest obecny,
adres MAC
Jeżeli brama nie widzi hosta w ARP, a host widzi bramę – ruch może być blokowany w jedną stronę lub host jest w innym VLAN‑ie niż zakładasz.
Krok 3: użycie ARP do lokalizacji kolizji adresów IP. Gdy istnieje podejrzenie duplikatu IP (np. losowe zrywanie sesji, raz działa, raz nie), zwróć uwagę na to, czy:
wpis ARP dla danego IP na hoście zmienia się (inny MAC co jakiś czas),
tablica ARP na routerze pokazuje inny MAC niż powinien,
logi routera nie raportują konfliktów IP.
Jeżeli MAC dla danego IP „miga” między różnymi adresami fizycznymi, znajdź oba urządzenia w tablicach MAC przełączników i ustal, kto bezprawnie używa tej samej adresacji.
Co sprawdzić: czy:
host ma poprawny wpis ARP dla gatewaya,
router/brama widzi MAC hosta w swojej tablicy ARP,
dla jednego IP nie pojawia się więcej niż jeden adres MAC.
Warstwa 3: adresacja IP, brama, routing
Weryfikacja podstawowej konfiguracji IP na hoście
Zanim przejdziesz do złożonych tras międzylokacyjnych, upewnij się, że sam host ma sensowną konfigurację IP. Zaskakująco często problemem jest źle wpisana brama lub maska.
Krok 1: sprawdź adres IP, maskę, bramę i DNS. Na stacji roboczej:
Windows: ipconfig /all
Linux/macOS: ip addr + ip route + zawartość /etc/resolv.conf
Porównaj dane hosta z:
zakresem przydzielanym przez DHCP dla danego VLAN-u,
adresacją opisującą podsieć (np. w dokumentacji lub w routerze),
konfiguracją innego, działającego hosta w tym samym segmencie.
Jeśli IP, maska lub brama różnią się od tego, co powinny mieć stacje w tej sieci, przyczyna problemu może być wyłącznie po stronie hosta lub serwera DHCP.
Krok 2: rozpoznaj, skąd pochodzi konfiguracja. Ustal, czy host dostaje adres z DHCP, czy jest ustawiony statycznie:
gdy ma statyczny IP w sieci, w której z założenia wszystko działa z DHCP – szukaj konfliktów i błędów w wpisach statycznych,
gdy jest ustawiony na DHCP, ale nie dostał adresu (APIPA/169.254.x.x) – skup się na serwerze DHCP i relayach.
ping do własnego adresu IP (sprawdzenie stosu TCP/IP hosta),
ping do innego hosta w tym samym VLAN-ie,
ping do gatewaya,
ping do zewnętrznego adresu IP (np. serwera w innej sieci, znanego hosta w internecie),
ping po nazwie (test DNS + łączność).
Na którym etapie pojawia się przerwa, tam zwykle jest sedno problemu.
Co sprawdzić: czy:
adres IP/maska/brama i DNS są zgodne z polityką dla danej podsieci,
host jest w stanie pingować lokalne urządzenia i gateway,
typ konfiguracji (DHCP/statyczny) jest świadomy i zgodny z tym, jak zaprojektowano sieć.
Diagnostyka DHCP i relaya
Analiza działania DHCP na problematycznym VLAN-ie
Diagnozując problemy z brakiem adresu IP z DHCP, przechodź od hosta, przez L2, aż do serwera. Chodzi o to, by ustalić, gdzie po drodze giną pakiety DISCOVER/OFFER/REQUEST/ACK.
Krok 1: potwierdź brak dzierżawy na hoście. Zacznij od samego klienta:
Windows: ipconfig /all – sprawdź, czy interfejs ma status DHCP Enabled = Yes, czy posiada adres serwera DHCP i jak długo ważna jest dzierżawa,
Linux: journalctl -u NetworkManager lub logi demona DHCP (np. journalctl -u dhclient, /var/log/syslog),
typowy objaw problemu: adres z puli APIPA 169.254.x.x lub brak adresu.
Jeżeli w logach klienta widzisz próby wysłania DHCPDISCOVER bez odpowiedzi DHCPOFFER, skup się na drodze do serwera.
Krok 2: test na tym samym porcie z innym urządzeniem. Pozwala szybko oddzielić awarię po stronie klienta od problemu z siecią:
podepnij laptopa testowego do tego samego gniazda,
porównaj: jeśli laptop dostaje adres, a oryginalny host nie – wróć do diagnostyki systemu/agentów zabezpieczeń na hoście.
Krok 3: sprawdź, czy VLAN jest poprawnie dowieziony do interfejsu z DHCP relayem/bramą. Na przełączniku L3 lub routerze zajrzyj do konfiguracji interfejsu SVI:
show run interface vlan <ID>
show ip interface vlan <ID>
Interfejs musi być:
UP/UP,
z poprawną adresacją IP przypisaną do tej podsieci,
bez akces list / polityk blokujących ruch broadcast z/na ten VLAN (filtry DHCP, storm-control itp.).
Co sprawdzić: czy:
host faktycznie korzysta z DHCP (a nie ma wpisanego ręcznie błędnego IP),
inny, testowy host w tym samym porcie/VLAN-ie ma ten sam problem lub wszystko działa,
interfejs SVI dla danego VLAN-u jest aktywny i ma poprawną adresację.
Sprawdzanie DHCP relay i komunikacji z serwerem
Gdy serwer DHCP nie znajduje się w tej samej podsieci, kluczową rolę odgrywa relay (helper-address). Błąd w jego konfiguracji powoduje, że broadcast z klienta nigdy nie dociera do serwera.
Krok 1: zweryfikuj konfigurację helper-address. Na interfejsie SVI dla problematycznego VLAN-u szukaj wpisów typu:
ip helper-address <IP_DHCP>
Sprawdź kilka elementów:
adres wskazuje na działający, właściwy serwer DHCP (nie na dawny, już wyłączony),
nie ma literówek ani „przestawionych” helperów z innego VLAN-u,
jeśli helperów jest kilka – kolejność i zawartość są zgodne z projektem (np. serwery centralne + lokalne).
Krok 2: prześledź, czy router/L3 switch wysyła zapytania do serwera. Na urządzeniu z relayem:
sprawdź liczniki (jeśli producent oferuje): show ip dhcp relay statistics,
włącz tymczasowo debug (np. debug ip dhcp server packet albo odpowiednik) na czas pojedynczego testu,
obserwuj, czy widzisz DHCPDISCOVER przychodzące z VLAN-u oraz wysyłane dalej pakiety UNICAST do serwera.
Przy debugu zachowaj ostrożność – na produkcyjnym core uruchamiaj go tylko na krótko, na oknie serwisowym, jeśli to ruchliwy węzeł.
Krok 3: potwierdź łączność IP między relayem a serwerem DHCP. Na routerze/L3 switchu:
ping do adresu IP serwera DHCP,
sprawdzenie trasy: traceroute <IP_DHCP> lub mtr (tam gdzie dostępne),
weryfikacja, czy po drodze nie ma ACL blokujących UDP/67-68.
Jeśli ping nie działa, zanim wini się DHCP, trzeba naprawić routing lub filtrację między VLAN-em a serwerem.
Krok 4: zajrzyj w logi serwera DHCP. Na serwerze (Windows DHCP, isc-dhcpd, Kea, inne) szukaj wpisów dotyczących problematycznego MAC-a:
czy serwer otrzymuje DISCOVER/REQUEST od tego klienta,
czy odpowiada OFFER/ACK i na jaki adres,
czy nie odrzuca żądań (np. z powodu wyczerpanej puli, filtrów po MAC-u, klas polityk).
Typowy błąd: serwer ma skonfigurowaną podsieć, ale z inną maską niż na routerze, przez co nie uważa tego VLAN-u za obsługiwany i milczy.
Co sprawdzić: czy:
na interfejsie SVI jest poprawny ip helper-address do właściwego serwera DHCP,
relay widzi i przekazuje pakiety z danego VLAN-u (statystyki/debbug),
serwer DHCP rzeczywiście otrzymuje żądania z tego segmentu i ma dla niego poprawną definicję podsieci.
Diagnostyka routingu w sieciach lokalnych i międzylokacyjnych
Gdy host ma adres IP, maskę i gateway skonfigurowane prawidłowo, a ping do bramy działa, kolejna warstwa problemów to routing między podsieciami i lokalizacjami.
Krok 1: potwierdź trasę domyślną i trasy do sąsiednich sieci. Na bramie VLAN-u:
show ip route
show ip route <adres_docelowy>
Najpierw skoncentruj się na dwóch rodzajach tras:
trasa do sieci źródłowej (podsiec hosta) – czy istnieje i prowadzi na właściwy interfejs,
trasa do sieci docelowej (np. do innego VLAN-u, oddziału, internetu) – czy jest statyczna, czy dynamiczna (OSPF/EIGRP/BGP) i czy jest obecna w RIB/FIB.
Jeśli router nie zna drogi do sieci docelowej, nie pomoże nawet idealna konfiguracja ARP czy VLAN-ów.
Krok 2: użyj traceroute z różnych punktów sieci. Przy niedogadanym routingu traceroute jest znacznie bardziej użyteczny niż sam ping:
uruchom traceroute z hosta do problematycznego celu,
powtórz traceroute z bramy VLAN-u do tego samego celu,
jeśli to możliwe – z drugiej strony, z sieci docelowej do IP problematycznego hosta.
Porównując wyniki, szybko namierzysz pierwszy router, który nie wie, gdzie dalej przekazać pakiet lub go filtruje.
Krok 3: potwierdź poprawność protokołów routingu dynamicznego. Jeżeli w środku sieci działa OSPF, EIGRP, BGP lub inny protokół, przejrzyj jego stan:
czy sąsiedztwa (neighborships) są w stanie FULL/ESTABLISHED,
czy problematyczne podsieci są faktycznie rozgłaszane (network statements, redystrybucja),
czy nie zastosowano filtrów kierunkowych (route-maps, distribute-list, prefix-list), które blokują pojedyncze trasy.
Przy niejednoznacznych problemach z preferowaniem „złej” trasy przyda się również zerknięcie w metryki i administrative distance.
Co sprawdzić: czy:
brama ma trasę do sieci docelowej problematycznego ruchu,
po drodze nie ma routera bez trasy powrotnej (asymetria),
protokoły routingu dynamicznego widzą i rozgłaszają odpowiednie prefiksy.
Filtracja ruchu, ACL i zapory po drodze
Często sieć „z punktu widzenia routingu” jest poprawna, ale ruch blokują ACL-e lub firewall. Dobrze jest oddzielić „brak trasy” od „droga istnieje, ale ruch jest odrzucany”.
Krok 1: zidentyfikuj wszystkie punkty filtracji. Spisz elementy po drodze między źródłem a celem:
ACL-e na interfejsach routerów/przełączników L3 (in/out),
firewall(e) między strefami,
polisy na UTM/NGFW, IPS/IDS,
polisy na kontrolerach Wi-Fi (np. ACL przypisany do SSID).
Bez tej mapy łatwo szukać błędu nie tam, gdzie trzeba.
Krok 2: testuj prostym ruchem diagnostycznym. Zamiast od razu badać problematyczną aplikację, zacznij od prostych testów:
ping (ICMP) – jeśli zablokowany, użyj tcping lub nc,
połączenie na konkretne porty TCP/UDP, które są w użyciu (np. 80/443/3389/1433),
z jednej i drugiej strony, aby sprawdzić, czy blokada jest jednokierunkowa.
Krok 3: korelacja z logami firewalli. Na zaporze centralnej lub brzegowej:
wyszukaj w logach ruch z IP źródłowego do IP docelowego (oraz odwrotnie),
zweryfikuj, czy zdarzenia są oznaczone jako permitted czy denied/dropped,
zwróć uwagę na zastosowaną politykę (nazwa reguły, strefy źródłowa/docelowa).
Częsty błąd: reguła jest, ale w złej kolejności (nad nią jest bardziej ogólne „deny”), albo obowiązuje tylko w jednym kierunku.
Krok 4: szybka weryfikacja ACL na routerze. Na routerach i L3 switchach sprawdź:
show access-lists
show run interface <interfejs>
Upewnij się, że:
ACL jest przypisana do właściwego interfejsu i kierunku (in/out),
w ACL-u nie ma „ukrytej” blokady (np. brak wpisu permit po dodaniu nowego deny),
liczniki (hit-counters) przy regułach rosną – to podpowiada, która reguła łapie ruch.
Co sprawdzić: czy:
dla problematycznego ruchu istnieje wyraźna reguła zezwalająca na przejście,
żaden firewall/ACL nie blokuje ruchu w jednym kierunku (zwłaszcza odpowiedzi),
logi zapór potwierdzają przejście lub blokadę ruchu w czasie testów.
Problemy z DNS jako źródło „niby sieciowych” awarii
Część zgłoszeń „nie działa sieć” to tak naprawdę awarie DNS. Ruch IP jest możliwy, ale aplikacja nie jest w stanie rozwiązać nazw.
Krok 1: rozdziel problem na test po IP i po nazwie. Dla dowolnego zasobu (np. aplikacji webowej) wykonaj dwa testy:
ping / curl / telnet do IP serwera,
to samo po nazwie DNS.
Jeżeli po IP działa, a po nazwie nie – głównym podejrzanym jest DNS, nie routing.
Krok 2: sprawdź, z jakich serwerów DNS korzysta host. Na kliencie:
Windows: ipconfig /all – pola DNS Servers,
Linux: zawartość /etc/resolv.conf lub konfiguracja NetworkManager,
spróbuj nslookup lub dig na problematyczną nazwę.
Jeżeli klient pyta zły serwer DNS (np. pozostawiony statycznie adres z innej lokalizacji), żadne zmiany w sieci mu nie pomogą, dopóki nie poprawisz konfiguracji.
Krok 3: test rozwiązywania nazw z różnych punktów. Użyj nslookup/dig z:
problematycznego hosta,
hosta, na którym wszystko działa (w tej samej podsieci),
samego serwera DNS (jeśli masz dostęp).
Porównanie odpowiedzi oraz czasu odpowiedzi (timeout vs. szybka odpowiedź) pozwoli stwierdzić, czy problem jest lokalny dla jednego klienta, czy ogólny dla całej strefy/VLAN-u.
Krok 4: zweryfikuj, czy DNS nie jest blokowany przez zapory. W trasie między hostem a serwerem DNS sprawdź, czy:
port 53/UDP i 53/TCP jest przepuszczany,
nie ma inspekcji/proxy DNS na firewallu, która odrzuca niektóre zapytania,
serwer DNS, z którego korzysta klient, w ogóle odpowiada z danej podsieci (brak ograniczeń strefowych).
Co sprawdzić: czy:
połączenie po IP do usługi działa poprawnie, a problemy pojawiają się tylko przy użyciu nazw,
