Como cambiar la IP en terminal Ubuntu server: ¿así?

IP fija en Ubuntu Server por terminal: Netplan, comandos ip, rutas y DNS, con el punto crítico de cloud-init para no perder acceso por SSH…!

Cambiar la IP de un Ubuntu Server desde la terminal, bien hecho y sin sustos, hoy pasa casi siempre por Netplan: localizar el archivo en /etc/netplan, editar un YAML con la interfaz correcta, y aplicar con netplan try para no quedarte “colgado” si estabas conectado por SSH. Para un ajuste rápido, de esos de apagar fuegos, también existe la vía quirúrgica de ip addr y ip route, útil para probar una red nueva sin tocar todavía la configuración permanente.

En la práctica, el cambio “real” no es solo una cifra distinta al final de una dirección: implica interfaz, prefijo, puerta de enlace y DNS, y en entornos con VPS o nube aparece un actor que manda mucho, cloud-init, capaz de reescribir la red si le dejas el volante. Todo esto, contado sin épica barata: lo que falla, por qué falla, y cómo se deja estable para que no vuelva a ser noticia a la próxima actualización o reinicio.

La escena típica: una IP que se queda pequeña y una ventana de mantenimiento mínima

Hay un momento muy reconocible en infraestructura: un servicio crece, cambias de segmento, te mueves a una VLAN distinta o el proveedor te reasigna rangos, y de pronto esa IP de siempre se convierte en un cuello de botella operativo. No porque la IP “no sirva”, sino porque alrededor han cambiado cosas: un firewall con reglas nuevas, un balanceador que ya apunta a otro sitio, una política de routing que quiere orden, o una migración que exige que el servidor esté en otra red “ya”. Y entonces aparece la búsqueda, directa, casi urgente sin decirlo: como cambiar la ip en terminal ubuntu server.

Ubuntu Server, en versiones modernas, dejó atrás el viejo esquema de “retoque aquí y listo” en /etc/network/interfaces como si el sistema fuese de otra década. El corazón actual suele ser Netplan, que actúa como un traductor: tú describes lo que quieres en YAML y por debajo se lo entrega a systemd-networkd (lo más común en servidor) o a NetworkManager (más habitual en escritorios, aunque aparece en algunos servers por herencia o por necesidad). Ese “por debajo” importa, porque si no sabes quién gobierna la red, puedes estar escribiendo algo impecable… para el motor equivocado.

Aquí conviene mirar antes de tocar. No por ceremonias, sino por supervivencia: saber qué interfaz está viva, qué IP tiene, y por dónde sale el tráfico. Es un vistazo que evita el error clásico de editar ens18 cuando el servidor en realidad usa ens3, o de poner un prefijo mal y dejar la máquina hablando sola.

ip a
ip route

Con eso ya aparecen dos pistas decisivas: la interfaz con estado activo y la ruta por defecto (la línea que empieza por default). Si esa ruta apunta a un gateway que no existe en tu nueva red, el servidor puede tener una IP preciosa… y cero salida. Y cuando la salida cae, caen dependencias, repositorios, registros, monitorización. La cadena no perdona.

Netplan, el YAML y el punto exacto donde la red “se hace permanente”

El cambio que queda para siempre —reinicios incluidos— suele hacerse en /etc/netplan/. Ahí viven archivos con nombres que parecen administrativos, tipo 00-installer-config.yaml, 01-netcfg.yaml, 50-cloud-init.yaml. La clave no es el nombre bonito, es cuál se está usando y si alguno está siendo gestionado por cloud-init.

ls -l /etc/netplan/

Si aparece un 50-cloud-init.yaml, mala palabra no es, pero sí una advertencia: en muchas VPS, cloud-init genera esa configuración y puede rehacerla. Tocar ahí sin saber puede funcionar… hasta que un reinicio devuelve todo al punto de partida. En escenarios estables, suele ser más limpio crear tu propio archivo, con un nombre que “gane” por orden, y dejar claro que esa es la configuración que manda.

El YAML típico para una IP fija en IPv4, con systemd-networkd, se parece a esto. La estructura importa: sangrado, guiones, y que cada línea esté donde toca. YAML no perdona espacios.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: no
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

Aquí hay cuatro piezas que conviene leer como si fueran titulares: la interfaz (ens18), la IP con prefijo (/24 o el que toque), la ruta por defecto (gateway) y los DNS. Cuando algo falla, suele fallar en una de estas cuatro. Un prefijo equivocado es una grieta silenciosa; un gateway mal puesto es una puerta cerrada; unos DNS inexistentes son un servidor que “ve IPs” pero no “entiende nombres”.

