Netplan es una herramienta exclusiva de Ubuntu (introducida en 17.10) que actúa como capa intermedia entre tú y el backend real de red: o bien NetworkManager o bien systemd-networkd. Escribes un archivo YAML en /etc/netplan/ describiendo lo que quieres —una IP estática, un bond, una VLAN— y Netplan genera la configuración nativa del backend y la aplica. No es un daemon ni un gestor de red por sí mismo; es un traductor.
El diseño responde a un problema concreto de Ubuntu: quería usar NetworkManager en escritorio (con su integración gráfica y gestión de perfiles por usuario) y systemd-networkd en servidores (más ligero, sin dependencias de D-Bus para uso interactivo), pero mantener una sintaxis de configuración unificada. En lugar de duplicar documentación y herramientas, Canonical introdujo esta capa YAML que compila hacia cualquiera de los dos. El precio es una indirección extra: cuando algo falla, tienes que rastrear si el error está en el YAML de Netplan, en la configuración generada para el backend, o en el backend mismo.
¿Cuándo lo usas? Siempre que configures red en Ubuntu 18.04 o posterior en un servidor o VM. Ignorar Netplan y tocar directamente /etc/network/interfaces funciona en algunos casos, pero las versiones recientes de Ubuntu ya no garantizan que ese archivo se procese correctamente si Netplan está activo.
Si llegas de Debian, el contraste es directo: Debian configura la red sin intermediarios. En un servidor Debian usas /etc/network/interfaces gestionado por ifupdown, o directamente archivos en /etc/systemd/network/ si prefieres systemd-networkd, o NetworkManager si instalaste entorno gráfico. No hay YAML de abstracción. Netplan no existe en Debian y no tiene equivalente —no lo necesita, porque Debian no tiene que reconciliar dos backends con una interfaz unificada para millones de usuarios con perfiles de uso muy distintos. Cuando ves un tutorial que dice “edita /etc/netplan/“, ese tutorial es para Ubuntu; en Debian ese directorio no existe.
Lo que rompe si te equivocas: un YAML con errores de sintaxis o de lógica (como una máscara de red mal expresada) puede dejarte sin red tras un reinicio. Por eso existe netplan try: aplica la configuración durante 120 segundos y, si no confirmas explícitamente, revierte automáticamente. Es la diferencia entre perder acceso SSH a una máquina remota y recuperarla sola.
Ejemplo: servidor Ubuntu con IP estática, DNS y ruta adicional
El escenario es una VM Ubuntu 22.04 LTS usada como servidor, con una sola interfaz (ens3), que necesita IP fija, resolver DNS corporativo y una ruta estática hacia una red interna.
# /etc/netplan/01-servidor.yaml
#
# Convención de nombres: el prefijo numérico determina el orden de
# procesamiento cuando hay varios archivos en /etc/netplan/.
# Ubuntu Cloud suele generar un 00-installer-config.yaml o similar;
# renombrar o eliminar ese archivo antes de crear el tuyo evita conflictos.
network:
version: 2
renderer: networkd # backend: systemd-networkd, apropiado para servidor sin entorno gráfico
ethernets:
ens3:
dhcp4: false # desactivamos DHCP explícitamente; si lo omites, el default es false
dhcp6: false
addresses:
- 192.168.10.50/24 # notación CIDR; Netplan no acepta máscara separada como "255.255.255.0"
routes:
- to: default
via: 192.168.10.1 # puerta de enlace predeterminada
- to: 10.8.0.0/16
via: 192.168.10.254 # ruta estática hacia red interna a través de router secundario
nameservers:
addresses:
- 192.168.10.5
- 1.1.1.1 # fallback externo
search:
- corp.ejemplo.com # dominio de búsqueda; afecta a resolución de nombres cortos
# Validar sintaxis antes de tocar nada sudo netplan generate # Probar con rollback automático: si en 120 s no ejecutas "netplan apply", # la configuración anterior se restaura sola — imprescindible en servidores remotos sudo netplan try # Si la conexión se mantiene y todo va bien, confirmar: # (netplan try lo solicita interactivamente; también puedes hacerlo así:) sudo netplan apply # Verificar que systemd-networkd recibió la configuración generada sudo networkctl status ens3 # Comprobar rutas activas ip route show
Qué está pasando en cada decisión
renderer: networkd es la elección correcta en un servidor sin entorno gráfico. Si lo cambias a NetworkManager, necesitas que ese daemon esté corriendo, lo que en una instalación server mínima puede no ser el caso. En instalaciones de escritorio Ubuntu, el renderer por defecto ya es NetworkManager y puedes omitir la línea; en servidor, escríbela explícitamente para evitar que cambie si instalas paquetes de escritorio más adelante.
El archivo generado por Netplan para systemd-networkd acaba en /run/systemd/network/ —no en /etc/systemd/network/— y es efímero: se regenera cada vez que ejecutas netplan apply. Nunca edites esos archivos directamente; los cambios se perderán en la siguiente aplicación.
to: default en el bloque routes es la forma moderna de declarar la gateway predeterminada en Netplan v2. La clave gateway4 todavía funciona en Ubuntu 22.04 pero está deprecada y produce advertencias; la verás en documentación antigua o en configuraciones generadas por el instalador.
La ruta 10.8.0.0/16 via 192.168.10.254 demuestra que puedes tener múltiples entradas en routes. Netplan las pasa todas a networkd, que las instala en la tabla de routing del kernel. Puedes verificarlo con ip route show o ip route show table all si usas routing policy.
netplan generate sin apply es el paso de validación que más se salta y más se necesita. Genera los archivos del backend en /run/systemd/network/ sin activarlos; si hay errores de esquema YAML o valores inválidos, los verás aquí sin afectar la red activa. En un pipeline de automatización (Ansible, cloud-init), siempre conviene ejecutarlo primero como dry-run antes de apply.
El dominio en search merece atención: corp.ejemplo.com hace que el resolver intente host.corp.ejemplo.com cuando haces ping a host a secas. En entornos con muchos dominios de búsqueda esto puede ralentizar la resolución porque el sistema prueba cada sufijo en orden antes de intentar el nombre como FQDN. Mantén la lista corta.
[Ubuntu]: Todo lo de este artículo es exclusivo de Ubuntu. En Debian no existe /etc/netplan/, no hay paquete netplan.io en los repositorios estables, y la red se configura directamente mediante /etc/network/interfaces con ifupdown, o con archivos .network en /etc/systemd/network/ si usas systemd-networkd explícitamente.