Jak sprawdzić otwarty port w systemie Linux

Sprawdzanie otwartego portu w systemie Linux: najpierw wybierz właściwe pytanie

Aby sprawdzić, czy port jest otwarty w systemie Linux, należy najpierw określić, czego dotyczy pytanie, ponieważ termin "otwarty" ma inne znaczenie w zależności od punktu obserwacji. Na samym serwerze "otwarty" oznacza, że proces jest powiązany z danym portem i oczekuje na połączenia. Z perspektywy innej maszyny "otwarty" oznacza, że pakiet dociera do procesu i otrzymuje odpowiedź. Jeśli odpowiedź nie nadchodzi, kluczowe jest ustalenie, które urządzenie odrzuciło pakiet. sudo ss -ltnp odpowiada na pierwsze pytanie. nc -z lub nmap odpowiadają na drugie. Liczniki firewalla oraz tcpdump pozwalają odpowiedzieć na trzecie.

Wykonywanie niewłaściwego testu jest częstą przyczyną utraty czasu. Test uruchomiony na serwerze nigdy nie sprawdza sieciowego firewalla dostawcy, ponieważ ten filtr znajduje się poza maszyną. Jeśli numery portów są nowym zagadnieniem, artykuł jak działają porty i gniazda w systemie Linux opisuje model, na którym opiera się reszta tego przewodnika.

Co nasłuchuje na tym serwerze? Analiza wyjścia ss

ss jest dostarczany wraz z iproute2, dlatego znajduje się w każdej współczesnej dystrybucji. netstat pochodzi z pakietu net-tools, którego Ubuntu nie instaluje domyślnie od lat, więc netstat -tulpn często odpowiada netstat: command not found. Należy opanować ss, aby uniknąć problemów.

sudo ss -ltnp

-l wyświetla tylko gniazda w stanie nasłuchiwania. -t ogranicza listę do protokołu TCP. -n wypisuje numery zamiast rozwiązywać nazwy, dzięki czemu polecenie kończy działanie natychmiast. -p wskazuje proces właściciela i wymaga uprawnień root: bez sudo kolumna Process pozostanie pusta dla wszystkich procesów, których użytkownik nie jest właścicielem. Należy zamienić -t na -u, aby wyświetlić gniazda UDP.

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.53%lo:53    0.0.0.0:*   users:(("systemd-resolve",pid=612,fd=14))
LISTEN 0      128    0.0.0.0:22          0.0.0.0:*   users:(("sshd",pid=921,fd=3))
LISTEN 0      511    127.0.0.1:8080      0.0.0.0:*   users:(("node",pid=1442,fd=19))
LISTEN 0      128    [::]:22             [::]:*      users:(("sshd",pid=921,fd=4))

Kolumna Local Address jest kluczowa, choć często pomijana podczas analizy.

• 0.0.0.0:22 oznacza każdy adres IPv4 na maszynie, więc usługa jest dostępna z zewnątrz, jeśli pozwala na to firewall.
• [::]:22 to odpowiednik dla IPv6.
• 127.0.0.1:8080 oznacza wyłącznie interfejs zwrotny (loopback). Żaden zewnętrzny host nie może nawiązać połączenia.
• 10.20.0.5:5432 oznacza konkretny adres interfejsu i żaden inny, co jest typowe w konfiguracjach sieci prywatnych.
• Pusta kolumna Process zazwyczaj oznacza brak uprawnień sudo, a nie brak procesu.

Aby sprawdzić konkretny port, należy użyć filtra wewnątrz ss zamiast przeszukiwać całą listę za pomocą grep:

sudo ss -ltnp 'sport = :8080'
sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
sudo fuser 8080/tcp

Brak wyjścia z powyższych poleceń oznacza, że żaden proces nie zajmuje danego portu. Usługa jest zatrzymana, nie uruchomiła się poprawnie lub nasłuchuje na innym adresie. Przed modyfikacją jakiejkolwiek reguły firewalla należy sprawdzić systemctl status <unit> oraz journalctl -u <unit> -n 50.

