Когда я запускаю tcpdump на шлюзе, я получаю много запросов arp, исходящих от самого шлюза. Интересно знаю, почему это происходит. Как я могу найти процесс, вызывающий эти запросы arp?
$ tcpdump -n arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:51:03.662114 ARP, Request who-has 211.123.123.251 tell 211.123.123.242, length 28
16:51:03.954113 ARP, Request who-has 211.123.123.246 tell 211.123.123.242, length 28
16:51:04.002111 ARP, Request who-has 211.123.123.254 tell 211.123.123.242, length 28
16:51:04.518111 ARP, Request who-has 211.123.123.248 tell 211.123.123.242, length 28
16:51:04.954113 ARP, Request who-has 211.123.123.246 tell 211.123.123.242, length 28
16:51:05.002110 ARP, Request who-has 211.123.123.254 tell 211.123.123.242, length 28
16:51:05.518110 ARP, Request who-has 211.123.123.248 tell 211.123.123.242, length 28
16:51:06.002112 ARP, Request who-has 211.123.123.254 tell 211.123.123.242, length 28
16:51:06.210111 ARP, Request who-has 211.123.123.252 tell 211.123.123.242, length 28
16:51:06.518114 ARP, Request who-has 211.123.123.248 tell 211.123.123.242, length 28
16:51:07.114111 ARP, Request who-has 211.123.123.246 tell 211.123.123.242, length 28
16:51:07.210111 ARP, Request who-has 211.123.123.252 tell 211.123.123.242, length 28
16:51:07.314112 ARP, Request who-has 211.123.123.249 tell 211.123.123.242, length 28
Ниже приведена конфигурация ворот:
$ ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 6c:f0:49:a8:05:4c brd ff:ff:ff:ff:ff:ff
inet 211.123.123.242/28 brd 211.123.123.255 scope global eth0
inet6 fe80::6ef0:49ff:fea8:54c/64 scope link
valid_lft forever preferred_lft forever
В этой подсети доступен только 211.123.123.242 (IP-адрес шлюза), другие IP-адреса (например, 211.123.123.246) недоступны.
Обновить:
Я вижу трафик на эти недоступные IP-адреса, думаю, это причина этих сигналов. Хотя я пока не могу понять, почему происходит такой трафик. Может неверная настройка в провайдерах isp.
$ tcpdump host 211.103.252.245
23:50:11.414705 IP 59.34.131.5.7099 > 211.123.123.245.17701: Flags [S.], seq 3745049197, ack 1625918577, win 8760, options [mss 1460], length 0
23:50:12.991258 IP 75.126.1.222.80 > 211.123.123.245.1078: Flags [S.], seq 651817046, ack 152032452, win 17473, length 0
Такое поведение очень часто встречается при запущенном DHCP-сервере. Сервер проверяет адреса в диапазоне аренды, чтобы узнать, какие из них свободны. Существуют также другие решения для мониторинга сети, которые используют ARP для отслеживания того, какие адреса используются в сети.
Насколько мне известно, в Unix-подобных системах нет системы, которая позволяла бы видеть, какая программа инициирует запрос arp. Вы могли бы, возможно, strace / ktrace / dtrace найти системный вызов.
В конце концов, я бы не стал слишком об этом беспокоиться. Большое количество пакетов ARP может вызвать проблемы, но только когда оно попадает в диапазон 1000 пакетов в секунду. Несколько пакетов в секунду - не о чем беспокоиться.
Запросы ARP на маршрутизаторе - это ожидаемое поведение. Запросы ARP используются, чтобы маршрутизатор знал адрес следующего перехода в сети для определенного маршрута. Его основная задача - сопоставить IP-адрес с MAC-адресом.
Из образца, который вы предоставили выше, не похоже, что это чрезмерное использование ARP.
Если ARP-пакеты исходят из Linux-сервера, вы можете попробовать сгенерировать большое количество правил iptables с параметром --pid-owner XXX (соответствует, если pid процесса, создающего пакет, равен XXX; вам придется охватить большой диапазон pid) и надеемся, что процесс, который действительно отправляет пакеты, не является недолговечным порождением чего-то еще.
В качестве альтернативы вы можете использовать (гораздо меньше) параметров --uid-owner XXX, чтобы найти uid владельца процесса, отправившего пакет.
С другой стороны, если 211.123.123.242 - ваш шлюз, и он ищет MAC-адреса, соответствующие различным IP-адресам из этой сети, тогда у него может быть несколько пакетов для доставки извне. Кто и почему пытается связаться с несуществующими адресами, на самом деле может быть более интересным вопросом, чем поиск отправителя ARP-запросов на шлюзе.