A resposta estranha do servidor DHCP do Linux ao ARP de boa qualidade causa falha de DHCP

1

Este é um problema que encontrei recentemente em um servidor linux bastante configurado. Esta máquina executa o Samba como um controlador de domínio do Active Directory, um servidor de e-mail, um servidor da Web, duas máquinas virtuais (usando KVM / QEMU e conectando uma das suas interfaces Ethernet virtualizadas a uma das interfaces Ethernet reais da máquina por meio de uma ponte virtual configurado com brctl) e mais alguns serviços. Em uma VLAN privada, ela também opera um servidor DHCP. Isso estava funcionando bem, mas recentemente ele começou a deixar os dispositivos da Apple entrarem. Mas também um ponto de acesso WiFi simples (que é configurado para receber dinamicamente seu IP via DHCP) também falha ao receber um IP.

O loop infinito, onde os dispositivos tentam obter um endereço IP, é o seguinte (capturado via tcpdump -e ). Há 2c:30:33:2b:68:d0 é o MAC da caixa remota, e 74:d0:2b:99:52:bc é o servidor linux. Depois de cada pacote, escrevi minha interpretação desse pacote:

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)

Os clientes DHCP, que não enviam o ARP gratuito mencionado acima, podem se registrar bem. Então eu suponho que a resposta do servidor linux a esse ARP gratuito, onde ele responde, que o endereço pertence à máquina linux, é o problema.

Eu assegurei que os endereços IP, que o servidor DHCP deve fornecer, não estão registrados no servidor linux. Então, francamente, não sei por que esse pacote é enviado.

Todas as tentativas de reprodução com /proc/sys/net/ipv4/conf/eth0.9/arp_accept, /proc/sys/net/ipv4/conf/eth0.9/arp_announce e assim por diante falharam. Mesmo a tentativa de filtrar os pacotes ARP ruins com arptables não teve sucesso. E desligar o ARP totalmente na interface também não tem o efeito desejado.

Alguma idéia, por que esse pacote estranho é criado? Onde eu poderia procurar mais?

    
por Kai Petzke 22.09.2018 / 16:06

0 respostas