Gerenciamento de host de VM no caso de ponte Linux

Question

Eu tenho um host de máquina virtual ( vm-host ) que executa duas máquinas virtuais qemu-kvm em toque em modo. Isso significa que a topologia de rede se parece com isso:

Como preciso gerenciar vm-host sobre a VLAN 123, vejo três abordagens:

• Eu crio uma eth0.123 interface em vm-host e configuro o IP de gerenciamento para eth0.123
• Eu crio uma ponte entre eth0.123 e br0 e configuro o IP de gerenciamento para br0
• Eu configuro o IP de gerenciamento diretamente para eth0 in vm-host e configuro r1 de uma maneira que ele remove a tag VLAN 123 para o tráfego de gerenciamento antes de enviá-lo para vm-host

Existe um design claramente melhor que os outros? Eu suponho que a terceira opção de design é a melhor do ponto de vista de vm-host porque o servidor não precisa estourar a tag VLAN como no caso das duas primeiras opções e os quadros de tráfego de gerenciamento não passam no switch Linux br0 como seria no caso de uma segunda opção. Em outras palavras, essa parece ser a opção de design mais simples. A segunda opção parece ser a pior porque não vejo nenhuma vantagem em mover esse tráfego através da ponte Linux.

    

Answer 1

Se sua caixa tiver mais de uma VLAN (na mesma interface), eu as manteria todas marcadas. (Em vez de, por exemplo, dois marcados e um não marcado.) Isso facilita a configuração mais tarde, já que é explícito quais são as VLANs em questão. A caixa tem que lidar com tags VLAN de qualquer maneira, e não é que seria um gargalo (comparado à análise de IP / TCP / SSH / whatever).

Além disso, se você realmente não precisa unir a VLAN de gerenciamento a nada, não há necessidade de colocá-la em uma ponte. Não criar uma ponte para isso deixa claro que a VLAN em questão não é voltada para suas VMs, mas para o próprio host. (Assumindo pontes por VLAN.)

Então, dentre essas escolhas, eu acabei de colocar o gerenciamento em eth0.123.

Por outro lado, você pode dedicar um NIC separado para o gerenciamento. Além de manter as coisas limpas e separadas, ele teria a vantagem de que o tráfego de gerenciamento e as VMs não competiriam pela mesma largura de banda. Mesmo o tráfego extremo nas redes de VMs não seria capaz de inundar o acesso de gerenciamento diretamente. (Assumindo que a caixa em si e o switch possam acompanhar, é claro).

(Não sei exatamente se há algum motivo "difícil" para fazer um ou outro. Como você disse, há várias maneiras de fazer isso e pode ser apenas uma escolha pessoal. Em caso de dúvida, use o método mais simples.)

    

Answer 2

1. gerenciamento ip em eth0.123

   Desvantagem - fluxo de tráfego marcado e não marcado em bridge, portanto, as VMs podem potencialmente forjar o vlan123. Para protegê-lo Você precisa filtrar o tráfego marcado para a frente na ponte (ferramenta ebtables)

   ebtables -t filter -A FORWARD -p 0x88a8 -j DROP
   ebtables -t filter -A FORWARD -p 0x8100 -j DROP
   

2. por ponte vlan (como diz o @ilkkachu) é possível, mas a opção lá e a ponte "não marcada" (ligada diretamente à interface física) sofrem do mesmo problema que 1

3. Deve ser possível definir vlan na bridge (br0.123), mas é muito semelhante a 1 e a bridge que combina várias vlans pode sofrer de endereços MAC não exclusivos entre VLAN.

4. manipulando a VLAN no roteador para tornar as duas vlan desmarcadas, parecer ofuscadas e não fornecer isolamento entre gerenciamento de host e rajadas no aspecto de segurança. Mas possível, a VLAN baseada em MAC no roteador pode ser razoável. Se a meta for isolar os domínios de broadcast, mas não isolar com segurança o host das VMs.