En el Módulo 3 aprendiste a mirar la red: ip a, ping, dig, ss -tulpn, curl -v y una metodología en capas para averiguar por qué algo no responde. Eso era diagnóstico, y el diagnóstico es lectura. Esta lección da el paso siguiente y bastante más comprometido: escribir. Vas a decidir la dirección de srv-tramontana, su puerta de enlace, sus servidores DNS y sus rutas, y vas a dejarlo escrito de forma que sobreviva a un reinicio.

Comprometido es la palabra exacta: configurar la red de una máquina a la que accedes por la red es la única tarea de administración en la que un error de una letra te deja fuera de forma instantánea y sin aviso. Por eso, además de la sintaxis de netplan, esta lección te enseña el procedimiento: validar antes de aplicar, tener una reversión automática y no soltar nunca la consola de la VM. srv-tramontana sigue con la configuración que dejó el instalador —DHCP puro—, así que su IP depende de un servidor que no controlas. Una aplicación de reservas cuyo nombre de servicio apunta a 10.0.2.15 no puede permitirse que esa dirección cambie un martes por la noche.

1. Repaso operativo: IPv4, máscara, CIDR y redes privadas
2. IPv6 hoy: link-local, SLAAC y por qué no lo desactivas
3. Configuración efímera con ip y por qué se pierde
4. Netplan: el modelo de renderers en Ubuntu 24.04
5. El YAML de netplan, campo a campo
6. netplan try y los permisos 600
7. Resolución de nombres: systemd-resolved y el stub 127.0.0.53
8. El nombre de la máquina: hostnamectl y /etc/hosts
9. Interfaces: nombres predecibles, alias, VLAN, bonding y puentes
10. Rutas, métricas e ip route get
11. Reenvío de paquetes y NAT como conceptos
12. Caso Tramontana: de DHCP a IP estática, verificado

Una dirección IPv4 son 32 bits en cuatro octetos. La máscara los parte en dos: la parte de red (bits a 1) y la de host (bits a 0). La notación CIDR escribe la máscara como el número de bits a 1.

De cada red, dos direcciones no son asignables: la de red (todos los bits de host a 0, 10.0.2.0) y la de difusión (todos a 1, 10.0.2.255). De ahí el «−2».

Las redes privadas de la RFC 1918 no se enrutan en Internet: 10.0.0.0/8 (empresas, VirtualBox NAT, nubes), 172.16.0.0/12 (Docker usa 172.17.0.0/16) y 192.168.0.0/16 (routers domésticos). La puerta de enlace es la dirección del router dentro de tu propia red a la que se envía todo lo que no es local: srv-tramontana está en 10.0.2.15/24, habla directamente con cualquier 10.0.2.x y entrega el resto a 10.0.2.2.

Para las IP externas usamos siempre los rangos de documentación de la RFC 5737: 192.0.2.0/24, 198.51.100.0/24 y 203.0.113.0/24. Nunca uses direcciones reales ajenas en ejemplos ni en pruebas.

IPv6 dejó de ser «el futuro» hace más de una década y Ubuntu 24.04 lo trae activo.

• Toda interfaz operativa tiene una dirección link-local fe80::/10. No se enruta fuera del segmento, pero la usan el descubrimiento de vecinos (NDP, el equivalente de ARP) y los anuncios de router.
• SLAAC (autoconfiguración sin estado) permite que un host se construya su dirección global a partir del prefijo que anuncia el router, sin DHCP. Es lo normal en IPv6; DHCPv6 existe y convive con él.

Solo hay link-local porque la red NAT de VirtualBox no anuncia prefijo IPv6. Desactivar IPv6 «por si acaso» es mala idea, aunque medio Internet lo recomiende: no reduces la superficie de ataque, la reduces mal. Si un servicio escucha en :: y tú desactivas IPv6 a medias, acabas con reglas de firewall que no cubren un camino que sigue existiendo. Además rompes software que asume ::1 —systemd-resolved incluido— con timeouts difíciles de diagnosticar. La postura correcta es la misma que con IPv4: si está activo, protégelo; por eso el firewall del 06-03 usará table inet, que cubre las dos familias. Y si de verdad no lo necesitas en un segmento, desactívalo de forma explícita en netplan (accept-ra: false, link-local: []), no con un parche a medias.

El comando ip no solo lee: también escribe. Y lo que escribe vive solo en el kernel, en memoria.

