Controleren of een poort openstaat op Linux

Controleren of een poort openstaat op Linux: bepaal eerst de juiste vraag

Om te controleren of een poort openstaat op Linux, moet u eerst bepalen welke vraag u stelt. "Open" betekent namelijk iets anders afhankelijk van uw positie. Op de server zelf betekent open dat een proces aan die poort is gebonden en luistert. Vanaf een andere machine betekent open dat een pakket dat proces bereikt en een antwoord terugkrijgt. Wanneer er geen antwoord komt, is de werkelijke vraag welk apparaat het pakket heeft geweigerd. sudo ss -ltnp beantwoordt de eerste vraag. nc -z of nmap beantwoordt de tweede. Firewall-tellers en tcpdump beantwoorden de derde.

Het uitvoeren van de verkeerde controle kost vaak onnodig veel tijd. Een test op de server zelf raakt nooit de netwerkfirewall van uw provider, omdat dat filter zich buiten de server bevindt. Als poortnummers nieuw voor u zijn, behandelt hoe poorten en sockets werken op Linux het model waarvan de rest van deze handleiding uitgaat.

Wat luistert er op deze machine? Lees de ss-output

ss wordt meegeleverd met iproute2 en is daarom op elke huidige distributie aanwezig. netstat is afkomstig van net-tools, dat Ubuntu al jaren niet meer standaard installeert, waardoor netstat -tulpn vaak netstat: command not found als antwoord geeft. Leer ss en voorkom teleurstellingen.

sudo ss -ltnp

-l toont alleen luisterende sockets. -t beperkt de lijst tot TCP. -n toont getallen in plaats van namen op te lossen, waardoor het commando direct resultaat geeft. -p toont het eigenaar-proces; hiervoor is root vereist: zonder sudo blijft de kolom Process leeg voor elk proces waarvan u niet de eigenaar bent. Vervang -t door -u om UDP te zien.

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))

De kolom Local Address bepaalt alles, en dit is de kolom waar mensen vaak overheen kijken.

• 0.0.0.0:22 betekent elk IPv4-adres op de machine; het is dus bereikbaar vanaf buiten als de firewall dit toestaat.
• [::]:22 is hetzelfde voor IPv6.
• 127.0.0.1:8080 betekent alleen loopback. Niets buiten deze machine kan dit bereiken.
• 10.20.0.5:5432 betekent dat specifieke interface-adres en geen enkel ander, wat gebruikelijk is bij private netwerkconfiguraties.
• Een lege kolom Process duidt meestal op een ontbrekende sudo, niet op een ontbrekend proces.

Om naar één specifieke poort te vragen, filtert u binnen ss in plaats van de hele lijst te doorzoeken met grep:

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

Een lege output bij alle drie betekent dat niets die poort bezet houdt. De service is gestopt, het starten is mislukt, of de service luistert ergens anders. Lees systemctl status <unit> en journalctl -u <unit> -n 50 voordat u ook maar één firewallregel aanpast.

Waarom 127.0.0.1 in Local Address mensen een middag kost

Een socket die is gebonden aan 127.0.0.1 is niet bereikbaar vanaf een andere host, en geen enkele firewallregel verandert dat. De kernel routeert 127.0.0.0/8 uitsluitend naar de loopback-interface, en een pakket met dat bestemmingsadres dat op een fysieke netwerkkaart binnenkomt, wordt als 'martian' verworpen. Het proces draait dus, ss toont dat het luistert, ufw allow 8080 rapporteert succes, en de verbinding vanaf uw laptop mislukt alsnog. Het mislukt met een directe Connection refused, omdat het pakket uw publieke adres bereikt, daar geen gebonden socket vindt, en de kernel antwoordt met een TCP reset.

Veel programma's binden bewust aan loopback, en voor een database of een beheerinterface is dat de juiste standaardinstelling. U heeft twee legitieme keuzes. Wijzig het bind-adres in de configuratie van het programma zelf (listen_addresses in postgresql.conf, bind in redis.conf, of het host-argument dat uw applicatie accepteert) en open vervolgens de firewall. Of laat het op loopback staan en bereik het via een andere weg, zoals een nginx reverse proxy, of een SSH-tunnel vanaf uw laptop:

