Cómo configurar rutas en Linux: método rápido y persistente

¿Cuál es la mejor manera de configurar rutas en Linux?

La mejor manera para la mayoría, y por qué

Quien solo tiene una máquina Linux en casa, con un router del operador y un proveedor de internet, no necesita tocar rutas: NetworkManager en modo gráfico las gestiona por él. Quien administra un servidor único en la nube o físico debería usar Netplan si es Ubuntu/Debian reciente (versiones con Netplan ≥ 0.106) o nmcli si es RHEL, Fedora, Rocky, Alma o derivados. Quien lleva una red con varias VLAN, VRF o políticas de enrutado necesita ip route directo, guardado en un script con systemd unit o en un .network de systemd-networkd, porque ni Netplan ni el editor gráfico de NetworkManager exponen con limpieza tablas de enrutado separadas. El resumen útil: escritorio doméstico → NetworkManager gráfico; servidor único Ubuntu/Debian → Netplan (netplan.io ≥ 0.106); servidor único RHEL/Fedora → nmcli; enrutado complejo → ip route + unidad systemd o .network.

Tres líneas que ahorran una tarde: escritorio → GUI; servidor Ubuntu → Netplan; servidor RHEL → nmcli; red compleja → ip route + script systemd.

Lo que hay que tener antes de tocar nada

Kernel 3.6 o superior instalado: por debajo de esa versión existe la caché de rutas IPv4 (rt_cache) y cambian flags de ip route (rtnetlink_ifinfo), así que comandos modernos no se comportan como en este artículo. La distribución del usuario casi siempre lo cumple; compruébese con uname -r.
Paquete iproute2 instalado, que aporta los comandos ip, ss y bridge. Debian y Ubuntu lo traen por defecto; en sistemas minimalistas se añade con apt install iproute2 y en RHEL con dnf install iproute.
Acceso root o sudo sin contraseña para servicios (sudo -n). Sin esto, cambios persistentes no se aplican al reiniciar.
Nombre real de la interfaz de salida: ip -o link show lo lista en la columna final por línea (eth0, ens3, enp0s3, wlp3s0, según esquema que use udev).
Asunción importante: este artículo trabaja con iproute2 moderno, no con el comando route de net-tools, que está obsoleto desde hace años y no entiende los mismos objetos (tablas, ip rule, multipath ECMP).

Tabla de métodos comparados

Método	Persistencia al reiniciar	Dificultad	Distros por defecto	Policy routing (VRF/ip rule)	IPv6	Multipath ECMP
`ip route` + script systemd	Sí, si el script se ejecuta al arranque	Media-alta	Cualquiera con iproute2	Sí, completo	Sí, con `ip -6 route`	Sí, con `nexthop`
Netplan (Ubuntu/Debian moderno)	Sí, gestionado por netplan	Baja	Ubuntu Server/Desktop, Debian reciente con netplan.io instalado	Limitado vía renderer	Sí, clave `routes:` con `to:` IPv6	Limitado, depende del renderer
nmcli / NetworkManager (RHEL, Fedora, derivados)	Sí, en `connection.nmconnection`	Baja-media	RHEL, Fedora, Rocky, Alma, openSUSE con NetworkManager	Limitado, sin tablas separadas maduras	Sí, con `+ipv6.routes`	No de forma nativa
systemd-networkd `.network`	Sí, recargable con `networkctl reload`	Media	Servidores minimalistas, imágenes cloud, Debian sin NM	Sí, con `[RoutingPolicyRule]`	Sí, en la misma sección	Sí, con varios `[Route]`
`/etc/network/interfaces` (Debian legacy)	Sí, vía `ifupdown`	Media	Debian antiguo, sin Netplan ni NM	Limitado	Sí, con `up ip -6 route add`	No de forma nativa

Las cinco opciones comparten iproute2 por debajo; la diferencia está en quién guarda la configuración y en cuánta negociación permite el formato.

Método 1: ip route en caliente, para probar

Este método sirve para validar una ruta antes de hacerla persistente. Los cambios viven solo en el kernel y desaparecen al reiniciar.

