TCP-poortcontrole

Over deze tool

Een port-check is de eenvoudigste "luistert de dienst werkelijk"-vraag die u het publieke internet kunt stellen. Onze port checker opent een echte TCP-verbinding vanaf onze server in Frankfurt naar de host en poorten die u opgeeft, met een time-out van 3 seconden per poort. Als de handshake voltooit, is de poort open; als de host actief weigert, is de poort closed; als het stil blijft, is de poort filtered — meestal een firewall die het SYN-pakket zonder antwoord laat vallen.

U kunt tot 100 poorten per run scannen — een enkele poort (80), een door komma's gescheiden lijst (80,443,22), of een klein bereik (20-25). Elk resultaat toont het poortnummer, ons oordeel, de tijd die de dial duurde, en een service-naam-gok op basis van IANA-achtige toewijzingen (22 → ssh, 5432 → postgresql, etc.). De uitkomst wordt rij voor rij bijgewerkt terwijl we dial-en — u hoeft niet te wachten op de traagste poort om over de snelle te leren.

Wat u ermee kunt doen

• Een deploy verifiëren zonder SSH-en. Als uw dienst op poort 5432 zou moeten staan en de checker zegt filtered, heeft de listener nooit gebonden of zit de firewall ertussen — verschillende oplossingen, maar de port-check vertelt u welke.
• Externe blootstelling auditen. Voer de populaire-poorten-preset uit tegen uw server. Alles dat open is en dat u niet herkent is uw huiswerk. closed en filtered zijn beide prima voor het publieke internet.
• "De firewall moet fout zijn"-discussies diagnosticeren. filtered op elke poort vanaf ons — maar bereikbaar vanaf uw laptop — is concreet bewijs dat de firewall van de host een bron-IP-allowlist heeft, geen poortprobleem.

Het resultaat lezen

"Open" is ondubbelzinnig: een TCP-listener accepteerde ons. "Closed" betekent dat de host leeft en de kernel RST stuurde; de poort wordt niet gebruikt. "Filtered" is het interessante geval: een firewall liet ons pakket vallen zonder antwoord, de route is kapot, of de listener is overbelast. De dial-tijd-kolom helpt onderscheiden — open en closed antwoorden in milliseconden van één cijfer; filtered zit altijd op de volledige 3-seconden time-out. Veel UDP-gebaseerde diensten (DNS op 53, SNMP op 161) accepteren ook TCP, maar als ze dat niet doen, verwacht filtered — dat is normaal, geen bug.