ssh -L 8080:127.0.0.1:8080 user@203.0.113.10

Docker hanteert hetzelfde onderscheid in de publish-vlag. -p 8080:8080 bindt aan 0.0.0.0 en stelt de container bloot aan het internet. -p 127.0.0.1:8080:8080 bindt aan loopback en houdt de toegang lokaal.

Hoe u op Linux vanaf een andere machine controleert of een poort openstaat

Voer deze test uit vanaf een ander netwerk. Een test vanaf de server zelf bewijst alleen dat het loopback-pad werkt. Zelfs verbinding maken met uw eigen publieke IP-adres vanaf de server omzeilt de netwerkfirewall van uw provider, omdat dat filter buiten de VPS draait.

nc -zv -w 3 203.0.113.10 443

-z maakt verbinding en sluit deze weer zonder data te verzenden. -w 3 geeft het na drie seconden op, en die vlag is van belang: zonder timeout blijft een verloren pakket de client meer dan twee minuten lang de SYN laten proberen voordat de kernel stopt. Succes ziet er als volgt uit:

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

Als de tool ontbreekt (nc: command not found), installeer dan netcat-openbsd op Debian of Ubuntu, of gebruik de ingebouwde netwerk-redirectie van bash, waarvoor geen pakket nodig is:

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

Die syntaxis is een bash-functie, dus voer deze uit met bash. /bin/sh op Debian en Ubuntu is dash, dat geen /dev/tcp heeft en meldt dat het pad niet bestaat. Gebruik voor een reeks poorten, of wanneer u de status benoemd wilt hebben, nmap tegen hosts waarvoor u verantwoordelijk bent:

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

-Pn slaat host-detectie over. De meeste VPS-hosts blokkeren ICMP echo, dus zonder -Pn besluit nmap dat de host offline is en scant het niets. nmap toont open wanneer iets antwoordde en de verbinding accepteerde, closed wanneer iets antwoordde met een reset, en filtered wanneer er helemaal geen antwoord kwam. Voor een webservice scheidt curl -sS -o /dev/null -w '%{http_code}\n' https://example.com een netwerkfout van een applicatiefout, omdat een statuscode bewijst dat het volledige pad werkte.

Waarom een geblokkeerde poort blijft hangen en een gesloten poort direct weigert

Een onmiddellijke weigering. Het pakket bereikte de machine en er kwam antwoord.

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

Twee verschillende oorzaken leiden tot die specifieke melding. Ofwel is er geen proces gekoppeld aan dat adres en die poort, waardoor de kernel antwoordde met een TCP reset, ofwel heeft een firewallregel het pakket geweigerd met een reset of een ICMP port unreachable-bericht. Een weigering is een definitief antwoord dat binnen één round-trip terugkomt.

Een pauze, gevolgd door een timeout. Iets heeft het pakket genegeerd en gaf geen antwoord.

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

Dat is wat een DROP-regel doet, en het is ook wat een firewall van een provider of een cloud security group doet. Stilte is het kenmerk van een drop, omdat de verzender het verschil niet kan zien tussen een drop en een onbereikbare host.

Het symptoom vertelt u waar u verder moet zoeken. Refused betekent dat pakketten het netwerk correct doorkruisen; ga dus terug naar ss -ltnp en controleer het bind-adres en het poortnummer. Timed out betekent dat pakketten worden genegeerd; controleer daarom de firewalls van buiten naar binnen. refused versus timed out bij SSH behandelt hetzelfde onderscheid voor poort 22, waar de meeste mensen dit voor het eerst tegenkomen.

ufw biedt beide gedragingen aan: ufw deny 8080 voert een drop uit, en ufw reject 8080 verstuurt een weigering. In nftables zijn de twee targets drop en reject, en in iptables zijn dit -j DROP en -j REJECT. Standaardbeleid is bijna altijd een drop, en dat is de reden waarom een ontbrekende regel leidt tot een hangende verbinding in plaats van een foutmelding.

