336. BRIDGING

336.1 Software

Deve-se obter o Utilitário de Configuração de Bridge das páginas de Alan Cox. É a mesma referenciada no documento de Christopher Cole.

336.2 Leitura Prévia

Deve-se ler o documento COMO FAZER Ethernets Múltiplas para informações sobre a instalação simultânea de mais de uma placa de rede.

Mais alguns detalhes sobre o tipo de mágica de inicialização que se possa precisar podem ser encontrados em COMO FAZER Prompt de Inicialização.

Deve-se ainda verificar o conteúdo de COMO FAZER NET-2. É uma boa e longa leitura e pode-se retirar dela os detalhes necessários sobre a rede como um todo.

336.3 Configuração de inicialização

O material de leitura acima, dirá que é necessário preparar o kernel para reconhecer um segundo dispositivo Ethernet na inicialização, adicionando-se o seguinte conteúdo ao arquivo /etc/lilo.conf e após deve-se reexecutar o programa lilo:

append = "ether=0,0,eth1" 

Observe que "eth0" é a primeira placa, enquanto que "eth1" é a segunda. Pode-se sempre adicionar os parâmetros da inicialização na resposta à linha que o lilo oferece.

Para três placas teremos a seguinte configuração:

linux ether=0,0,eth1 ether=0,0,eth2 

Pode-se usar o loadlin para inicializar o kernel a partir do DOS, no seguinte formato:

loadlin.exe c:\vmlinuz root=/dev/hda3 ro ether=0,0,eth1 ether=0,0,eth2 

Note que este truque faz com que o kernel teste as placas na inicialização do sistema. Isto não acontecerá caso os controladores Ethernet sejam carregados como módulos (por segurança, desde que a ordem de entrada não pode ser determinada quando da verificação automática). Na utilização de módulos deverá ser acrescentada a IRQ apropriada, assim como os parâmetros para o controlador no arquivo /etc/conf.modulos, como no arquivo de exemplo a seguir:

alias eth0 3c509
alias eth1 de620
options 3c509 irq=5 io=0x210
options de620 irq=7 bnc=1

Para verificar se o kernel está utilizando módulos, deve-se executar o comando ``ps -aux'' e verificar se o kerneld está sendo executado, assim como verificar se existem arquivos .o em um subdiretório do diretório /lib/modules/. Será possível verificar o diretório, através do uso do comando uname -r que indicará o nome em uso. Caso o kerneld esteja sendo executado e/ou haja um arquivo foo.o, deve ser editado o arquivo /etc/conf.modules e deve-se ler a página manual on-line de depmod cuidadosamente.

Note também que até recentemente (kernel 2.0.25) o controlador 3c509 não podia ser usado por mais de um placa, caso fosse usado como módulo. Há uma atualização que corrige este aspecto.

336.4 Configuração do kernel

Deve-se recompilar o kernel com a opção Bridging habilitada no seguinte formato:

CONFIG_BRIDGE=y 

Deve-se ainda habilitar as funções de firewall e IP-forwarding e -masquerading, caso se deseje utilizar as funções de firewall:

CONFIG_FIREWALL=y           
CONFIG_NET_ALIAS=y          
CONFIG_INET=y               
CONFIG_IP_FORWARD=y         
CONFIG_IP_MULTICAST=y       
CONFIG_IP_FIREWALL=y        
CONFIG_IP_FIREWALL_VERBOSE=y
CONFIG_IP_MASQUERADE=y

Caso não se utilizem estas opções, pode-se somente configurar os parâmetros padrões de rede através do parâmetro:

CONFIG_REDE=y 

Penso que não haja necessidade de se preocupar com qualquer outra opção de rede. Não há nenhuma opção que não se tenha compilado no kernel disponível através de módulos que não possa ser acrescentada posteriormente.

A seguir deve-se instalar o novo kernel, reexecutando o programa lilo e reinicializando o sistema com o novo kernel. Nada deve ter mudado até este ponto!

336.5 Endereços de rede

Chris afirma que uma Bridge não deve ter um endereço IP, mas esta não é a configuração a ser descrita aqui.