Dlaczego 127.0.0.1 w Local Address kosztuje użytkowników całe popołudnie

Gniazdo powiązane z 127.0.0.1 nie jest osiągalne z innego hosta i żadna zmiana reguł firewalla tego nie naprawi. Jądro systemu kieruje 127.0.0.0/8 wyłącznie na interfejs pętli zwrotnej (loopback), a pakiet z takim adresem docelowym, który dotrze do fizycznej karty sieciowej, jest odrzucany jako tzw. martian packet. Proces więc działa, ss pokazuje, że nasłuchuje, ufw allow 8080 zgłasza sukces, a połączenie z laptopa nadal kończy się niepowodzeniem. Kończy się ono natychmiastowym Connection refused, ponieważ pakiet dociera na publiczny adres, nie znajduje tam powiązanego gniazda, a jądro odpowiada sygnałem TCP reset.

Wiele programów celowo wiąże się z interfejsem loopback i dla bazy danych lub interfejsu administracyjnego jest to właściwe ustawienie domyślne. Istnieją dwa poprawne rozwiązania. Należy zmienić adres powiązania w konfiguracji programu (listen_addresses w postgresql.conf, bind w redis.conf, argument hosta przyjmowany przez aplikację), a następnie otworzyć firewall. Alternatywnie można pozostawić powiązanie na loopback i uzyskiwać dostęp za pośrednictwem innego komponentu, takiego jak reverse proxy Nginx lub tunel SSH z laptopa:

ssh -L 8080:127.0.0.1:8080 user@203.0.113.10

Docker stosuje to samo rozróżnienie w swojej fladze publikowania portów. -p 8080:8080 wiąże 0.0.0.0 i wystawia kontener na świat. -p 127.0.0.1:8080:8080 wiąże się z loopback i ogranicza dostęp do lokalnego hosta.

Jak sprawdzić, czy port jest otwarty w systemie Linux z innej maszyny

Test należy przeprowadzić z innej sieci. Test wykonany z poziomu samego serwera potwierdza jedynie poprawność działania interfejsu loopback. Nawet połączenie z własnym publicznym adresem IP z poziomu serwera pomija firewall dostawcy, ponieważ ten filtr działa poza VPS.

nc -zv -w 3 203.0.113.10 443

-z nawiązuje połączenie i zamyka je bez przesyłania danych. -w 3 przerywa próbę po trzech sekundach; ta flaga jest istotna, ponieważ bez limitu czasu odrzucony pakiet powoduje, że klient ponawia próbę SYN przez ponad dwie minuty, zanim jądro systemu przerwie operację. Sukces wygląda następująco:

Connection to 203.0.113.10 443 port [tcp/https] succeeded!

Jeśli narzędzie jest niedostępne (nc: command not found), zainstaluj netcat-openbsd w systemie Debian lub Ubuntu albo użyj wbudowanej w bash funkcji przekierowania sieciowego, która nie wymaga żadnego pakietu:

timeout 3 bash -c '</dev/tcp/203.0.113.10/443' && echo open || echo "no answer"

Ta składnia jest funkcją powłoki bash, dlatego należy ją uruchomić za pomocą bash. /bin/sh w systemach Debian i Ubuntu to dash, który nie posiada /dev/tcp i zgłasza błąd braku ścieżki. W przypadku sprawdzania zakresu portów lub gdy wymagane jest nazwanie stanu połączenia, należy użyć nmap wobec hostów, za które odpowiadasz:

sudo nmap -Pn -p 22,80,443 203.0.113.10
sudo nmap -Pn -p 1-1024 203.0.113.10