Fíjate en que ip addr add añade, no sustituye: una interfaz puede tener varias direcciones a la vez. Y todo esto desaparece al reiniciar, y también en cuanto systemd-networkd reconfigure la interfaz tras un netplan apply. No hay ningún fichero implicado: el estado de red del kernel es volátil por diseño. Eso convierte a ip en la herramienta perfecta para probar una hipótesis y en la peor posible para configurar un servidor.

Ubuntu unificó la configuración de red en netplan: tú escribes YAML declarativo y netplan genera la configuración del backend que toque.

El renderer networkd es el de Ubuntu Server —máquinas fijas, servidores, nube— y NetworkManager el de Ubuntu Desktop, pensado para portátiles con wifi, roaming y VPN de usuario. En srv-tramontana es networkd.

Los ficheros viven en /etc/netplan/ con extensión .yaml, se leen en orden alfabético y los últimos ganan sobre los primeros. Por eso se numeran:

Ese fichero lo escribió cloud-init durante la instalación y puede reescribirlo en el siguiente arranque. La forma limpia de tomar el control es desactivar esa parte:

La sintaxis YAML que rompe a todo el mundo: la indentación es con espacios, nunca con tabuladores, y dos espacios por nivel es la convención. Un tabulador produce un error tan críptico como found character '\t' that cannot start any token. Otros tres clásicos: los dos puntos necesitan un espacio detrás (dhcp4: false, no dhcp4:false); las listas se escriben con - o entre corchetes, pero no a medias; y yes/no se interpretan como booleanos, así que usa siempre true/false.

netplan generate traduce el YAML a ficheros de systemd-networkd en /run sin activarlos. Si falla, no has tocado la red:

Este es el comando que separa a quien ha perdido un servidor de quien no.

netplan try aplica la configuración, arranca una cuenta atrás de 120 segundos y espera tu ENTER. Si has roto la red y tu sesión SSH se corta, no puedes pulsar nada: al agotarse el plazo, netplan restaura la configuración anterior. Ajusta el plazo con --timeout 300 si el cambio es delicado.

netplan try no cubre todos los casos: revierte bien si el proceso sigue vivo esperando tu ENTER, pero no si el sistema se cuelga. Por eso la regla completa es try más consola de la VM abierta en otra ventana; en VirtualBox esa consola no pasa por la red.

Desde 24.04, netplan avisa si sus ficheros son legibles por otros: Permissions for /etc/netplan/50-cloud-init.yaml are too open. La razón es directa: un fichero de netplan puede contener la contraseña de una red wifi o credenciales 802.1X en claro, y con 644 las leería cualquier usuario, incluido becario. Aplica umask 027 y déjalos en 600 root:root.

/etc/resolv.conf es un enlace simbólico a un fichero generado, y el único servidor que aparece es 127.0.0.53: el stub local de systemd-resolved. Las aplicaciones preguntan al stub y el stub reenvía a los DNS reales que le ha entregado netplan. Editarlo a mano no sirve de nada: se regenera en el siguiente arranque o netplan apply.

Tres cosas que importan de esa salida:

• El DNS se configura por interfaz. Una máquina con dos interfaces puede tener DNS distintos en cada una, y +DefaultRoute marca cuál se usa para lo que no encaje en un dominio concreto.
• DNS Domain es el dominio de búsqueda: con él, resolvectl query reservas completa a reservas.tramontana.example.
• resolvectl tiene en cuenta /etc/hosts; dig no, porque habla directamente con el servidor. Esa discrepancia explica el 90 % de los «pero si dig lo resuelve bien». Y resolvectl flush-caches vacía la caché cuando acabas de cambiar un registro y sigues viendo el antiguo.

Hay tres nombres: el estático (el de /etc/hostname, el que persiste), el transitorio (el que puede imponer DHCP) y el bonito (--pretty, texto libre). /etc/hosts debe ser coherente, porque muchos programas resuelven su propio nombre al arrancar:

La línea 127.0.1.1 es una convención de Debian/Ubuntu para que el nombre resuelva incluso sin red.

enp0s3 no es arbitrario: es un nombre predecible generado por systemd a partir de la posición física del dispositivo — en (ethernet) + p0 (bus PCI 0) + s3 (slot 3). El sistema antiguo (eth0, eth1) numeraba según el orden de detección del kernel, que podía cambiar entre arranques y dejarte el cable de gestión en la interfaz equivocada.

