Duro golpe: você está conectado via SSH ou na interface web de um nó Proxmox, e a rede que você precisa modificar exatamente traz esse acesso. Um porto físico errado, um endereço deslocado ou um gateway adicionado no lugar errado pode fechar as duas portas ao mesmo tempo.
O bridge Proxmox deve partir da interface realmente utilizada, do endereçamento registrado no nó e de um retorno acessível. Você irá distinguir o bridge de gerenciamento do bridge reservado para as VMs, decidir se um trunk VLAN é necessário e, em seguida, controlar o resultado antes de fechar sua sessão.
Identificar o caminho da rede que mantém o Proxmox acessível
Comece registrando o estado das interfaces. Essa leitura serve para encontrar o nome exato da placa física e verificar se sua conexão está ativa. Não substitua esse nome por um exemplo como eno1, enp3s0 ou ens18.
ip -br linkA saída esperada exibe cada interface com seu estado, sem pedir que você adivinhe seu nome. Identifique a placa conectada à rede utilizada pela administração e, em seguida, compare-a com o bridge já presente. Se nenhuma interface corresponder ao caminho esperado, pare antes de criar vmbrX.
Em seguida, leia os endereços das interfaces e dos bridges. Você está procurando o endereço de gerenciamento, seu prefixo e o objeto de rede que o abriga atualmente.
ip -br addressA saída deve permitir nomear uma única interface ou um único bridge que carregue o endereço de gerenciamento. Anote essa associação antes de qualquer modificação. Se o endereço aparecer em uma placa física que você planeja conectar a um bridge de gerenciamento, a movimentação para o bridge deve ser prevista explicitamente.
Finalize o pré-vôo com a rota utilizada para sair da rede local. Ela define o gateway a ser mantido no caso simples apresentado aqui.
ip routeVocê deve encontrar uma rota padrão, seu gateway e a interface de saída. Mantenha um único gateway padrão para esta configuração simples. Um segundo gateway não resolve um erro de bridge e introduz uma escolha de rota que sai do escopo deste tutorial.
Antes de abrir o editor de rede, reúna os elementos que condicionam o retorno:
- o nome exato da placa física e o estado de sua conexão;
- o endereço IP de gerenciamento, seu prefixo e o gateway atual;
- a escolha entre bridge de gerenciamento e bridge adicional sem IP no host;
- a rede não marcada ou os VLANs realmente transportados;
- a configuração correspondente da porta no switch;
- uma console IPMI, KVM ou local realmente independente;
- um backup datado do arquivo de rede;
- a sessão SSH inicial mantida até o controle final.
Escolher o bridge, sua porta física e a localização do IP
Um bridge Linux conecta as interfaces de rede virtuais à rede física como um switch virtual. A documentação Proxmox sobre configuração de rede descreve essa pilha Linux e seus objetos. Sua decisão se baseia primeiro no papel de vmbrX e, em seguida, na porta física que serve como saída para ele.
Para a gestão do nó, coloque o endereço IP e o gateway no bridge conectado ao LAN. A placa física anexada serve então como porta para o bridge e não mantém um endereçamento concorrente. Para um bridge reservado para VMs, o host pode permanecer sem endereço IP nessa rede se não houver razão para se comunicar ali.
A tabela esclarece os três casos úteis aqui. Os nomes reais da placa e do bridge vêm do pré-vôo, não de um exemplo copiado.
| Necessidade | IP no host | Gateway padrão | Porta física | VLAN-aware |
|---|---|---|---|---|
| Bridge principal para gerenciamento e VMs no LAN | No vmbrX | Neste bridge no caso simples | Interface conectada ao LAN | Não para uma única rede não marcada; sim apenas para um trunk coerente |
| Bridge adicional reservado para VMs | Nenhum se o host não deve se conectar a essa rede | Nenhum novo gateway padrão | Interface dedicada ou nenhuma porta para uma rede interna | Dependendo da necessidade real das VMs e do switch |
| Trunk de vários VLANs para as VMs | Somente se o nó precisa se comunicar em um VLAN definido | Uma única rota padrão no contexto do tutorial | Porta do switch configurada para os VLANs esperados | Sim |
Se vmbrX carrega o gerenciamento, o endereço não deve permanecer em paralelo na placa física. Se vmbrX serve apenas para VMs, um endereço ausente no host pode ser normal. Em ambos os casos, a rota padrão continua única no cenário simples.
Ativar VLAN-aware apenas para um trunk planejado no switch
Ative VLAN-aware somente se múltiplos VLANs devem atravessar o mesmo bridge em direção às VMs. Para uma única rede não marcada, essa configuração adiciona uma dependência sem atender a uma necessidade identificada. O botão do lado Proxmox não configura a porta do switch e não decide o VLAN de gerenciamento.
Separe três decisões: a ativação de VLAN-aware no bridge, a tag atribuída à placa de rede de uma VM e o transporte permitido pela porta física do switch. Se o VLAN de gerenciamento é marcado, seu tratamento deve ser coerente dos dois lados.
Depois de estabelecer essa arquitetura, leia a tabela VLAN do lado Linux. Este comando não valida o switch; ele serve para comparar o bridge e sua porta com os VLANs previstos.
bridge vlan showA saída esperada deve corresponder aos VLANs realmente permitidos no trunk e às portas membros do bridge. Uma lista vazia, uma porta ausente ou uma pertença incoerente exige rever o bridge e a configuração do switch antes da aplicação. A documentação Proxmox sobre VLANs lembra que VLAN-aware não substitui a configuração do transporte físico.
Preparar o rollback antes de aplicar a configuração
Uma modificação no bridge de gerenciamento afeta o caminho da sua sessão. Eu aconselho a confirmar o acesso a uma console IPMI, KVM ou local antes de tocar no endereçamento. Uma segunda sessão SSH é útil para a prova final, mas não constitui um acesso independente se passar pelo mesmo bridge, switch e gateway.
Mantenha uma cópia datada do arquivo de rede antes da gravação. Este backup não substitui a console, mas fornece um estado conhecido para reexaminar caso a configuração remota corte o acesso.
sudo cp /etc/network/interfaces /etc/network/interfaces.bak-$(date +%F-%H%M)Após o comando, o arquivo de backup deve conter a data e a hora no seu nome, ao lado do arquivo original. Se a cópia falhar ou se a console de backup não estiver realmente acessível, não prossiga remotamente. As próximas etapas devem permanecer recuperáveis a partir deste caminho independente.
Aplicar a mudança sem forçar ifdown no bridge
Na interface Proxmox, releia o nome de vmbrX, a porta física, o endereço, o prefixo, o gateway e a escolha do VLAN antes de validar. Em seguida, use o mecanismo de aplicação controlada proposto pelo Proxmox, documentado no guia de administração de rede do Proxmox. Este método não elimina o risco de uma inconsistência no switch, mas evita adicionar uma mudança improvisada a esse risco.
Se você editar diretamente /etc/network/interfaces, mantenha a mesma disciplina: releia os nomes registrados, coloque o IP no nível correto e não invente um exemplo de interface. Atenção: a dupla ifdown/ifup acionada por reflexo pode interromper o tráfego dos convidados e não restabelecê-lo como esperado. Ela não é um método de recuperação remota.
Após a aplicação, não conclua a partir de um único botão ou de uma única janela que permaneceu aberta. Vá para os controles do bridge, da rota, da porta membro e dos VLANs, e então abra uma nova conexão.
Comprovar o bridge antes de confiar as VMs a ele
Comece verificando o endereço do bridge. Essa leitura permite distinguir o caso onde vmbrX carrega o gerenciamento do caso onde ele permanece voluntariamente sem IP no host.
ip -br address show vmbrXSe vmbrX carrega o gerenciamento, a saída deve exibir o endereço e o prefixo registrados inicialmente. Se o bridge é reservado para VMs, a ausência de endereço pode ser esperada. Um endereço ausente no primeiro caso, ou presente no segundo sem necessidade identificada, exige que você retorne à configuração antes de continuar.
Em seguida, verifique se a placa física esperada realmente pertence ao bridge. Você está buscando a conexão entre vmbrX e a porta registrada durante o pré-vôo.
bridge linkA saída esperada mostra a porta física conectada ao bridge, com um estado de conexão coerente. Se a porta estiver ausente ou se outra porta aparecer, não confie VMs a vmbrX e use a console independente para corrigir a configuração.
Finalmente, releia a rota após a mudança. O comando deve confirmar que o único gateway continua anexado ao caminho previsto.
ip routeA saída deve exibir a rota padrão e o gateway esperados. Uma rota padrão ausente, concorrente ou proveniente de uma interface errada interrompe a validação. Corrija primeiro o endereçamento e o bridge, sem adicionar um segundo gateway para esconder o problema.
Para um trunk, retome o controle VLAN após a aplicação. Ele deve continuar coerente com a porta do switch e a plano de tags previsto.
bridge vlan showA saída esperada mostra os VLANs úteis no bridge e sua porta membro. Um resultado diferente do plano exige que você suspenda a ativação das VMs e verifique o switch. O bridge ativo não comprova por si só que o tráfego marcado passa corretamente.
De um outro cliente ou sessão, agora abra uma nova conexão SSH para o nó e recarregue a interface web. Se esses dois acessos funcionam enquanto o bridge, a rota, a porta membro e os VLANs esperados estão coerentes, você pode então diagnosticar a rede de uma VM Proxmox se um convidado permanecer offline.
Mantenha a sessão inicial aberta até lá. Feche-a apenas após abrir uma nova conexão SSH e o funcionamento da interface web. Se um desses dois controles falhar, use a console independente e o backup em vez de multiplicar as mudanças remotas.
