VE-02 отвечает на ARP в чужих сетях

[san]

В процессе настройки схемы на производстве обнаружили одну странную вещь в поведении VE-02:
Сергей по ошибке установил порту LAN платы некорректную настройку маски,
по проекту было:
LAN 192.168.3.133
mask LAN 255.255.255.252
Wan 192.168.3.164
mask WAN 255.255.255.0
Proxy ARP - включен

Сергей по ошибке установил mask LAN 255.255.255.0. В результате плата начала пересылать ответы ARP во всех сетях(в том числе и в сети 192.168.0.0), подставляя свой мак адрес в качестве адреса источника, таким поведением плата сломала всю сеть к которой была подключена.
Для демонстрации, я снял дамп в сети WAN(снаружи платы), отфильтровав пакеты по адресу платы (02:ad:c5:00:01:fb).
Дамп и конфиг платы(до внесения ошибки) прилагаю

[san]

прошивка VE-02 ревизии 45

[alx]

Вынужден напомнить о том, что на стартовой странице проекта есть специальный раздел, в котором даны рекомендации о том, как сделать хороший баг-рипорт. Если кратко его резюмировать, то хороший баг-рипорт состоит из трех основных компонентов:

• описания того, что с устройством делали;
• описания того, что ожидали получить в результате;
• описания того, что получили в действительности.

Этот тикет имеет тип "баг", из чего я заключаю, что что-то в описанном поведении платы VE-02 ты считаешь неправильным (ошибочным). Однако в описании тикета не написано, что именно (отсутствует второй из перечисленных выше компонентов хорошего баг-рипорта). В результате этого я совершенно не понимаю, что же я должен с этим тикетом сделать (кроме, конечно же, прочтения)...

Уточни, пожалуйста, что ты ожидал получить в результате описанных тобой действий с платой VE-02.

[san]

Я ожидал что неправильная настройка сломает маршрутизацию в LAN, и возможно ARP в сети WAN.
Однако неожиданно, что пострадали чужие (для платы) сети .0.0, .0.1, .0.20

[alx]

Спасибо за уточнение.

Провел ряд экспериментов: загрузил в плату VE-02 приложенную к тикету конфигурацию, после чего изменил маску сети LAN на 255.255.255.0. Описанная проблема не воспроизвелась - плата не отвечает на ARP запросы из "чужих" сетей. Более того, плата перестала отвечать даже на запросы адреса 192.168.3.134 (на которые отвечала до изменения маски LAN на ошибочную).

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

Пока я вынужден закрыть тикет, так как исчерпал возможные попытки воспроизвести описанное поведение VE-02. Если появится акая-то новая информация, переоткрой тикет.

[san]

Странно, я воспроизводил у себя, просто введя в настройки одинаковые сети для WAN и LAN.
Я подозреваю что проблема может быть в формулировке "отвечает на запросы", возможно она просто пересылает чужие запросы от своего адреса, но я не уверен.

[alx]

Replying to san:

Странно, я воспроизводил у себя, просто введя в настройки одинаковые сети для WAN и LAN.

Действительно, странно...

Я подозреваю что проблема может быть в формулировке "отвечает на запросы", возможно она просто пересылает чужие запросы от своего адреса, но я не уверен.

Поясню, что я имел в виду, написав "не отвечает". На входе в интерфейс eth0 есть запросы ARP с адресами сетей 192.168.[0,1,20].0/24 (я их вижу tcpdump'ом), но никаких ответов на эти запросы я тем же самым tcpdump'ом не вижу (делал tcpdump -i eth0 -pnv arp and ether src 02:ad:c5:00:01:17 - в результате видел только запросы от самой VE-02, и ответы на запросы адреса 192.168.3.164). Еще уточню, что я смотрел tcpdump'ом в самой плате VE-02, а не во внешней сети.

Также на всякий случай уточню, что во время проведения экспетиментов чтобы не нарушить работу других хостов я в коммутаторе SW-01 заблокировал ARP пакеты, исходящие из VE-02 на любые MAC адреса кроме MAC адреса моего компьютера. На поведение самой VE-02 это повлиять не могло.

[san]

Ой, я вспомнил существенное условие воспроизведения.
Такое поведение воспроизводилось только после перезапуска VE-02. Т.е. после установки плохих настроек нужно перезапустить плату, и тогда она будет вести себя как описано.

[alx]

Replying to san:

Такое поведение воспроизводилось только после перезапуска VE-02.

Хорошо. Описанное поведение мне удалось воспроизвести. Но теперь непонятно, что с этим можно сделать, так как при описанных настройках плата по сети недоступна, и получить какую-либо дополнительную информацию, которая могла бы подсказать о причинах такого поведения, не представляется возможным... :(

А при изменении настроек на "нормальные" плата тоже начинает вести себя нормально. :)

Я еще немного подумаю, но, скорее всего, придется "оставить как есть" (c).

[alx]

Провел еще один эксперимент: при установке LAN интерфейсу маски 255.255.254.0 проблема не проявляется. Можно предположить, что проблему триггерит установка одинаковой сети на оба интерфейса вместе с proxy_arp. Если так, то, наверное, можно проверять это конкретное условие в веб-интерфейсе и выдавать предупреждение при попытке записать такие настройки...

[san]

плата по сети недоступна, и получить какую-либо дополнительную информацию, которая могла бы подсказать о причинах такого поведения, не представляется возможным... :(

Могу попробовать соединить com порт твоего компьютера с com портом платы...

[alx]

Replying to san:

Могу попробовать соединить com порт твоего компьютера с com портом платы...

Если твоя попытка увенчается успехом, будет шанс получить какую-то еще полезную информацию. Правда пока не представляю какую... :)

[alx]

Провел еще один эксперимент: установил одинаковые маски, но без включения proxy_arp. Уже после перезагрузки включил proxy_arp. Проблема воспроизвелась. Какой из этого можно сделать вывод, пока не понимаю...

[san]

Replying to alx:

Replying to san:

Могу попробовать соединить com порт твоего компьютера с com портом платы...

Если твоя попытка увенчается успехом, будет шанс получить какую-то еще полезную информацию. Правда пока не представляю какую... :)

подключил

[alx]

Провел еще один эксперимент. В программе перенес установку маски интерфейса чуть выше по тексту (скорее из эстетических соображений, чем предполагая, что это как-то поможет - там между установкой адреса и маски интерфейсу eth2 "вклинился" рестарт dnsmasq). Результат - проблема воспроизводиться перестала (сделал три попытки)! Более того, после загрузки плата доступна из сети по адресу 192.168.3.164, в нее можно зайти по ssh.

[alx]

In 2159/sip_ua:

Перенес установку маски сети eth2 чуть выше по тексту
(до рестарта dnsmasq). По неизвестной причине это
устранило проблему, описанную в #415. Closes #415.