Comprobador de puertos TCP

Sobre esta herramienta

Una comprobación de puerto es la pregunta más simple que puede hacer a la internet pública del tipo «¿está realmente escuchando el servicio?». Nuestro comprobador de puertos abre una conexión TCP real desde nuestro servidor de Frankfurt hacia el host y los puertos que indique, con un tiempo de espera de 3 segundos por puerto. Si el handshake se completa, el puerto está abierto; si el host rechaza activamente, el puerto está cerrado; si hay silencio, el puerto está filtrado — normalmente un cortafuegos que descarta el paquete SYN sin respuesta.

Puede sondear hasta 100 puertos por ejecución — un solo puerto (80), una lista separada por comas (80,443,22) o un rango pequeño (20-25). Cada resultado muestra el número de puerto, nuestro veredicto, el tiempo de la conexión y una estimación del nombre del servicio basada en asignaciones de estilo IANA (22 → ssh, 5432 → postgresql, etc.). El veredicto se actualiza fila a fila a medida que conectamos — no hay que esperar al puerto más lento para conocer los rápidos.

Para qué sirve

• Verificar un despliegue sin entrar por SSH. Si su servicio debería estar en el puerto 5432 y el comprobador dice filtered, el listener no se ha enlazado o el cortafuegos lo bloquea — soluciones distintas, pero la comprobación de puerto le dice cuál.
• Auditar la exposición externa. Ejecute el preset de puertos populares contra su servidor. Cualquier puerto open que no reconozca es tarea suya. closed y filtered son ambos adecuados para la internet pública.
• Diagnosticar discusiones del tipo «el cortafuegos debe estar mal». filtered en todos los puertos desde nuestro lado — pero alcanzable desde su portátil — es prueba concreta de que el cortafuegos del host tiene una lista blanca por IP de origen, no un problema de puertos.

Lectura del resultado

«Open» es inequívoco: un listener TCP nos aceptó. «Closed» significa que el host está vivo y el kernel envió RST; el puerto no está en uso. «Filtered» es el caso interesante: un cortafuegos descartó nuestro paquete sin respuesta, la ruta está rota o el listener está saturado. La columna de tiempo de marcado ayuda a desambiguar — abiertos y cerrados responden en milisegundos de un dígito; los filtrados siempre se quedan en el tiempo de espera completo de 3 segundos. Muchos servicios basados en UDP (DNS en 53, SNMP en 161) aceptan TCP también, pero si no lo hacen, espere filtered — eso es normal, no un fallo.