Curso intensivo de Netplan para servidores dedicados Ubuntu

Qué es Netplan, y si lo estás usando

Netplan es la capa de configuración de red que Ubuntu incluye por defecto desde la 17.10. Escribes tus interfaces, direcciones, rutas y DNS como YAML en /etc/netplan/, y un generador convierte esa única descripción en configuración para el backend que sea el que maneje la red por debajo: systemd-networkd en Ubuntu Server, NetworkManager en Ubuntu Desktop. Editas un solo formato de archivo; Netplan renderiza debajo la configuración específica del backend.

Si alquilaste un servidor dedicado e instalaste Ubuntu en él, tienes Netplan. Esta guía está escrita para exactamente esa máquina: un servidor, una dirección IPv4 pública estática (y a menudo una asignación IPv6), sin Wi-Fi, y SSH como único punto de acceso. Ese último detalle marca el tono de todo el artículo, porque un error de red en un servidor remoto es exactamente cómo te quedas fuera de él. Netplan tiene una herramienta específica para evitar que eso pase, y nos apoyamos en ella cada vez que cambiamos algo en caliente.

El curso intensivo cubre:

• dónde viven los archivos de configuración, y la regla de permisos con la que tropieza la gente
• el modelo de dos backends, y qué cambia cuando copias configuración de un tutorial escrito para el otro
• una configuración estática IPv4 e IPv6 completa que puedes adaptar línea por línea
• los comandos que usas en el día a día: generate, try, apply y status
• VLANs, bonds LACP, y un bridge para hosts de VM
• por qué tus cambios a veces desaparecen tras un reinicio, y el ajuste de cloud-init que lo soluciona

Una nota rápida sobre versiones. Ubuntu 26.04 LTS «Resolute Raccoon», publicada el 23 de abril de 2026, trae la serie Netplan 1.2. La LTS anterior, 24.04 «Noble Numbat», traía Netplan 1.0, la primera versión estable, fechada el 29 de febrero de 2024. La serie upstream es la 1.2.x en el momento de escribir esto; consulta la página de releases para la versión actual. Todo lo de aquí se aplica a ambas, con las diferencias señaladas donde ocurren. Si todavía estás eligiendo qué versión ejecutar, la guía de LTS de Ubuntu Server cubre los plazos de soporte.

Dónde vive la configuración

Todo archivo *.yaml en /etc/netplan/ cuenta. Otros dos directorios también participan: /run/netplan/ para configuración en tiempo de ejecución y /lib/netplan/ para valores por defecto del proveedor. Los archivos se leen en orden lexicográfico por nombre y se combinan en un solo modelo. Cuando la misma clave se define dos veces, gana el archivo leído después. Si existe un archivo con el mismo nombre en más de un directorio, la copia en /run/netplan/ tiene prioridad sobre /etc/netplan/, que a su vez tiene prioridad sobre /lib/netplan/.

Este orden es la razón por la que un archivo llamado 50-cloud-init.yaml importa. En la mayoría de las imágenes de cloud y de servidor dedicado, cloud-init escribe tu configuración de red inicial exactamente en ese archivo, y su prefijo 50- queda pronto en el orden de clasificación. Coloca tu propio 90-static.yaml al lado y el tuyo gana la fusión, pero cloud-init puede reescribir su propio archivo en el siguiente arranque y deshacer las suposiciones que hiciste. La solución limpia llega más abajo, en la resolución de problemas. Por ahora, ten en cuenta que 50-cloud-init.yaml está generado, no escrito a mano, y trátalo como tal.

Hay una regla que pilla a casi todo el mundo al menos una vez. Todo archivo bajo /etc/netplan/ debería pertenecer a root y ser legible solo por root, modo 600. Netplan guarda en estos archivos credenciales como contraseñas Wi-Fi y claves de túnel, así que una config legible por cualquiera filtra secretos. Desde la versión 0.106, la herramienta muestra un aviso en cuanto encuentra un archivo que puede leer alguien más aparte de root:

** (generate:1234): WARNING **: Permissions for /etc/netplan/50-cloud-init.yaml
are too open. Netplan configuration should NOT be accessible by others.

Arréglalo con un solo comando:

