Introducción
La resolución de problemas de red resulta más sencilla cuando se comprueba una capa cada vez. Empiece por la identidad del host y, después, confirme 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, la política del firewall local.
En este laboratorio seguirá esa secuencia en un host Ubuntu. Hay un servicio HTTP preparado que escucha únicamente en el puerto de loopback 8088; así dispondrá de un objetivo seguro para practicar con ss, curl y las reglas de UFW. No cambiará la configuración de las interfaces del host, la ruta predeterminada, los ajustes de DNS ni el servicio SSH. Antes de activar UFW, conservará explícitamente el acceso SSH.
Identificar el host
En este paso, examinará el nombre del host y los registros de nombres locales que ayudan a los programas a identificar esta máquina.
Entre en el espacio de trabajo del laboratorio:
cd /home/labex/project/network-lab
Muestre el nombre actual del host:
hostname
Muestre 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.
Examine 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 una red externa. Muestre las direcciones IP asignadas al host en formato compacto:
hostname -I
Guarde 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
Examinar las interfaces y las direcciones IP
En este paso, identificará las interfaces de red, el estado del enlace, las direcciones IPv4, los prefijos y el ámbito de las direcciones.
Use la vista breve de los enlaces:
ip -brief link
lo es la interfaz de loopback. Otra interfaz, que normalmente se denomina eth0 o ens..., conecta la máquina virtual con su red. UP significa que la interfaz está habilitada administrativamente.
Muestre 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.
Examine 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. Busque la interfaz que 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"
El comando ifconfig es una herramienta antigua para interfaces que todavía aparece en procedimientos existentes y en instrucciones de resolución de problemas. Compare su salida con la salida moderna de ip que acaba de consultar:
ifconfig
Guarde también la vista heredada:
ifconfig > ifconfig-addresses.txt
Guarde una instantánea breve de las interfaces:
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
Leer la tabla de enrutamiento
En este paso, identificará la puerta de enlace predeterminada y preguntará a Linux qué ruta utilizaría para llegar a un destino.
Muestre la tabla de enrutamiento principal:
ip route
Las rutas conectadas describen redes conectadas directamente. Una línea que comienza por default via se utiliza cuando no coincide ninguna ruta más específica.
Pregunte al kernel cómo llegaría a un destino público. Este comando muestra 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
Extraiga 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"
Guarde 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á ping para probar límites cada vez más alejados y tendrá en cuenta que algunas redes bloquean los paquetes de diagnóstico.
Empiece por el loopback. La opción -c 2 envía 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, obtenga y pruebe 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, aun así, rechazar los pings. Pruebe una dirección IP pública sin depender de DNS:
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
Guarde un resultado estable de conectividad local en lugar de depender de la política externa:
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
Probar la resolución del nombre del host
En este paso, examinará la configuración del resolvedor y traducirá nombres de host a direcciones.
Vea el archivo del resolvedor que utilizan 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.
Resuelva un nombre local mediante toda la configuración de servicios de nombres del sistema:
getent hosts localhost
getent sigue las reglas de /etc/nsswitch.conf, por lo que puede combinar /etc/hosts, DNS y otras fuentes configuradas. Resuelva un nombre externo y solicite direcciones de socket IPv4:
getent ahostsv4 example.com
Si el ping a una IP funciona, pero esta consulta falla, centre la investigación en la configuración del resolvedor o en la conectividad con DNS. Guarde el primer registro IPv4 resuelto:
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
Examinar un puerto en escucha y una respuesta HTTP
En este paso, asociará un socket TCP en escucha con el proceso propietario y probará el protocolo de la aplicación.
El servicio de demostración preparado escucha en el puerto de loopback 8088. Utilice ss para examinar 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'
Busque 127.0.0.1:8088. Asociarse a loopback significa que el servicio solo es accesible desde este host.
Compruebe el proceso del servicio asociado al socket:
systemctl status labex-network-demo.service --no-pager
Utilice curl -i para mostrar las cabeceras y el cuerpo de la respuesta HTTP:
curl -i http://127.0.0.1:8088/
El estado HTTP 200 OK demuestra algo más que un puerto abierto: la aplicación aceptó una solicitud HTTP y devolvió contenido. Guarde únicamente el cuerpo de la respuesta con 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, examinará el estado de UFW, conservará el acceso de administración remota, permitirá el puerto del servicio de práctica y activará el firewall.
UFW es una interfaz para las reglas de filtrado de paquetes de Linux. Examine su estado actual:
sudo ufw status verbose
La configuración inicial deja UFW inactivo y con un conjunto de reglas limpio. Antes de activar cualquier firewall del host de forma remota, permita la vía de administración de la que depende. Esta máquina virtual utiliza el puerto TCP 22 para SSH:
sudo ufw allow 22/tcp
Ahora permita el tráfico TCP entrante al puerto del servicio de práctica:
sudo ufw allow 8088/tcp
Revise los cambios preparados antes de activarlos:
sudo ufw show added
Active UFW sin solicitar confirmación interactiva:
sudo ufw --force enable
Confirme que el firewall está activo y que ambas reglas de permiso están presentes:
sudo ufw status verbose
El servicio está asociado a loopback, así que pruébelo localmente después del cambio del firewall:
curl -fsS http://127.0.0.1:8088/
Guarde 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: conserve la vía de administración, añada las reglas necesarias para el servicio, active el firewall y verifique inmediatamente tanto la política como la accesibilidad de la aplicación. Los hosts de producción pueden utilizar otro puerto SSH, por lo que debe confirmar la vía de administración real en lugar de asumir que es el puerto 22.
Resumen
Siguió 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. Aprendió que cada capa responde a una pregunta diferente y que un fallo en un límite concreto acota la siguiente investigación.
También conservó el acceso SSH, permitió el puerto de un servicio de práctica, activó UFW y verificó tanto la política activa como la respuesta de la aplicación. Estos hábitos le preparan para diagnosticar y proteger un servicio de red sin realizar cambios amplios ni disruptivos.
