Crear un puente Proxmox sin perder el acceso al servidor

Duro golpe: estás conectado por SSH o en la interfaz web de un nodo Proxmox, y la red que debes modificar lleva justamente ese acceso. Un puerto físico incorrecto, una dirección desplazada o una puerta de enlace añadida en el lugar equivocado pueden cerrar ambas puertas al mismo tiempo.

El puente Proxmox debe partir de la interfaz realmente utilizada, de la direccionamiento registrado en el nodo y de un retroceso accesible. Vas a distinguir el puente de gestión del puente reservado para las VM, decidir si es necesario un trunk VLAN, y luego controlar el resultado antes de cerrar tu sesión.

Identificar la ruta de red que mantiene Proxmox accesible

Comienza por verificar el estado de las interfaces. Esta lectura sirve para encontrar el nombre exacto de la tarjeta física y para verificar si su enlace está activo. No reemplaces este nombre por un ejemplo como eno1, enp3s0 o ens18.

ip -br link

La salida esperada muestra cada interfaz con su estado, sin pedirte que adivines su nombre. Encuentra la tarjeta conectada a la red utilizada por la administración, y luego compárala con el puente que ya está presente. Si ninguna interfaz corresponde a la ruta esperada, detente antes de crear vmbrX.

Luego, lee las direcciones asignadas a las interfaces y los puentes. Estás buscando la dirección de gestión, su prefijo y el objeto de red que la porta actualmente.

ip -br address

La salida debe permitir nombrar una sola interfaz o un solo puente que porte la dirección de gestión. Anota esta asociación antes de cualquier modificación. Si la dirección aparece en una tarjeta física que planeas conectar a un puente de gestión, el desplazamiento hacia el puente debe estar previsto explícitamente.

Termina la prevalidación con la ruta utilizada para salir de la red local. Esta define la puerta de enlace a conservar en el caso simple presentado aquí.

ip route

Debes encontrar una ruta por defecto, su puerta de enlace y la interfaz de salida. Mantén una sola puerta de enlace por defecto para esta configuración simple. Una segunda puerta de enlace no resuelve un error de puente e introduce una elección de ruta que sale del alcance de este tutorial.

Antes de abrir el editor de red, reúne los elementos que condicionan el retroceso:

• el nombre exacto de la tarjeta física y el estado de su enlace;
• la dirección IP de gestión, su prefijo y la puerta de enlace actual;
• la elección entre puente de gestión y puente adicional sin IP en el anfitrión;
• la red no etiquetada o los VLAN realmente transportados;
• la configuración correspondiente del puerto en el conmutador;
• una consola IPMI, KVM o local realmente independiente;
• una copia de seguridad fechada del archivo de red;
• la sesión SSH inicial conservada hasta el control final.

Elegir el puente, su puerto físico y la ubicación de la IP

Un puente Linux conecta las interfaces de red virtuales a la red física como un conmutador virtual. La documentación Proxmox sobre la configuración de red describe esta pila de Linux y sus objetos. Tu decisión se basa primero en el rol de vmbrX, y luego en el puerto físico que le sirve de salida.

Para la gestión del nodo, coloca la dirección IP y la puerta de enlace en el puente conectado al LAN. La tarjeta física conectada sirve como puerto del puente y no mantiene una direccionamiento concurrente. Para un puente reservado para las VM, el anfitrión puede permanecer sin dirección IP en esta red si no tiene ninguna razón para comunicarse allí.

La tabla ilustra los tres casos útiles aquí. Los nombres reales de la tarjeta y del puente provienen de la prevalidación, no de un ejemplo copiado.

Necesidad	IP en el anfitrión	Puerta de enlace por defecto	Puerto físico	VLAN-aware
Puente principal para gestión y VM en el LAN	Sobre vmbrX	Sobre este puente en el caso simple	Interfaz conectada al LAN	No para una sola red no etiquetada; sí solo para un trunk coherente
Puente adicional reservado para las VM	Ninguna si el anfitrión no debe unirse a esta red	Ninguna nueva puerta de enlace por defecto	Interfaz dedicada o ningún puerto para una red interna	Según la necesidad real de las VM y del conmutador
Trunk de varios VLAN hacia las VM	Solo si el nodo debe comunicarse en un VLAN definido	Una sola ruta por defecto en el contexto del tutorial	Puerto del conmutador configurado para los VLAN esperados	Sí

Si vmbrX soporta la gestión, la dirección no debe permanecer en paralelo en la tarjeta física. Si vmbrX sirve exclusivamente a las VM, una dirección ausente en el anfitrión puede ser normal. En ambos casos, la ruta por defecto sigue siendo única en el escenario simple.

Activar VLAN-aware solo para un trunk previsto en el conmutador

Activa VLAN-aware solo si varios VLAN deben atravesar el mismo puente hacia las VM. Para una única red no etiquetada, este ajuste añade una dependencia sin responder a una necesidad identificada. El botón del lado Proxmox no configura el puerto del conmutador y no decide el VLAN de gestión.

