Linux ethernet bridge pode ser acessado atrás de um roteador

Question

Eu rodei o Debian 8 e precisei criar uma ponte com uma interface de toque tap0 to eth0 (tentando configurar um servidor OpenVPN). Eu uso o script de bridging padrão da página de ajuda do OpenVPN:

#!/bin/sh

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="192.168.0.140"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.0.255"

for t in $tap; do
    openvpn --mktun --dev $t
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
    brctl addif $br $t
done

for t in $tap; do
    ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up

ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

em que 192.168.0.140 é o endereço IP reservado para este servidor pelo DHCP do roteador. O roteador (192.168.0.1) é usado para acessar a Internet.

Quando executo o script, tudo parece bem por dentro da LAN. No entanto, todas as portas que foram encaminhadas no roteador para 192.168.0.140 de repente param de responder.

Percebi que o DHCP do roteador usa o endereço MAC para identificar o servidor e que br0 tem um MAC diferente de eth0 . Então eu adicionei

ifconfig $br hw ether d0:50:99:3b:4e:ff

no final do script de bridging para fazer com que br0 tenha o mesmo MAC que eth0 . E realmente atribui o MAC 'correto' a br0 , mas, infelizmente, não resolve o problema.

O problema parece estar no próprio roteador, porque o servidor ainda pode ser acessado pela LAN.

    

Answer 1

Tudo bem, a resposta é bem simples. Quando a ponte sobe, a rota do gateway padrão desaparece. Então

route add default gw 192.168.0.1 br0

funciona como um encanto.