Я прочитал довольно много информации по этой теме в последнее время - потому что я действительно не привык работать с такими "низкими слоями" - но я не могу указать пальцем на то, что я делаю неправильно. Поверьте мне, я старался ;)
Я хотел бы подключить облачный сервер, так как он является частью нашей корпоративной локальной сети.
Я решил создать мост уровня 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
После всех этих часов я был совершенно уверен, что то, что я делаю, не так уж и далеко от истины.
Я решил подключить тот же экземпляр облака к новому хосту в моей домашней локальной сети. Он заработал без особых проблем.
Я до сих пор не уверен, что именно является причиной первоначальной проблемы (может быть, дорогостоящее оборудование в корпоративной сети?), но, по крайней мере, я знаю, что это не из-за меня :)