Aplicar el cambio es donde se separan los servidores tranquilos de los servidores que te hacen sudar. En remoto, el comando más sensato es netplan try: aplica, te deja un margen para confirmar y, si te quedas sin conexión, revierte solo. Es el equivalente a poner una cuerda extra antes de cruzar el puente.

sudo netplan try

Si todo sigue vivo, confirmas. Si no, el sistema vuelve atrás sin convertir tu madrugada en un ejercicio de telepatía con un panel de emergencia. El atajo de netplan apply existe, funciona y es directo, pero cuando estás conectado por SSH a la IP que estás cambiando, conviene no jugar a la ruleta.

sudo netplan apply

Lo que se ve a menudo en incidentes pequeños es esto: alguien hace apply, cambia la IP, el SSH cae, y luego se descubre que el firewall de la red nueva todavía no permite el puerto 22, o que el gateway era otro. No es una tragedia; es un guion repetido.

El cambio exprés: la IP “de prueba” con iproute2 cuando necesitas aire

Hay momentos en que no quieres casarte con una configuración todavía. Vas a probar, a validar, a comprobar que el rango nuevo responde, a ver si la VLAN está bien etiquetada, a confirmar que el router tiene la ruta. Ahí entra ip, la herramienta que no escribe novelas: actúa y se va.

Para añadir una IP temporal a una interfaz:

sudo ip addr add 192.168.1.50/24 dev ens18

Para retirarla, si te equivocaste o ya no la necesitas:

sudo ip addr del 192.168.1.50/24 dev ens18

Y si el cambio también implica la puerta de enlace, el tráfico puede necesitar un giro completo. La ruta por defecto se puede reemplazar al vuelo:

sudo ip route replace default via 192.168.1.1 dev ens18

Este método tiene un “pero” claro: no es persistente. Reinicias y se pierde. Aun así, como herramienta de verificación es brillante, porque te permite comprobar conectividad sin tocar todavía Netplan, sin pelearte con YAML, sin alterar cómo arrancará el sistema después. Cuando todo encaja, pasas a permanente. Cuando no encaja, el servidor no queda con una configuración rota guardada en piedra.

En servidores con servicios críticos, esta táctica también sirve para una transición cuidadosa: mantener durante un rato la IP antigua y añadir la nueva como secundaria, comprobar que entras por la nueva, y luego retirar la vieja. Es menos “romántico”, más seguro. Y la seguridad, aquí, es no quedarte fuera.

SSH, rutas y el error más humano: cortar la rama donde estás sentado

La mayoría de los cambios de IP “que salen mal” no salen mal por la IP. Salen mal por el camino: estabas dentro por SSH, cambiaste la dirección, y el túnel se desplomó. Hay una lógica cruel: tu sesión depende de la conectividad que estás reconfigurando. Por eso, cuando el cambio es remoto, se vuelve valioso todo lo que reduzca el riesgo: dos sesiones SSH abiertas, una consola de proveedor preparada, y aplicar con netplan try en lugar de lanzarte de cabeza.

El otro punto donde se rompe todo sin hacer ruido es el routing. Puedes tener una IP válida y seguir sin llegar a ninguna parte si la ruta por defecto no apunta a donde debe. El diagnóstico se hace mirando lo básico, sin adornos:

ip route

Si la línea default no coincide con el gateway de tu red, la máquina está, pero no “sale”. Y si “sale” por una interfaz distinta porque hay dos tarjetas de red o una VPN, puede que tú veas conectividad desde dentro pero desde fuera no te vean, o al revés. Es el tipo de confusión que parece paranormal y luego era simplemente una ruta con más prioridad de la que esperabas.

También está el firewall, que no siempre vive “en la red”. A veces vive en el propio servidor, con ufw, con reglas directas de iptables/nftables, con políticas heredadas. Cambias de segmento y, de pronto, tu acceso ya no está permitido desde la subred nueva. La IP cambió; el guardia también cambió de criterio.

DNS, ese detalle que convierte un servidor sano en un servidor “mudo”

Hay fallos que se disfrazan de otra cosa. Ejemplo típico: ping a una IP pública funciona, pero cualquier comando que use un nombre de dominio falla. Se acusa al routing, se acusa al proveedor, se acusa al tiempo. Y era DNS.

En sistemas con systemd-resolved, ver el estado ayuda:

resolvectl status 2>/dev/null || cat /etc/resolv.conf

