☰

Linux-мост с интерфейсами SSH-подключения (облако -> LAN)

tag-icon • tag-icon networking bridge
Linux-мост с интерфейсами SSH-подключения (облако -> LAN)

Я прочитал довольно много информации по этой теме в последнее время - потому что я действительно не привык работать с такими "низкими слоями" - но я не могу указать пальцем на то, что я делаю неправильно. Поверьте мне, я старался ;)

Я хотел бы подключить облачный сервер, так как он является частью нашей корпоративной локальной сети.

Я решил создать мост уровня 2 ( br0), основная причина в том, что мне нужно получать широковещательные пакеты из локальной сети, чтобы облачный сервер мог видеть устройство.

Я создал маршрут на облачном сервере, чтобы направить подсеть LAN через tap0интерфейс.

Все iptablesони ebtablesимеют политику по умолчанию ACCEPT(правка: правила не определены и даже отключены).

Таблица ARP на клиенте локальной сети отображает запись IP/MAC облачного сервера.

Я могу выполнить ping br0из облака и могу выполнить ping облачной машины tap0(статически определенный IP в клиентской подсети) из клиента локальной сети.

Когда я делаю это tcpdumpна обоих интерфейсах ( cloud tap0 and LAN br0), я вижу проходящий трафик локальной сети (STP, IP, ARP, ...).

Вот тут-то все и заканчивается плохо: я не могу связаться с другими машинами в локальной сети (когда я пингую шлюз локальной сети, получаю сообщение «Узел назначения недоступен». При выполнении теста с другими компьютерами локальной сети ответа не получаю).

PS: не заставляйте меня устанавливать OpenVPN ^^

редактировать:

$ bridge link

2: eth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 
4: tap0 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100

$ brctl show

bridge name     bridge id               STP enabled     interfaces
br0             8000.00155da90b0b       no              eth0
                                                        tap0

$ ip link

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 8e:15:41:dc:70:b0 brd ff:ff:ff:ff:ff:ff
11: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:a9:0b:0b brd ff:ff:ff:ff:ff:ff

решение1

После всех этих часов я был совершенно уверен, что то, что я делаю, не так уж и далеко от истины.

Я решил подключить тот же экземпляр облака к новому хосту в моей домашней локальной сети. Он заработал без особых проблем.

Я до сих пор не уверен, что именно является причиной первоначальной проблемы (может быть, дорогостоящее оборудование в корпоративной сети?), но, по крайней мере, я знаю, что это не из-за меня :)

Связанный контент