Відповіді ARP містять неправильну MAC-адресу

У мене робот під управлінням Linux з провідними та бездротовими адаптерами. Коли я завантажуюся, він підключається до бездротового штрафу. Коли я призначаю IP-провідник (статично або за допомогою DHCP), схоже, він працює. Як і в, ifconfigпоказує правильний IP та routeпоказує правильні маршрути. Однак, коли я роблю запит ARP провідного IP, відповідь ARP містить бездротовий MAC.

??? На робота не працює міст, так чому б мені не отримати провідний MAC ???

Коли провід від'єднаний, провідний IP відповідає на ping ...

Чому робот відповідає по бездротовому інтерфейсу на IP-запити провідним ???

EDIT: як дротовий, так і бездротовий адаптери в одній і тій самій підмережі IP. Я роблю запит ARP з комп'ютера (пробували з різними комп'ютерами) в одній і тій самій підмережі IP.

відповідне виведення ifconfig:

eth0      Link encap:Ethernet  HWaddr 00:01:C0:04:BD:F7  
          inet addr:192.168.0.110  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
ra0       Link encap:Ethernet  HWaddr 24:3C:20:06:3E:6D  
          inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:59 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:31023598 (29.5 MiB)  TX bytes:85640627 (81.6 MiB)

відповідний вихідний маршрут:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ra0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Це дуже розрізний Linux, тому у мене немає таких інструментів як artptables, iptables, sysctl, brctl тощо.

EDIT: схема за запитом

EDIT: Я скидаю трафік і дивлюсь на таблицю ARP. Запит ARP 192.168.0.110 повертає відповідь ARP, що містить 24: 3C: 20: 06: 3E: 6D. Джерело MAC пакета відповідей ARP також становить 24: 3C: 20: 06: 3E: 6D. Я спробував зіграти з _filter, _ignore та _announce, як згадувалося тут , але безрезультатно.

EDIT: встановлення шлюзу (на будь-якому інтерфейсі) не має значення (як і не повинно).

EDIT: це спрацювало чудово на попередній версії ОС (на основі відкритої). чи можливо вони щось змінили?

Те, що ви бачите, - це нормальна поведінка, коли у вас є два інтерфейси в одній мережі. Це описано в цій статті LWN .

Коли ви говорите, що отримуєте відповідь 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 - зробити перевірку джерела за зворотним шляхом, як зазначено в RFC1812
        Рекомендована опція для одиночних хостів та мережевих каналів
        маршрутизатори. Може спричинити неприємності для складних (без циклу)
        мережі, які працюють повільно ненадійним протоколом (на зразок RIP),
        або за допомогою статичних маршрутів.

    0 - Немає перевірки джерела.

    conf / all / rp_filter також має бути встановлено на TRUE, щоб зробити перевірку джерела
    на інтерфейсі

    Значення за замовчуванням - 0. Зверніть увагу, що деякі дистрибутиви це дозволяють
    в сценаріях запуску.

arp_filter - BOOLEAN
    1 - Дозволяє мати кілька мережевих інтерфейсів на одному
    підмережі та відповіді на ARP для кожного інтерфейсу
    на основі того, чи буде ядро ​​спрямовувати пакет з
    ARP'd IP-інтерфейс із цього інтерфейсу (тому ви повинні використовувати джерело
    на основі маршрутизації для цього). Іншими словами, це дозволяє контролювати
    з яких карток (як правило, 1) відповість на запит arp.

    0 - (за замовчуванням) Ядро може відповідати на запити arp з адресами
    з інших інтерфейсів. Це може здатися неправильним, але зазвичай це робить
    сенс, тому що це збільшує шанс на успішне спілкування.
    IP-адреси належать повному хосту в Linux, а не
    конкретні інтерфейси. Тільки для більш складних налаштувань, таких як завантаження
    врівноважуючи, чи викликає така поведінка проблеми.

    arp_filter для інтерфейсу буде ввімкнено, якщо хоча б один із
    conf / {all, для інтерфейсу} / arp_filter встановлено значення TRUE,
    він буде відключений інакше