Wie blokkeert de poort? Werk van buiten naar binnen

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

De -v-tellers zijn het nuttige onderdeel. Voer uw nc-test uit vanaf een externe locatie, voer het iptables-commando opnieuw uit en zoek naar de teller die is veranderd: de regel waarvan het pakket-aantal oploopt, is de regel die uw verkeer afhandelt. Dit vervangt gissen door bewijs.

De beslissende test voert u uit op de server, waarbij u het netwerkverkeer observeert terwijl u vanaf buiten verbinding maakt:

sudo tcpdump -ni any tcp port 8080

Een SYN die aankomt zonder dat er een SYN-ACK wordt teruggestuurd, betekent dat het pakket uw VPS heeft bereikt en door de host is geweigerd; de firewall van de provider is dan in orde en uw lokale regels zijn dat niet. Geen enkele output betekent dat het pakket nooit is aangekomen, wat betekent dat de firewall van de provider, een security group of een onjuist IP-adres de oorzaak is. Dat ene onderscheid bespaart het meeste werk.

Twee lagen zorgen voor resultaten die onmogelijk lijken. Ten eerste IPv6: als de hostnaam een AAAA-record heeft, kan uw client verbinding maken via IPv6 terwijl uw regel alleen IPv4 dekt. Test daarom elke familie met nc -4 en nc -6 voordat u op een resultaat vertrouwt. ufw-regels en IPv6-poorten op een VPS behandelt dit verschil. Ten tweede Docker: een gepubliceerde containerpoort reageert vanaf het internet, zelfs terwijl ufw status die poort als geweigerd weergeeft, omdat die pakketten worden afgehandeld voordat de chain van ufw ze ooit ziet. waarom Docker poorten publiceert en ufw omzeilt bevat het mechanisme en de oplossing, en de ufw-regels voor een nieuwe VPS is de basisset die u als eerste moet instellen.

Waarom UDP-antwoorden inherent ambigu zijn

UDP kent geen handshake, waardoor een probe geen succesvol eindpunt heeft. nc -zu 203.0.113.10 53 sluit af met exitcode 0 zodra het pakket is verzonden; dit bewijst enkel dat uw eigen machine het pakket heeft verstuurd en zegt niets over de ontvangende kant. Wanneer een UDP-poort gesloten is, antwoordt de host normaal gesproken met een ICMP port unreachable-bericht. De kernel rapporteert deze fout echter alleen aan een verbonden socket bij de volgende schrijfactie, waardoor een probe met één enkel pakket dit mist. Firewalls blokkeren ICMP vaak standaard, waardoor zelfs die aanwijzing wegvalt. Dit is de reden waarom nmap voor de meeste UDP-poorten open|filtered rapporteert: geen antwoord is precies wat zowel een open, stille service als een gefilterde poort oplevert.

Test UDP door het protocol te spreken dat u wilt controleren. Een DNS-server antwoordt op dig +short @203.0.113.10 example.com met een adres of helemaal niet. Een WireGuard-peer toont een recente latest handshake-regel in sudo wg show. Bewijs vervolgens de aankomst aan de serverzijde:

sudo tcpdump -ni any udp port 51820

Als er pakketten verschijnen terwijl de client verzendt, dan komen ze aan en ligt het probleem bij de service of de input-chain. Als er helemaal geen pakketten verschijnen, dan hebben ze de bestemming nooit bereikt.

Een checklist in de volgorde waarin u het snelst een fout vindt