Si tus DNS no están bien, Netplan puede fijarlos con nameservers. Y si estás en una red corporativa, a veces necesitas DNS internos, y lo que valía en una red doméstica (poner 1.1.1.1 y 8.8.8.8 y a correr) aquí no sirve porque hay nombres privados, zonas internas, servicios que solo existen dentro. Sin resolver nombres internos, el servidor puede seguir “vivo” a nivel IP, pero se queda ciego a medio mundo de su propia infraestructura.

Hay otro matiz que se ve bastante en empresas: el DNS funciona para nombres completos, pero no para nombres cortos. Ahí entra el dominio de búsqueda, el sufijo. No es algo para inventar a ojo; se configura cuando existe una política clara en la red. La moral aquí es sencilla: si al cambiar IP cambias de entorno, cambia también el contexto DNS. Y el servidor, si no se lo dices, no lo adivina.

NetworkManager en servidor: cuando el control cambia de manos sin que nadie lo anuncie

Aunque lo típico en Ubuntu Server es systemd-networkd, hay instalaciones donde aparece NetworkManager. Puede ser por una imagen preconfigurada, por una migración, por un servidor que también gestiona Wi-Fi o por decisiones históricas. El síntoma suele ser que Netplan tiene renderer: NetworkManager o que nmcli está disponible y activo.

nmcli -t general status 2>/dev/null

En ese caso, puedes seguir usando Netplan como capa superior, sí, pero también puedes cambiar la IP con nmcli a nivel de conexión. Es práctico, sobre todo cuando hay perfiles, varias redes o cambios frecuentes. Un ejemplo, sin convertirlo en recetario infinito, sería localizar la conexión y fijar método manual, IP, gateway y DNS, y luego levantarla. Lo importante no es memorizar comandos, sino entender el mapa: perfil de red que define parámetros, y activación del perfil.

Aquí conviene una precaución fina: mezclar herramientas sin saber quién tiene la autoridad real termina en servidores “con dos jefes”. Y en red, dos jefes es conflicto. Si decides que NetworkManager es el motor, mantén coherencia. Si decides que networkd manda, mantén coherencia. El caos suele venir de intentar que todo mande a la vez.

cloud-init: el guion que se reescribe solo y te deja cara de “pero si lo cambié”

En nube, cloud-init no es un adorno. Su trabajo es preparar la instancia: usuarios, llaves, hostname, y a menudo red. Cuando la red la gestiona cloud-init, puede generar un Netplan y aplicarlo. Y cuando reinicias, puede volver a hacerlo. Así que el cambio “manual” se evapora.

La señal más clara suele estar en /etc/netplan/50-cloud-init.yaml. A partir de ahí, el comportamiento depende del proveedor y de cómo esté configurada la imagen. En entornos donde quieres control absoluto, se desactiva la gestión de red de cloud-init y se deja Netplan en manos del administrador. En otros, el proveedor espera que cloud-init siga mandando, porque desde su panel cambian IPs, gateways o DNS y lo aplican al vuelo.

Si se desactiva, se hace con una configuración simple que indica que la red está “disabled” para cloud-init. Esto no es un truco universal; es una decisión de operación. Lo relevante es entender el conflicto: si cloud-init reescribe y tú editas, estás luchando contra un generador automático. El servidor no está “haciendo lo que quiere”; está obedeciendo a otro guion.

Una forma más suave, cuando no quieres tocar cloud-init todavía, es crear un archivo Netplan propio y comprobar si realmente gana sin chocar. En algunos casos funciona bien; en otros, al definir la misma interfaz en dos archivos, terminas con un resultado inesperado. Netplan combina, sí, pero combinar no siempre significa “gana el último” de forma intuitiva. Por eso, en cambios delicados, se prueba con cuidado y con rollback disponible.

IPv6: el invitado silencioso que a veces ya estaba gestionando parte del tráfico

En muchas instalaciones, IPv6 está ahí aunque no se use conscientemente. Cambias IPv4, todo parece bien, y luego algunos servicios resuelven por AAAA, algunos clientes prefieren IPv6, el firewall filtra distinto, y te preguntas por qué una cosa va y otra no. No es brujería: es dual-stack.

En Netplan puedes decidir si IPv6 va por DHCPv6, por autoconfiguración o estático. Y aunque el objetivo sea “cambiar la IP” en el sentido tradicional de IPv4, conviene al menos mirar qué ocurre en la interfaz: si hay direcciones IPv6 globales, si hay ruta por defecto IPv6, si algún servicio escucha en IPv6. Es un detalle que no se anuncia con luces, pero que puede explicar comportamientos raros, sobre todo en proveedores que empujan IPv6 con fuerza.

El enfoque prudente es simple: no tocar IPv6 si no es necesario, pero no ignorarlo. Si tu red nueva cambia políticas de IPv6, entonces sí, se planifica. Si no, se comprueba que no esté interfiriendo con expectativas de conectividad.

