Sem internet após a renovação do contrato dhcp

Hoje, várias máquinas pararam de obter acesso à Internet. Após muita solução de problemas, o problema comum é que todos eles tiveram sua concessão dhcp renovada hoje (estamos com concessões de 8 dias aqui).

Tudo o que você esperaria parece bom após a renovação da concessão: eles têm um endereço IP, servidor DNS e gateway válidos. Eles têm acesso a recursos internos (compartilhamentos de arquivos, intranet, impressoras etc.). Um pouco mais de solução de problemas revela que eles não conseguem fazer ping ou rastrear para o nosso gateway, mas podem acessar nosso switch principal da camada3 logo em frente ao gateway. A atribuição de um IP estático à máquina funciona como uma solução temporária.

Uma desvantagem final é que até agora os relatórios chegaram apenas para clientes na mesma vlan que o gateway. Nossa equipe administrativa e o corpo docente estão na mesma vlan dos servidores e impressoras, mas os telefones, as chaves / câmeras, os alunos / wifi e os laboratórios têm suas próprias vlans e, até onde eu não vi nada em outras vlans ainda teve um problema.

Eu tenho um ingresso separado com o fornecedor do gateway, mas suspeito que eles aceitem o problema e me digam que o problema está em outra parte da rede, por isso estou perguntando aqui também. Limpei os caches ARP no gateway e no switch principal. Todas as idéias são bem-vindas.

Atualização:
tentei efetuar ping do gateway de volta para alguns hosts afetados, e o mais estranho é que recebi uma resposta: de um endereço IP completamente diferente. Eu tentei mais alguns aleatoriamente e, finalmente, consegui isso:

Sex 02 de setembro de 2011 13:08:51 GMT-0500 (horário de verão central)
PING 10.1.1.97 (10.1.1.97) 56 (84) bytes de dados.
64 bytes de 10.1.1.105: icmp_seq = 1 ttl = 255 time = 1.35 ms
64 bytes de 10.1.1.97: icmp_seq = 1 ttl = 255 time = 39.9 ms (DUP!)

10.1.1.97 é o destino pretendido real do ping. 10.1.1.105 deveria ser uma impressora em outro prédio. Eu nunca vi um DUP em uma resposta de ping antes.

Meu melhor palpite no momento é um roteador Wi-Fi desonesto em um de nossos dormitórios na sub-rede 10.1.1.0/24 com um gateway ruim.

...contínuo. Agora desliguei a impressora incorreta e pings para um host afetado do gateway simplesmente falham completamente.

Atualização 2:
Verifico as tabelas arp em uma máquina afetada, no gateway e em todos os comutadores entre elas. Em cada ponto, as entradas para esses dispositivos estavam todas corretas. Não verifiquei todas as entradas da tabela, mas todas as entradas que poderiam impactar o tráfego entre o host e o gateway estavam corretas. ARP não é o problema.

Atualização 3:
As coisas estão funcionando no momento, mas não consigo ver nada que fiz para corrigi-las e, portanto, não tenho idéia se isso pode ser apenas uma pausa temporária. De qualquer forma, não há muito que eu possa fazer para diagnosticar ou solucionar problemas agora, mas atualizarei mais se ele quebrar novamente.

"Meu melhor palpite no momento é um roteador Wi-Fi desonesto em um de nossos dormitórios na sub-rede 10.1.1.0/24 com um gateway ruim".

Isso aconteceu no meu escritório. O dispositivo infrator acabou sendo um dispositivo android não autorizado:

http://code.google.com/p/android/issues/detail?id=11236

Se o dispositivo Android obtiver o IP do gateway de outra rede via DHCP, ele poderá ingressar na sua rede e começar a responder às solicitações ARP para o IP do gateway com seu MAC. Seu uso da rede 10.1.1.0/24 comum aumenta a probabilidade desse cenário não autorizado.

Consegui verificar o cache do ARP em uma estação de trabalho afetada na rede. Lá, observei um problema de fluxo ARP em que a estação de trabalho alternava entre o MAC correto e o endereço MAC de algum dispositivo não autorizado. Quando procurei o MAC suspeito que a estação de trabalho possuía para o gateway, ele voltou com um prefixo Samsung. O usuário astuto da estação de trabalho problemática respondeu que sabia quem tinha um dispositivo Samsung em nossa rede. Acabou por ser o CEO.

Como já discutido na seção de comentários, obter uma captura de pacotes é realmente crítico. No entanto, também existe uma ótima ferramenta chamada arpwatch:

http://ee.lbl.gov/

(ou http://sid.rstack.org/arp-sk/ para Windows)

Essa ferramenta enviará um e-mail a você ou apenas manterá um registro de todos os novos endereços MAC vistos na rede, bem como quaisquer alterações nos endereços MAC para IPs em uma determinada sub-rede (flip-flops). Para esse problema, você teria detectado as duas teorias atuais, relatando que havia flip-flops para IPs alterando MACs ou você veria um novo MAC para o roteador DHCP não autorizado quando ele começou a se comunicar com os hosts. O lado negativo da ferramenta é que você precisa ter o host conectado a todas as redes que monitora, mas é um preço pequeno pelas excelentes informações que ela pode fornecer para ajudar a diagnosticar esses tipos de problemas.

Uma maneira rápida de detectar os servidores DHCP não autorizados comuns é executar ping no gateway que ele serve e, em seguida, examinar o seu MAC na tabela ARP correspondente. Se a infraestrutura de comutação for gerenciada, o MAC também poderá ser rastreado até a porta que a hospeda e a porta poderá ser desligada ou rastreada até o local do dispositivo incorreto para reparação adicional.

O uso do DHCP Snooping em switches que o suportam também pode ser uma opção eficaz na proteção de uma rede contra servidores DHCP não autorizados.