Nmap nie działa? 7 najczęstszych błędów początkujących i ich diagnoza

Nmap nie działa i od razu pojawia się myśl: „To narzędzie jest zepsute”. Spokojnie. W większości przypadków Nmap działa dokładnie tak, jak powinien — tylko dostaje zły adres, nie może rozwiązać nazwy, nie ma drogi do celu albo firewall celowo milczy.

W tym artykule zrobimy porządną diagnozę krok po kroku. Zobaczysz siedem najczęstszych błędów początkujących, nauczysz się czytać komunikaty zamiast zgadywać i rozdzielisz dwie rzeczy, które często są mylone: maszyna wyłączona oraz maszyna dostępna w sieci, ale niewidoczna dla Twojego skanu.

Wszystkie przykłady wykonuj wyłącznie na własnym, lokalnym labie. Nie skanuj cudzych adresów, firmowych sieci ani hostów znalezionych w internecie bez jednoznacznej zgody. Tutaj wystarczą dwie maszyny wirtualne: Kali jako skaner i druga Linuxowa maszyna jako cel.

Zanim uznasz, że Nmap nie działa: przygotuj punkt odniesienia

Po co zaczynać od punktu odniesienia? Bo nie da się diagnozować skanu, jeśli nie wiesz, czy cel w ogóle działa, jaki ma adres i czy obie maszyny są w tej samej sieci laboratoryjnej.

Na maszynie testowej uruchommy prostą usługę HTTP. Nie potrzebujemy podatnej aplikacji ani rozbudowanego serwera. Chcemy tylko jeden przewidywalny port, na którym da się porównać wyniki.

python3 -m http.server 8080 --bind 0.0.0.0

Co robi ta komenda? python3 -m http.server uruchamia prosty serwer HTTP, 8080 wskazuje port, a --bind 0.0.0.0 pozwala przyjmować połączenia na interfejsach sieciowych maszyny testowej.

Teraz na Kali sprawdźmy podstawowy stan sieci i wykonajmy mały, kontrolowany skan jednego portu.

ip -br address
ip route
nmap -n -Pn -p 8080 --reason 192.168.56.10

Parametr -n wyłącza rozwiązywanie nazw DNS, więc wynik nie miesza się z problemami nazw. -Pn pomija etap wykrywania hosta i każe Nmapowi spróbować skanu wskazanego adresu. -p 8080 ogranicza test do naszego serwera, a --reason pokazuje powód, dla którego Nmap przypisał stan hostowi lub portowi.

Jeżeli lab jest ustawiony poprawnie, port 8080/tcp powinien być widoczny jako open. Wynik może wyglądać podobnie, ale nie musi być identyczny — zależy od systemu, wersji Nmapa i konfiguracji maszyny.

1. Błąd DNS: podajesz nazwę, której system nie umie zamienić na adres IP

Wpisałeś nazwę hosta zamiast adresu i Nmap kończy pracę niemal od razu? Pierwsze pytanie brzmi: czy ta nazwa w ogóle istnieje dla Twojego systemu?

DNS jest jak książka telefoniczna sieci. Podajesz nazwę, a system ma znaleźć numer, czyli adres IP. Jeśli książka nie ma wpisu, Nmap nie ma czego skanować.

Zróbmy bezpieczny test na celowo nieistniejącej nazwie w naszym labie.

getent hosts brak-takiej-maszyny.lab
nmap -sL -n brak-takiej-maszyny.lab

getent hosts pyta systemowy mechanizm rozwiązywania nazw. Jeżeli nie zobaczysz żadnej odpowiedzi, nazwa nie została znaleziona. Druga komenda używa -sL, czyli list scan — Nmap ma tylko przygotować listę celów, bez wysyłania pakietów do hosta. To dobry, mało inwazyjny test poprawności celu.

Co nam to daje? Rozdzielasz problem nazwy od problemu sieci. Jeżeli Nmap zgłasza błąd rozwiązywania nazwy, firewall, porty i uprawnienia nie są jeszcze tematem. Najpierw popraw nazwę.

W lokalnym labie możesz świadomie dodać prosty wpis do własnego pliku hosts. To nie jest prawdziwy serwer DNS, ale wygodny sposób na nazwanie jednej maszyny testowej.

echo '192.168.56.10 lab-target.local' | sudo tee -a /etc/hosts
getent hosts lab-target.local
nmap -sL -n lab-target.local

Po zmianie pierwszy test powinien zwrócić adres przypisany do nazwy. Drugi powinien pokazać, że Nmap interpretuje lab-target.local jako właściwy cel. Jeżeli adres jest inny niż adres maszyny testowej, nie skanuj dalej — popraw wpis.

