Mal momento: estás conectado por SSH o en la interfaz web de un nodo Proxmox, y la red que necesitas modificar es precisamente la que proporciona ese acceso. Un puerto físico incorrecto, una dirección cambiada o una puerta de enlace añadida en el lugar equivocado pueden cerrar ambas puertas al mismo tiempo.
El bridge de Proxmox debe, por lo tanto, partir de la interfaz realmente utilizada, de la dirección identificada en el nodo y de un regreso accesible. Debes distinguir el bridge de gestión del bridge 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 verificar si su enlace está activo. No reemplaces este nombre por un ejemplo como eno1, enp3s0 o ens18.
ip -br linkLa salida esperada muestra cada interfaz con su estado, sin pedirte que adivines su nombre. Identifica la tarjeta conectada a la red utilizada para la administración, luego compárala con el bridge ya presente. Si ninguna interfaz corresponde a la ruta esperada, detente antes de crear vmbrX.
Luego, lee las direcciones de las interfaces y los bridges. Buscas la dirección de gestión, su prefijo y el objeto de red que actualmente la alberga.
ip -br addressLa salida debe permitir nombrar una sola interfaz o un solo bridge que contenga 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 bridge de gestión, el movimiento hacia el bridge debe ser previsto explícitamente.
Termina el preflight con la ruta utilizada para salir de la red local. Esto establece la puerta de enlace a conservar en el caso simple presentado aquí.
ip routeDebes encontrar una ruta por defecto, su puerta de enlace y la interfaz de salida. Mantén solo una puerta de enlace por defecto para esta configuración simple. Una segunda puerta de enlace no resuelve un error de bridge e introduce una elección de ruta que está fuera del alcance de este tutorial.
Antes de abrir el editor de red, reúne los elementos que condicionan el regreso:
- 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 bridge de gestión y bridge adicional sin IP en el host;
- 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 bridge, su puerto físico y la ubicación de la IP
Un bridge Linux conecta las interfaces de red virtuales a la red física como un switch virtual. La documentación de Proxmox sobre la configuración de red describe esta pila de Linux y sus objetos. Tu decisión se centra primero en el papel de vmbrX, 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 bridge conectado al LAN. La tarjeta física unida sirve entonces como puerto al bridge y no mantiene un direccionamiento concurrente. Para un bridge reservado a las VM, el host puede permanecer sin dirección IP en esta red si no tiene razón para comunicarse allí.
La tabla distingue los tres casos útiles aquí. Los nombres reales de la tarjeta y del bridge provienen del preflight, no de un ejemplo copiado.
| Necesidad | IP en el host | Puerta de enlace por defecto | Puerto físico | Consciente de VLAN |
|---|---|---|---|---|
| Bridge principal para gestión y VM en el LAN | En vmbrX | En este bridge en el caso simple | Interfaz conectada al LAN | No para una sola red no etiquetada; sí solo para un trunk coherente |
| Bridge adicional reservado para VM | Ninguna si el host no debe unirse a esta red | Sin 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 múltiples VLAN hacia las VM | Solo si el nodo debe comunicarse en un VLAN definido | Una única ruta por defecto en el marco del tutorial | Puerto del conmutador configurado para los VLAN esperados | Sí |
Si vmbrX lleva la gestión, la dirección no debe permanecer paralela en la tarjeta física. Si vmbrX sirve únicamente para las VM, una dirección ausente en el host puede ser normal. En ambos casos, la ruta por defecto sigue siendo única en el escenario simple.
Activar consciente de VLAN solo para un trunk previsto en el conmutador
Activa consciente de VLAN solo si múltiples VLAN deben atravesar el mismo bridge hacia las VM. Para una sola red no etiquetada, esta configuración añade una dependencia sin atender a una necesidad identificada. El botón del lado de Proxmox no configura el puerto del conmutador y no decide el VLAN de gestión.
Separa tres decisiones: la activación de consciente de VLAN en el bridge, 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 establecer esta arquitectura, lee la tabla VLAN del lado de Linux. Este comando no valida el conmutador; sirve para comparar el bridge y su puerto con los VLAN previstos.
bridge vlan showLa salida esperada debe corresponder a los VLAN realmente autorizados en el trunk y a los puertos miembros del bridge. Una lista vacía, un puerto ausente o una pertenencia inconsistente obliga a revisar el bridge y la configuración del conmutador antes de aplicar. La documentación de Proxmox sobre los VLAN recuerda que consciente de VLAN no reemplaza la configuración del transporte físico.
Preparar el rollback antes de aplicar la configuración
Una modificación del bridge de gestión afecta la ruta de tu sesión. Te aconsejo confirmar el acceso a una consola IPMI, KVM o local antes de tocar el direccionamiento. Una segunda sesión SSH es útil para la prueba final, pero no constituye un acceso independiente si pasa por el mismo bridge, el mismo conmutador y la misma puerta de enlace.
Conserva una copia fechada del archivo de red antes de escribir. Esta copia de seguridad no reemplaza la consola, pero proporciona un estado conocido para revisar 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 copia de seguridad debe llevar la fecha y la hora en su nombre, junto al archivo original. Si la copia falla o si la consola de respaldo no es realmente accesible, no continúes de forma remota. La continuación debe seguir siendo recuperable desde esta ruta independiente.
Aplicar el cambio sin forzar ifdown en el bridge
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 de VLAN antes de validar. Luego utiliza el mecanismo de aplicación controlada propuesto por Proxmox, documentado en la guía de administración de red de 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 identificados, 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 los invitados y no restaurarlo como se esperaba. No constituye un método de recuperación a distancia.
Después de la aplicación, no concluyas a partir de un solo botón o de una sola ventana abierta. Pasa a los controles del bridge, de la ruta, del puerto miembro y de los VLAN, luego abre una nueva conexión.
Probar el bridge antes de confiarle las VM
Comienza verificando la dirección del bridge. Esta lectura permite distinguir el caso donde vmbrX lleva la gestión del caso donde permanece deliberadamente sin IP en el host.
ip -br address show vmbrXSi vmbrX lleva la gestión, la salida debe mostrar la dirección y el prefijo identificados al principio. Si el bridge 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, obliga a regresar a la configuración antes de continuar.
Luego verifica que la tarjeta física esperada pertenece al bridge. Buscas el enlace entre vmbrX y el puerto identificado durante el preflight.
bridge linkLa salida esperada muestra el puerto físico vinculado al bridge, con un estado de enlace coherente. Si falta el puerto o entra otro puerto, no confíes VM a vmbrX y utiliza la consola independiente para corregir la configuración.
Por último, vuelve a revisar la ruta después del cambio. El comando debe confirmar que la puerta de enlace única sigue estando vinculada a la ruta prevista.
ip routeLa salida debe mostrar la ruta por defecto y la puerta de enlace esperadas. Una ruta por defecto ausente, concurrente o llevada por una interfaz incorrecta detiene la validación. Corrige primero el direccionamiento y el bridge, sin añadir una segunda puerta de enlace para ocultar el problema.
Para un trunk, retoma el control de VLAN después de la aplicación. Debe seguir siendo coherente con el puerto del conmutador y el plan de etiquetas previsto.
bridge vlan showLa salida esperada muestra los VLAN útiles en el bridge y su puerto miembro. Un resultado diferente del plan obliga a suspender la puesta en marcha de las VM y verificar el conmutador. Un bridge activo no prueba por sí solo que el tráfico etiquetado pasa correctamente.
Desde otro cliente o sesión, abre ahora una nueva conexión SSH hacia el nodo y recarga la interfaz web. Si estos dos accesos funcionan mientras que el bridge, la ruta, el puerto miembro y los VLAN esperados son coherentes, entonces puedes diagnosticar la red de una VM Proxmox si un invitado permanece fuera de línea.
Mantén la sesión inicial abierta hasta entonces. Ciérrala únicamente después de abrir una nueva conexión SSH y de que la interfaz web funcione. Si alguno de estos dos controles falla, utiliza la consola independiente y la copia de seguridad en lugar de multiplicar los cambios remotos.