-Pn pomija wykrywanie hosta. Większość dostawców VPS odrzuca pakiety ICMP echo, więc bez -Pn nmap uzna hosta za niedostępnego i nie wykona skanowania. nmap wyświetla open, gdy usługa odpowiedziała i zaakceptowała połączenie, closed, gdy usługa odpowiedziała sygnałem reset, oraz filtered, gdy nie otrzymano żadnej odpowiedzi. W przypadku usługi webowej curl -sS -o /dev/null -w '%{http_code}\n' https://example.com pozwala odróżnić błąd sieciowy od błędu aplikacji, ponieważ kod statusu potwierdza, że cała ścieżka połączenia działa poprawnie.

Dlaczego zablokowany port powoduje zawieszenie, a zamknięty port natychmiastową odmowę

Natychmiastowa odmowa. Pakiet dotarł do maszyny i otrzymał odpowiedź.

nc: connect to 203.0.113.10 port 443 (tcp) failed: Connection refused

Dwie różne przyczyny wywołują ten sam efekt. Albo żaden proces nie jest powiązany z danym adresem i portem, więc jądro odpowiedziało sygnałem TCP reset, albo reguła zapory sieciowej odrzuciła pakiet za pomocą resetu lub komunikatu ICMP port unreachable. Odmowa jest konkretną odpowiedzią, która wraca po jednym cyklu komunikacji.

Pauza, a następnie przekroczenie czasu oczekiwania. Pakiet został odrzucony bez żadnej odpowiedzi zwrotnej.

nc: connect to 203.0.113.10 port 443 (tcp) timed out: Operation now in progress

Tak działa reguła DROP, a także zapora sieciowa dostawcy lub grupa zabezpieczeń w chmurze. Cisza jest sygnaturą odrzucenia, ponieważ nadawca nie jest w stanie odróżnić odrzucenia pakietu od niedziałającego hosta.

Objaw wskazuje, gdzie szukać przyczyny. Odmowa oznacza, że pakiety przechodzą przez sieć poprawnie, więc należy wrócić do ss -ltnp i sprawdzić adres powiązania oraz numer portu. Przekroczenie czasu oczekiwania oznacza, że pakiety są odrzucane, więc należy przeanalizować zapory sieciowe od zewnątrz do wewnątrz. odmowa a przekroczenie czasu oczekiwania w SSH omawia to samo rozróżnienie dla portu 22, gdzie większość użytkowników napotyka ten problem.

ufw oferuje oba zachowania celowo: ufw deny 8080 odrzuca pakiety (drop), a ufw reject 8080 wysyła odmowę (reject). W nftables dwa dostępne cele to drop oraz reject, a w iptables są to -j DROP oraz -j REJECT. Domyślne polityki prawie zawsze polegają na odrzuceniu (drop), dlatego brakująca reguła powoduje zawieszenie zamiast komunikatu o błędzie.

Kto blokuje port? Analiza od zewnątrz do wewnątrz

sudo ufw status verbose
sudo iptables -L INPUT -n -v --line-numbers
sudo nft list ruleset

Liczniki -v są kluczowym elementem diagnostyki. Wykonaj test nc z zewnątrz, uruchom ponownie polecenie iptables i sprawdź, który licznik uległ zmianie: reguła, której licznik pakietów rośnie, obsługuje Twój ruch. Pozwala to zastąpić domysły twardymi dowodami.

Decydujący test wykonuje się na serwerze, monitorując ruch sieciowy w momencie nawiązywania połączenia z zewnątrz:

sudo tcpdump -ni any tcp port 8080

Pakiet SYN docierający do serwera bez odpowiedzi SYN-ACK oznacza, że pakiet dotarł do VPS, ale został odrzucony przez hosta; firewall dostawcy działa poprawnie, a problem leży w lokalnych regułach. Brak jakiegokolwiek wyjścia oznacza, że pakiet w ogóle nie dotarł do serwera, co wskazuje na firewall dostawcy, grupę bezpieczeństwa lub błędny adres IP. To rozróżnienie eliminuje większość pracy diagnostycznej.

