Bridge Ethernet com máquinas virtuais no LinuxJá faz algum tempo que estou usando somente o virt-manager como solução de virtualização no desktop. Como você já sabe, o virt-manager utiliza a libvirt para se comunicar com o sistema de virtualização. Como a libvirt é muito bem feita, tudo funciona sem qualquer percalço, inclusive a configuração da rede virtual. A libvirt cria novas interfaces virtuais de rede e estabelece uma bridge Ethernet entre elas e uma interface física, para que as máquinas virtuais consigam acessar a rede externa. No entanto, a libvirt vem preparada e pré-configurada para um modo de operação aplicável apenas a ambientes desktop: redes virtuais com NAT. Neste modo, a bridge recebe um IP e age como um roteador e servidor DHCP, fornecendo a todas as demais interfaces (exceto a eth0) um IP automático. O que torna esta solução ruim é justamente o uso de NAT. Se você estiver utilizando servidores virtuais, o NAT prejudicará o desempenho de rede da sua solução por exigir maior processamento por parte da máquina física para a tradução de portas. Solução ideal: sem NATPara suas máquinas virtuais se tornarem completamente acessíveis a partir da rede externa, a configuração padrão da libvirt talvez atrapalhe. É aí que surge a necessidade de entender melhor o funcionamento das bridges Ethernet para expor na sua rede todas as máquinas virtuais que você desejar. O que é uma bridgeUma bridge é semelhante a um switch: atua na camada 2 do modelo OSI (enlace), isto é, na camada Ethernet. Isto garante a ela independência de protocolo: é possível transmitir por essas bridges qualquer protocolo de camada 3, como IP, FCoE, AoE etc. Uma bridge permite interligar múltiplas interfaces virtuais — cada uma pertencente a uma máquina virtual — à(s) interface(s) física(s) da máquina anfitriã, como na figura abaixo.
Como criar uma bridgeO passo inicial mais importante na criação de uma bridge frequentemente é esquecido por quem deseja começar a estudá-la: desativar todas as interfaces de rede envolvidas. No nosso exemplo, seria assim: # ip link set eth0 down # ip link set vnet0 down # ip link set vnet1 down # ip link set vnet2 down Feito isso, já podemos criar a bridge. No nosso caso, seu nome será # brctl addbr br0 # brctl addif br0 eth0 # brctl show Agora nossa bridge já está conectada à rede externa e faz o papel de ponte que lhe dá o nome. Note que a bridge pega emprestado o endereço MAC da interface ligada a ela: # ip link list 2: eth0: <BRO Máquinas virtuais e libvirtComo eu disse antes, a libvirt se encarrega de criar as interfaces virtuais e associá-las à bridge que desejarmos. Basta informarmos a ela, na configuração das máquinas virtuais, o nome do dispositivo de bridge: Sempre que possível, utilizar também o driver virtio é uma boa ideia, pois ele reduz o overhead decorrente da virtualização de I/O. Trata-se de um driver paravirtualizado. IP para todosAntes de subir as máquinas virtuais, só precisamos obter um IP em nossa bridge e ativar a repassagem de pacotes IP: # dhclient br0 # sysctl -w net. Feito isto, fique à vontade para iniciar as máquinas virtuais e acessá-las diretamente a partir da rede externa, pois elas pertencerão à mesma subrede da máquina física (10.1.2.0/24, no exemplo das figuras deste post). AjustesSe você usar duas interfaces físicas na bridge (por exemplo, # brctl stp br0 on # brctl show Além disso, o segmento de rede entre sua bridge e as máquinas virtuais é extremamente rápido e confiável, pois sequer passa por barramentos físicos. Portanto, pode ser uma boa ideia aplicar jumbo frames Ethernet (no exemplo, com 9000 bytes) nesse segmento: # ip link set mtu 9000 dev br0 # ip link set mtu 9000 dev vnet0 # ip link set mtu 9000 dev vnet1 # ip link set mtu 9000 dev vnet2 Filtragem de pacotesÉ possível filtrar pacotes usando o netfilter/iptables na sua bridge. Nela, os pacotes destinados à máquina física usarão a cadeia Como o filtro para a máquina local será aplicado à interface do bridge, é necessário utilizar um módulo do netfilter específico para este caso: o módulo Dois exemplos de regras para negar conexões à porta TCP 23 na interface # iptables -A INPUT -m physdev --device-in eth1 -p tcp » « --dport 23 -j DROP # iptables -A INPUT -m physdev --device-out eth0 -p udp » « --sport 9876 -j DROP Além disso, esse módulo também é necessário para aplicar regras de filtragem às cadeias de repassagem de pacotes # iptables -A FORWARD -m physdev --device-is-bridged » « -d 10.1.2.5 -j DROP Alguns outros procedimentos ainda mais específicos, como a completa desativação do netfilter em dispositivos de bridge, são cobertos na documentação da Red Hat. Se você deseja filtrar pacotes IP já na camada Ethernet, claramente violando o modelo TCP/IP — mas com benefícios potenciais de desempenho — talvez valha a pena experimentar o ebtables (de Ethernet bridge tables). Trata-se de um filtro de frames Ethernet capaz de atuar também na camada IP. O ebtables é independente do netfilter/iptables, mas pode atuar em conjunto com este para oferecer maior flexibilidade. Configurações automatizadasPara automatizar essas configurações no seu sistema, comece ativando de forma persistente o encaminhamento de pacotes IPv4 no seu kernel: # echo "net O restante dos procedimentos dependem do utilitário de configuração de rede empregado. O único fator comum a todas as distribuições é que o NetworkManager ainda não funciona com interfaces em bridge. Portanto, é preciso desvincular do NetworkManager as interfaces físicas associadas a bridges. Em distribuições da família Debian que utilizem a infra-estrutura do # Quem será iniciado automaticamente auto lo br0 iface lo inet loopback # eth0 e eth1 não serão gerenciadas por ninguém iface eth0 inet manual iface eth1 inet manual # A bridge br0 usará DHCP e será associada a eth0 e eth1 iface br0 inet dhcp bridge_ports eth0 eth1 Já na família Red Hat, que utiliza o diretório # cat /etc Até a próxima! Links relacionados
Outros artigos deste autor
|