Resolución de problemas de red para principiantes: Parte 3 — Puertos

La dirección IP identifica el nodo, y el puerto — el servicio concreto en él. El servidor web normalmente acepta conexiones en el puerto 80 (HTTP) y 443 (HTTPS), SSH en el 22, las bases de datos y el correo en sus puertos. El servidor puede responder a ping, pero si el servicio necesario no está iniciado o el puerto está cerrado por un cortafuegos, la aplicación no podrá comunicarse con él.

En esta sección — cómo comprobar el puerto de un servidor remoto y qué puertos escucha tu máquina.

Comprobación de un puerto en un servidor remoto

nc (netcat)

nc -zv example.com 443

• -z — solo comprobar la conexión, sin transferir datos;
• -v — salida detallada.

Resultado exitoso:

Connection to example.com (93.184.215.14) 443 port [tcp/https] succeeded!

Fallo:

nc: connect to example.com port 81 (tcp) failed: Connection refused

El texto exacto depende de la variante de nc en el sistema (OpenBSD o traditional), pero el sentido es el mismo. Para limitar el tiempo de espera añade -w 5 — cinco segundos. Más ejemplos — en el artículo sobre netcat.

Windows: Test-NetConnection

En PowerShell la comprobación de puertos está integrada:

Test-NetConnection example.com -Port 443

En la salida, la línea TcpTestSucceeded : True significa que la conexión se estableció.

telnet

Un método antiguo que funciona dondequiera que esté instalado el cliente telnet:

telnet example.com 443

El mensaje Connected to … significa que el puerto está abierto; para salir — Ctrl+], luego quit. En Windows el cliente telnet no está instalado por defecto, por eso allí es más cómodo usar Test-NetConnection.

Cómo interpretar los errores

• Connection refused — el nodo es accesible, pero en ese puerto nadie acepta conexiones: el servicio no está iniciado o escucha en otro puerto o dirección.
• Connection timed out — no hay respuesta en absoluto. Normalmente los paquetes son descartados por el cortafuegos en el servidor, por el proveedor o en la ruta.
• No route to host — no hay ruta hasta el nodo o este la rechaza por el cortafuegos.

La diferencia entre refused y timeout es la pista principal: en el primer caso llegas al servidor, en el segundo no.

Qué escucha tu máquina

En Linux la herramienta principal es ss:

ss -tulpn

• -t — TCP;
• -u — UDP;
• -l — solo sockets en escucha;
• -n — números de puerto en lugar de nombres de servicio;
• -p — proceso que abrió el socket (para procesos ajenos se necesita sudo).

Ejemplo de línea:

tcp  LISTEN 0  4096  0.0.0.0:22   0.0.0.0:*   users:(("sshd",pid=812,fd=3))

Presta atención a la dirección en la columna de dirección local:

• 0.0.0.0:22 o [::]:22 — el servicio acepta conexiones en todas las interfaces;
• 127.0.0.1:5432 — solo desde la misma máquina; no es posible conectarse desde fuera, y esta es una causa frecuente de la pregunta “el puerto está abierto pero no se puede conectar”.

En Windows:

netstat -ano

La columna State con el valor LISTENING muestra los puertos en escucha, la última columna es el identificador del proceso. La utilidad netstat en Linux está obsoleta; la reemplaza ss.

Si el servicio está escuchando pero el puerto no es accesible desde fuera

Orden de comprobación:

1. El servicio escucha la dirección correcta (0.0.0.0, y no 127.0.0.1) — ss -tlnp.
2. El puerto está abierto en el cortafuegos del servidor. La configuración de UFW se trata en el artículo «Protección del servidor Linux: Parte 1 — Cortafuegos UFW».
3. El puerto está abierto en el proveedor de hosting (grupos de seguridad en la nube) y reenviado en el router si el servidor está detrás de NAT.

Resumen

• nc -zv, Test-NetConnection -Port, telnet — comprobar el puerto de un nodo remoto;
• refused — el servicio no está escuchando; timeout — los paquetes son descartados en la ruta;
• ss -tulpn y netstat -ano — qué escucha tu máquina y en qué dirección.

Recursos

• ss (man7.org)
• Test-NetConnection (Microsoft Learn)
• nc (OpenBSD)