Uma vez que ela seja utilizada para conexão com a Internet, por exemplo, um endereço IP será então necessário, assim como assegurar-se que um dispositivo de rede local esteja configurado da forma correta, permitindo assim a conexão com outros pontos da rede da maneira usual. Caso o dispositivo de rede local não esteja ativo, o sistema de resolução de nomes ou outro serviço de rede pode falhar. Veja o COMO FAZER NET-2, porém a configuração padrão do sistema já deve conter a seguinte configuração:

ifconfig lo 127.0.0.1 route add -net 127.0.0.0 

Deve-se então fornecer os endereços para as placas de rede. Pode-se por exemplo alterar o arquivo /etc/rc.d/rc.inet1 em uma sistema Slackware (3.x) para se configurar duas placas. Provavelmente o que se deve fazer é verificar no arquivo de configuração de rede e dobrar ou triplicar o número de instruções ali contidas. Supondo-se que já se tenha o endereço:

192.168.2.100 

(isto está no intervalo reservado a endereços da redes privadas, mas não importa - não fará mal a ninguém o uso deste endereço) então provavelmente já se tem uma linha no formato:

ifconfig eth0 192.168.2.100 netmask 255.255.255.0 metric 1 

na configuração do sistema. A primeira coisa que provavelmente será feita é cortar pela metade o espaço de endereço abrangido por esta placa, podendo-se criar eventualmente uma Bridge ou proteger as duas metades. Para tanto deve-se acrescentar uma linha que reduz a máscara para endereçar um menor número de máquinas:

ifconfig eth0 netmask 255.255.255.128 

Isto restringe a placa ao espaço de endereços entre .0 e .127.

Agora é possível configurar a segunda placa na outra metade do intervalo de endereços locais. Assegure-se de que ninguém já esteja utilizando este endereço. Por simetria configuramos aqui os endereços no seguinte formato: 228 = 128+100. Qualquer endereço fará o mesmo, contanto que não invada o intervalo de outra máscara. Endereços especiais devem ser evitados como por exemplo .0, .1, .128 etc. a não ser que se esteja seguro do que se está fazendo.

ifconfig eth1 192.168.2.228 netmask 255.255.255.128 metric 1 

Isto restringe a segunda placa ao intervalo de endereços entre .128 e .255.

336.6 Roteamento de Rede

Aqui é onde tem que ser descritas as "armadilhas" do esquema Bridge + Firewall: não se pode proteger pacotes que não estiverem sendo roteados, ou seja sem rotas não há proteção. Pelo menos isto parece ser verdadeiro no kernel 2.0.30 e nos mais recentes. Os filtros de proteção estão muito envolvidos com o código de reenvio de IP.

Isto não significa que não se pode ter uma Bridge. Pode-se ter uma Bridge entre duas placas e um firewall em uma terceira. Pode-se ter somente duas placas e proteger ambas de IPs externos, como um roteador, desde que o roteamento seja realizado por uma das placas.

Em outras palavras, para uso do firewall é necessário controlar precisamente o destino físico de alguns pacotes.

Em uma pequena rede de máquinas ligadas a um hub através da interface eth0, a configuração poderia ser a seguinte:

route add -net 192.168.2.128 netmask 255.255.255.128 dev eth0 

O 128 poderia ser igual a 0 caso se estivesse utilizando uma classe C inteira. Neste caso, por definição, o espaço foi dividido ao meio. O parâmetro "dev eth0" não é necessário aqui porque os endereços de placas estão enquadrados dentro da máscara, mas ele pode ser necessário em outras situações. Pode ser necessária mais de um placa nesta sub-rede (127 máquinas em um segmento é um número relativamente elevado), sendo que estas placas funcionariam como uma Bridge sob a mesma máscara de rede, parecendo serem um dispositivo único para o código de roteamento.

Na outra placa há uma conexão indo diretamente para um grande roteador confiável:

                                             cliente 129
         __                                        |    __ 
client 1   \    .0                    .128         |   /   net 1
client 2 --- Hub - eth0 - Kernel - eth1 - Hub - Router --- net 2
client 3 __/       .100            .228         .2 |   \__ net 3
                                                   |
                                             cliente 254 

