Это проблема, с которой я недавно столкнулся на довольно сильно настроенном сервере Linux. На этой машине работает Samba в качестве контроллера домена Active Directory, почтового сервера, веб-сервера, двух виртуальных машин (с использованием KVM / QEMU и подключения одного из их виртуализированных интерфейсов Ethernet к одному из реальных интерфейсов Ethernet машины через виртуальный мост. настроил с помощью brctl) и еще несколько сервисов. В частной VLAN он также управляет DHCP-сервером. Это работало нормально, но недавно оно начало не пропускать устройства Apple. Но также и простая точка доступа Wi-Fi (которая настроена на динамическое получение своего IP-адреса через DHCP) также не может получить IP-адрес.
Бесконечный цикл, в котором устройства пытаются получить IP-адрес, выглядит следующим образом (захватывается через tcpdump -e
). Там 2c:30:33:2b:68:d0
это MAC удаленного ящика, и 74:d0:2b:99:52:bc
это сервер Linux. После каждого пакета я написал свою интерпретацию этого пакета:
15:48:33.350358 2c:30:33:2b:68:d0 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 345: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 2c:30:33:2b:68:d0, length 303
(DHCPDISCOVER from 2c:30:33:2b:68:d0)
15:48:34.351523 74:d0:2b:99:52:bc > 2c:30:33:2b:68:d0, ethertype IPv4 (0x0800), length 345: 172.17.9.1.67 > 172.17.9.7.68: BOOTP/DHCP, Reply, length 303
(DHCPOFFER on 172.17.9.7 to 2c:30:33:2b:68:d0 via eth0.9)
15:48:34.366366 2c:30:33:2b:68:d0 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 2c:30:33:2b:68:d0, length 315
(DHCPREQUEST for 172.17.9.7 (172.17.9.1) from 2c:30:33:2b:68:d0 via eth0.9)
15:48:34.492289 74:d0:2b:99:52:bc > 2c:30:33:2b:68:d0, ethertype IPv4 (0x0800), length 345: 172.17.9.1.67 > 172.17.9.7.68: BOOTP/DHCP, Reply, length 303
(DHCPACK on 172.17.9.7 to 2c:30:33:2b:68:d0 via eth0.9)
15:48:34.492707 2c:30:33:2b:68:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.17.9.7 tell 172.17.9.7, length 46
(gratuitous ARP of the newly registered box)
15:48:34.492761 74:d0:2b:99:52:bc > 2c:30:33:2b:68:d0, ethertype ARP (0x0806), length 42: Reply 172.17.9.7 is-at 74:d0:2b:99:52:bc, length 28
(this is the packet, that I don't understand)
15:48:34.526375 2c:30:33:2b:68:d0 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 346: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, unknown (0x00), length 304
(DHCPDECLINE of 172.17.9.7 from 2c:30:33:2b:68:d0 via eth0.9, the box abandones the IP address 172.17.9.7, because it seems in use)
DHCP-клиенты, которые не отправляют упомянутый выше бесплатный ARP, могут нормально зарегистрироваться. Итак, я предполагаю, что ответ Linux-сервера на этот бесплатный ARP, где он отвечает, что адрес принадлежит Linux-машине, является проблемой.
Я убедился, что IP-адреса, которые должен выдавать DHCP-сервер, не зарегистрированы на сервере Linux. Так что я, честно говоря, не знаю, почему этот пакет отправлен.
Все попытки поиграть с /proc/sys/net/ipv4/conf/eth0.9/arp_accept, /proc/sys/net/ipv4/conf/eth0.9/arp_announce и т. Д. Потерпели неудачу. Даже попытка отфильтровать плохие пакеты ARP с помощью arptables
не имел успеха. И полное отключение ARP на интерфейсе тоже не дает желаемого эффекта.
Есть идеи, почему создается этот странный пакет? Где мне посмотреть дальше?