Curso intensivo de NetworkManager: nmcli y keyfiles para servidores RHEL

Qué es NetworkManager y si lo estás ejecutando

NetworkManager es el daemon que decide qué hacen tus interfaces de red: qué direcciones llevan, a través de qué gateway enrutan, contra qué servidores DNS resuelven. En la familia RHEL (RHEL y las reconstrucciones comunitarias AlmaLinux y Rocky) es el predeterminado, y desde que se eliminó el paquete network-scripts es la única pila de red que Red Hat admite. Si usas RHEL 8, 9 o 10, o una de sus reconstrucciones, NetworkManager ya se está ejecutando y ya contiene tu configuración, la hayas tocado o no.

Este curso intensivo está escrito para una sola configuración: un servidor dedicado con una dirección IPv4 pública estática, quizá un bloque IPv6 enrutado, sin Wi-Fi, al que solo se accede por SSH. Ese es un caso distinto del portátil que asumen la mayoría de los tutoriales de NetworkManager, así que empezamos por el direccionamiento estático y la herramienta de línea de comandos, nmcli, y tratamos las piezas gráficas como una nota al margen. Al final tendrás un perfil estático de IPv4 e IPv6 que puedes copiar y adaptar, una idea clara de dónde vive la configuración, y suficiente del modelo como para depurarlo cuando un cambio no surta efecto. Los comandos de nmcli aquí son estables entre versiones, así que la versión exacta rara vez importa para lo que sigue; en el momento de escribir esto, la serie estable actual es NetworkManager 1.56 (febrero de 2026). Consulta las notas de la versión para ver qué incluye tu distribución.

Un tema recorre todo esto: en una máquina remota, un error de red te deja bloqueado fuera. El diseño de NetworkManager te da un margen de seguridad aquí, y el acceso a la consola fuera de banda (IPMI, iKVM o una consola serie del proveedor) es el respaldo para cuando ese margen no basta. Ambos aparecen más abajo donde son relevantes.

Supuestos para los ejemplos:

• Una sola interfaz Ethernet, enp1s0. La tuya puede ser eno1, ens3 o similar; nmcli device status muestra el nombre real.
• Acceso root por SSH, o un usuario con sudo.
• Direcciones tomadas de los rangos de documentación de RFC 5737 y RFC 3849, así que nada de esto enruta de verdad. Sustituye tus propios valores en todo el texto.

Dispositivos, perfiles y los dos estados

La mayoría de la confusión con nmcli viene de no ver dos distinciones. Apréndelas y los comandos dejan de parecer arbitrarios.

La primera es dispositivo frente a perfil de conexión. Un dispositivo es el hardware: enp1s0, la NIC física. Un perfil de conexión es un conjunto guardado de ajustes que se puede aplicar a un dispositivo: una dirección, un gateway, DNS y una larga lista de otras propiedades. La relación es de uno a muchos. Un solo dispositivo puede tener varios perfiles guardados (uno estático, uno DHCP, uno para una VLAN de mantenimiento), y solo uno está activo a la vez. Cuando ejecutas nmcli con up, estás eligiendo qué perfil guardado debe llevar puesto el dispositivo en ese momento. Así que "configurar la red" en NetworkManager son dos pasos: editar un perfil y luego activarlo.

La segunda es estado guardado frente a estado en ejecución. Editar un perfil con nmcli con mod escribe en disco. No toca la interfaz activa. La interfaz conserva lo que recibió la última vez que se activó su perfil actual, hasta que lo actives de nuevo. Ese desfase no es una rareza que sortear; es la característica de seguridad. Puedes reescribir la dirección, el gateway o una ruta en el perfil que lleva tu sesión SSH, leer exactamente lo que cambiaste, y solo entonces confirmarlo reactivando. Nada de lo que escribiste llega a la red hasta ese momento.

Con las dos ideas juntas, el flujo de trabajo se lee con claridad. Elige o crea un perfil. Modifica sus propiedades, que queda guardado pero inerte. Actívalo, que es lo que se pone en marcha. Todo lo que viene después es cuestión de qué propiedades y qué flags.

