Проблема с openvpn мостом

Кто распарсил - просим внеочередную звезду.

Запутанно описал проблему? Попробую иначе.

Есть два маршрутизатора с прошивкой openwrt

маршрутизатор1 (wan 192.168.1.5, lan 10.0.0.1) openvpn server маршрутизатор2 (wan 192.168.1.2, lan 10.0.0.5) openvpn client

Между маршрутизаторами есть openvpn соединение в режиме моста.

далее кейс проблемы:

1) к маршрутизатору1 подключается устройство (macbook) по wifi, оно видит маршрутизатор2 - все хорошо

2) к маршрутизатору2 подключается тоже самое устройство (macbook) по wifi, оно видит маршрутизатор1 - все хорошо

3) к маршрутизатору1 снова подключается тоже самое устройство (macbook) по wifi, оно НЕ видит маршрутизатор2 - проблема (!)

При этом анализ траффика показывает, что в момент когда устройство (macbook) подключенное на 3 шаге к к маршрутизатору1 пингует маршрутизатор2, оно шлет ARP запрос кто есть 10.0.0.5? Это ARP запрос виден на tap0 интерейсе маршрутизатора1, далее его видно на tap0 интерейсе маршрутизатора2, маршрутизатор2 отправляет ARP ответ со своим MAC-адресом, но этот ARP уже не виден на tap0 маршрутизатор1 и соотвественно самому устройству (macbook)

Я так понимаю это тестовый стенд? На уровне предположения, посмотрите arp таблицы как на первом так и на втором роутере на предмет мака macbook

Macbook есть в ARP таблицах обоих маршрутизаторов, там указан правильный ip выданный при последнем подключении к маршрутизатору1 (шаг 3)

проблема проявляется только в одном случае - после того как мак маршрутизартору впн-серверу после подключения к маршрутизатору впн-клиенты, при этом если подключиться к маршрутизатору впн-серверу а потом к маршрутизатору впн-клиенту, такой проблемы не наблюдается

решить проблему помогает ребут любого из маршрутизаторов

Macbook есть в ARP таблицах обоих маршрутизаторов, там указан правильный ip выданный при последнем подключении к маршрутизатору1 (шаг 3)

А на каком интерфейсе он приписан у них?

после того как мак маршрутизартору впн-серверу после подключения к маршрутизатору впн-клиенты

Вот вы сами можите понять что написали?

Mac прописан в обоих случаях на интерфейсе br-lan.

br-lan это мост который влючает в том числе интерфейсы wifi и tap

сори за описание, мысли текут быстрее чем руки печатают, попробую перефразировать

проблема проявляется только в одном случае - когда макбук подключается к маршрутизартору впн-серверу после подключения к маршрутизатору впн-клиенту, при этом если подключиться сначала к маршрутизатору впн-серверу, а потом к маршрутизатору впн-клиенту, такой проблемы не наблюдается

Подобным извращением не занимался, так что сорри, даже не знаю в какую сторону смотреть.

Две удаленные квартиры объеденены в сеть в режиме моста. Необходимость моста обусловлена тем, что с одной стороны есть dnla сервак. Есть проблема, если я подключаюсь со стороны клиента, а потом со стороны сервера с ноутбука, то часть сети со стороны клиента становиться не видна, причину я описал выше. В чем извращение?

Простите, слово «извращением» в кавычках не написал.

В смысле собирать в бридж усе в одном флаконе включая ovpn.

Я очень поверхностно знаком с сетевыми протоколами, поэтому буду рад любым дополнительным сведениям. В моей практике я сталкивался с прошивками маршрутизаторов ddwrt openwrt - вайфай и ланпорты по умолчанию там всегда объединены в мост, поэтому мне кажется логичным tap интерфейс включать сюда же?

если я подключаюсь со стороны клиента, а потом со стороны сервера с ноутбука, то часть сети со стороны клиента становиться не видна

Когда VPN построен на основе TUN, подобные косяки обычно разруливаются через метрику маршрутов.
Для TAP, полагаю, надо разбираться с ARP-кэшами и фаерволами.

К сожалению tun в моем случае не подходит, для dlna мне нужна общая единая подсеть с бродкастами.

