Curso de Ubuntu 26.04 / Práctica final: construir, verificar y entregar un servidor

El criterio de finalización de la construcción del servidor Ubuntu no es el éxito de la instalación, sino el estado en que otros administradores puedan acceder, modificar y recuperar. Esta práctica integral configura solo los servicios necesarios en una VM dedicada 26.04 LTS y verifica el acceso permitido/denegado, reinicios y restauración de respaldo, dejando los resultados reales en un documento de entrega.

Confirmar alcance de la práctica y condiciones de éxito

La tarea básica es la gestión SSH dentro de la LAN y el servicio web Nginx. Se preparan VM dedicada, consola, planificación de direcciones, clientes de gestión permitidos y ubicación de respaldo independiente. HTTPS público se agrega solo si se tiene un dominio propio y una ruta de verificación externa; Samba o contenedores se seleccionan solo cuando son necesarios. No se busca instalar todos los servicios.

Configurar según el orden de dependencia y dividir los cambios en partes pequeñas

1. Después de la instalación, registrar la versión, el dispositivo, la hora y la dirección actual desde la consola y completar las actualizaciones y los reinicios necesarios.
2. Verifique el alcance real de la administración de Netplan o NetworkManager y aplíquelo con cambio de dirección, consola, respaldo y comprobación de prueba.
3. Después de verificar la autenticación de clave SSH en una nueva sesión, ajuste la política de administración. Revise los puertos basándose en el oyente real y la configuración de servicios/sockets.
4. Instale solo los servicios necesarios y aplique después de realizar un respaldo de configuración y una verificación de sintaxis. Limite los clientes y puertos reales en UFW y en el firewall externo.
5. Prepare un respaldo y prueba de restauración independientes y rutas de notificación de fallos, y guarde el estado antes de la prueba de reinicio.

Si falla la verificación paso a paso, no agregue el siguiente cambio y revise las diferencias y los registros actuales. Cambiar al mismo tiempo el puerto de administración, la autenticación y el firewall dificulta identificar la causa de la desconexión y los elementos a restaurar. También verifique si la ruta de recuperación de la consola se puede abrir realmente.

Separar la verificación local del servicio en la LAN

El sitio 127.0.0.1:8080 de la lección de Nginx se comprueba desde el propio servidor. Asociar alpha.example.test a la dirección 192.168.56.20 del servidor no permite acceder desde fuera a un listener de loopback. Compruebe primero la respuesta alpha-site desde el servidor, indicando el nombre y el destino de loopback con --resolve como se muestra a continuación. El ejemplo de contenedores utiliza 8081 y esta práctica en la LAN utiliza 8082.

curl --fail --show-error --resolve alpha.example.test:8080:127.0.0.1 http://alpha.example.test:8080/

Para probar la red local (LAN), prepare la red solo para el anfitrión de las lecciones de creación de VM e IP fija: servidor Ubuntu 192.168.56.20/24 y cliente Linux 192.168.56.10/24. El bloque siguiente reutiliza la raíz documental /srv/ubuntu-course-alpha del ejercicio de Nginx. Si emplea otras direcciones o rutas, adapte todas las referencias de forma coherente y compruebe conflictos de puertos. El ejemplo se detiene si ya existen los archivos del nuevo sitio.

(
set -eu
site=/etc/nginx/sites-available/ubuntu-course-lan
enabled=/etc/nginx/sites-enabled/ubuntu-course-lan
sudo test -f /srv/ubuntu-course-alpha/index.html
if ! ip -4 -o address show | grep -Fq ' 192.168.56.20/24 '; then
    printf 'Configure the verified server lab address first.\n' >&2; exit 1
fi
for path in "$site" "$enabled"; do
    if sudo test -e "$path" || sudo test -L "$path"; then
        printf 'Existing lab site: inspect before changing.\n' >&2; exit 1
    fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-lan.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<'EOF'
server {
    listen 192.168.56.20:8082;
    server_name course-lab.example.test;
    root /srv/ubuntu-course-alpha;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp
printf 'LAN site backup: %s\n' "$backup_dir"
)

Aplique la regla siguiente solo tras preparar la configuración de UFW con entrada denegada por defecto y acceso SSH de administración. Revise que ninguna otra regla autorice ampliamente el puerto 8082, porque invalidaría la prueba de denegación. Mantenga 8082 en la red de práctica y no lo redirija desde Internet.

sudo ufw allow from 192.168.56.10 to 192.168.56.20 port 8082 proto tcp
sudo ufw status numbered

Desde el cliente Linux autorizado, 192.168.56.10, ejecute el curl siguiente para verificar la respuesta alpha-site. Una conexión nueva desde un cliente excluido, como el anfitrión 192.168.56.1, debe quedar bloqueada según la política. Si además desea rechazar nombres HTTP diferentes, configure un servidor virtual predeterminado de rechazo: server_name no sustituye el cortafuegos ni la autenticación.

curl --fail --show-error --connect-timeout 5 --max-time 10 --resolve course-lab.example.test:8082:192.168.56.20 http://course-lab.example.test:8082/

Al organizar, solo registre y compare las reglas de este sitio y UFW para eliminarlas, y luego, después de que nginx -t tenga éxito, haga reload. Mantenga los sitios de loopback de la lección 23 u otros servicios. En la verificación después del reinicio, mida nuevamente la dirección del servidor, el listener real y los accesos permitidos y excluidos.

Crear un pequeño script de verificación de estado HTTP

Guarde el bloque completo en un archivo nuevo ~/check-web-lab.sh, sin reemplazar otro script. Requiere Bash, curl y las herramientas básicas que utiliza; recibe una URL real y un fragmento literal no vacío de una sola línea. Para la prueba local, registre alpha.example.test como 127.0.0.1 en el archivo hosts del propio servidor, conservando y revisando las entradas existentes, y ejecute bash ~/check-web-lab.sh http://alpha.example.test:8080/ alpha-site. La opción --resolve de una ejecución anterior de curl no cambia la resolución del script. Revise las exclusiones de proxy si el entorno usa uno.

set -eu
if [ "$#" -ne 2 ]; then
    printf "Usage: bash check-web-lab.sh URL EXPECTED_TEXT\n" >&2
    exit 2
fi
url=$1
expected=$2
case "$url" in
    http://*|https://*) ;;
    *) printf "Use an HTTP or HTTPS URL.\n" >&2; exit 2 ;;