La comprobación que evita autoengaños: cuando “parece” que funciona no vale

Después de aplicar cambios, hay un momento tentador: ver la IP nueva en ip a y darlo por cerrado. Es un error común porque es visual, inmediato, y tranquiliza. Pero el éxito de un cambio de IP se demuestra en cadena: interfaz con dirección correcta, ruta por defecto correcta, acceso a gateway, acceso a una IP externa, resolución DNS, y disponibilidad de servicios en los puertos que importan. No hace falta convertirlo en un ritual sagrado; hace falta que no te engañe una apariencia.

ip a show dev ens18
ip route | grep ^default
ping -c 2 192.168.1.1
ping -c 2 1.1.1.1
getent hosts example.com 2>/dev/null
ss -tulpn | grep -E '(:22|:80|:443)\b' 2>/dev/null

Si el ping al gateway falla, el problema suele estar fuera: VLAN, switch, cable, filtrado por MAC, prefijo mal puesto. Si el gateway responde pero no sales a internet, puede ser NAT, firewall perimetral, ruta upstream. Si sales a IPs pero no resuelves nombres, es DNS. Y si todo “sale” pero desde fuera no llegas, se mira firewall, escucha de servicios, reglas de seguridad del proveedor, y esa manía de algunas aplicaciones de bindearse a una IP concreta en lugar de a 0.0.0.0.

Aquí entra un detalle que provoca confusiones: hay servicios que quedan escuchando solo en localhost o solo en una IP antigua porque alguien lo configuró así. El sistema tiene la IP nueva, la red funciona, pero el servicio no está “en esa IP”. No hay misterio: es configuración de la aplicación. Y se arregla en la aplicación.

Cuando el cambio deja de ser “cambiar la IP” y se convierte en ordenar el sistema

Un servidor con IP cambiada no vive en el vacío. Vive en un ecosistema de dependencias: monitorización, backups, listas de permitidos, reglas de firewall, DNS, certificados, proxies, balanceadores. Cambias la IP y, si el resto no se entera, parece que has roto cosas que en realidad no estaban preparadas para moverse.

Un ejemplo muy corriente: el servidor pasa a una red donde el puerto 22 está restringido desde ciertas subredes, y de pronto tu acceso remoto no entra. O el servidor está detrás de un reverse proxy y el proxy sigue apuntando a la IP vieja. O hay un sistema de backups que solo conecta a la IP antigua. O un panel de control de seguridad que tiene allowlists fijas. Son engranajes que no tienen por qué actualizarse solos.

También hay una parte casi invisible: el servidor puede conservar entradas antiguas en caches, resolver diferente durante unos minutos, o necesitar reinicios de servicios que “leyeron” una IP al arrancar. No es que Ubuntu esté caprichoso; es que algunos procesos capturan configuración al inicio. Y si el servicio es crítico, se hace con orden: cambiar IP, validar red, validar servicios, y revisar quién dependía de la vieja. Sin dramatizarlo, pero sin confiar en la suerte.

En entornos con más de una interfaz, la cosa se vuelve aún más interesante. No porque sea imposible, sino porque el routing puede decidir que el tráfico salga por la interfaz equivocada. Hay casos donde el servidor tiene una interfaz para gestión y otra para datos, y el cambio de IP afecta a una pero no a otra. Si el default route apunta a la de datos y tú te conectas por la de gestión, una modificación mal planteada puede dejarte dentro pero “sin salida” para repositorios o actualizaciones. Son los fallos que no se ven con un simple ip a. Se ven cuando intentas operar.

Cuando la nueva IP deja de ser noticia

El final bueno de esta historia es silencioso. No hay aplausos, no hay banner de “éxito”; hay calma en los logs y estabilidad en el acceso. Lo que suele funcionar, con margen real, es identificar la interfaz correcta, decidir si el cambio será temporal con ip o permanente con Netplan, aplicar con netplan try cuando hay SSH de por medio, y no olvidar que una IP nueva exige coherencia: ruta por defecto alineada con el gateway real, DNS que resuelva lo que tiene que resolver, y servicios escuchando donde deben.

Cuando todo eso está bien, el servidor vuelve a su papel natural: estar ahí, hacer su trabajo, sin llamar la atención. Y ese es el mejor titular que no se publica, el que te deja dormir.

🔎​ Contenido Verificado ✔️

Este artículo ha sido redactado basándose en información procedente de fuentes oficiales y confiables, garantizando su precisión y actualidad. Fuentes consultadas: Ubuntu Documentation, Netplan, man7.org, cloud-init.