Un alias de IP es simplemente una segunda dirección en la misma interfaz: basta añadirla a addresses. Sirve para migrar un servicio de una IP a otra sin cortar. Y esta es la vista general de las interfaces virtuales que verás en cuanto salgas del laboratorio, sin montarlas aquí:

La VPN aparece aquí solo como concepto de red: el servidor WireGuard completo se monta en el proyecto 08-04.

Dos entradas: la ruta por defecto y la ruta de enlace de la propia red, que el kernel crea solo al asignar la dirección. El kernel elige siempre la ruta más específica (el prefijo más largo) y, a igualdad, la de métrica menor. Una ruta estática persistente se añade al bloque routes del YAML con to: 198.51.100.0/24 y via: 10.0.2.9.

La herramienta de oro para no discutir es preguntarle al kernel qué hará con un paquete concreto, sin enviar nada:

La primera sale por el router 10.0.2.9 según la ruta estática; la segunda es local y no pasa por ningún router. Cuando alguien afirme «es que el tráfico no va por donde debe», ip route get cierra la conversación en un segundo.

Por defecto, Linux no reenvía paquetes entre interfaces: si llega uno que no va dirigido a él, lo descarta. Lo controla un parámetro del kernel, y activarlo convierte la máquina en un router:

Se hace de forma persistente en /etc/sysctl.d/, nunca editando /etc/sysctl.conf a mano. NAT es lo que hace tu router de casa y lo que hace VirtualBox con la red 10.0.2.0/24: reescribe la dirección de origen de los paquetes salientes para que todos parezcan venir de una sola IP, y mantiene una tabla para devolver las respuestas. NAT no es seguridad, aunque lo parezca: es un apaño para la escasez de IPv4 que, de propina, hace que las conexiones entrantes no lleguen a nadie por defecto.

srv-tramontana no necesita ni reenvío ni NAT: es un servidor final, y dejar ip_forward = 0 es la postura correcta. Lo activarás con la VPN del proyecto 08-04. Las reglas de filtrado y NAT se escriben con ufw/nftables, y eso es la lección 06-03.

Paso 0 — medir antes y hacer copia, la convención del curso:

Paso 1 — abrir la consola de la VM en VirtualBox y dejar una segunda sesión SSH abierta. Nunca cierres la puerta por la que estás entrando.

Paso 2 — escribir la configuración:

El fichero de cloud-init se retira fuera de /etc/netplan/: no basta con renombrarlo dentro del directorio, porque netplan lee cualquier .yaml.

Paso 3 — validar sin aplicar: sudo netplan generate y comprobar que devuelve 0.

Paso 4 — aplicar con red de seguridad: sudo netplan try. Antes de pulsar ENTER, comprueba desde la otra sesión que sigues teniendo acceso y que la aplicación responde. Solo entonces aceptas.

Paso 5 — medir después y comparar:

Lo único que ha cambiado es lo que queríamos: la ruta pasa de proto dhcp a proto static y aparece el dominio de búsqueda. La IP es la misma y los servicios escuchan igual. Si el diff mostrara algo más, tendrías un problema que investigar ahora, no dentro de tres semanas.

Paso 6 — la prueba de fuego, reiniciar:

Una configuración de red no está terminada hasta que sobrevive a un reinicio. Documenta el cambio en /opt/tramontana/HISTORIAL, como todo lo demás.

• Tabuladores en el YAML. Es, con diferencia, el error número uno. Configura tu editor para que en .yaml inserte espacios (:set expandtab en vim) y ejecuta siempre netplan generate antes de aplicar.
• Olvidar el CIDR en addresses. - 10.0.2.15 sin /24 da un error de validación poco claro. La dirección siempre lleva su máscara.
• Usar netplan apply en una máquina remota. Si te equivocas, solo la recuperas por consola física o del hipervisor. netplan try cuesta lo mismo y perdona.
• Editar /etc/resolv.conf. Es un enlace a un fichero generado: tu cambio dura hasta el siguiente arranque. El DNS se cambia en netplan y se comprueba con resolvectl status.
• Dejar activo el fichero de cloud-init. Puede reescribir tu configuración en el arranque; desactívalo con 99-disable-network-config.cfg.
• Asignar una IP estática dentro del rango del DHCP. Tarde o temprano el servidor DHCP se la da a otro y tienes un conflicto intermitente y desesperante. Pide una reserva o un rango excluido.
• Consejo: guarda /etc/netplan/ en git junto a tus scripts. Es configuración de producción y merece historial, igual que las unidades de systemd.