1. Voer op de server sudo ss -ltnp 'sport = :8080' uit. Geen output betekent dat er niets luistert; repareer dus eerst de service.
2. Bij output, lees de kolom Local Address. 127.0.0.1 betekent dat toegang van buitenaf onmogelijk is totdat u de binding aanpast of een proxy voor de service plaatst.
3. Voer vanaf een ander netwerk nc -zv -w 3 <public ip> 8080 uit.
4. Een weigering (refusal) betekent dat u terug moet naar stap 1. Het adres, de poort of de machine is niet wat u denkt dat het is.
5. Een timeout betekent dat pakketten worden gedropt. Start sudo tcpdump -ni any tcp port 8080 op de server en herhaal de test.
6. SYN komt aan, maar er gaat niets terug: dit duidt op de host-firewall. Zoek de regel waarvan de teller oploopt in sudo iptables -L INPUT -n -v.
7. Er komt geen SYN aan: dit duidt op de firewall van de provider, een security group of het verkeerde IP-adres.

FAQ

Hoe controleer ik welke poorten openstaan op mijn eigen Linux-server?

Voer sudo ss -ltnp uit voor TCP en sudo ss -lunp voor UDP. Elke regel is één luisterende socket, en de kolom Local Address geeft aan wie deze kan bereiken: 0.0.0.0 en [::] accepteren verbindingen vanaf elke locatie die de firewall toestaat, terwijl 127.0.0.1 alleen verbindingen vanaf de machine zelf accepteert. De kolom Process vereist root-rechten; voer het commando daarom uit met sudo, anders blijft deze kolom leeg. ss is onderdeel van iproute2 en is altijd geïnstalleerd; netstat is onderdeel van net-tools en is dat meestal niet.

Waarom toont ss dat mijn service luistert, maar kan ik toch geen verbinding maken?

Er zijn twee veelvoorkomende oorzaken en één commando helpt u deze te onderscheiden. Als het Local Address 127.0.0.1 is, is de service gebonden aan de loopback-interface en onbereikbaar vanaf elke andere host, omdat de kernel dat bereik alleen naar de loopback-interface routeert. Als het 0.0.0.0 is en verbindingen nog steeds mislukken, voer dan sudo tcpdump -ni any tcp port <port> uit op de server en probeer vanaf een externe locatie verbinding te maken. Een SYN-pakket dat aankomt zonder antwoord betekent dat een lokale firewallregel het pakket blokkeert. Als er niets aankomt, wordt het pakket vóór uw VPS tegengehouden, meestal door een firewall van de provider of een security group.

Wat is het verschil tussen een verbinding die wordt geweigerd en een verbinding die een time-out geeft?

Een weigering is een antwoord. Het pakket bereikte de host en ontving een TCP-reset of een ICMP-melding dat de poort onbereikbaar is; dit betekent dat er niets luistert op dat adres en die poort, of dat een regel de verbinding heeft afgewezen. Een time-out is stilte: een regel heeft het pakket genegeerd en niets teruggestuurd, waardoor uw client het blijft proberen totdat deze opgeeft. Een weigering wijst op de service en het bind-adres. Een time-out wijst op een firewall; controleer in dat geval eerst de firewall die het dichtst bij het internet staat.

Hoe controleer ik of een UDP-poort openstaat?

U kunt geen betrouwbaar antwoord krijgen met een algemene scan, omdat UDP geen handshake heeft en een stille service er hetzelfde uitziet als een genegeerd pakket. nc -zu meldt succes zodra het pakket is verzonden, en nmap rapporteert om dezelfde reden open|filtered. Test het door het protocol zelf te spreken: dig +short @<host> example.com voor DNS, of sudo wg show voor een WireGuard-peer met een recente handshake. Om te verifiëren of pakketten aankomen, voert u sudo tcpdump -ni any udp port <port> uit op de server terwijl de client gegevens verstuurt.

Kan ik nog steeds telnet host port gebruiken om een poort te testen?

Het werkt voor TCP, en Escape character is '^]' betekent dat de verbinding is geaccepteerd. Sluit af met Ctrl+] en vervolgens quit. Twee redenen maken nc -z een betere tool: telnet is op de meeste moderne server-images niet geïnstalleerd, en nc ondersteunt een time-out met -w en geeft een exit-status terug die u in een script kunt testen. Wanneer geen van beide beschikbaar is, heeft timeout 3 bash -c '</dev/tcp/<host>/<port>' geen enkel pakket nodig.