chmod 600 /etc/netplan/*.yaml

Ese aviso es fácil de ignorar porque la red sigue funcionando, pero ajustar los permisos forma parte de cualquier ronda de hardening del servidor y no cuesta nada.

Una fuente YAML, dos backends

Netplan en sí no gestiona ninguna interfaz directamente. Genera configuración para un renderer, y es el renderer el que hace el trabajo. Hay dos, y cuál se ejecuta por defecto depende de cómo se instaló Ubuntu:

En un servidor rara vez cambias esto. systemd-networkd arranca pronto en el proceso de arranque, no tiene dependencias gráficas, y es el backend correcto para una máquina a la que accedes por SSH. Puedes nombrarlo explícitamente con renderer: networkd al principio del archivo, aunque en Ubuntu Server ya es el valor por defecto.

Por qué importa esta distinción: una configuración que copias de un tutorial orientado a escritorio puede definir renderer: NetworkManager o depender de claves exclusivas de NetworkManager, y se comportará de forma distinta, o se negará a aplicarse, en un servidor networkd. Cuando tomes prestado un fragmento, comprueba qué backend asume antes de pegarlo.

Una configuración estática completa

Aquí tienes una configuración estática completa para una sola interfaz, con IPv4 e IPv6. Asigna las direcciones, define las rutas por defecto y configura el DNS. Los nombres de interfaz en un Ubuntu moderno siguen el esquema predecible, así que la tuya probablemente se llame enp1s0, eno1, o algo parecido; ejecuta ip -br link para ver cómo la llama tu kernel.

# /etc/netplan/90-static.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.0.2.10/24
        - "2001:db8::10/64"
      routes:
        - to: default
          via: 192.0.2.1
        - to: default
          via: "2001:db8::1"
      nameservers:
        addresses:
          - 192.0.2.53
          - 2001:db8::53
        search:
          - example.com

version: 2 es la versión de formato de Netplan y es obligatoria. dhcp4: false ya es el valor por defecto en cuanto proporcionas direcciones estáticas, pero indicarlo explícitamente deja clara tu intención para la próxima persona que lea esto. Cada dirección lleva su longitud de prefijo en formato CIDR. El bloque routes es la parte que merece leerse dos veces.

Encontrarás tutoriales antiguos que definen la puerta de enlace así:

      gateway4: 192.0.2.1

Esa clave está deprecated. Netplan avisa contra gateway4 y gateway6 desde la versión 0.103, y el mensaje es directo:

gateway4 has been deprecated, use default routes instead.

El reemplazo es la entrada routes con to: default, exactamente como en el ejemplo completo de arriba. Hace el mismo trabajo, funciona para IPv4 e IPv6 mediante un único mecanismo, y te permite añadir más adelante rutas que no sean la de por defecto sin cambiar de estilo. Úsala, y sáltate gateway4 aunque todavía funcione.

No reutilices tal cual las IP y los nombres de interfaz que se muestran aquí. Las direcciones vienen de los rangos TEST-NET y de documentación reservados para ejemplos; sustitúyelas por los valores que te dio tu proveedor.

El conjunto de comandos: generate, try, apply

Netplan no le hace nada a tu red activa hasta que ejecutas uno de tres comandos. Conocer la diferencia entre ellos es lo que mantiene viva una sesión remota.

netplan generate renderiza tu YAML en configuración de backend bajo /run/systemd/network/ (para networkd) sin tocar la red en ejecución. También hace de validador: si tu YAML tiene un error de sintaxis o una clave desconocida, generate falla y te dice dónde, y todavía no ha cambiado nada. Ejecútalo primero siempre que tengas dudas.

El comando que cambia el sistema activo es netplan apply. Regenera la config y luego la aplica de golpe, reconfigurando la interfaz al momento cuando cambia una dirección estática. En una máquina remota el peligro es inmediato: si la nueva config está mal, acabas de cortar tu propia sesión SSH, y no hay deshacer posible desde donde estás sentado.

netplan try es la respuesta a ese peligro, y en un servidor remoto es el comando al que recurrir por defecto. Aplica la configuración y luego inicia una cuenta atrás; si no confirmas dentro del plazo, revierte el cambio al estado anterior. El plazo por defecto es de 120 segundos, ajustable con --timeout:

netplan try --timeout 90

Pulsa Enter para conservar el cambio, o espera y deja que revierta. Si tu nueva config rompe la conectividad, pierdes la sesión, nunca confirmas, y dos minutos después el servidor ha restaurado la configuración que funcionaba y tu SSH vuelve a estar accesible. Esa reversión automática es todo el sentido del comando. No es infalible: algunos cambios que implican renombrar interfaces o ciertas transiciones de backend no revierten limpiamente, y ahí es donde un servidor dedicado con consola IPMI o iKVM demuestra su valor. El acceso por consola fuera de banda es el respaldo para el día en que try no pueda salvarte, y vale la pena confirmar que lo tienes antes de necesitarlo.

Una vez que la red está activa, netplan status te muestra lo que el backend hizo con tu config:

     Online state: online
    DNS Addresses: 192.0.2.53
       DNS Search: example.com

●  2: enp1s0 ethernet UP (networkd: enp1s0)
      MAC Address: 52:54:00:11:22:33
        Addresses: 192.0.2.10/24
                   2001:db8::10/64
           Routes: default via 192.0.2.1 (static)
                   default via 2001:db8::1 (static)

(La salida es ilustrativa.) netplan status llegó en la versión 0.106. Desde la 1.0 en adelante, netplan status --diff también muestra dónde el estado en ejecución difiere de tu YAML, lo que es la forma más rápida de detectar una config que se generó pero no se aplicó del todo.

Dos comandos más leen y escriben el modelo combinado sin abrir un editor. netplan get imprime la configuración actual como YAML, y netplan set cambia un solo valor mediante una ruta con puntos:

netplan get ethernets.enp1s0.addresses
netplan set ethernets.enp1s0.dhcp4=false

netplan set escribe por defecto en /etc/netplan/90-netplan-set.yaml, lo cual es útil para scripts y confuso si olvidas que lo hace; revisa ese archivo si un valor aparece de la nada.

Chuleta

Las tareas que repites, y el fragmento YAML o comando para cada una:

VLANs, bonds y bridges

Hay tres construcciones que aparecen en servidores con suficiente frecuencia como para tenerlas a mano. Cada una se apoya en el mismo archivo; los tipos de interfaz pasan a su propio bloque de nivel superior.

Un VLAN etiquetado en un uplink

Cuando tu proveedor te da un VLAN etiquetado para una red privada, defínelo como una entrada vlans que referencia la interfaz física mediante su link:

network:
  version: 2
  ethernets:
    enp1s0: {}
  vlans:
    enp1s0.100:
      id: 100
      link: enp1s0
      addresses:
        - 198.51.100.10/24

El id es la etiqueta 802.1Q, y link nombra la interfaz padre, que permanece definida (aquí con un {} vacío) para que Netplan la active. El tráfico sin etiquetar sigue usando la interfaz padre; las tramas etiquetadas para el VLAN 100 viajan por la nueva interfaz lógica.

Dos NIC en bond con LACP

Un bond agrega varios enlaces en una sola interfaz lógica, por ancho de banda o redundancia. El modo 802.3ad es LACP, y exige que el lado del switch esté configurado a juego:

network:
  version: 2
  ethernets:
    eno1: {}
    eno2: {}
  bonds:
    bond0:
      interfaces: [eno1, eno2]
      addresses:
        - 192.0.2.20/24
      routes:
        - to: default
          via: 192.0.2.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100

LACP es un acuerdo entre dos extremos. Si los puertos del switch aguas arriba no están en un grupo LACP que coincida, el bond no levantará, así que coordínate con quien administre el switch antes de aplicar esto.

Un bridge para máquinas virtuales

Si el servidor es un host KVM o LXD, un bridge permite que los invitados compartan la NIC física como si estuvieran conectados a un switch. La dirección del host se traslada al bridge, y la interfaz física se convierte en un puerto del bridge sin dirección propia:

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp1s0]
      addresses:
        - 192.0.2.30/24
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [192.0.2.53]
      parameters:
        stp: false
        forward-delay: 0

Esta es la misma idea que Proxmox implementa con su vmbr0, si te has topado con eso. Desactivar spanning-tree y el forward delay conviene a un bridge de host con un solo uplink; déjalos activados solo cuando el bridge tenga varios puertos físicos que puedan formar un bucle.

Cuando la configuración no surte efecto: resolución de problemas

La mayoría de los problemas de Netplan caen en unas pocas categorías.

Sangría del YAML. El YAML de Netplan usa espacios para la sangría y rechaza los tabuladores sin excepción. Un tabulador perdido, o una sangría inconsistente, produce un error de parseo. Ejecuta netplan generate después de cada cambio: es el validador más barato que tienes, y se niega a escribir una config rota en lugar de aplicarla.

El cambio se generó, pero la interfaz se ve mal. Pregúntale al backend qué hizo en lugar de confiar en el YAML. ip addr e ip route muestran las direcciones y rutas instaladas en el enlace; networkctl status enp1s0 muestra la vista de systemd-networkd; resolvectl status muestra los servidores DNS en vigor. Si netplan status --diff informa de un hueco entre tu archivo y el estado en ejecución, el apply no surtió efecto del todo, y uno de esos comandos te mostrará dónde.

Tus cambios desaparecen tras un reinicio. Esto es el sobrescrito de cloud-init, la sorpresa más común en un servidor dedicado o cloud. cloud-init regenera /etc/netplan/50-cloud-init.yaml en el arranque a partir de su propia fuente de datos, sobrescribiendo todo lo que cree suyo. La solución soportada es decirle a cloud-init, de una vez, que deje de gestionar la red:

echo 'network: {config: disabled}' | \
  tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Después de eso, cloud-init deja /etc/netplan/ en paz y tu propio archivo se convierte en la única fuente de verdad. Después puedes borrar o reescribir 50-cloud-init.yaml y seguirá siendo así. Haz esto antes de invertir tiempo en una config escrita a mano, no después de haber peleado dos veces con el mismo reinicio.

Cuando no tienes Netplan

Netplan es un valor por defecto de Ubuntu, no una constante universal de Linux. En la familia RHEL (RHEL, AlmaLinux, Rocky) y en la mayoría de las distribuciones de escritorio, no hay capa Netplan: NetworkManager gestiona las interfaces directamente, y lo configuras con nmcli, nmtui, o archivos de conexión. Si tu flota es mixta, el curso intensivo de NetworkManager que lo acompaña cubre ese lado con el mismo enfoque de servidor.

Debian es el que casi encaja. El paquete netplan.io está en los repositorios de Debian, así que puedes instalarlo y usarlo, pero Debian no lo usa por defecto; un servidor Debian de serie sigue configurando la red mediante ifupdown y /etc/network/interfaces, o NetworkManager en el escritorio. Si estás sopesando los dos, la comparativa Ubuntu contra Debian repasa dónde encaja cada uno, y la guía de elección de distro más amplia enfrenta Netplan por defecto contra las alternativas.

Desplegar en Serverside

Netplan es tan útil como lo sea la red que hay debajo. Un servidor dedicado de Serverside corre en nuestra propia red (AS55285), así que las direcciones IPv4 e IPv6 estáticas que escribes en ese YAML quedan detrás de un enrutamiento que controlamos, con mitigación DDoS activa permanentemente delante de la interfaz pública. El aprovisionamiento tarda menos de un minuto: un servidor Ubuntu recién creado se despliega en menos de un minuto, una imagen LTS con Netplan ya en su sitio, lista antes de que termines de redactar la config que va a ejecutar.

Preguntas frecuentes

¿Cuál es la diferencia entre netplan apply y netplan try?

netplan apply regenera la configuración del backend y la aplica de inmediato al sistema activo, sin vuelta atrás si eso corta tu conexión. netplan try aplica la misma configuración, pero inicia una cuenta atrás de 120 segundos y revierte el cambio automáticamente a menos que pulses Enter para confirmar. En un servidor remoto, recurre a try cuando cambies algo que pueda afectar al enlace por el que estás conectado, y reserva apply para cambios de los que estés seguro o que hagas desde la consola.

¿Por qué desaparecen mis cambios de red después de un reinicio?

Casi siempre cloud-init. En las imágenes de cloud y de servidor dedicado, cloud-init regenera /etc/netplan/50-cloud-init.yaml en cada arranque a partir de su propia fuente de datos y sobrescribe los cambios que cree suyos. Detenlo creando /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg con el contenido network: {config: disabled}, y gestiona /etc/netplan/ tú mismo a partir de ahí. Después de eso, tus archivos persisten entre reinicios.

¿Cómo configuro los servidores DNS en Netplan?

Añade un bloque nameservers a la interfaz, con una lista addresses y, opcionalmente, una lista search de dominios. Los resolvers se aplican en cuanto ejecutas netplan apply o netplan try, y puedes confirmarlos con resolvectl status. En sistemas systemd-networkd, el DNS lo gestiona systemd-resolved, así que los servidores que definas aparecen ahí en lugar de directamente en /etc/resolv.conf.

¿Es Netplan lo mismo que NetworkManager?

No. Netplan es una capa de configuración que genera config para un backend; NetworkManager es uno de los dos backends a los que puede apuntar, el otro es systemd-networkd. Ubuntu Server usa el backend networkd por defecto, Ubuntu Desktop usa NetworkManager, y ambos se controlan a través del mismo YAML de Netplan. En sistemas sin Netplan, como los servidores de la familia RHEL, configuras NetworkManager directamente en su lugar.

Estoy migrando desde /etc/network/interfaces. ¿Netplan lo sustituye?

Sí, en Ubuntu. La antigua pila ifupdown y su archivo /etc/network/interfaces son lo que Netplan sustituyó cuando Ubuntu lo adoptó en la 17.10. No editas los dos: convierte cada bloque iface en la entrada ethernets de Netplan equivalente, con su dirección, rutas y nameservers, y deja que Netplan genere la config del backend. Debian sigue usando /etc/network/interfaces por defecto, una diferencia a esperar al moverte entre ambos.