Advertencia de seguridad y compliance: un cambio de direccionamiento en un servidor que trata datos personales de huéspedes afecta a reglas de cortafuegos, listas de control de acceso y registros de auditoría. En un entorno real se planifica con ventana de mantenimiento, se comunica a las personas responsables y lo revisa el responsable de seguridad. Nunca reconfigures ni escanees redes que no sean tuyas: aquí todo se hace sobre srv-tramontana, tu propia VM.

1. Doble comprobación antes de aplicar. Escribe la secuencia exacta de comandos para cambiar el DNS de srv-tramontana de 10.0.2.2 a 192.0.2.53, desde una sesión SSH, sin arriesgarte a perder la resolución de nombres. Incluye la verificación posterior.
2. Segunda dirección y ruta estática. Añade a enp0s3 la dirección 10.0.2.16/24 y una ruta hacia 198.51.100.0/24 a través de 10.0.2.9, de forma persistente. Después demuestra, sin generar tráfico real, que un paquete a 198.51.100.7 saldrá por esa ruta y no por la de defecto.
3. Diagnóstico de un YAML roto. Al aplicar tu configuración obtienes Error in network definition: enp0s3: unknown key 'gateway4'. Explica qué ha pasado, corrígelo y di por qué netplan no ha dejado la máquina sin red.

1. Un DNS que no responde deja la máquina «funcionando y muda», así que se trata con el mismo procedimiento que la IP:

Verificación desde la sesión de seguridad, antes de pulsar ENTER:

Dos detalles: la copia va a /root y no a /etc/netplan/, porque cualquier fichero .yaml de ese directorio se lee (con .bak-fecha no lo sería, pero es mejor no depender de eso); y si el DNS nuevo no respondiera, netplan try revierte solo a los 120 segundos.

2. Se añade la dirección a la lista y la ruta al bloque routes:

ip route get interroga la tabla de rutas del kernel sin enviar ningún paquete: es la demostración exacta que pedía el enunciado. Si hubiera devuelto via 10.0.2.2, la ruta estática no se habría aplicado.

3. gateway4 era la clave clásica para la puerta de enlace y está eliminada en las versiones de netplan de Ubuntu 24.04. Su sustituto es una entrada en routes:

El cambio se hizo porque gateway4 solo permitía una puerta de enlace y no admitía métricas ni tablas alternativas; routes cubre todos los casos con la misma sintaxis. Y la máquina no se ha quedado sin red porque el error lo detectó el analizador de netplan en la fase de generate, antes de tocar nada: la configuración solo llega al kernel si el YAML es válido en su totalidad. Ese es exactamente el motivo por el que netplan generate va siempre antes que netplan try: separa los errores de sintaxis (baratos) de los de contenido (caros).

srv-tramontana ya no depende de un servidor DHCP para tener la dirección que su propio nombre de servicio anuncia. Has dejado la red escrita, versionada y verificada: un fichero de netplan con permisos 600, IP estática 10.0.2.15/24, puerta de enlace 10.0.2.2, DNS y dominio de búsqueda declarados, resolución a través de systemd-resolved y un procedimiento —medir, generate, try, comparar con diff -u, reiniciar— que puedes repetir en cualquier máquina sin sudar. Por el camino has visto por qué ip sirve para probar y no para configurar, por qué IPv6 se protege en vez de desactivarse, y cómo preguntarle al kernel por dónde saldrá un paquete concreto.

Pero fíjate en lo que acabas de hacer: has fijado una dirección estable y bien conocida para un servidor que acepta conexiones SSH con contraseña, permite entrar como root y ya acumula 47 intentos fallidos desde 203.0.113.44 en /var/log/btmp. Le has puesto un buzón permanente a una puerta que no tiene cerradura. En la lección siguiente, 06-02: SSH y Acceso Remoto, arreglas justamente eso: entenderás las tres fases del protocolo y qué significa de verdad la huella que te pide aceptar la primera vez, generarás claves ed25519, desterrarás la autenticación por contraseña, endurecerás sshd_config directiva por directiva sin quedarte fuera de la máquina, montarás túneles para llegar a la base de datos de Tramontana sin exponerla, y leerás con lastb quién lleva 47 intentos llamando a tu puerta.