Kein Internet nach Verlängerung des DHCP-Mietvertrags

Heute hatten wir eine Reihe von Maschinen, die keinen Internetzugang mehr hatten. Nach vielen Fehlern ist der rote Faden, dass alle ihren DHCP-Mietvertrag heute erneuert haben (wir haben hier 8-Tage-Mietverträge).

Alles, was Sie erwarten würden, sieht nach der Verlängerung des Mietvertrags gut aus: Sie haben eine gültige IP-Adresse, einen DNS-Server und ein Gateway. Sie haben Zugriff auf interne Ressourcen (Dateifreigaben, Intranet, Drucker usw.). Ein wenig mehr Fehlerbehebung zeigt, dass sie nicht in der Lage sind, einen Ping- oder Tracert-Vorgang zu unserem Gateway durchzuführen, aber sie können zu unserem Core-Layer3-Switch direkt vor dem Gateway gelangen. Das Zuweisen einer statischen IP zum Computer funktioniert als temporäre Lösung.

Eine letzte Falte ist, dass bisher nur Berichte für Kunden auf demselben VLAN wie das Gateway eingegangen sind. Unser Verwaltungspersonal und unsere Fakultät befinden sich auf demselben VLAN wie die Server und Drucker, aber Telefone, Schlüsselanhänger / Kameras, Studenten / WLAN und Labore haben jeweils ihre eigenen Vlans, und soweit ich auf keinem der anderen Vlans etwas gesehen habe hat schon ein Problem gehabt.

Ich habe ein separates Ticket beim Gateway-Anbieter, aber ich vermute, dass sie das Problem lösen und mir mitteilen, dass das Problem an einer anderen Stelle im Netzwerk liegt. Deshalb frage ich auch hier. Ich habe Arp-Caches auf dem Gateway und dem Core-Switch gelöscht. Irgendwelche Ideen sind willkommen.

Update:
Ich habe versucht, vom Gateway zurück zu einigen betroffenen Hosts zu pingen, und das Seltsame ist, dass ich eine Antwort erhalten habe: von einer völlig anderen IP-Adresse. Ich habe ein paar mehr zufällig ausprobiert und schließlich folgendes bekommen:

Fri Sep 02 2011 13:08:51 GMT-0500 (Zentrale Sommerzeit)
PING 10.1.1.97 (10.1.1.97) 56 (84) Datenbytes.
64 Bytes vom 10.1.1.105: icmp_seq = 1 ttl = 255 time = 1,35 ms
64 Bytes vom 10.1.1.97: icmp_seq = 1 ttl = 255 Zeit = 39,9 ms (DUP!)

10.1.1.97 ist das tatsächlich beabsichtigte Ziel des Pings. 10.1.1.105 soll ein Drucker in einem anderen Gebäude sein. Ich habe noch nie zuvor ein DUP in einer Ping-Antwort gesehen.

Meine derzeit beste Vermutung ist ein betrügerischer WLAN-Router in einem unserer Schlafsäle im Subnetz 10.1.1.0/24 mit einem schlechten Gateway.

... fuhr fort. Ich habe jetzt den fehlerhaften Drucker ausgeschaltet und Pings an einen betroffenen Host vom Gateway aus schlagen einfach vollständig fehl.

Update 2:
Ich überprüfe Arp-Tabellen auf einem betroffenen Computer, dem Gateway und jedem Wechsel zwischen ihnen. Zu jedem Zeitpunkt waren die Einträge für diese Geräte alle korrekt. Ich habe nicht jeden Eintrag in der Tabelle überprüft, aber jeder Eintrag, der möglicherweise den Datenverkehr zwischen dem Host und dem Gateway beeinträchtigen könnte, war in Ordnung. ARP ist nicht das Problem.

Update 3: Die
Dinge funktionieren im Moment, aber ich kann nichts sehen, was ich getan habe, um sie zu beheben, und daher habe ich keine Ahnung, ob dies nur eine vorübergehende Pause sein könnte. Wie auch immer, ich kann jetzt nicht viel tun, um zu diagnostizieren oder Fehler zu beheben, aber ich werde mehr aktualisieren, wenn es wieder kaputt geht.

"Meine derzeit beste Vermutung ist ein betrügerischer WLAN-Router in einem unserer Schlafsäle im Subnetz 10.1.1.0/24 mit einem schlechten Gateway."

Das ist in meinem Büro passiert. Das beleidigende Gerät stellte sich als betrügerisches Android-Gerät heraus:

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

Wenn das Android-Gerät die IP des Gateways über DHCP von einem anderen Netzwerk erhält, tritt es möglicherweise Ihrem Netzwerk bei und reagiert auf ARP-Anfragen nach der Gateway-IP mit seinem MAC. Ihre Verwendung des gemeinsamen 10.1.1.0/24-Netzwerks erhöht die Wahrscheinlichkeit dieses Schurkenszenarios.

Ich konnte den ARP-Cache auf einer betroffenen Workstation im Netzwerk überprüfen. Dort beobachtete ich ein ARP-Flussproblem, bei dem die Workstation zwischen dem richtigen MAC und einer MAC-Adresse von einem nicht autorisierten Gerät umgedreht wurde. Als ich nach dem verdächtigen MAC suchte, den die Workstation für das Gateway hatte, kam er mit einem Samsung-Präfix zurück. Der kluge Benutzer mit der gestörten Workstation antwortete, er wisse, wer ein Samsung-Gerät in unserem Netzwerk habe. Es stellte sich heraus, der CEO zu sein.

Wie bereits im Kommentarbereich erläutert, ist es sehr wichtig, eine Paketerfassung zu erhalten. Es gibt jedoch auch ein wirklich tolles Tool namens Arpwatch:

http://ee.lbl.gov/

(oder http://sid.rstack.org/arp-sk/ für Windows)

Dieses Tool sendet Ihnen eine E-Mail oder führt nur ein Protokoll aller neuen MAC-Adressen im Netzwerk sowie aller Änderungen der MAC-Adressen für IPs in einem bestimmten Subnetz (Flip-Flops). Bei diesem Problem hätten Sie beide aktuellen Theorien erkannt, indem Sie entweder gemeldet hätten, dass für IPs, die MACs ändern, Flip-Flops ausgeführt wurden, oder Sie hätten einen neuen MAC für den nicht autorisierten DHCP-Router gesehen, als er zum ersten Mal mit Hosts kommunizierte. Der einzige Nachteil des Tools ist, dass der Host mit allen von Ihnen überwachten Netzwerken verbunden sein muss. Dies ist jedoch ein geringer Preis für die hervorragenden Informationen, die zur Diagnose dieser Art von Problemen bereitgestellt werden können.

Eine schnelle Möglichkeit, die typischen unerwünschten DHCP-Server zu erkennen, besteht darin, das von ihm bereitgestellte Gateway zu pingen und dann den MAC in der entsprechenden ARP-Tabelle zu überprüfen. Wenn es sich bei der Switching-Infrastruktur um eine verwaltete Infrastruktur handelt, kann der MAC auch bis zu dem Port zurückverfolgt werden, auf dem er sich befindet, und der Port kann entweder heruntergefahren oder zur weiteren Behebung auf den Standort des fehlerhaften Geräts zurückgeführt werden.

Die Verwendung von DHCP-Snooping auf Switches, die dies unterstützen, kann auch eine wirksame Option sein, um ein Netzwerk auch vor unerwünschten DHCP-Servern zu schützen.