Define-se o endereço do roteador para esta placa através de uma rota fixa ("static") porque, de outro modo, ele poderia cair dentro da faixa de endereços da primeira máscara e o kernel, erroneamente, enviaria os pacotes para o roteador. Ainda, pode-se querer proteger estes pacotes e essa é outra razão para querer roteá-los desta forma.

route add 192.168.2.2 dev eth1 

Caso se tenha mais máquinas na segunda metade do espaço de endereços, deve-se declarar uma rede também na segunda placa. Separando as interfaces dentro de duas configurações via roteamento permitirá fazer eventualmente proteções mais adequadas.

route add -net 192.168.2.128 netmask 255.255.255.128 dev eth1 

Deve-se ainda indicar ao kernel para enviar para o roteador todos os pacotes não endereçados à rede local.

route add default gw 192.168.2.2 

336.7 Configuração de placas de rede

A configuração da rede é padronizada, mas como estamos executando funções de bridging, então as duas placas devem tratar todos os pacotes que transitem pela rede, mesmo os não dirigidos para elas. Logo elas devem ter a seguinte configuração:

ifconfig promisc eth0 ifconfig promisc eth1 

A página de manual informa allmulti=promisc, mas isto na verdade não parece funcionar muito bem.

336.8 Roteamentos adicionais

Algo observado na prática, foi a necessidade de se colocar ao menos a segunda placa dentro de um modo em que ela possa responder para o roteador questões sobre quais máquinas estão contidas na rede local. Nestes casos deve-se utilizar o comando:

ifconfig arp eth1 

Para garantir um fluxo de comunicação permanente, isso foi feito também nas demais placas.

ifconfig arp eth0. 

336.9 Configuração da Bridge

Para habilitar o funcionamento da Bridge, deve-se ter o seguinte conteúdo no seu arquivo de configuração:

brcfg  -enable 

A configuração da Bridge apresentará alguns números. Pode-se experimentar o seu funcionamento ligando e desligando as portas, uma de cada vez:

brcfg -port 0 -disable/-enable
brcfg -port 1 -disable/-enable 

É possível ainda obter informações sobre o estado do sistema a qualquer momento, bastando informar:

brcfg

sem qualquer parâmetro. Pode-se perceber que a Bridge inicialmente ouve o tráfego, aprende e posteriormente executa o reenvio (não compreendo porque o código repete os mesmos endereços de hardware para as duas placas, mas não importa. O COMO FAZER de Christopher diz que isto está correto).

336.10 Testando o Sistema

Caso se esteja testando realmente este roteiro e verificando a configuração, deve-se agora desabilitar as duas placas de rede através do comando:

ifconfig eth0 down ifconfig eth1 down /etc/rc.d/rc.inet1

Com um pouco de sorte, os vários subsistemas (nfs, ypbind, etc.) não notarão a falta de comunicação imediatamente, porém isso deve ser realizado com o operador sentado na frente do teclado!

Caso se queira ser mais cuidadoso, deve-se desativar previamente o maior número possível de programas servidores e desmontar os diretórios NFS. O pior que poderá acontecer é ter que reiniciar o sistema no modo monousuário (com o parâmetro "single" do lilo ou loadlin) e retirar as mudanças realizadas, antes de reinicializar o sistema no modo multiusuário.

336.11 Verificações

Deve ser checada a existência de tráfego diferente em cada uma das interfaces:

tcpdump -i eth0

(em uma janela)

tcpdump -i eth1

(em outra janela)

O usuário deve habituar-se a usar o utilitário tcpdump para procurar por possíveis problemas de comunicação de rede.

Por exemplo, procure os pacotes que foram enviados através da Bridge para a segunda placa da rede interna. No exemplo a seguir estamos procurando pacotes da máquina com endereço final igual a .22:

tcpdump -i eth1 -e host 192.168.2.22

Deve-se então executar o comando ping destinado ao roteador. Deverá ser possível visualizar o pacote através do tcpdump.

Neste estágio deve-se ter uma Bridge pronta que tem dois endereços de rede. Deve-se testar o funcionamento do "ping" de fora e de dentro da rede local, e verificar se é possível executar os utilitários "telnet" e "ftp" de dentro para fora e vice e versa.