Curso de Linux / Diagnosticar fallos de red: rutas, DNS, puertos y HTTP

Los problemas de conexión en Linux son más fáciles de diagnosticar si se revisan en el orden de interfaz y dirección, ruta, resolución de nombres, conexión de transporte y respuesta de la aplicación. No juzgue el estado de Internet o de los servicios web solo con el éxito o fracaso de un ping.

Al interpretar la dirección y la ruta predeterminada, consulte el papel de la dirección IP, DNS y puertos. Si falla solo en SSH, también debe verificar los puertos, claves y hosts según conexión y transferencia de archivos SSH.

El estándar para la práctica de configuración del sistema es Ubuntu 26.04 LTS y VMs de instalación general de la serie Rocky Linux 9. En contenedores, WSL u otras versiones, la configuración de servicios y paquetes puede variar. Preparar primero la recuperación de consola y la verificación de la versión se indica en Crear un entorno de práctica con máquina virtual.

Registrar el alcance de la falla y las condiciones de comparación

Anote desde qué computadora, a qué dirección o puerto y desde cuándo no se puede conectar. Compare si falla en todos los sitios o solo en uno, si otros dispositivos de la misma red fallan, y si difiere la versión de IP, VPN o proxy. Dejar registrados los ajustes cambiados recientemente junto con los mensajes de error reales puede reducir las conjeturas. En servidores de producción, asegúrese de tener acceso a la consola o a una ruta de gestión alternativa antes de reiniciar la red.

Verificar interfaz, dirección y ruta

ip -brief link
ip -brief address
ip route
ip -6 route

UP indica que la interfaz está activada a nivel de administración, pero no garantiza comunicación hasta el destino. Observe también la información de enlace como LOWER_UP, la existencia de la dirección esperada y la ruta correcta hacia el destino. Si es una máquina virtual, verifique si la interfaz de red virtual (NIC) está conectada y si el modo de NAT o puente es el deseado según la configuración de virtualización del host. No asuma que el nombre de la interfaz es eth0.

Después de averiguar la dirección de destino real, si ejecuta ip route get DIRECCIÓN_IPV4_REAL, puede ver la interfaz seleccionada, el siguiente salto y la dirección de origen. “Network is unreachable” indica primero un problema de ruta, a diferencia de un error de resolución de nombres. Incluso si se imprime la ruta, no significa que el siguiente salto o los dispositivos posteriores respondan.

Usar ping como una pista de alcanzabilidad

ping -c 3 127.0.0.1
ping -c 3 example.com

El primer comando envía ICMP Echo al loopback y el segundo realiza la resolución de nombres antes de enviarlo al destino. Si el destino o los equipos intermedios bloquean ICMP, ping puede fallar incluso si el acceso web es normal. Por el contrario, un ping exitoso no verifica si el puerto web, el certificado o la respuesta HTTP son correctos. En lugar de enviar tráfico repetido a destinos externos, realice solo unas pocas verificaciones con los objetivos de práctica permitidos.

Separar fallos de resolución de nombres y fallos de conexión

getent ahosts example.com
curl -I -v --connect-timeout 5 --max-time 15 https://example.com/
printf "exit=%s\n" "$?"

Si no hay resultados de getent, primero verifique la configuración del servicio de nombres. En la salida detallada de curl, observe el orden de selección de dirección, conexión, intercambio TLS y respuesta. El código de salida 6 generalmente indica fallo en la resolución del nombre de host, 7 fallo en la conexión y 28 tiempo de espera. El código 60 corresponde a problemas de verificación del certificado y puede que no se resuelva simplemente abriendo el firewall o cambiando DNS. No use -k para desactivar la verificación como solución.

La opción -I solicita el método HTTP HEAD: un rechazo de HEAD no demuestra que una solicitud GET también falle. Compare el método que utiliza la aplicación. Por defecto, curl puede terminar con estado 0 al completar una transferencia aunque reciba HTTP 404 o 500. Para tratar errores HTTP como fallos, consulte --fail-with-body o --fail en la versión instalada y lea por separado el código HTTP y el estado del proceso. Antes de compartir una salida detallada, oculte cookies, cabeceras sensibles y direcciones internas.

Verificar la dirección y el puerto de escucha en el servidor

ss -lnt
ss -lnu
sudo ss -lntp

Si el servicio solo escucha en 127.0.0.1:8080, solo se puede acceder directamente desde el mismo servidor. 0.0.0.0:8080 se dirige a todas las interfaces IPv4, y si [::]:8080 recibe simultáneamente IPv4 depende de la configuración del socket y del sistema. La información del proceso está limitada según los permisos. UDP no tiene el mismo significado que LISTEN de TCP, por lo que no se puede garantizar la respuesta a solicitudes solo con la lista UDP.

Aplicar solo un cambio que corresponda con los resultados observados

Antes de cambiar, registre el valor original y luego cambie solo un elemento y pruebe nuevamente con el mismo cliente·dirección·puerto. Si no tiene efecto, vuelva al valor original y verifique otra hipótesis. Hacer esto ayuda a no pasar por alto qué cambio causó el problema y también reduce la posibilidad de crear una nueva falla durante el proceso de resolución.

Para distinguir errores HTTP sin depender de sitios externos, asegúrese de que python3 y curl estén en la VM de práctica. Si no están, instálelos con el gestor de paquetes de la distribución. En una nueva terminal, ejecute el servidor a continuación y déjelo así. Si hay error porque el puerto 18080 está en uso, elija otro puerto libre y cambie los números en ambos comandos.

lab=$(mktemp -d "$HOME/linux-http-check.XXXXXX") &&
python3 -m http.server 18080 --bind 127.0.0.1 --directory "$lab"

Después de que el servidor se haya iniciado correctamente, ejecute lo siguiente en otro terminal de la misma VM. Se mostrará HTTP 404 y el estado de salida de curl será 22. Esto significa que la conexión TCP y la respuesta HTTP llegaron en esta solicitud, pero el archivo no existe. Después de finalizar el terminal del servidor con Ctrl+C y volver a hacer la solicitud, si no hay un servidor receptor, normalmente el estado de curl será 7 por fallo de conexión, y en un entorno donde el intento de conexión espera hasta el límite de tiempo, puede ser estado 28. Verifique inmediatamente el valor del estado y también compruebe que un nuevo servidor no esté usando el mismo puerto.

curl --fail --show-error --connect-timeout 2 --max-time 5 http://127.0.0.1:18080/missing-file
printf "exit=%s\n" "$?"

Documentación oficial

• Manual oficial de opciones y códigos de salida de curl
• Documento de configuración de red del kernel