esac
if [ -z "$expected" ]; then
    printf "Expected text must not be empty.\n" >&2
    exit 2
fi
body_file=$(mktemp)
trap 'rm -f -- "$body_file"' EXIT
if ! curl --fail --silent --show-error --connect-timeout 5 --max-time 10 "$url" -o "$body_file"; then
    printf "FAIL: request or TLS verification failed\n" >&2
    exit 1
fi
if ! grep -Fq -- "$expected" "$body_file"; then
    printf "FAIL: expected text missing\n" >&2
    exit 1
fi
printf "PASS: %s %s\n" "$(date -u +%FT%TZ)" "$url"

El script devuelve 0 y PASS si la petición finaliza sin el fallo que detecta --fail y encuentra el fragmento; devuelve 1 ante fallo de petición, validación TLS o contenido, y 2 ante argumentos inválidos. Pruebe también un texto inexistente. Este chequeo no exige expresamente un estado HTTP 200 ni sigue redirecciones; tampoco prueba autenticación de usuarios, escrituras de base de datos o copias de seguridad. No incluya secretos en la URL y recopile por separado el estado de salida y la hora para automatizarlo.

Para verificar el estado de la LAN, conecte course-lab.example.test a 192.168.56.20 en /etc/hosts del cliente .10 o en el DNS de administración, y luego ejecute bash ~/check-web-lab.sh http://course-lab.example.test:8082/ alpha-site. Guarde la versión original antes de modificar hosts y no duplique entradas de nombres existentes. No mezcle URL locales, de LAN o HTTPS públicas, y distinga entre bloqueos esperados y fallos de servicio.

Registrar accesos permitidos y denegados, reinicios y restauraciones

Además del éxito de curl en el propio servidor, pruebe en clientes permitidos y excluidos. Cree nuevas conexiones manteniendo las conexiones SSH existentes, y ejecute el reinicio según el tiempo planificado para volver a conectarse. Verifique el contenido y los permisos en ubicaciones de restauración separadas y vacías, y realice también las comprobaciones requeridas por la aplicación. Los elementos no ejecutados quedarán como incompletos.

Registro de reglas aplicadas y pruebas de conexión basado en la guía de firewall de Ubuntu.

Completar la documentación de entrega con valores verificados

El siguiente formulario es el punto de inicio del archivo de registro operativo. Sustituya los corchetes por los valores verificados y no escriba valores secretos en el documento; indique solo la ubicación de almacenamiento aprobada. Asigne responsables y encargados de recuperación, y no copie suposiciones de IP de ejemplo o instalaciones exitosas tal cual en los resultados medidos.

Sistema: [nombre del equipo, propósito, responsable]
Plataforma: [versión de Ubuntu, kernel, anfitrión de la VM, acceso a la consola]
Red: [interfaz, gestor, dirección, puerta de enlace, DNS]
Acceso: [clientes permitidos, escucha SSH real, ubicación de custodia de claves]
Servicios: [versiones, rutas de configuración, órdenes de validación y recarga]
Exposición: [puertos de escucha, reglas UFW, cortafuegos externo, enlaces de contenedores]
TLS: [nombres de host, renovación, supervisión de caducidad y fallos]
Copia de seguridad: [alcance, identidad del destino independiente, retención, custodia de claves]
Prueba de restauración: [momento, destino, resultados de contenido, permisos y aplicación]
Aceptación: [prueba, cliente, resultado previsto y real, ubicación de evidencias]
Reversión: [alcance del cambio, estado previo conservado, procedimiento de restauración]
Pendiente: [comprobaciones no realizadas, riesgos sin resolver, responsable, fecha prevista]

Se almacena conjuntamente el registro de verificación y el historial de cambios, y se examina si otros administradores pueden leer solo los procedimientos y preparar el acceso, la inspección y la restauración. Si se determina quién recibe las notificaciones y se establecen los ciclos de actualización, certificados y verificación de copias de seguridad, y si el responsable de las tareas pendientes está claro, se puede continuar la operación sin depender de la memoria de la persona que creó el servidor.