Dónde vive la configuración y la historia de ifcfg

Los perfiles guardados son keyfiles: pequeños archivos de estilo INI bajo /etc/NetworkManager/system-connections/, uno por perfil, cada uno llamado <profile>.nmconnection. Pueden contener secretos como una PSK de Wi-Fi o credenciales 802.1X, así que NetworkManager se niega a leer cualquier archivo que no pertenezca a root y esté restringido al permiso 0600. Un perfil que creas con nmcli obtiene esos permisos automáticamente; un archivo que colocas a mano necesita chown root:root y chmod 600, o el daemon lo ignora.

Si llevas años usando RHEL, recordarás una ubicación distinta: /etc/sysconfig/network-scripts/ifcfg-*. El abandono de esos archivos ocurrió en etapas, y en qué etapa está tu servidor cambia lo que vas a encontrar.

• RHEL 8 declaró obsoleto el servicio heredado network-scripts. NetworkManager pasó a ser el predeterminado y ifup/ifdown se reconectaron para llamarlo, pero el formato predeterminado en disco seguía siendo el antiguo: los nuevos perfiles se escribían como archivos ifcfg-*.
• RHEL 9 invirtió ese predeterminado. Los nuevos perfiles se escriben como keyfiles bajo system-connections/. Los archivos ifcfg-* existentes se siguen leyendo mediante un plugin de compatibilidad, así que una máquina actualizada sigue funcionando, pero el formato quedó formalmente obsoleto y se añadió nmcli connection migrate para convertir los perfiles.
• RHEL 10, publicado en mayo de 2025, terminó el trabajo. El plugin ifcfg desapareció, NetworkManager ignora cualquier cosa en /etc/sysconfig/network-scripts/, y ya no queda conversión in situ en la máquina. Los keyfiles son el único formato que lee.