Znaczenie dla bezpieczeństwa: błędna nazwa może skierować skan na niewłaściwy system. W profesjonalnej pracy weryfikacja zakresu jest obowiązkiem, a nie formalnością.

2. Zły adres IP: Nmap skanuje poprawnie, ale nie tę maszynę

To jeden z najbardziej podstępnych błędów. Komenda wygląda dobrze, Nmap się uruchamia, ale wynik nie pasuje do tego, co masz uruchomione na celu. Po co? Bo adres IP nie jest adresem „na zawsze”. W labie może się zmienić po restarcie maszyny, przełączeniu adaptera albo zmianie konfiguracji DHCP.

Najpierw sprawdź adres bezpośrednio na maszynie testowej.

ip -br address
hostname -I

Szukasz adresu przypisanego do interfejsu labowego, a nie do innej karty sieciowej. hostname -I może pokazać więcej niż jeden adres. Dlatego nie wybieraj pierwszego na ślepo — porównaj go z siecią Kali.

Na Kali sprawdźmy potem sąsiadów warstwy drugiej i wykonajmy ten sam mały skan.

ip neigh show
nmap -n -Pn -p 8080 --reason 192.168.56.10

Jeżeli maszyny są w tej samej wirtualnej sieci Ethernet, wpis sąsiada może zawierać adres MAC i stan typu REACHABLE, STALE albo inny zależny od systemu. Brak wpisu sam w sobie nie jest wyrokiem, ale jest wskazówką.

A co jeśli Nmap pokazuje port zamknięty, mimo że serwer HTTP działa? Sprawdź ponownie adres na celu. Bardzo możliwe, że skanujesz stary adres albo inny host w tej samej sieci. No i proszę — problemem nie był Nmap, tylko identyfikacja celu.

Praktyczna reguła: zanim zmienisz opcje Nmapa, potwierdź adres IP na maszynie docelowej i porównaj go z adresem wpisanym w komendzie.

3. Brak trasy do hosta: Twoja maszyna nie wie, którędy wysłać pakiet

Zły IP oznacza, że wskazałeś złą maszynę. Brak trasy oznacza coś innego: system nie ma nawet drogi do sieci, w której leży cel.

Analogia jest prosta. IP to numer mieszkania, a trasa to droga do osiedla. Sam poprawny numer mieszkania nic nie da, gdy nie masz drogi do budynku.

Najpierw zobaczmy, jak Kali chce dotrzeć do naszego celu.

ip route get 192.168.56.10
ip route

W pierwszym wyniku szukasz interfejsu, przez który system zamierza wysłać ruch, oraz adresu źródłowego. Jeżeli widzisz interfejs od Twojej sieci labowej, jest dobrze. Jeżeli pojawia się nieoczekiwany interfejs albo komunikat o braku trasy, problem leży poniżej Nmapa.

Chcesz zobaczyć błąd w kontrolowany sposób? Utwórzmy lokalną przestrzeń sieciową bez żadnej trasy. To nadal jest Twoja maszyna i Twój lab.

sudo ip netns add nmap-lab
sudo ip -n nmap-lab link set lo up
sudo ip netns exec nmap-lab ip route
sudo ip netns exec nmap-lab nmap -n -Pn -sT -p 8080 192.168.56.10

ip netns add tworzy oddzielną lokalną przestrzeń sieciową. Ustawiamy tam tylko interfejs pętli zwrotnej lo, ale nie dodajemy karty ani trasy do sieci 192.168.56.0/24. Nmap działa, jednak system nie ma którędy wysłać połączenia TCP.

Wynik może zawierać komunikat typu Network is unreachable albo wskazywać, że nie da się ustalić trasy. Dokładne brzmienie zależy od systemu i wersji narzędzi. Interpretacja jest jednak prosta: nie naprawiasz tego opcją skanowania. Musisz przywrócić poprawną kartę sieciową, adres lub trasę w konfiguracji labu.

Po ćwiczeniu usuńmy przestrzeń, żeby zostawić system w porządku.

sudo ip netns del nmap-lab

Znaczenie dla bezpieczeństwa: błąd trasy często oznacza segmentację sieci. To mechanizm ochronny — administrator celowo może nie pozwalać stacji w jednej sieci rozmawiać z serwerem w drugiej.

4. Komunikat „Host seems down”: mylisz wykrywanie hosta ze skanowaniem portów

Nmap zwykle najpierw próbuje ustalić, czy host odpowiada. Dopiero potem przechodzi do intensywniejszego skanowania portów. I teraz uwaga: brak odpowiedzi na próby wykrywania nie dowodzi automatycznie, że komputer jest wyłączony.

Co może się wydarzyć? Host działa, ale filtruje ICMP albo pakiety użyte podczas wykrywania. Nmap nie dostaje odpowiedzi i może zgłosić, że host wygląda na wyłączony.

