Этот вопрос очень похож на этот:
Linux отправляет запросы ARP узлам в других подсетях?
Основная проблема - сервер Ubuntu Linux отправляет ARP-запросы с запросом MAC-адреса хоста в другой подсети.
К одному маршрутизатору физически подключены четыре разные сети класса C. Нет VLAN или какого-либо другого разделения.
Маршрутизатор имеет IP-адрес в каждой из четырех подсетей класса C. Это то, что позволяет осуществлять маршрутизацию между четырьмя подсетями.
Сервер Ubuntu Linux имеет IP-адрес x.x.250.2.
Когда эхо-запрос выполняется в одной из разных подсетей (x.x.249.x), НЕКОТОРЫЕ запросы успешны, а другие нет. Для тех, кто этого не делает, Wireshark (сниффер пакетов, работающий на сервере Ubuntu Linux) показывает, что он отправляет пакеты ARP («У кого IP x.x.249.x?»)
Почему это происходит? Никакие ARP-пакеты не должны отправляться с сервера, предназначенного для чего-то не в той же подсети.
Сетевая конфигурация на сервере x.x.250.2. Маска подсети 255.255.255.0. Шлюз - x.x.250.1. Установить статически.
Таблица маршрутизации не была изменена и используется по умолчанию для этого:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 x.x.250.1 0.0.0.0 UG 0 0 0 eth0
x.x.250.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Кэш arp на сервере Linux показывает множество MAC-адресов для систем в x.x.249.x, а также в сети x.x.250.x. Опять же, этого не должно происходить.
Теперь - для тестирования использовался компьютер с Windows XP. Поместите в ту же подсеть, что и сервер Linux. Он может пинговать те адреса в подсети x.x.249.x, что не может сервер Linux.
В стеке TCP Ubuntu / Linux должна быть какая-то потенциальная ошибка. Отправка пакетов ARP в другие сети / подсети не должна происходить.
Это было решено.
Очевидно, что Linux не совсем соответствует обычным правилам стека TCP, как это делают машины с Windows.
Я перезапустил сервер Linux. Выполнен пинг на проблемный IP-адрес (x.x.249.76).
От маршрутизатора (x.x.250.1) было получено перенаправление ICMP, в котором говорилось: «Эй, вы можете поговорить с x.x.249.76 напрямую, и вам не нужно проходить через меня). Сразу после того, как это было получено, ответы на эхо-запрос истекли и завершились.
Маршрутизатор - это маршрутизатор MicroTik, и я уверен, что он также основан на Linux.
Поскольку все эти четыре подсети были на одном маршрутизаторе, устройство MikroTik МЫСЛЬ что ему не нужно передавать сообщения. Неправильно.
Решением было обновить файл /etc/sysctl.d/10-network-security.conf и добавить следующие строки:
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
Это сказало моему серверу Linux полностью игнорировать любые перенаправления ICMP.
Сервер был перезапущен. Запуск проверки связи x.x.249.76 и уведомления о перенаправлении все еще были получены, но были проигнорированы, и сервер продолжил успешно проверять связь с IP-адресом.