ARP-ответы содержат неверный MAC-адрес
У меня есть робот под управлением Linux с проводными и беспроводными адаптерами. Когда я загружаюсь, он подключается к беспроводной сети нормально. Когда я назначаю IP для проводного (статически или с DHCP), это выглядит как работает. Как в, ifconfig
показывает правильный IP и route
показывает правильные маршруты. Однако, когда я делаю запрос ARP для проводного IP, ответ ARP содержит беспроводной MAC.
??? На роботе нет моста, так почему я не могу получить проводной MAC???
Когда провод отключен, проводной IP отвечает на пинг...
Почему робот отвечает по беспроводному интерфейсу на IP-запросы в проводной сети???
РЕДАКТИРОВАТЬ: проводной и беспроводной адаптеры в одной 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 и т. Д.
РЕДАКТИРОВАТЬ: диаграмма в соответствии с просьбой
РЕДАКТИРОВАТЬ: я сбрасываю трафик и смотрю на таблицу ARP. Запрос ARP 192.168.0.110 возвращает ответ ARP, содержащий 24:3C:20:06:3E:6D. MAC-адрес исходного ответного пакета ARP также составляет 24:3C:20:06:3E:6D. Я пробовал возиться с _filter, _ignore и _announce, как упоминалось здесь, но безрезультатно.
РЕДАКТИРОВАТЬ: установка шлюза (на любом интерфейсе) не имеет значения (как это не должно).
РЕДАКТИРОВАТЬ: это работало нормально на предыдущей версии ОС (на основе openembedded). Возможно, они что-то изменили?
6 ответов
То, что вы видите, - это нормальное поведение, когда у вас есть два интерфейса в одной сети. Это описано в этой статье LWN.
Я знаю, что это старая проблема, но недавно я столкнулся с точно такой же ситуацией со встроенным устройством. Устройство имеет как интерфейс Ethernet, так и интерфейс Wi-Fi, и требования заключаются в том, что оба интерфейса могут быть активными и находиться в одной и той же сети в любое время, но сетевой трафик должен маршрутизироваться через "предпочтительный" интерфейс.
Большинство пользователей не будут настраивать свои устройства таким образом, но теоретически это должно быть возможно.
Сначала мы обнаружили проблемы с маршрутизаторами Netgear, поскольку они сообщали о конфликте IP-адресов - 2 MAC-адреса совместно использовали один IP-адрес. Очевидно, что в этом случае маршрутизатор начнет плохо себя вести и испортит сеть пользователей.
Я создал частную сеть, которая содержала только маршрутизатор (ethernet + wifi), ноутбук с Windows (только Ethernet) и встроенное устройство (ethernet + wifi). Используя wireshark, tcpdump на устройстве и arp на окнах, я вижу следующее поведение:
- Ifconfig на устройстве показывает разные IP-адреса wln и Ethernet и разные MAC-адреса
- Иногда (очень редко) и arp –a из окон показывает правильную комбинацию IP-MAC.
- Большую часть времени arp –a из окон показывает, что wln и eth0 имеют одинаковый MAC-адрес
- При пинге wln или eth0 из окон ответ на пинг приходит от wln и очень редко от eth0. tcpdump показывает, что wln ответил только на 1 из 4 пингов (например)
- Когда windows отправляет arp сообщение "кто имеет" для eth0 IP - оба интерфейса eth0 и wln отвечают, что у них есть этот IP
Я полагаю, что пункт 3 вызван пунктом 5. Таблицы arp запутаны, потому что wln отвечает на сообщения arp, на которые должен отвечать только eth0. Я полагаю, что пункт 4 также вызван пунктом 5. Пинг отправляется на основе MAC-адреса, и поскольку последнее полученное сообщение arp было получено от wln, сообщившим, что он имеет eth0 IP, эхо-запросы неверно маршрутизируются в интерфейс 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 - выполнить проверку источника по обратному пути, как указано в RFC1812 Рекомендуемая опция для одиночных хостов и заглушки сети маршрутизаторы. Может вызвать проблемы для сложных (не без петель) сети с медленным ненадежным протоколом (вроде RIP), или используя статические маршруты. 0 - Нет проверки источника. conf / all / rp_filter также должен быть установлен в TRUE для проверки исходного кода на интерфейсе Значение по умолчанию равно 0. Обратите внимание, что некоторые дистрибутивы включают его в скриптах запуска. arp_filter - BOOLEAN 1 - Позволяет иметь несколько сетевых интерфейсов на одном подсеть, и есть ARP для каждого интерфейса отвечено в зависимости от того, будет ли ядро маршрутизировать пакет из ARP'd IP из этого интерфейса (поэтому вы должны использовать источник на основе маршрутизации, чтобы это работало). Другими словами, это позволяет контролировать из которых карты (обычно 1) будут отвечать на запрос arp. 0 - (по умолчанию) Ядро может отвечать на запросы arp с адресами с других интерфейсов. Это может показаться неправильным, но обычно смысл, потому что это увеличивает вероятность успешного общения. IP-адреса принадлежат всему хосту в Linux, а не конкретные интерфейсы. Только для более сложных установок, таких как load- балансировка, это поведение вызывает проблемы. arp_filter для интерфейса будет включен, если хотя бы один из conf/{all,interface}/arp_filter установлен в TRUE, иначе он будет отключен
Для более тщательного лечения, см. Эту статью:
Так как это работало нормально на предыдущей версии ОС (на основе openembedded), я решил дождаться следующей версии ОС. Мое лучшее предположение было то, что модуль беспроводного ядра был глючным.
В продолжение комментария Инсайта.
Давайте сделаем несколько имен:
- ПК1 - вверху справа
- ПК2 - вверху слева
- PC3 - внизу слева
Поскольку ваш робот доступен с 3 ПК через проводную и беспроводную сеть. И поскольку они находятся в одной подсети, вы не можете точно сказать, каким образом был выполнен запрос arp для вашего проводного носителя. Под этим я подразумеваю то, что, когда коммутатор передает широковещательный запрос 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 на своих ПК, и ваш робот будет доступен через любую из двух IP-адресов. Вы не можете иметь два исходящих пути для одной подсети на одном хосте. Нет, если нет чего-то, что заставляет вашего робота отдавать предпочтение одному другому. Ваш робот может выбрать только один путь для отправки пакетов.
Некоторые чтения: arp_announce, arp_ignore
Я думаю, что есть неправильная конфигурация между вашей беспроводной точкой доступа и коммутатором. коммутатор и AP запутываются, куда отправлять пакеты. не уверен в этом, хотя. Кроме того, я думаю, вы должны попытаться определить шлюз, где программы могут знать, куда отправлять пакеты. что-то вроде
route add default gw 192.168.0.1