Для більш ретельного лікування дивіться цю статтю:

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

Я знаю, що це стара проблема, але нещодавно я зіткнувся з точно такою ж ситуацією із вбудованим пристроєм. Пристрій має як інтерфейс Ethernet, так і Wi-Fi, і вимоги полягають у тому, що обидва інтерфейси можуть бути активними та в одній мережі в будь-який час, але мережевий трафік повинен бути спрямований через "бажаний" інтерфейс.

Більшість користувачів не налаштовували б там пристрої таким чином, але теоретично це повинно бути можливо.

Ми спочатку вирішили проблеми з маршрутизаторами Netgear, оскільки вони повідомили про конфлікт IP-адрес - 2 MAC адреси ділилися одним IP-адресою. Мабуть, маршрутизатор почав би погано поводитися за цим сценарієм і зіпсувати мережу користувачів.

Я створив приватну мережу, яка містила лише маршрутизатор (ethernet + wifi), ноутбук Windows (лише Ethernet) та вбудований пристрій (ethernet + wifi). Використовуючи wireshark, tcpdump на пристрої та arp на windows, я бачу таку поведінку:

1. Ifconfig на пристрої показує чіткі wln та IP-адреси Ethernet та окремі MAC-адреси
2. Іноді (дуже рідко) і arp –a з Windows показує правильну комбінацію IP-MAC.
3. Більшість часу arp –a з windows показує, що і wln, і eth0 мають однакову MAC-адресу
4. Коли pinging або wln, або eth0 з Windows, відповідь ping надходить від wln і дуже рідко від eth0. tcpdump показує, що wln відповів лише на 1 з 4 пінгерів (наприклад)
5. Коли Windows надсилає arp "хто має" повідомлення для eth0 IP - і інтерфейси eth0, і wln відповідають, кажучи, що вони мають цей IP

Я вважаю, що пункт 3 викликаний пунктом 5. Таблиці арп переплутуються через те, що wln відповідає на арп-повідомлення, на які повинен відповідати лише eth0. Я вважаю, що пункт 4 також викликаний пунктом 5. Ping надсилається на основі MAC-адреси, і оскільки останнє отримане арп-повідомлення було отримано від wln, в якому вказано, що воно має IP0 eth, пінг-файли неправильно перенаправлені до інтерфейсу 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

Оскільки це спрацювало чудово на попередній версії ОС (на основі відкритої), моє рішення полягало в тому, щоб чекати наступної версії ОС. Я найкраще здогадувався, що модуль бездротового ядра баггі.

Слідом за коментарем Insyte.

Давайте кілька імен:

• PC1 - праворуч зверху
• PC2 - верхній лівий
• PC3 - знизу зліва

У вас робот може бути доступний з трьох ПК через дротовий та бездротовий носії. А оскільки вони знаходяться в одній підмережі, ви точно не можете сказати, через який шлях пройшов арп-запит для ваших провідних носіїв інформації. Під тим, що я маю на увазі, коли комутатор передає запит на arp-запит, ваш робот отримує його на обох інтерфейсах [з посиланням на вашу діаграму], тому він отримує запит arp для IP на дротових носіях на бездротових носіях теж швидше за все , він відповів фізичною адресою бездротового носія для коробки, в якій налаштовано IP-адресу

У мене виникало це питання в минулому, воно було не точно для вашого, але було схожим. За замовчуванням відповіді Linux з фізичною адресою інтерфейсу отримує запит arp незалежно від того, на який інтерфейс налаштовано IP-адресу. Тож у вашому випадку підключіть PC3 до інтерфейсу 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 на своїх ПК, і ваш робот буде доступний на будь-якому двох ІС. У вас не може бути двох вихідних шляхів для тієї ж підмережі на одному хості. Якщо тільки щось не змушує вашого робота віддати перевагу один одному. Ваш робот може пройти лише один шлях для надсилання пакетів з нього.

Деякі показання: arp_announce , arp_ignore

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

route add default gw 192.168.0.1