Ответы ARP содержат неправильный MAC-адрес

То, что вы видите, является нормальным поведением, когда у вас есть два интерфейса в одной сети. Это описано в эта статья LWN.

Я знаю, что это старая проблема, но недавно я столкнулся с такой же ситуацией со встроенным устройством. Устройство имеет интерфейс Ethernet и Wi-Fi, и требования заключаются в том, что оба интерфейса могут быть активными и находиться в одной сети в любое время, но сетевой трафик должен маршрутизироваться через «предпочтительный» интерфейс.

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

Сначала мы подняли проблемы с маршрутизаторами Netgear, потому что они сообщали о конфликте IP-адресов - два MAC-адреса использовали один IP-адрес. Очевидно, в этом сценарии маршрутизатор начнет плохо себя вести и нарушит работу пользовательской сети.

Я создал частную сеть, которая содержала только маршрутизатор (Ethernet + Wi-Fi), ноутбук с Windows (только Ethernet) и встроенное устройство (Ethernet + Wi-Fi). Используя wirehark, tcpdump на устройстве и arp на Windows, я могу увидеть следующее поведение:

1. Ifconfig на устройстве показывает разные IP-адреса wln и Ethernet, а также разные MAC-адреса.
2. Иногда (очень редко) и arp –a из окон показывает правильную комбинацию IP-MAC.
3. В большинстве случаев arp –a из окон показывает, что wln и eth0 имеют одинаковый MAC-адрес.
4. При отправке ping-запроса wln или eth0 из окон ответ ping исходит от wln и очень редко от eth0. tcpdump показывает, что wln ответил только на 1 из 4 эхо-запросов (например)
5. Когда Windows отправляет сообщение arp «who has» для IP-адреса eth0 - интерфейсы eth0 и wln отвечают, что у них есть этот IP-адрес.

Я считаю, что пункт 3 вызван пунктом 5. Таблицы arp перепутались, потому что wln отвечает на сообщения arp, на которые должен отвечать только eth0. Я считаю, что пункт 4 также вызван пунктом 5. Ping отправляется на основе MAC-адреса, и поскольку последнее полученное сообщение arp было от wln, в котором говорилось, что он имеет IP-адрес eth0, эхо-запросы неправильно маршрутизируются на интерфейс wln.

После долгих поисков и испытаний решение оказалось действительно простым. См. Эту статью - http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

Сетевые драйверы ядра Linux настроены таким образом, что при получении запроса arp для известного интерфейса (даже если он получен на другом интерфейсе) он будет отвечать на запрос arp.

Этот параметр решает проблему:

echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

Пояснение:

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied

Когда вы говорите, что получаете ответ ARP для неправильного интерфейса, вы действительно сбрасываете трафик или просто смотрите на итоговую таблицу ARP? Возможно, вы получаете ответы ARP для обе интерфейсы ...

В любом случае, я считаю, что ответ на вашу проблему заключается в правильном манипулировании rp_filter и arp_filter. Документация по каждому из них приведена ниже.

Я предлагаю сначала попробовать это:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

Вы может необходимо также внести это изменение:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

rp_filter - BOOLEAN
    1 - do source validation by reversed path, as specified in RFC1812
        Recommended option for single homed hosts and stub network
        routers. Could cause troubles for complicated (not loop free)
        networks running a slow unreliable protocol (sort of RIP),
        or using static routes.

    0 - No source validation.

    conf/all/rp_filter must also be set to TRUE to do source validation
    on the interface

    Default value is 0. Note that some distributions enable it
    in startup scripts.

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

Для более тщательного лечения см. Эту статью:

http://www.embedded-bits.co.uk/tag/rp_filter/

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

В продолжение комментария Insyte.

Давайте сделаем несколько имен:

• PC1 - вверху справа
• PC2 - Вверху слева
• PC3 - внизу слева

Потому что ваш робот доступен с 3 ПК через проводные и беспроводные сети. И поскольку они находятся в одной подсети, вы не можете точно сказать, через какой путь прошел запрос arp для вашего проводного носителя. Под этим я подразумеваю, что когда коммутатор транслирует запрос arp, ваш робот получает его на обоих интерфейсах [ссылаясь на вашу диаграмму], поэтому он получает запрос arp для IP на проводном носителе на беспроводные СМИ слишком высока вероятность, что в ответ будет указан физический адрес беспроводного носителя, поскольку в коробке настроен этот IP-адрес

У меня была эта проблема в прошлом, она не была точной вашей, но была похожа. По умолчанию linux отвечает физическим адресом интерфейса, который получает запрос arp, независимо от того, на каком интерфейсе настроен IP. Итак, в вашем случае подключите ПК3 к интерфейсу eth0 робота напрямую и выполните запрос arp для 192.168.0.101, он ответит вам физическим адресом интерфейса eth0 вместо ra0.

Мой сценарий развертывания был:

[RTR] | ------------ eth0 --- [сервер]
| -------- | switch1 | ----- eth1 ----- [сервер]

Это тот же переключатель, к которому подключаются оба интерфейса. Надеюсь, что это поможет вам.

Маршрутизатор имел первичный и вторичный IP-адрес, настроенный на его интерфейсе для двух разных сетей на двух разных интерфейсах на сервере. Но получив запрос arp на eth1 для IP-адреса eth0, он ответил с физическим адресом eth1

Чтобы предотвратить это, у меня до сих пор работало следующее:

# echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore

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

Рекомендации: я бы порекомендовал вам настроить две разные подсети (скажем, 192.168.1.x / 24 на ra0 и 192.168.2.x / 24 на eth0), вы можете использовать псевдонимы IP на своих ПК, и ваш робот будет доступен через любой из двух IP-адресов. У вас не может быть двух исходящих путей для одной подсети на одном хосте. Нет, если есть что-то, что заставляет вашего робота предпочитать одного другому. Ваш робот может использовать только один путь для отправки пакетов из него.

Некоторые чтения: arp_announce, arp_ignore

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

route add default gw 192.168.0.1