Pas d'Internet après le renouvellement du bail DHCP

Aujourd'hui, un certain nombre de machines ont cessé d'avoir accès à Internet. Après beaucoup de dépannage, le fil conducteur est qu'ils ont tous renouvelé leur bail DHCP aujourd'hui (nous sommes en location de 8 jours ici).

Tout ce que vous attendez semble bon après le renouvellement du bail: ils ont une adresse IP valide, un serveur DNS et une passerelle. Ils ont accès aux ressources internes (partages de fichiers, intranet, imprimantes, etc.). Un peu plus de dépannage révèle qu'ils ne peuvent pas envoyer de ping ou tracert à notre passerelle, mais ils peuvent accéder à notre commutateur core layer3 juste en face de la passerelle. L'attribution d'une adresse IP statique à la machine fonctionne comme une solution temporaire.

Un dernier inconvénient est que jusqu'à présent, les rapports ne sont parvenus que pour les clients sur le même vlan que la passerelle. Notre personnel administratif et notre faculté sont sur le même vlan que les serveurs et les imprimantes, mais les téléphones, les porte-clés / caméras, les étudiants / wifi et les laboratoires ont chacun leurs propres vlans et pour autant que je n'ai rien vu sur aucun des autres vlans a encore eu un problème.

J'ai un ticket séparé avec le fournisseur de la passerelle, mais je soupçonne qu'ils vont retirer la facilité et me dire que le problème est ailleurs sur le réseau, donc je pose la question ici également. J'ai effacé les caches d'arp sur la passerelle et le commutateur principal. Toutes les idées sont les bienvenues.

Mise à jour:
j'ai essayé de faire un ping depuis la passerelle vers certains hôtes affectés, et la chose étrange est que j'ai obtenu une réponse: à partir d'une adresse IP complètement différente. J'en ai essayé quelques autres au hasard et j'ai finalement obtenu ceci:

Ven. 02 sept. 2011 13:08:51 GMT-0500 (heure avancée du Centre)
PING 10.1.1.97 (10.1.1.97) 56 (84) octets de données.
64 octets à partir du 10.1.1.105: icmp_seq = 1 ttl = 255 time = 1,35 ms
64 octets à partir du 10.1.1.97: icmp_seq = 1 ttl = 255 temps = 39,9 ms (DUP!)

10.1.1.97 est la cible réelle prévue du ping. 10.1.1.105 est censé être une imprimante dans un autre bâtiment. Je n'ai jamais vu de DUP dans une réponse ping auparavant.

Ma meilleure supposition pour le moment est un routeur wifi escroc dans l'une de nos dortoirs sur le sous-réseau 10.1.1.0/24 avec une mauvaise passerelle.

...a continué. J'ai maintenant éteint l'imprimante incriminée et les pings vers un hôte affecté depuis la passerelle échouent complètement.

Mise à jour 2:
je vérifie les tables d'arp sur une machine affectée, la passerelle et chaque commutateur entre elles. À chaque point, les entrées pour ces appareils étaient toutes correctes. Je n'ai pas vérifié toutes les entrées du tableau, mais toutes les entrées susceptibles d'avoir un impact sur le trafic entre l'hôte et la passerelle étaient correctes. L'ARP n'est pas le problème.

Mise à jour 3:
Les choses fonctionnent pour le moment, mais je ne vois rien de ce que j'ai fait pour les réparer et je n'ai donc aucune idée si cela pourrait être juste une accalmie temporaire. Quoi qu'il en soit, il n'y a pas grand-chose que je puisse faire pour diagnostiquer ou dépanner maintenant, mais je mettrai à jour plus s'il se brise à nouveau.

"Ma meilleure supposition pour le moment est un routeur wifi escroc dans l'une de nos dortoirs sur le sous-réseau 10.1.1.0/24 avec une mauvaise passerelle."

C'est arrivé dans mon bureau. L'appareil incriminé s'est avéré être un appareil Android voyou:

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

Si l'appareil Android obtient l'IP de la passerelle d'un autre réseau via DHCP, il peut rejoindre votre réseau et commencer à répondre aux demandes ARP pour l'IP de la passerelle avec son MAC. Votre utilisation du réseau commun 10.1.1.0/24 augmente la probabilité de ce scénario escroc.

J'ai pu vérifier le cache ARP sur un poste de travail affecté sur le réseau. Là, j'ai observé un problème de flux ARP où la station de travail basculait entre le MAC correct et une adresse MAC à partir d'un périphérique voyou. Lorsque j'ai recherché le MAC suspect que la station de travail avait pour la passerelle, il est revenu avec un préfixe Samsung. L'utilisateur astucieux avec la station de travail en difficulté a répondu qu'il savait qui avait un appareil Samsung sur notre réseau. Il s'est avéré être le PDG.

Comme déjà discuté dans la section commentaire, l'obtention d'une capture de paquets est vraiment critique. Cependant, il existe également un très bon outil appelé arpwatch:

http://ee.lbl.gov/

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

Cet outil vous enverra un e-mail ou conservera simplement un journal de toutes les nouvelles adresses MAC vues sur le réseau ainsi que toutes les modifications des adresses MAC pour les IP sur un sous-réseau donné (bascules). Pour ce problème que vous aviez, il aurait détecté les deux théories actuelles en signalant qu'il y avait des bascules en cours pour les IP changeant de MAC, ou vous verriez un nouveau MAC pour le routeur DHCP escroc lorsqu'il a commencé à communiquer avec les hôtes. Le seul inconvénient de l'outil est que vous devez avoir l'hôte connecté à tous les réseaux que vous surveillez, mais c'est un petit prix pour les excellentes informations qu'il peut fournir pour aider à diagnostiquer ce genre de problèmes.

Un moyen rapide de détecter les serveurs DHCP escrocs typiques consiste à envoyer une requête ping à la passerelle qu'il sert, puis à examiner son MAC dans la table ARP correspondante. Si l'infrastructure de commutation est gérée, le MAC peut également être localisé jusqu'au port qui l'héberge et le port peut être fermé ou retracé jusqu'à l'emplacement du périphérique incriminé pour une réparation supplémentaire.

L'utilisation de DHCP Snooping sur les commutateurs qui le prennent en charge peut également être une option efficace pour protéger un réseau contre les serveurs DHCP non autorisés.