Najpierw wykonajmy sam etap wykrywania w naszym labie.

nmap -sn -n --reason 192.168.56.10

-sn oznacza: nie skanuj portów, sprawdź tylko dostępność hosta. --reason pomaga zobaczyć, na podstawie jakiej odpowiedzi Nmap uznał host za dostępny albo niedostępny.

A co jeśli wynik mówi, że host nie odpowiada, ale masz pewność, że maszyna testowa jest uruchomiona? Zróbmy drugi test — ten sam cel, jeden znany port, lecz bez etapu wykrywania hosta.

nmap -Pn -n -p 8080 --reason 192.168.56.10

To porównanie jest bardzo ważne. Jeżeli pierwszy test nie widzi hosta, a drugi znajduje 8080/tcp open, masz jasną odpowiedź: host działa, a problem dotyczył wykrywania dostępności. Nie „ożywiasz” maszyny — po prostu dobierasz właściwy etap diagnozy.

5. Firewall: port jest filtrowany, a niekoniecznie zamknięty

Port closed i port filtered to nie to samo. Zamknięty port zwykle oznacza, że host odpowiedział, ale żadna usługa tam nie nasłuchuje. Filtrowany oznacza, że Nmap nie dostał odpowiedzi pozwalającej jednoznacznie ustalić stan — pakiet lub odpowiedź mogły zostać odrzucone przez filtr.

Sprawdźmy to metodą problem → test → jedna zmiana → ten sam test. Załóżmy, że nasz serwer HTTP nadal działa na maszynie testowej na porcie 8080.

Na Kali wykonaj test początkowy.

nmap -Pn -n -p 8080 --reason 192.168.56.10

Oczekujesz stanu open, bo przed chwilą uruchomiłeś usługę. Teraz na maszynie testowej, jeżeli korzystasz tam z UFW, dodaj jedną regułę blokującą ten port.

sudo ufw deny 8080/tcp
sudo ufw status numbered

Pierwsza komenda dodaje regułę blokującą ruch TCP do portu 8080. Druga pozwala potwierdzić, że reguła rzeczywiście istnieje. Nie zakładaj, że zmiana zadziałała — sprawdźmy.

nmap -Pn -n -p 8080 --reason 192.168.56.10

W zależności od polityki firewalla i zachowania systemu port może pojawić się jako filtered, a test może potrwać dłużej niż wcześniej. Co to oznacza? Nmap nie dostał jednoznacznej odpowiedzi. To nie jest dowód, że usługa została wyłączona.

Przywróćmy dostęp tylko z adresu Kali. To lepsze niż globalne otwarcie portu, bo reguła jest ograniczona do naszego skanera laboratoryjnego.

sudo ufw allow from 192.168.56.20 to any port 8080 proto tcp
sudo ufw status numbered

Uruchom ponownie dokładnie ten sam skan. Jeśli port wróci do stanu open, widzisz porównanie czarno na białym: usługa działała przez cały czas, ale firewall zmieniał to, co widzi skaner.

Znaczenie dla bezpieczeństwa: firewall nie musi ukrywać wszystkiego. Dobra reguła wpuszcza tylko potrzebny ruch, z potrzebnego źródła, na potrzebny port.

6. Brak uprawnień: wybierasz skan wymagający surowych pakietów

Uruchamiasz Nmap jako zwykły użytkownik, wybierasz określony typ skanu i dostajesz komunikat o braku uprawnień? To nie awaria. Część technik Nmapa potrzebuje możliwości wysyłania i odbierania surowych pakietów. Na systemach Unix zwykle oznacza to uruchomienie z odpowiednimi uprawnieniami.

Najpierw sprawdźmy, kim jesteś.

id
nmap -sS -n -p 8080 192.168.56.10

id pokaże Twój identyfikator użytkownika i grupy. -sS wybiera TCP SYN scan. Jeżeli pracujesz bez wymaganych uprawnień, Nmap może odmówić wykonania tego typu skanu albo zasugerować inną technikę.

Masz dwa sensowne rozwiązania w labie. Pierwsze: użyj skanu połączeniowego TCP Connect Scan, który korzysta z normalnego mechanizmu połączeń systemu operacyjnego.

nmap -sT -n -p 8080 --reason 192.168.56.10

-sT oznacza TCP Connect Scan. Jest dobrym wyborem, gdy nie masz uprawnień do pracy z surowymi pakietami. Druga możliwość to uruchomienie Nmapa z sudo, ale rób to świadomie i tylko w swoim labie.

sudo nmap -sS -n -p 8080 --reason 192.168.56.10

