Запустив захват пакетов на моих маршрутизаторах, я вижу, что некоторые из моих серверов отправляют запросы ARP для IP-адресов, которые существуют за пределами его сети.
Например, если моя сеть:
Network: 8.8.8.0/24
Gateway: 8.8.8.1 (MAC: 00:21:9b:aa:aa:aa)
Example Server: 8.8.8.20 (MAC: 00:21:9b:bb:bb:bb)
Запустив захват на интерфейсе с 8.8.8.1, я вижу такие запросы:
Sender Mac: 00:21:9b:bb:bb:bb
Sender IP: 8.8.8.20
Target MAC: 00:21:9b:aa:aa:aa
Target IP: 69.63.181.58
Кто-нибудь видел такое поведение раньше? Насколько я понимаю, ARP таков, что запросы должны поступать только для IP-адресов внутри подсети ... Я запутался в своем понимании ARP? Если я не запутался, кто-нибудь видел такое поведение?
Кроме того, похоже, что это происходит всплесками, и этого не происходит, когда я делаю что-то вроде проверки связи с IP-адресом вне сети.
Обновить:
В ответ на вопросы Яна. Я не использую ничего похожего на Hyper-V. У меня несколько интерфейсов, но активен только один (с использованием группы аварийного переключения BACS). Маска подсети 255.255.255.0 (даже если бы это было что-то другое, это не объясняло бы IP, например 69.63.181.58).
Когда я запускаю MS Network Monitor или wirehark, я не вижу этих запросов ARP. Что происходит, так это то, что при захвате маршрутизатора я вижу пакет из примерно 10 запросов IP-адресов за пределами сети с хост-машины. На самой машине, использующей wirehark или NetMon, я вижу поток Ответы ARP для всех машин в сети. Однако я не вижу никаких запросов в захвате, требующих этих ответов.
Таким образом, похоже, что это может быть обновление кеша arp, но включая IP-адреса, находящиеся за пределами сети. Также, когда это NetMon не показывает запросы ARP?
Если вы не видите запросы ARP в Wireshark / Netmon, тогда двумя дополнительными источниками кадров ARP могут быть драйвер объединения Broadcom (BASP) и управляемость OEM-сетью (например, Dell DRAC и HP iLo).
Драйвер объединения Broadcom включает функцию под названием «LiveLink», которая использует кадры ARP для проверки сетевых подключений к удаленным системам (см. http://support.dell.com/support/edocs/network/p29352/english/teaming.htm). Если пользователь устанавливает зонд LiveLink для IP-адреса за пределами локальной подсети, тогда BASP с радостью сгенерирует ARP для этого адреса. Конечно, если адрес поддельный, команда должна указать сбой на одном или нескольких сетевых адаптерах, используемых в группе.
Корпоративные серверы часто имеют выделенный порт Ethernet для управления. Более дешевые серверы могут использовать порт LOM и отправлять трафик через тот же разъем RJ-45, что и Windows. Если функция управления сервера включена, но настроена неправильно, он может генерировать ARP за пределами IP-подсети, используемой хостом. Эти кадры ARP также будут невидимы для Wireshark / Netmon. Большинство решений для управления также работают, когда система выключена, поэтому, если вы продолжаете видеть ARP, созданные системой, когда она выключена, то источником может быть функция управления.
Возникает очевидный вопрос: какая у вас конфигурация сети? У вас несколько интерфейсов? У вас на сервере есть Hyper-V или VMware?
В любом случае ваше понимание arp действительно правильное. Ошибка конфигурации сети кажется наиболее вероятным объяснением.
Попробуйте установить MSNetmon на свой сервер и перехватить трафик arp. Он должен указать вам, откуда он. Скорее всего, это будет система, а не какой-то вредоносный процесс. Если это вредоносное ПО, как упомянуто выше, оно должно быстро идентифицировать его.
Вы правильно понимаете ARP. Хост не должен использовать ARP для IP-адреса, не входящего в его локальную подсеть, потому что он должен знать, что IP-адрес не является локальным, и поэтому должен знать, что данные должны быть отправлены на шлюз по умолчанию. Единственный раз, когда я видел это, был компьютер, зараженный вредоносным ПО.