Ver tabla actual con ip route show y nombres reales de interfaces con ip -o link show.
Añadir ruta a una red concreta: ip route add 10.20.0.0/16 via 192.168.1.1 dev eth0. Para IPv6: ip -6 route add 2001:db8:1::/48 via fe80::1 dev eth0.
Comprobar antes de seguir: ip route get 10.20.0.42 y ip -6 route get 2001:db8:1::5. Si devuelve el gateway esperado, la ruta es válida.
Sustituir si ya existía con ip route replace 10.20.0.0/16 via 192.168.1.1 dev eth0. replace la crea si no está y la sobreescribe si existe, sin error.
Borrar cuando ya no haga falta con ip route del 10.20.0.0/16 via 192.168.1.1 dev eth0. Si se modifica sin querer, ip route flush cache limpia la caché de rutas IPv4 cuando el kernel la tiene.

Si el comando responde RTNETLINK answers: No such process, casi siempre el gateway no es alcanzable por esa interfaz; conviene revisar ip link show eth0 antes de añadir nada.

Método 2: Netplan en Ubuntu y derivados

En Ubuntu Server desde la 18.04 y en cualquier Debian con netplan.io instalado, las rutas persistentes viven en /etc/netplan/*.yaml.

Identificar el archivo activo con ls /etc/netplan/ y leerlo con cat. Solo debe haber uno o combinarse en un único fichero; tener dos .yaml activos solapa la configuración.
Editarlo con permisos root y añadir el bloque routes: dentro del ethernets: correspondiente, con sangrado de dos espacios. Ejemplo:

network:
  version: 2
  ethernets:
    ens3:
      addresses: [192.168.1.50/24]
      routes:
        - to: 10.20.0.0/16
          via: 192.168.1.1
          metric: 100
        - to: default
          via: 192.168.1.1
          metric: 200

Validar primero: sudo netplan try deja el cambio activo 120 segundos y lo revierte si se desconecta la sesión SSH, según la documentación oficial de Netplan.
Aplicar de forma definitiva con sudo netplan apply. Comprobar con ip route show que la ruta aparece con la métrica indicada.
Para IPv6, mismo esquema con to: 2001:db8:1::/48 y via: fe80::1 en direcciones locales de enlace, o la pasarela global si la red la publica.

La trampa más frecuente de YAML es la indentación: las claves routes: y via: deben estar alineadas con dos espacios bajo addresses:. Un espacio extra rompe el parseo sin mensaje claro; netplan try lo detecta antes de aplicarlo.

Método 3: nmcli en RHEL, Fedora y clones

En RHEL, Fedora, Rocky, Alma, openSUSE con NetworkManager y derivados, las rutas se guardan en el perfil de conexión, y nmcli es la forma reproducible de tocarlas.

Listar perfiles: nmcli -t -f NAME,UUID,DEVICE con show --active devuelve el nombre real, que no siempre coincide con el de la interfaz.
Añadir IPv4 persistente: sudo nmcli con modify "ens3" +ipv4.routes "10.20.0.0/16 192.168.1.1 100". El último número es la métrica; si se omite, NetworkManager la asigna.
Añadir IPv6 con sudo nmcli con modify "ens3" +ipv6.routes "2001:db8:1::/48 fe80::1 100".
Aplicar sin reiniciar la interfaz: sudo nmcli con up "ens3".
Verificar lo que está realmente guardado en la conexión con nmcli -f ipv4.routes,ipv6.routes con show "ens3". Esto muestra exactamente la cadena to via metric que NetworkManager traducirá a ip route.

Si se usa NetworkManager en modo gráfico (nmtui o el applet), lo que se escriba desde ahí acaba en el mismo perfil; nmcli simplemente expone la misma estructura. La documentación de nmcli describe cada modificador.

Método 4: systemd-networkd y .network

Conviene en servidores minimalistas, imágenes en la nube y sistemas que no quieren NetworkManager encima.

Habilitar el servicio con sudo systemctl enable --now systemd-networkd, según la documentación de systemd-networkd.
Crear /etc/systemd/network/10-ens3.network con una unidad parecida a:

[Match]
Name=ens3

[Network]
Address=192.168.1.50/24
Gateway=192.168.1.1

[Route]
Destination=10.20.0.0/16
Gateway=192.168.1.1

Para IPv6, añadir otra entrada [Route] con Destination=2001:db8:1::/48 y Gateway=fe80::1.
Aplicar con sudo networkctl reload o reiniciar la interfaz concreta con sudo networkctl reconfigure ens3.
Verificar con networkctl status ens3 y ip route show para confirmar que la ruta aparece tras networkctl reload.

Una unidad .network puede combinar Address, Gateway y varias [Route] con multipath repitiendo Gateway= varias veces en la misma sección, según la página de manual de systemd.network.

Comprobar que la ruta funciona y se mantiene

Probar resolución real con ip route get 10.20.0.42 y ip -6 route get 2001:db8:1::5; ambos deben devolver el gateway configurado.
Medir el camino con traceroute -n 10.20.0.42 o traceroute6 -n 2001:db8:1::5; el primer salto debe ser el gateway de la ruta añadida.
Confirmar el otro extremo haciendo ping -c 4 <IP_destino> y ping6 -c 4 <IPv6_destino> con paquetes pequeños; fallos aquí suelen indicar firewall, no enrutado.
Reiniciar con sudo reboot y, tras el arranque, repetir ip route show y networkctl status ens3 o nmcli -f ipv4.routes con show "ens3" para confirmar persistencia.
Si tras el reinicio la ruta ha desaparecido, casi siempre falta la métrica, hay un archivo YAML con sangrado roto o NetworkManager tomó el control por encima del .network.

Síntoma	Causa probable	Solución
Ruta añadida pero ping falla al primer salto	Gateway inalcanzable por esa interfaz	Revisar con `ip link show eth0` que la interfaz está UP y en la misma subred que `via`
Ruta desaparece tras reinicio	Cambio hecho con `ip route add` directo	Mover la ruta a Netplan, `nmcli con modify` o `.network`
`netplan apply` devuelve error de parseo	Indentación YAML incorrecta	Corregir espacios y validar con `netplan generate` antes de aplicar
`nmcli con up` desconecta la sesión SSH	Se cambió la ruta por defecto (`0.0.0.0/0`)	Cambiar métrica por defecto mayor que la actual y aplicar con `netplan try` o script temporal
`RTNETLINK answers: File exists` al añadir ruta	Ruta duplicada	Usar `ip route replace` o `ip route del` antes de `add`

Si tras estos pasos la ruta sigue sin llegar al destino, el problema no es Linux: es el firewall, el MTU del túnel o la pasarela del otro lado. La capa de red local queda validada. Datos comprobados en octubre de 2026.

Preguntas frecuentes sobre configurar rutas en Linux

1. ¿Cómo añadir una ruta en Linux para que sobreviva a un reinicio?

Depende del sabor de red que tengas. En sistemas con NetworkManager edita el archivo de la interfaz en /etc/NetworkManager/system-connections/ y añade una sección ipv4.routes con la red de destino, el prefijo y el next hop; en distribuciones con netplan (Ubuntu 22.04 y posteriores) declara routes dentro de la interfaz en /etc/netplan/*.yaml. En RHEL 9 y clones con NetworkManager puedes crear la ruta con nmcli connection modify y luego recargar con nmcli connection up, lo que la deja persistente automáticamente.

2. ¿Cómo dejo una ruta estática permanente en RHEL 9?

La forma más limpia en RHEL 9 es con nmcli: ejecuta nmcli connection modify "nombre_conexion" +ipv4.routes "10.10.0.0/16 192.168.1.1" y guarda con nmcli connection up "nombre_conexion"; el cambio queda escrito en el archivo de la conexión, así que aguanta reinicios. Si prefieres un archivo manual, NetworkManager sigue leyendo los scripts de ruta desde /etc/sysconfig/network-scripts/route-ifname con el formato ADDRESS0=10.10.0.0 NETMASK0=255.255.0.0 GATEWAY0=192.168.1.1.

3. ¿Por qué me aparece el error «nexthop has invalid gateway»?

El kernel rechaza la ruta porque el gateway que le pasas no es alcanzable desde ninguna interfaz local: suele pasar si el next hop está en una subred distinta a la que tiene tu equipo o si escribes la IP al revés. También aparece cuando el gateway es 0.0.0.0 en una ruta que no es la default. Revisa con ip route get 8.8.8.8 que el kernel sepa llegar al gateway antes de añadirlo con ip route add.

Fuentes

ServerspaceHow to Set Up Routing in Linux: Add, View, and Configure Routesconsultado el 19/10/2026
DatahackerLinux Network Routing Best Practices – datahackerconsultado el 19/10/2026
Ss64ip route Man Page – Linux – SS64consultado el 19/10/2026
SdnLinux Routing Fundamentals – SDN Clinicconsultado el 19/10/2026
SpiceworksMake Linux Routes Permenant – Spiceworks Communityconsultado el 19/10/2026