Introducción
La resolución de problemas de red resulta más sencilla cuando se comprueba cada capa por separado. Empieza por la identidad del host y, a continuación, verifica sus interfaces y direcciones, la selección de rutas, la conectividad básica, la resolución de nombres, los sockets en escucha, la respuesta de la aplicación y, por último, las reglas del cortafuegos local.
En este laboratorio seguirás esa secuencia en un host Ubuntu. Hay un servicio HTTP preparado que escucha únicamente en el puerto de loopback 8088, lo que proporciona un objetivo seguro para practicar con ss, curl y las reglas de UFW. No modificarás la configuración de las interfaces, la ruta predeterminada, los ajustes de DNS ni el acceso SSH del host.
Identificar el host
En este paso inspeccionarás el nombre del host y los registros de nombres locales que ayudan a los programas a identificar esta máquina.
Entra en el espacio de trabajo del laboratorio:
cd /home/labex/project/network-lab
Muestra el nombre actual del host:
hostname
Muestra la identidad estática, transitoria y del sistema operativo que conoce systemd:
hostnamectl
Static hostname es el nombre configurado. En las máquinas de formación en la nube, el nombre transitorio puede asignarse durante el arranque.
Inspecciona las asignaciones de hosts locales:
cat /etc/hosts
Los nombres de loopback localhost, 127.0.0.1 y ::1 identifican este mismo host sin utilizar redes externas. Muestra las direcciones IP asignadas al host en un formato compacto:
hostname -I
Guarda el nombre del host y la lista de direcciones:
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
Inspeccionar interfaces y direcciones IP
En este paso identificarás las interfaces de red, el estado del enlace, las direcciones IPv4, los prefijos y el ámbito de las direcciones.
Usa la vista resumida de los enlaces:
ip -brief link
lo es la interfaz de loopback. Otra interfaz, normalmente denominada eth0 o ens..., conecta la máquina virtual con su red. UP indica que la interfaz está habilitada administrativamente.
Muestra las direcciones en formato compacto:
ip -brief address
Una dirección como 192.0.2.10/24 combina una dirección IPv4 y la longitud del prefijo. El prefijo indica qué bits iniciales identifican la red local.
Inspecciona la interfaz de loopback con todos sus detalles:
ip address show dev lo
La dirección IPv4 127.0.0.1/8 tiene scope host, por lo que solo es válida dentro de este host. Averigua qué interfaz utiliza la ruta predeterminada:
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
ifconfig es una herramienta de interfaces más antigua que todavía aparece en manuales y guías de diagnóstico existentes. Compara su salida con la salida moderna de ip que acabas de consultar:
ifconfig
Guarda también la vista heredada:
ifconfig > ifconfig-addresses.txt
Guarda una instantánea resumida de las interfaces:
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
Leer la tabla de enrutamiento
En este paso identificarás la puerta de enlace predeterminada y consultarás a Linux qué ruta utilizaría para llegar a un destino.
Muestra la tabla de enrutamiento principal:
ip route
Las rutas conectadas describen las redes conectadas directamente. Una línea que comienza por default via se utiliza cuando no coincide ninguna ruta más específica.
Consulta al kernel cómo llegaría a un destino público. Este comando informa de la puerta de enlace, la interfaz y la dirección de origen seleccionadas sin enviar ningún paquete:
ip route get 1.1.1.1
Extrae la puerta de enlace y la interfaz predeterminadas:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
Guarda el resumen de la ruta:
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
Probar la conectividad de red
En este paso utilizarás ping para comprobar límites cada vez más alejados, teniendo en cuenta que algunas redes bloquean los paquetes de diagnóstico.
Comienza con el loopback. Las opciones -c 2 envían dos solicitudes y -W 2 espera como máximo dos segundos por cada respuesta:
ping -c 2 -W 2 127.0.0.1
Una prueba de loopback correcta demuestra que la pila IP local responde. A continuación, obtén y prueba la puerta de enlace predeterminada:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
El mensaje alternativo es importante porque un router puede reenviar tráfico y, al mismo tiempo, rechazar los mensajes ping. Prueba una dirección IP pública sin depender del DNS:
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
Guarda un resultado estable de conectividad local en lugar de depender de políticas externas:
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
Probar la resolución de nombres del host
En este paso inspeccionarás la configuración del resolvedor y convertirás nombres de host en direcciones.
Consulta el archivo del resolvedor utilizado por las aplicaciones estándar de Linux:
cat /etc/resolv.conf
Normalmente contiene una o varias líneas nameserver. En los hosts que utilizan systemd-resolved, la dirección puede identificar un resolvedor local de tipo stub en lugar de un servidor DNS externo directamente.
Resuelve un nombre local mediante la configuración completa de servicios de nombres del sistema:
getent hosts localhost
getent sigue la configuración de /etc/nsswitch.conf, por lo que puede combinar /etc/hosts, DNS y otras fuentes configuradas. Resuelve un nombre externo y solicita direcciones de socket IPv4:
getent ahostsv4 example.com
Si el ping a una IP funciona, pero esta consulta falla, centra la investigación en la configuración del resolvedor o en la conectividad DNS. Guarda el primer registro IPv4 resuelto:
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
Inspeccionar un puerto en escucha y una respuesta HTTP
En este paso relacionarás un socket TCP en escucha con el proceso propietario y probarás el protocolo de la aplicación.
El servicio de demostración preparado escucha en el puerto de loopback 8088. Usa ss para inspeccionar los sockets TCP en escucha. Las opciones -l, -t, -n y -p significan escucha, TCP, direcciones numéricas e información del proceso:
sudo ss -ltnp | grep ':8088'
Busca 127.0.0.1:8088. Al estar vinculado al loopback, el servicio solo es accesible desde este host.
Comprueba el proceso del servicio asociado al socket:
systemctl status labex-network-demo.service --no-pager
Usa curl -i para mostrar las cabeceras y el cuerpo de la respuesta HTTP:
curl -i http://127.0.0.1:8088/
Un estado HTTP 200 OK demuestra algo más que la existencia de un puerto abierto: la aplicación aceptó una solicitud HTTP y devolvió contenido. Guarda únicamente el cuerpo de la respuesta mediante el modo silencioso -s:
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
Conservar el acceso y activar UFW
En este paso, inspeccionarás el estado de UFW, conservarás el acceso de administración remota, permitirás el puerto del servicio de práctica y activarás el firewall.
UFW es una interfaz para las reglas de filtrado de paquetes de Linux. Inspecciona su estado actual:
sudo ufw status verbose
La preparación deja UFW inactivo y con un conjunto de reglas limpio. Antes de activar remotamente cualquier firewall del host, permite la ruta de administración de la que dependes. Esta máquina virtual utiliza el puerto TCP 22 para SSH:
sudo ufw allow 22/tcp
Ahora permite el tráfico TCP entrante al puerto del servicio de práctica:
sudo ufw allow 8088/tcp
Revisa los cambios preparados antes de activarlos:
sudo ufw show added
Activa UFW sin una solicitud de confirmación interactiva:
sudo ufw --force enable
Confirma que el firewall está activo y que ambas reglas de permiso están presentes:
sudo ufw status verbose
El servicio está vinculado a la interfaz de bucle local, así que pruébalo localmente después del cambio del firewall:
curl -fsS http://127.0.0.1:8088/
Guarda el estado activo como resultado observable:
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
El orden es importante: conserva la ruta de administración, añade las reglas de servicio necesarias, activa el firewall y verifica inmediatamente tanto la política como la accesibilidad de la aplicación. Los hosts de producción pueden utilizar otro puerto SSH; confirma la ruta de administración real en lugar de asumir el puerto 22.
Resumen
Has seguido una cadena estructurada de diagnóstico de red en Linux: identidad del host, interfaces y direcciones IP, selección de rutas, conectividad, resolución de nombres, sockets en escucha y respuesta HTTP. Has aprendido que cada capa responde a una pregunta diferente y que un fallo en un límite concreto ayuda a acotar la siguiente fase de la investigación.
También has inspeccionado el estado de UFW y has gestionado de forma segura una regla limitada al loopback sin poner en riesgo el acceso remoto. Estos hábitos te preparan para diagnosticar y proteger un servicio de red sin realizar cambios amplios ni disruptivos.