Co nam to daje? Nie chodzi o to, aby zawsze wpisywać sudo. Chodzi o rozumienie różnicy: problem leży w uprawnieniach i typie skanu, a nie w dostępności hosta.

Nie traktuj uprawnień administratora jako automatycznej naprawy każdego problemu. Najpierw przeczytaj komunikat Nmapa i ustal, czego konkretnie brakuje.

7. Maszyna wyłączona czy tylko niedostępna? Tego nie zgaduj

To błąd, który potrafi wyprowadzić w pole nawet osoby mające już trochę praktyki. Nmap może nie dostać żadnej odpowiedzi zarówno wtedy, gdy maszyna jest wyłączona, jak i wtedy, gdy działa, lecz po drodze ruch blokuje firewall, filtracja, zła trasa albo niepoprawna konfiguracja wirtualnej sieci.

Po co to rozróżnienie? Bo działania naprawcze są zupełnie inne. Wyłączoną VM uruchamiasz. Niedostępną VM diagnozujesz przez sieć, trasę, reguły i usługi.

Zróbmy kontrolowany test. Najpierw, gdy maszyna testowa jest włączona i serwer HTTP działa, zapisz wynik:

nmap -sn -n --reason 192.168.56.10
nmap -Pn -n -p 8080 --reason 192.168.56.10

Potem wyłącz maszynę testową z poziomu jej systemu albo menedżera maszyn wirtualnych. Nie rób tego na systemie, na którym pracujesz. Powtórz dokładnie te same dwie komendy.

Możesz zobaczyć brak odpowiedzi, komunikat sugerujący, że host jest wyłączony, albo długie oczekiwanie na próby połączenia. Nie zakładaj jednak, że ten sam obraz zawsze oznacza wyłączenie hosta. Teraz włącz VM ponownie, ale zostaw regułę firewalla blokującą port 8080. Wykonaj drugi test jeszcze raz.

Co my tu mamy? Maszyna może być aktywna, a port może nadal wyglądać na filtrowany lub niedostępny. Dlatego rozsądna diagnoza idzie w tej kolejności:

1. Potwierdź stan VM w swoim panelu wirtualizacji albo bezpośrednio na jej konsoli.
2. Sprawdź adres IP na celu przez ip -br address.
3. Sprawdź trasę na Kali przez ip route get adres_celu.
4. Porównaj wykrywanie hosta z testem -Pn.
5. Sprawdź reguły firewalla i usługę na maszynie testowej.

Jednym wynikiem Nmapa rzadko udowodnisz, że komputer jest fizycznie wyłączony. Możesz za to bardzo dobrze udowodnić, na którym etapie komunikacja przestała działać. I to jest praktyczna umiejętność.

Krótka checklista, gdy Nmap nie działa

Zanim zmienisz dziesięć flag naraz, przejdź tę listę po kolei:

• Czy skanujesz wyłącznie własny, autoryzowany cel laboratoryjny?
• Czy nazwa hosta rozwiązuje się na właściwy adres?
• Czy adres IP został potwierdzony bezpośrednio na maszynie testowej?
• Czy Kali ma trasę do tej sieci?
• Czy znasz jeden port usługi, który powinien być otwarty?
• Czy porównałeś -sn z testem -Pn?
• Czy firewall nie filtruje ruchu?
• Czy wybrany typ skanu pasuje do Twoich uprawnień?

Ta kolejność oszczędza czas. Najpierw eliminujesz błędy celu i sieci, potem interpretujesz zachowanie Nmapa, a dopiero na końcu bawisz się bardziej zaawansowanymi opcjami.

FAQ: problemy z Nmapem

Co dalej: przestań zgadywać, zacznij czytać sieć

Jeśli po tym artykule zapamiętasz jedną rzecz, niech będzie taka: Nmap nie jest magiczną różdżką ani wyrocznią. To narzędzie, które interpretuje odpowiedzi sieciowe. Gdy odpowiedzi nie ma, Twoim zadaniem jest ustalić dlaczego — nazwa, adres, trasa, wykrywanie hosta, firewall, uprawnienia czy faktycznie wyłączona maszyna.

W praktyce właśnie to odróżnia przypadkowe wpisywanie komend od świadomej pracy ze skanerem. Najpierw mały test, potem jedna zmiana, następnie ten sam test i porównanie. Prosto, powtarzalnie i bez zgadywania.

Jeżeli chcesz przejść od takich kontrolowanych diagnoz do systematycznej pracy z typami skanów, wykrywaniem usług, interpretacją stanów portów i ćwiczeniami w Kali, zobacz kurs Nmap – Network Mapper od zera do hakera. Skanuj sieć jak haker. Kali Linux. To naturalny kolejny krok: zamiast tylko uruchamiać Nmap, nauczysz się rozumieć, co dokładnie mówi Ci wynik.