Что касается фаервола, то при первом подключение с любой стороны, все работает правильно. Так же правильно работает если устройство после впн-сервера подключается к впн-клиенту, а вот если после впн-клинета подключиться к впн-серверу, то тут: до устройства не возращается ARP-ответ. Т.е. ARP бродкаст уходит по назначению (достигает искомое устройство), а вот ответ не возращается ... вот на ARP-кеш похоже, видимо ответ уходит куда-то не туда ...

Перепробовал разные версии прошивок openwrt, менял местами роутер-сервер и роутер-клиент (роутеры разных производителей, думал может проблема в каком-то конкретном роутере) - ничего не помогло в итоге прихожу к одному и тому же.

при первом подключение с любой стороны, все работает правильно

Да, имеет смысл копнуть в сторону ARP-кэша: sysctl net.ipv4 | grep arp
В особенности следует обратить внимание на arp_filter, proxy_arp, а также таймауты:
http://stackoverflow.com/questions/15372011/configuring-arp-age-timeout

Mac прописан в обоих случаях на интерфейсе br-lan.

А дальше? Команда ″brctl showmacs br-lan″, чтобы определить номер порт, где mac и ″brctl showbr br-lan″ чтобы определить интерфейс по номеру порта.

sysctl net.ipv4 | grep arp net.ipv4.conf.all.arp_accept = 0 net.ipv4.conf.all.arp_announce = 0 net.ipv4.conf.all.arp_filter = 0 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_notify = 0 net.ipv4.conf.all.proxy_arp = 0 net.ipv4.conf.all.proxy_arp_pvlan = 0 net.ipv4.conf.br-lan.arp_accept = 0 net.ipv4.conf.br-lan.arp_announce = 0 net.ipv4.conf.br-lan.arp_filter = 0 net.ipv4.conf.br-lan.arp_ignore = 1 net.ipv4.conf.br-lan.arp_notify = 0 net.ipv4.conf.br-lan.proxy_arp = 0 net.ipv4.conf.br-lan.proxy_arp_pvlan = 0 net.ipv4.conf.default.arp_accept = 0 net.ipv4.conf.default.arp_announce = 0 net.ipv4.conf.default.arp_filter = 0 net.ipv4.conf.default.arp_ignore = 1 net.ipv4.conf.default.arp_notify = 0 net.ipv4.conf.default.proxy_arp = 0 net.ipv4.conf.default.proxy_arp_pvlan = 0 net.ipv4.conf.eth0.arp_accept = 0 net.ipv4.conf.eth0.arp_announce = 0 net.ipv4.conf.eth0.arp_filter = 0 net.ipv4.conf.eth0.arp_ignore = 0 net.ipv4.conf.eth0.arp_notify = 0 net.ipv4.conf.eth0.proxy_arp = 0 net.ipv4.conf.eth0.proxy_arp_pvlan = 0 net.ipv4.conf.eth0.1.arp_accept = 0 net.ipv4.conf.eth0.1.arp_announce = 0 net.ipv4.conf.eth0.1.arp_filter = 0 net.ipv4.conf.eth0.1.arp_ignore = 1 net.ipv4.conf.eth0.1.arp_notify = 0 net.ipv4.conf.eth0.1.proxy_arp = 0 net.ipv4.conf.eth0.1.proxy_arp_pvlan = 0 net.ipv4.conf.eth0.2.arp_accept = 0 net.ipv4.conf.eth0.2.arp_announce = 0 net.ipv4.conf.eth0.2.arp_filter = 0 net.ipv4.conf.eth0.2.arp_ignore = 1 net.ipv4.conf.eth0.2.arp_notify = 0 net.ipv4.conf.eth0.2.proxy_arp = 0 net.ipv4.conf.eth0.2.proxy_arp_pvlan = 0 net.ipv4.conf.lo.arp_accept = 0 net.ipv4.conf.lo.arp_announce = 0 net.ipv4.conf.lo.arp_filter = 0 net.ipv4.conf.lo.arp_ignore = 1 net.ipv4.conf.lo.arp_notify = 0 net.ipv4.conf.lo.proxy_arp = 0 net.ipv4.conf.lo.proxy_arp_pvlan = 0 net.ipv4.conf.tap0.arp_accept = 0 net.ipv4.conf.tap0.arp_announce = 0 net.ipv4.conf.tap0.arp_filter = 0 net.ipv4.conf.tap0.arp_ignore = 1 net.ipv4.conf.tap0.arp_notify = 0 net.ipv4.conf.tap0.proxy_arp = 0 net.ipv4.conf.tap0.proxy_arp_pvlan = 0 net.ipv4.conf.wlan0.arp_accept = 0 net.ipv4.conf.wlan0.arp_announce = 0 net.ipv4.conf.wlan0.arp_filter = 0 net.ipv4.conf.wlan0.arp_ignore = 1 net.ipv4.conf.wlan0.arp_notify = 0 net.ipv4.conf.wlan0.proxy_arp = 0 net.ipv4.conf.wlan0.proxy_arp_pvlan = 0 net.ipv4.conf.wlan1.arp_accept = 0 net.ipv4.conf.wlan1.arp_announce = 0 net.ipv4.conf.wlan1.arp_filter = 0 net.ipv4.conf.wlan1.arp_ignore = 1 net.ipv4.conf.wlan1.arp_notify = 0 net.ipv4.conf.wlan1.proxy_arp = 0 net.ipv4.conf.wlan1.proxy_arp_pvlan = 0