La conclusión práctica: en cualquier versión desde RHEL 9 en adelante, trata system-connections/*.nmconnection como la fuente de verdad. Una trampa al editar esos archivos directamente es que NetworkManager no vigila el directorio. Después de una edición manual, ejecuta nmcli con reload para releer todos los perfiles, o nmcli con load <path> para uno solo, y luego actívalo. Si te saltas la recarga, el daemon sigue trabajando con la copia que leyó la última vez.

Una configuración estática completa

Aquí tienes un perfil estático completo para enp1s0: una dirección IPv4 y gateway, dos servidores DNS, una dirección y gateway IPv6 estáticos, y autoconnect activado para que vuelva tras un reinicio. Cambia los valores y ejecútalo como un solo comando:

nmcli con add type ethernet con-name static-enp1s0 ifname enp1s0 \
  ipv4.method manual \
  ipv4.addresses 203.0.113.10/24 \
  ipv4.gateway 203.0.113.1 \
  ipv4.dns "1.1.1.1,9.9.9.9" \
  ipv6.method manual \
  ipv6.addresses 2001:db8:2:a::10/64 \
  ipv6.gateway 2001:db8:2:a::1 \
  ipv6.dns "2606:4700:4700::1111" \
  connection.autoconnect yes

ipv4.method manual es lo que lo hace estático; el equivalente DHCP es auto. Las direcciones usan notación CIDR. ipv4.dns acepta una lista separada por comas. La mitad IPv6 refleja la mitad IPv4 propiedad por propiedad, así que un servidor dual-stack es un solo comando en lugar de dos perfiles. connection.autoconnect yes ya es el valor predeterminado, pero indicarlo es un seguro barato contra un perfil que funciona hasta el primer reinicio y luego deja de hacerlo.

con add crea y guarda el perfil. En la mayoría de los servidores aprovisionados, la interfaz ya tiene un perfil activo (a menudo uno DHCP de la instalación), así que todavía no cambia nada en la red. Léelo de vuelta antes de confirmar:

root@server01:~# nmcli -f ipv4.addresses,ipv4.gateway,ipv6.addresses con show static-enp1s0
ipv4.addresses:                         203.0.113.10/24
ipv4.gateway:                           203.0.113.1
ipv6.addresses:                         2001:db8:2:a::10/64

Cuando se lea de vuelta tal como querías, actívalo:

root@server01:~# nmcli con up static-enp1s0

Esta es la línea peligrosa, y el único punto en el que hay que ir despacio. Activar este perfil desactiva lo que estuviera llevando tu sesión. Si el gateway está mal o la dirección choca con otra, el SSH se cae y no vuelve, porque lo que usarías para arreglarlo es justo lo que acabas de romper. Dos hábitos mantienen esto seguro: acertar con los valores leyéndolos de vuelta primero, y tener la consola IPMI o serie del servidor abierta en otra ventana antes de pulsar intro. NetworkManager no deshace por ti un nmcli con up en crudo; la consola es tu deshacer.

Para cambiar una propiedad más adelante, modifica y reactiva:

root@server01:~# nmcli con mod static-enp1s0 ipv4.dns "9.9.9.9"
root@server01:~# nmcli con up static-enp1s0

La línea con mod queda guardada pero inerte. La línea con up es la que lo pone en la red.

Leer lo que sabe NetworkManager

Cuatro comandos responden a casi cualquier pregunta de "qué está pasando".

nmcli device status es lo primero que hay que ejecutar en cualquier servidor. Una línea por interfaz: su tipo, si NetworkManager la gestiona, y qué perfil está activo.

root@server01:~# nmcli device status
DEVICE   TYPE      STATE                   CONNECTION
enp1s0   ethernet  connected               static-enp1s0
lo       loopback  connected (externally)  --

nmcli con show lista los perfiles guardados, activos o no. Añade un nombre para volcar todas las propiedades de un perfil, que es como ves lo que hará un perfil antes de activarlo:

root@server01:~# nmcli con show
NAME            UUID                                  TYPE      DEVICE
static-enp1s0   6d2c8f5a-1e3b-4a7d-9c11-2f0a7b3e5d84  ethernet  enp1s0

El flag -f selecciona campos para que no tengas que desplazarte por doscientas líneas, y -g (get) imprime un solo valor sin cabecera, que es lo que quieres en un script:

root@server01:~# nmcli -g ipv4.addresses con show static-enp1s0
203.0.113.10/24

La salida anterior es ilustrativa; los UUID y el espaciado exacto de columnas varían según la versión y el host.

nmtui para un formulario en lugar de flags

Si prefieres rellenar un formulario antes que recordar nombres de propiedades, nmtui es la interfaz curses del mismo motor. Ejecútalo por SSH o en la consola y tienes tres opciones: editar una conexión, activar una conexión y establecer el hostname del sistema. El editor de conexiones expone el direccionamiento IPv4 e IPv6, DNS, y los campos para bonds, bridges y VLAN, así que una configuración estática es posible sin tocar nmcli en absoluto. Entra directamente con nmtui edit enp1s0 o nmtui connect.

Vale la pena conocer sus límites. nmtui no se puede scriptar, y no expone todas las propiedades: las reglas de enrutamiento, los scripts de dispatcher y los ajustes más oscuros siguen necesitando nmcli o editar el keyfile. Como forma guiada de volver cuando has perdido la red y estás sentado ante una consola, se gana su sitio.

Chuleta de nmcli

Los comandos a los que recurrirás más a menudo, con static-enp1s0 en lugar del nombre de tu perfil:

Quién usa NetworkManager por defecto

Qué pila obtienes es sobre todo consecuencia de la distribución que instalaste, una decisión aparte de esta (cubierta en nuestra guía para elegir una distribución Linux). Así queda repartido en 2026:

La fila de Debian servidor sorprende a la gente. Instalar network-manager en un servidor Debian que ya usa ifupdown no hace que tome el control de las interfaces existentes; todo lo declarado en /etc/network/interfaces se queda con su renderer antiguo y aparece como unmanaged en nmcli. Eso es intencionado, y es el comportamiento seguro por defecto.

VLAN, bonds y bridges

Tres patrones de servidor van más allá de una sola dirección plana. Cada uno es un tipo de perfil, y la sintaxis rima con el ejemplo estático.

Una VLAN pone tráfico etiquetado en una interfaz virtual superpuesta a una física. Esto añade la VLAN 40 sobre enp1s0 con su propia dirección:

nmcli con add type vlan con-name vlan40 ifname enp1s0.40 dev enp1s0 id 40 \
  ipv4.method manual ipv4.addresses 198.51.100.10/24

La enp1s0 padre sigue llevando el tráfico sin etiquetar. El puerto del switch tiene que ser un trunk que deje pasar la VLAN 40, o las tramas etiquetadas no llegan a ningún sitio.

Un bond agrega dos NIC en un solo enlace lógico. LACP (modo 802.3ad) es la opción habitual en servidores para throughput y failover de enlace:

nmcli con add type bond con-name bond0 ifname bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet con-name bond0-p1 ifname eno1 master bond0 slave-type bond
nmcli con add type ethernet con-name bond0-p2 ifname eno2 master bond0 slave-type bond

LACP se negocia, no es unilateral. El switch necesita un grupo de agregación de enlaces correspondiente en esos dos puertos, o el bond se queda caído. Pon el direccionamiento en bond0, nunca en los puertos miembro.

Un bridge convierte el host en un switch virtual, que es lo que necesita un hipervisor KVM para que sus invitados lleguen directamente a la red. La IP del host se traslada al bridge, y la NIC física pasa a ser un puerto sin dirección propia:

nmcli con add type bridge con-name br0 ifname br0 \
  ipv4.method manual ipv4.addresses 203.0.113.10/24 ipv4.gateway 203.0.113.1 ipv4.dns 1.1.1.1
nmcli con add type ethernet con-name br0-port ifname enp1s0 master br0 slave-type bridge

Mover la dirección del host a un bridge por SSH tiene el mismo riesgo de bloqueo que cualquier reactivación, más agudo porque estás reestructurando la interfaz sobre la que viaja la sesión. Constrúyelo desde la consola, o en una segunda NIC por la que no hayas iniciado sesión. Este es el mismo bridge que Proxmox monta como vmbr0; aquí lo construyes a mano.

Solución de problemas

• Un dispositivo aparece como unmanaged. Se le ha dicho a NetworkManager que lo ignore. Busca en /etc/NetworkManager/NetworkManager.conf y /etc/NetworkManager/conf.d/*.conf una línea managed=false o una sección [device-*] con managed=0. En Debian, las interfaces definidas en /etc/network/interfaces aparecen como unmanaged por diseño. Para devolver un dispositivo durante la sesión, nmcli device set enp1s0 managed yes; para que sea permanente, elimina la configuración que lo excluía.
• Un cambio no se aplicó. Casi siempre es una de dos cosas: ejecutaste con mod pero nunca con up, así que la edición está guardada e inerte, o editaste a mano un keyfile y nunca ejecutaste nmcli con reload, así que el daemon sigue con la copia antigua. Ninguna de las dos falla de forma ruidosa. Ambas se resuelven en el momento en que activas.
• Lo guardado y lo activo no coinciden. ip addr y ip route muestran lo que el kernel está haciendo en este momento; nmcli -f all con show <name> muestra lo que hará el perfil la próxima vez que se active. Cuando la dirección en la red no coincide con el perfil, lo que hay pendiente es una activación, no un fallo.
• Nada de lo anterior lo explica. Lee el propio log del daemon: journalctl -u NetworkManager -b para este arranque, o -f para verlo en vivo en una ventana mientras ejecutas con up en otra. NetworkManager es hablador sobre por qué falló una activación, y el motivo suele estar en el último puñado de líneas.

nmstate, la capa declarativa

Para flotas, y para quien prefiera describir el estado final en lugar de emitir pasos, Red Hat distribuye nmstate y su comando nmstatectl. Escribes la red que quieres como YAML, ejecutas nmstatectl apply, y nmstate dirige a NetworkManager (su único backend) para que coincida. Lo que hace que merezca la pena recurrir a él en un servidor remoto es el rollback: aplicas un estado que rompe la conectividad y nmstate revierte por sí solo al anterior, algo que un nmcli con up en crudo no hace. Está disponible en RHEL 8, 9 y 10, y es lo que usa por debajo el system role de RHEL para redes. Para una sola máquina, nmcli basta. Cuando la misma configuración tiene que llegar a cincuenta servidores de forma idéntica y segura, nmstate es la capa hecha para eso.

Ubuntu Server usa Netplan, no NetworkManager

Si además llevas servidores Ubuntu, nada de lo anterior con nmcli se aplica ahí por defecto. Ubuntu Server trae Netplan escribiendo a systemd-networkd, configurado en /etc/netplan/*.yaml, sin NetworkManager en el panorama. Ubuntu Desktop también usa Netplan, pero con NetworkManager como renderer, así que ahí nmcli sí funciona. Los conceptos se mantienen (configuración declarada, un paso de activación, una separación entre guardado y activo), pero la herramienta y los archivos son distintos. El curso intensivo de Netplan es el hermano de esta guía para ese lado del parque de servidores.

Desplegar en Serverside

Un perfil de NetworkManager solo es tan útil como la red a la que apunta. Serverside opera su propia red (AS55285), así que un servidor RHEL, AlmaLinux o Rocky se aprovisiona en menos de un minuto, y la IPv4 e IPv6 públicas que configures quedan detrás de mitigación DDoS activa desde el primer arranque. La línea dedicated de RHEL trae la familia RHEL lista para el flujo de trabajo de nmcli de arriba, y la gama dedicated más amplia cubre el resto.

Para seguir leyendo: el desglose de suscripción AlmaLinux frente a RHEL si estás sopesando una licencia frente a una reconstrucción gratuita, y la checklist de hardening de servidores Linux para ejecutar en cuanto la interfaz esté activa y accesible.

Preguntas frecuentes

¿Por qué mi cambio de IP no sobrevivió a un reinicio?

Tres causas habituales. El perfil tiene autoconnect desactivado, así que nada lo activa al arrancar: pon connection.autoconnect yes. Cambiaste el perfil con nmcli con mod pero nunca ejecutaste nmcli con up, así que la edición se guardó y nunca se aplicó. O editaste a mano el keyfile y nunca ejecutaste nmcli con reload, así que NetworkManager siguió usando la copia que leyó al arrancar. Activar el perfil después del cambio soluciona las tres.

¿Debo editar los archivos .nmconnection a mano o usar nmcli?

Las dos opciones funcionan, y el keyfile es la fuente de verdad en ambos casos. nmcli comprueba los valores que le das y recarga el perfil por ti, así que es la opción más segura por defecto. Si editas el archivo directamente, mantenlo con propietario root y permiso 600, y luego ejecuta nmcli con reload para que el daemon recoja el cambio. NetworkManager no vigila el directorio por su cuenta.

¿Cómo evito que NetworkManager gestione una interfaz?

Para la sesión actual, ejecuta nmcli device set enp1s0 managed no. Para que persista entre reinicios, añade una sección [device-*] con managed=0 a un archivo bajo /etc/NetworkManager/conf.d/. Esto es habitual cuando otra herramienta es dueña de una NIC concreta, o en Debian donde las interfaces definidas en /etc/network/interfaces se dejan sin gestionar a propósito.

¿Sigo teniendo archivos ifcfg en RHEL?

Depende de la versión. RHEL 8 todavía escribía archivos ifcfg por defecto. RHEL 9 lee los existentes pero escribe los perfiles nuevos como keyfiles y marca el formato ifcfg como obsoleto. RHEL 10, desde mayo de 2025, eliminó por completo el plugin ifcfg e ignora esos archivos. En RHEL 9 y 10 los keyfiles bajo /etc/NetworkManager/system-connections son los que cuentan.

¿NetworkManager o systemd-networkd para un servidor?

En la familia RHEL la decisión ya está tomada por ti: NetworkManager es la pila predeterminada y la única compatible, y gestiona el direccionamiento estático de servidor sin problemas. Ubuntu Server va por el otro camino, usando systemd-networkd a través de Netplan. Ambas son de nivel de producción. Usa la que traiga tu distribución en lugar de sustituirla.