Dwie warstwy często powodują wyniki, które wydają się niemożliwe. Po pierwsze, IPv6: jeśli nazwa hosta posiada rekord AAAA, klient może łączyć się przez IPv6, podczas gdy reguła obejmuje tylko IPv4. Przed zaufaniem wynikom należy przetestować każdą rodzinę adresów za pomocą nc -4 oraz nc -6. Artykuł reguły ufw i porty IPv6 na VPS opisuje ten problem. Po drugie, Docker: opublikowany port kontenera odpowiada na zapytania z Internetu, nawet jeśli ufw status wskazuje, że port jest zablokowany, ponieważ pakiety te są obsługiwane, zanim trafią do łańcucha ufw. Artykuł dlaczego Docker publikuje porty z pominięciem ufw wyjaśnia mechanizm i sposób naprawy, a podstawowe reguły ufw dla nowego VPS zawiera zestaw reguł, które warto wdrożyć w pierwszej kolejności.

Dlaczego odpowiedzi UDP są z założenia niejednoznaczne

Protokół UDP nie wykorzystuje mechanizmu handshake, więc sonda nie ma potwierdzenia nawiązania połączenia. nc -zu 203.0.113.10 53 kończy działanie z kodem 0 natychmiast po wysłaniu pakietu, co potwierdza jedynie fakt wysłania go przez lokalną maszynę, a nie stan zdalnego hosta. Gdy port UDP jest zamknięty, host zazwyczaj odpowiada komunikatem ICMP port unreachable, jednak jądro systemu zgłasza ten błąd połączonemu gniazdu dopiero przy kolejnej operacji zapisu, przez co pojedyncza sonda pakietowa go pomija. Zapory sieciowe często domyślnie odrzucają pakiety ICMP, co eliminuje nawet tę wskazówkę. Z tego powodu nmap oznacza większość portów UDP jako open|filtered: brak odpowiedzi jest identyczny zarówno dla otwartej, cichej usługi, jak i dla portu filtrowanego.

Testuj UDP poprzez komunikację w protokole, który Cię interesuje. Serwer DNS odpowiada na dig +short @203.0.113.10 example.com adresem lub brakiem odpowiedzi. Węzeł WireGuard wykazuje niedawną aktywność w linii latest handshake w pliku sudo wg show. Następnie zweryfikuj dotarcie pakietów po stronie serwera:

sudo tcpdump -ni any udp port 51820

Pojawienie się pakietów w momencie wysyłania ich przez klienta oznacza, że docierają one do celu, więc problem leży po stronie usługi lub łańcucha wejściowego (input chain). Brak jakichkolwiek pakietów oznacza, że nigdy nie dotarły do serwera.

Lista kontrolna pozwalająca najszybciej zlokalizować usterkę

1. Na serwerze uruchom sudo ss -ltnp 'sport = :8080'. Brak danych wyjściowych oznacza, że żaden proces nie nasłuchuje, więc najpierw należy naprawić usługę.
2. Jeśli dane są widoczne, sprawdź kolumnę Local Address. Wartość 127.0.0.1 oznacza, że dostęp z zewnątrz jest niemożliwy, dopóki nie zmienisz powiązania adresu lub nie umieścisz przed usługą proxy.
3. Z innej sieci uruchom nc -zv -w 3 <public ip> 8080.
4. Odmowa połączenia oznacza powrót do punktu 1. Adres, port lub maszyna nie są tymi, o których myślisz.
5. Przekroczenie czasu oczekiwania oznacza odrzucenie pakietów. Uruchom sudo tcpdump -ni any tcp port 8080 na serwerze i powtórz test.
6. Pakiet SYN dociera, ale brak odpowiedzi: problem z firewallem hosta. Znajdź regułę, której licznik rośnie w sudo iptables -L INPUT -n -v.
7. Pakiet SYN nie dociera: problem z firewallem dostawcy, grupą zabezpieczeń lub błędnym adresem IP.

FAQ

