Encontrar servidores DHCP ativos duplicados na rede local

Nos clientes DHCP que recebem IPs duplicados, comece olhando as opções fornecidas com a oferta DHCP. Há uma chance diferente de zero de que cada servidor DHCP responda com algo apontando para si mesmo, como Roteador/Gateway ou Servidor de Nomes ou outra coisa.

Se isso não ajudar, escolha um horário em que você possa ter uma janela de manutenção, provavelmente fora do horário comercial, porque isso interromperá os serviços normais.
Em seus servidores DHCP aprovados, defina o tempo de concessão para algo baixo, como 5 a 10 minutos agora, para que seja mais fácil liberar as coisas.
Em seguida, desligue seus servidores DHCP adequados e use um cliente de teste para fazer uma solicitação DHCP. Em outra janela, execute um sniffer de pacotes como o wireshark ou, de preferência, o tcpdump:

# sudo tcpdump -i any -v -nn port 67 or port 68

10:00:18.982020 eth0  Out IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 66:ed:6e:c6:9d:56, length 300, xid 0x38e3094d, Flags [none]
          Client-Ethernet-Address 66:ed:6e:c6:9d:56
          Vendor-rfc1048 Extensions
            DHCP-Message (53), length 1: Request
            Parameter-Request (55), length 13: 
              Subnet-Mask (1), BR (28), Time-Zone (2), Default-Gateway (3)...

10:00:18.984436 eth0  In  IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 334)
    10.28.1.1.67 > 10.28.100.109.68: BOOTP/DHCP, Reply, length 306, xid 0x38e3094d, Flags [none]
          Your-IP 10.28.100.109
          Client-Ethernet-Address 66:ed:6e:c6:9d:56
          Vendor-rfc1048 Extensions
            DHCP-Message (53), length 1: ACK
*           Server-ID (54), length 4: 10.28.1.1
            Lease-Time (51), length 4: 7200
            Subnet-Mask (1), length 4: 255.255.0.0
*           Default-Gateway (3), length 4: 10.28.1.1
            Domain-Name (15), length 14: "criggie.org.nz"
*           Domain-Name-Server (6), length 8: 10.28.1.1,10.28.1.1
            Netbios-Name-Server (44), length 4: 10.28.1.2
*           NTP (42), length 4: 10.28.1.1

Neste caso, 66:ed:6e:c6:9d:56é o endereço MAC do cliente, e a resposta DHCP veio 10.28.1.1 deste mesmo IP, assim como os servidores DNS e NTP, etc.

Depois de obter um endereço IP, verifique rapidamente a tabela ARP do host de teste e obtenha um endereço MAC antes que o tempo limite se esgote.

# arp -an
? (10.28.2.9) at a0:36:9f:b9:ef:52 [ether] on eth0
? (10.28.1.1) at 00:0d:b9:35:29:c4 [ether] on eth0

Agora você sabe que 00:0d:b9:35:29:c4 é o endereço MAC de hardware para o IP que deu uma resposta DHCP.

Por fim, descubra onde na sua rede está esse endereço IP/mac. Uma simples pesquisa de nome de host no IP pode lhe dizer algo útil:

# host 10.28.1.1
1.1.28.10.in-addr.arpa domain name pointer pfsense.criggie.org.nz.

ou

$ dig -x 10.28.1.1
;; ANSWER SECTION:
1.1.28.10.in-addr.arpa. 1    IN   PTR   pfsense.criggie.org.nz.

Ou se isso não faz sentido para você, tem que rastrear o endereço MAC de volta com uma pesquisa OUI como https://www.wireshark.org/tools/oui-lookup.html
Para mim, ele retorna "00:0D:B9 PC Engines GmbH" , então eu sei que é um APU ou ALIX single board PC. Você pode obter um resultado que significa algo para você, ou pode obter algo amplo como "hp inc"

Seu próximo passo é olhar através das tabelas de pesquisa MAC do seu switch para descobrir a qual porta física esse endereço mac se conecta. Isso pressupõe que você tenha pelo menos um switch ethernet gerenciado na sua rede e possa fazer login nele.

Isso depende totalmente do tipo de switch que você tem e vai ser muito diferente entre os ecossistemas. Aqui está um Juniper mostrando que o dispositivo está na porta gigabit 19:

root@sw1-poe> show ethernet-switching table brief | grep 00:0d:b9:35:29:c4 
  default           00:0d:b9:35:29:c4 Learn          0 ge-0/0/19.0

Mesmo comando em um switch Hasivo, mostrando que o dispositivo está na porta te1 (este precisa de MAC em maiúsculas)

switch0# show mac address-table 00:0D:B9:35:29:C4
 VID | MAC Address       | Type    | Ports          
-----+-------------------+---------+----------
   1 | 00:0D:B9:35:29:C4 | Dynamic | te1 

Se você tiver apenas switches não gerenciados, sua única opção é fazer ping no IP repetidamente enquanto desconecta partes da sua LAN até que o ping pare. Se o host remoto não responder aos pings ICMP, use arpingo que requer root:

~$ sudo arping  10.28.1.1
ARPING 10.28.1.1
60 bytes from 00:0d:b9:35:29:c4 (10.28.1.1): index=0 time=182.578 usec
60 bytes from 00:0d:b9:35:29:c4 (10.28.1.1): index=1 time=156.675 usec
60 bytes from 00:0d:b9:35:29:c4 (10.28.1.1): index=2 time=198.373 usec
^C
--- 10.28.1.1 statistics ---
3 packets transmitted, 3 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 0.157/0.179/0.198/0.017 ms

Finalmente, quando você ENCONTRAR o misterioso servidor DHCP, explique gentilmente a quem fez isso quais são os problemas e por que isso lhe causou problemas.

Eu executei dois servidores DHCP desconexos por anos na mesma rede sem problemas. A solução foi o administrador do sistema (eu) certificar-se de que ambos estavam servindo o mesmo conjunto de opções com valores corretos, e que cada um tivesse seu próprio intervalo separado como um pool dinâmico que não se sobrepusesse. Eu também configurei muitas reservas DHCP para que muitos hosts sempre obtivessem o mesmo IP "estático", mas eu pudesse alterar opções como nameserver em apenas dois servidores DHCP.

Você consegue. Conte-nos como foi.

No cliente que recebe endereço IP do servidor DHCP desonesto, digite ipconfig /allcmd. Há uma linha que diz Servidor DHCP. Comece a procurar a partir daí.