Nesta configuração, a bridge br0 passa a ser a interface utilizada pelas aplicações da máquina física que normalmente usariam a eth0. Esta, por sua vez, passa a ser apenas uma forma de ligar a bridge à rede externa. O servidor DHCP da rede externa responderá às requisições da interface br0 e também das interfaces virtuais vnet0 a vnet2.

Como criar uma bridge

O 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á br0, mas também poderia ser qualquer outro como "bicicleta" ou "tralala". Já podemos adicionar a eth0 a ela.

  # 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: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc »
                              «pfifo_fast state DOWN qlen 1000
      link/ether 22:ee:f8:0e:4a:7a brd ff:ff:ff:ff:ff:ff
  15: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
      link/ether 22:ee:f8:0e:4a:7a brd ff:ff:ff:ff:ff:ff

Máquinas virtuais e libvirt

Como 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 todos

Antes 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.ipv4.ip_forward=1

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).

Ajustes

Se você usar duas interfaces físicas na bridge (por exemplo, eth0 e eth1), certamente seria uma boa ideia recorrer ao Spanning Tree Protocol para evitar problemas de roteamento decorrentes de redundância de links na rede externa.

  # 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 INPUT, e os que forem destinados às máquinas virtuais passarão pela cadeia FORWARD.

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 physdev (de physical device, dispositivo físico).

Dois exemplos de regras para negar conexões à porta TCP 23 na interface br0 recebidas pela interface física eth1 ou saindo da porta UDP 9876 pela interface física eth0:

  # 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 FORWARD e POSTROUTING. Por exemplo, para negar na bridge a repassagem de pacotes destinados ao IP 10.1.2.5:

  # 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 automatizadas

Para automatizar essas configurações no seu sistema, comece ativando de forma persistente o encaminhamento de pacotes IPv4 no seu kernel:

  # echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
  ou
  # sed -e '/ip_forward/s/0/1/' -i /etc/sysctl.conf

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 /etc/network/interfaces, a wiki do Debian explica (e eu replico aqui apenas com traduções) que é preciso colocar a interface do bridge em modo auto e definir, nas interfaces físicas associadas a ela, esse vínculo:

  # 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 /etc/sysconfig/network-scripts/, serão necessários procedimentos semelhantes, mas precisaremos ainda desativar o controle da(s) interface(s) física(s) pelo NetworkManager (no Red Hat Enterprise Linux, somente da versão 6 em diante). Novamente, a documentação online da Red Hat detalha e eu apenas replico traduzindo:

  # cat /etc/sysconfig/network-scripts/ifcfg-br0
  DEVICE=br0
  TYPE=Bridge   # Este "B" maiúsculo é obrigatório.
  BOOTPROTO=dhcp
  ONBOOT=yes
  DELAY=0
  
  # cat /etc/sysconfig/network-scripts/ifcfg-eth0
  DEVICE=eth0
  # Lembre-se de adequar o endereço MAC à sua interface
  HWADDR=00:11:22:33:44:55
  ONBOOT=yes
  BRIDGE=br0
  
  # cat /etc/sysconfig/network-scripts/ifcfg-eth1
  DEVICE=eth1
  # Lembre-se de adequar o endereço MAC à sua interface
  HWADDR=00:11:22:33:44:55
  ONBOOT=yes
  BRIDGE=br0

Até a próxima!

Links relacionados

• Documentação da Red Hat sobre bridges Ethernet para virtualização (a licença CC-BY-SA me permite replicar o conteúdo neste post)
• Verbete Bridging Network Connections na wiki do Debian
• Extensa documentação sobre bridge no Linux no site da Linux Foundation
• Página de manual online do iptables (inclui o módulo physdev)
• Documentação no site do ebtables

Outros artigos deste autor

• Mais uma forma de ganhar dinheiro com Software Livre
• As novidades do Linux 3.0
• LVM2 em servidores: obrigatório
• Os hackers mandam no Linux
• As novidades do Linux 2.6.39 – talvez o último da série 2.6
• Entrevista: Lennart Poettering, autor do systemd
• VPN por assinatura para qualquer usuário
• Virt-manager: virtualização fácil, flexível e 100% livre
• Comparativo: GnuTLS versus OpenSSL para criar uma CA
• Bê-á-bá dos cgroups, parte 3: automatização e configuração de grupos (com links para as partes anteriores)
• O que esperar do Linux 2.6.39
• Comparativo: upstart, sysvinit, systemd, openrc
• Mais protocolos para seu switch de rede
• As novidades do Linux 2.6.38
• Dragonfly BSD e seus recursos
• Certificados digitais, assinaturas de e-mail, mensagens criptografadas: por que tudo isso funciona?
• Bê-á-bá do Systemd, parte 6 (com links para as partes anteriores)
• Informações de automount via LDAP
• O fim da eth0?
• Uma loja de aplicativos para qualquer sistema GNU/Linux
• Próxima versão do kernel já tem direção
• Configuração de touchpad no xorg.conf.d
• Gentoo, uma ótima distribuição em queda:
• Bê-á-bá do MAC no Linux, parte 6: AppArmor (com links para as partes anteriores)
• Espionagem industrial: evite-a de forma colaborativa
• As novidades do Linux 2.6.37
• A fragmentação dos contêineres no Linux
• Melhorias no script de atualização do arquivo hosts
• Espírito natalino no Software Livre: você já fez sua doação?
• Tem disco na rede: ATA over Ethernet
• Navegação mais segura e rápida com um bom arquivo hosts
• Ative a compactação de memória com Zram
• Contra força bruta, defesa bruta
• Kernel Linux, blobs binários, liberdade de software e Linux-libre
• Fcron: melhor que Cron e Anacron juntos
• Com getopts, seus scripts ficam mais profissionais
• Systemd: Boot mais rápido, preciso, econômico...
• Novidades do kernel 2.6.36
• Dica rápida: Automount mais inteligente
• Dica rápida: otimização de desktops com kernel Linux no /proc e /sys
• Fez besteira no /etc? Use o git para retornar tudo ao normal
• Renomear interface de rede com Udev
• Servidores atacados: culpa do distribuidor do kernel?
• Dica rápida: calendário anual no OpenOffice.org
• Prompt de Bash mais útil
• Bê-á-bá do SSH, parte 9: Controle de acesso (com links para as partes anteriores)
• O planeta inteligente, na visão da IBM. Temos tempo até a Copa do Mundo?
• As novidades do kernel Linux 2.6.35
• Snapshots COW para os menos favorecidos: cron, rsync e hardlinks
• As novidades do kernel Linux 2.6.34
• Protocolos da Internet: futuro e futuro do pretérito
• Tux3, o sistema de arquivos que (mais uma vez) não aconteceu
• Compiladores melhorados pela genética