Jak sprawdzić, które porty są otwarte na własnym serwerze Linux?

Uruchom sudo ss -ltnp dla TCP oraz sudo ss -lunp dla UDP. Każda linia oznacza jeden gniazdo nasłuchujące, a kolumna Local Address wskazuje, kto może uzyskać do niego dostęp: 0.0.0.0 oraz [::] akceptują połączenia z dowolnego miejsca dozwolonego przez firewall, podczas gdy 127.0.0.1 akceptuje połączenia tylko z poziomu samej maszyny. Kolumna Process wymaga uprawnień root, dlatego należy uruchomić polecenie z sudo, w przeciwnym razie pozostanie pusta. ss jest częścią pakietu iproute2 i jest zawsze zainstalowane; netstat jest częścią net-tools i zazwyczaj nie jest dostępne.

Dlaczego ss pokazuje, że usługa nasłuchuje, a mimo to nie mogę się połączyć?

Istnieją dwie częste przyczyny, a jedno polecenie pozwala je rozróżnić. Jeśli Local Address to 127.0.0.1, usługa jest powiązana z interfejsem loopback i jest nieosiągalna z żadnego innego hosta, ponieważ jądro kieruje ten zakres wyłącznie do interfejsu zwrotnego. Jeśli adres to 0.0.0.0, a połączenia nadal kończą się niepowodzeniem, uruchom sudo tcpdump -ni any tcp port <port> na serwerze i spróbuj połączyć się z zewnątrz. Pakiet SYN docierający bez odpowiedzi oznacza, że lokalna reguła firewalla go odrzuca. Brak jakichkolwiek pakietów oznacza, że są one zatrzymywane przed dotarciem do VPS, zazwyczaj przez firewall dostawcy lub grupę zabezpieczeń.

Jaka jest różnica między połączeniem odrzuconym a przekroczeniem czasu oczekiwania?

Odrzucenie to odpowiedź. Pakiet dotarł do hosta i otrzymał w odpowiedzi TCP reset lub komunikat ICMP port unreachable, co oznacza, że na danym adresie i porcie nic nie nasłuchuje lub reguła go odrzuciła. Przekroczenie czasu to cisza: reguła odrzuciła pakiet i nie wysłała nic w zamian, więc klient ponawia próbę do momentu rezygnacji. Odrzucenie wskazuje na problem z usługą lub jej adresem powiązania. Przekroczenie czasu wskazuje na firewall, a w pierwszej kolejności należy sprawdzić ten, który znajduje się najbliżej sieci zewnętrznej.

Jak sprawdzić, czy port UDP jest otwarty?

Nie można uzyskać wiarygodnej odpowiedzi za pomocą ogólnego sondowania, ponieważ UDP nie posiada mechanizmu uzgadniania (handshake), a usługa nieodpowiadająca wygląda tak samo jak odrzucony pakiet. nc -zu zwraca sukces natychmiast po wysłaniu, a nmap zgłasza open|filtered z tego samego powodu. Należy przetestować usługę, komunikując się zgodnie z jej protokołem: dig +short @<host> example.com dla DNS lub sudo wg show dla węzła WireGuard z niedawnym uzgodnieniem. Aby potwierdzić, że pakiety docierają, uruchom sudo tcpdump -ni any udp port <port> na serwerze w trakcie wysyłania z klienta.

Czy nadal można używać telnet host port do testowania portu?

Działa to dla TCP, a Escape character is '^]' oznacza, że połączenie zostało zaakceptowane. Wyjdź za pomocą Ctrl+], a następnie quit. Dwa powody czynią nc -z lepszym narzędziem: telnet nie jest zainstalowany w większości współczesnych obrazów serwerowych, a nc obsługuje limit czasu za pomocą -w i zwraca status wyjścia, który można testować w skryptach. Gdy żadne z nich nie jest dostępne, timeout 3 bash -c '</dev/tcp/<host>/<port>' nie wymaga instalacji żadnego pakietu.