А дальше? Команда ″brctl showmacs br-lan″, чтобы определить номер порт, где mac и ″brctl showbr br-lan″ чтобы определить интерфейс по номеру порта.

«brctl showbr br-lan» не работает, но работает «brctl show»

bridge name	bridge id		STP enabled	interfaces
br-lan		7fff.16dae9f9118b	no		eth0.1
							tap0
							wlan1
							wlan0

C обоих сторон такие мосты.

Сейчас еще смотрел как меняется таблица ARP

Первое подключение к роутеру-серверу

Ноутбуку выдается ip по dhcp, запись ARP появляется на роутере-сервере и на роутере клиента. Все работает, все пингуется.

Второе подключение к роутеру-клиенту

Со стороны роурера клиента выдается новый ip по dhcp (я использую два dhcp сервера с каждой стороны, чтобы в случае разрыва моста они были независмые, кроме того мне надо чтобы у них были разные шлюзы для выхода в интеренет), новая запись ARP появляется на роутере-клиенте, т.е. на роутере клиенте сейчас две записи ARP c MAC адресом ноутбука. Все работает, все пингуется.

Третье подключение к роутеру-серверу

Ноутбуку выдается тот же ip по dhcp, что и при первом подключении. Таблицы ARP остались в том виде как при втором подключении. Ноутбук не пигует роутер-клиент.

Дополнение:

Перезагрузка openvpn сервера так же помогает решить эту проблему.

Парни еще кое что нарыл.

На стороне vpn сервера в status логе есть такая информация

OpenVPN CLIENT LIST
Updated,Wed Nov  9 15:37:39 2016
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
my-client,192.168.1.5:1194,122215,113289,Wed Nov  9 15:34:39 2016
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
0a:00:27:00:xx:xx,my-client,192.168.1.5:1194,Wed Nov  9 15:37:38 2016
00:18:e7:e9:xx:xx,my-client,192.168.1.5:1194,Wed Nov  9 15:35:20 2016
20:cf:30:ea:xx:xx,my-client,192.168.1.5:1194,Wed Nov  9 15:34:42 2016
e0:ac:cb:7c:xx:xx,my-client,192.168.1.5:1194,Wed Nov  9 15:37:32 2016
GLOBAL STATS
Max bcast/mcast queue length,1
END

Так вот после того как ноутбук подключается со стороны клиента он попадает в эту ROUTING TABLE, которая не изменяется в том числе когда ноутбук подключается со стороны сервера. Вероятно по этому все запросы туда перенаправляются.

ПС 192.168.1.5 в настоящий момент это wan адрес роутера клиента, а все перечисленные здесь

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

--stale-routes-check n [t]

Remove routes haven't had activity for n seconds (i.e. the ageing time). This check is ran every t seconds (i.e. check interval).

If t is not present it defaults to n

This option helps to keep the dynamic routing table small. See also --max-routes-per-client