Назад | Перейти на главную страницу

Доступ к Ethernet-мосту Linux можно получить через маршрутизатор

Я запускаю Debian 8, и мне нужно связать интерфейс касания tap0 к eth0 (пытаюсь настроить сервер OpenVPN). Я использую стандартный сценарий моста со страницы справки 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

где 192.168.0.140 - это IP-адрес, зарезервированный для этого сервера DHCP маршрутизатора. Маршрутизатор (192.168.0.1) используется для доступа в Интернет.

Когда я запускаю сценарий, все выглядит нормально внутри локальной сети. Однако все порты, которые были перенаправлены в маршрутизаторе на 192.168.0.140, внезапно перестают отвечать.

Я заметил, что DHCP маршрутизатора использует MAC-адрес для идентификации сервера, и что br0 имеет другой MAC, чем eth0. Я добавил

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

в конце сценария моста, чтобы br0 иметь тот же MAC, что и eth0. И он действительно назначает «правильный» MAC-адрес для br0, но, к сожалению, проблему не решает.

Проблема, похоже, в самом маршрутизаторе, потому что к серверу все еще можно получить доступ из локальной сети.

Хорошо, ответ довольно прост. Когда мост поднимается, маршрут для шлюза по умолчанию исчезает. Так

route add default gw 192.168.0.1 br0

работает как оберег.