Separa tres decisiones: la activación de VLAN-aware en el puente, la etiqueta asignada a la tarjeta de red de una VM y el transporte permitido por el puerto físico del conmutador. Si el VLAN de gestión está etiquetado, su tratamiento debe ser coherente de ambos lados.

Después de definir esta arquitectura, lee la tabla VLAN del lado de Linux. Este comando no valida el conmutador; sirve para comparar el puente y su puerto con los VLAN previstos.

bridge vlan show

La salida esperada debe corresponder a los VLAN realmente autorizados en el trunk y a los puertos miembros del puente. Una lista vacía, un puerto ausente o una pertenencia incoherente requieren revisar el puente y la configuración del conmutador antes de la aplicación. La documentación Proxmox sobre VLAN recuerda que VLAN-aware no reemplaza la configuración del transporte físico.

Preparar el rollback antes de aplicar la configuración

Una modificación del puente de gestión afecta la ruta de tu sesión. Te aconsejo confirmar el acceso a una consola IPMI, KVM o local antes de alterar el direccionamiento. Una segunda sesión SSH es útil para la prueba final, pero no constituye un acceso independiente si pasa por el mismo puente, el mismo conmutador y la misma puerta de enlace.

Conserva una copia fechada del archivo de red antes de la escritura. Esta copia de seguridad no reemplaza la consola, pero proporciona un estado conocido para consultar si la configuración remota corta el acceso.

sudo cp /etc/network/interfaces /etc/network/interfaces.bak-$(date +%F-%H%M)

Después del comando, el archivo de respaldo debe llevar la fecha y hora en su nombre, junto al archivo original. Si la copia falla o si la consola de emergencia no es realmente accesible, no continues a distancia. La siguiente parte debe seguir siendo recuperable desde este camino independiente.

Aplicar el cambio sin forzar ifdown en el puente

Desde la interfaz Proxmox, revisa el nombre de vmbrX, el puerto físico, la dirección, el prefijo, la puerta de enlace y la elección VLAN antes de validar. Luego utiliza el mecanismo de aplicación controlada propuesto por Proxmox, documentado en el guía de administración de red Proxmox. Este método no elimina el riesgo de una incoherencia en el conmutador, evita añadir un cambio improvisado a este riesgo.

Si editas directamente /etc/network/interfaces, mantén la misma disciplina: revisa los nombres registrados, coloca la IP en el nivel correcto y no inventes un ejemplo de interfaz. Atención: la pareja ifdown/ifup lanzada por reflejo puede interrumpir el tráfico de las invitadas y no restaurarlo como se esperaba. No constituye un método de recuperación a distancia.

Después de la aplicación, no concluyas basándote en un solo botón o en una sola ventana que permanezca abierta. Pasa a los controles del puente, de la ruta, del puerto miembro y de los VLAN, y luego abre una nueva conexión.

Probar el puente antes de confiarle las VM

Comienza verificando la dirección del puente. Esta lectura permite distinguir el caso en el que vmbrX lleva la gestión del caso en el que voluntariamente permanece sin IP en el anfitrión.

ip -br address show vmbrX

Si vmbrX lleva la gestión, la salida debe mostrar la dirección y el prefijo registrados al inicio. Si el puente está reservado para las VM, la ausencia de dirección puede ser esperada. Una dirección ausente en el primer caso, o presente en el segundo sin necesidad identificada, requiere volver a la configuración anterior antes de continuar.

Luego verifica que la tarjeta física esperada pertenezca al puente. Estás buscando el enlace entre vmbrX y el puerto registrado durante la prevalidación.

bridge link

La salida esperada muestra el puerto físico conectado al puente, con un estado de enlace coherente. Si el puerto falta o si aparece otro puerto, no confíes las VM a vmbrX y utiliza la consola independiente para corregir la configuración.

Por último, revisa la ruta después del cambio. El comando debe confirmar que la puerta de enlace única permanece unida a la ruta prevista.

ip route

La salida debe mostrar la ruta por defecto y la puerta de enlace esperadas. Una ruta por defecto ausente, concurrente o soportada por una mala interfaz detiene la validación. Corrige primero el direccionamiento y el puente, sin añadir una segunda puerta de enlace para ocultar el problema.

Para un trunk, retoma el control VLAN después de la aplicación. Debe mantenerse coherente con el puerto del conmutador y el plan de etiquetas previsto.

bridge vlan show

La salida esperada muestra los VLAN útiles en el puente y su puerto miembro. Un resultado diferente del plan exige suspender la puesta en marcha de las VM y verificar el conmutador. El puente activo no prueba por sí solo que el tráfico etiquetado pase correctamente.

Desde otro cliente o sesión, ahora abre una nueva conexión SSH hacia el nodo y recarga la interfaz web. Si estos dos accesos funcionan mientras que el puente, la ruta, el puerto miembro y los VLAN esperados son coherentes, luego puedes diagnosticar la red de una VM Proxmox si un invitado sigue fuera de línea.

Mantén la sesión inicial abierta hasta entonces. Ciérrala solo después de abrir una nueva conexión SSH y garantizar el funcionamiento de la interfaz web. Si alguna de estas dos comprobaciones falla, utiliza la consola independiente y la copia de seguridad en lugar de multiplicar los cambios a distancia.