Nessuna connessione Internet dopo il rinnovo del contratto dhcp


10

Oggi abbiamo avuto un certo numero di macchine smettere di ottenere l'accesso a Internet. Dopo un sacco di risoluzione dei problemi, il thread comune è che tutti hanno avuto il loro contratto di locazione dhcp rinnovato oggi (siamo con contratti di locazione di 8 giorni qui).

Tutto ciò che ti aspetteresti sembra buono dopo il rinnovo del contratto di locazione: hanno un indirizzo IP, un server DNS e un gateway validi. Hanno accesso a risorse interne (condivisioni di file, intranet, stampanti, ecc.). Un altro po 'di risoluzione dei problemi rivela che non sono in grado di eseguire il ping o il tracert sul nostro gateway, ma possono arrivare al nostro switch core layer3 proprio di fronte al gateway. L'assegnazione di un IP statico alla macchina funziona come soluzione temporanea.

Un'ultima ruga è che finora i rapporti sono arrivati ​​solo per i clienti sullo stesso vlan del gateway. Il nostro personale amministrativo e la nostra facoltà si trovano sullo stesso vlan dei server e delle stampanti, ma telefoni, portachiavi / videocamere, studenti / wifi e laboratori hanno ciascuno i propri vlan e per quanto non ho visto nulla su nessuno degli altri vlans ha ancora avuto un problema.

Ho un biglietto separato con il fornitore del gateway, ma sospetto che si prenderanno cura di me e mi diranno che il problema è altrove sulla rete, quindi chiedo anche qui. Ho cancellato le cache arp sul gateway e sul core switch. Qualche idea benvenuta.

Aggiornamento:
ho provato a eseguire il ping dal gateway ad alcuni host interessati e la cosa strana è che ho ricevuto una risposta: da un indirizzo IP completamente diverso. Ne ho provati alcuni altri a caso e alla fine ho ottenuto questo:

Ven 02 set 2011 13:08:51 GMT-0500 (ora legale centrale)
PING 10.1.1.97 (10.1.1.97) 56 (84) byte di dati.
64 byte dal 10.1.1.105: icmp_seq = 1 ttl = 255 tempo = 1,35 ms
64 byte dal 10.1.1.97: icmp_seq = 1 ttl = 255 tempo = 39,9 ms (DUP!)

10.1.1.97 è l'attuale obiettivo previsto del ping. 10.1.1.105 dovrebbe essere una stampante in un altro edificio. Non ho mai visto un DUP in una risposta ping prima.

La mia ipotesi migliore al momento è un router wifi canaglia in una delle nostre stanze dormitorio sulla sottorete 10.1.1.0/24 con un gateway difettoso.

... continua. Ora ho spento la stampante incriminata e il ping su un host interessato dal gateway non funziona più.

Aggiornamento 2:
controllo le tabelle arp su una macchina interessata, sul gateway e su ogni switch tra di loro. Ad ogni punto, le voci per quei dispositivi erano tutte corrette. Non ho verificato tutte le voci nella tabella, ma ogni voce che potrebbe avere un impatto sul traffico tra l'host e il gateway andava bene. ARP non è il problema.

Aggiornamento 3:
Le cose stanno funzionando al momento, ma non riesco a vedere nulla che ho fatto per risolverli e quindi non ho idea se questo potrebbe essere solo una pausa temporanea. Comunque, non c'è molto che posso fare per diagnosticare o risolvere i problemi ora, ma aggiornerò di più se si rompe di nuovo.


Eseguire il ping sul gateway? I server DNS configurati si trovano sulla stessa sottorete o altrove? La risoluzione DNS funziona?
Shane Madden,

@Shane, tutto ciò che funziona, e viene data risposta nel testo
Joel Coel,

Hai detto "incapace di eseguire il ping o il tracert al nostro gateway": è il gateway first-hop dei dispositivi o un router Internet a cui viene instradato il traffico dopo essere stato instradato da un altro dispositivo first-hop?
Shane Madden,

2
Vorrei eseguire un'acquisizione di pacchetti su uno dei client e quindi eseguire il ping e tracciare il percorso verso il gateway. Scopri quali indirizzi MAC vengono visualizzati nell'acquisizione per quali indirizzi IP e cerca anche i reindirizzamenti ICMP. Vorrei anche dare un'occhiata da vicino alla tabella ARP su uno dei client, lo switch e il gateway e assicurarmi che appaiano corretti.
joeqwerty,

1
Per chiarire: stai dicendo che il gateway ha un ARP valido per un host interessato e che l'host ha un ARP valido sul gateway, ma il gateway non riceve risposta quando tenta di eseguire il ping dell'host? I pacchetti di ping arrivano sul dispositivo o non vengono commutati correttamente?
Shane Madden,

Risposte:


3

"La mia ipotesi migliore al momento è un router wifi canaglia in una delle nostre camere dormitorio sulla sottorete 10.1.1.0/24 con un gateway difettoso."

Questo è successo nel mio ufficio. Il dispositivo offensivo si è rivelato essere un dispositivo Android canaglia:

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

Se il dispositivo Android ottiene l'IP del gateway da un'altra rete tramite DHCP, potrebbe unirsi alla tua rete e iniziare a rispondere alle richieste ARP per l'IP del gateway con il suo MAC. L'uso della comune rete 10.1.1.0/24 aumenta la probabilità di questo scenario canaglia.

Sono stato in grado di controllare la cache ARP su una workstation interessata sulla rete. Lì, ho osservato un problema di flusso ARP in cui la stazione di lavoro si spostava tra il MAC corretto e un indirizzo MAC da un dispositivo non autorizzato. Quando ho cercato il MAC sospetto che la workstation aveva per il gateway, è tornato con un prefisso Samsung. L'utente astuto con la postazione di lavoro problematica rispose che sapeva chi aveva un dispositivo Samsung sulla nostra rete. Si è rivelato essere l'amministratore delegato.


2

Come già discusso nella sezione commenti, acquisire un pacchetto è davvero fondamentale. Tuttavia esiste anche uno strumento davvero eccezionale chiamato arpwatch:

http://ee.lbl.gov/

(o http://sid.rstack.org/arp-sk/ per windows)

Questo strumento ti invierà un'e-mail o manterrà un registro di tutti i nuovi indirizzi MAC visti sulla rete, nonché di eventuali modifiche per gli indirizzi MAC per gli IP su una determinata sottorete (flip-flop). Per questo problema, avresti rilevato entrambe le teorie attuali segnalando che c'erano infradito in corso per IP che cambiano MAC, o vedresti un nuovo MAC per il router DHCP non autorizzato quando inizia a comunicare con gli host. L'unico lato negativo dello strumento è che è necessario che l'host sia collegato a tutte le reti monitorate, ma è un piccolo prezzo per le informazioni eccezionali che può fornire per aiutare a diagnosticare questo tipo di problemi.


1

Un modo rapido per rilevare i tipici server DHCP non autorizzati è eseguire il ping del gateway utilizzato e quindi esaminare il relativo MAC nella tabella ARP corrispondente. Se l'infrastruttura di commutazione è gestita, il MAC può anche essere rintracciato fino alla porta che lo ospita e la porta può essere arrestata o rintracciata nella posizione del dispositivo in questione per ulteriore riparazione.

L'uso di snooping DHCP su switch che lo supportano può anche essere un'opzione efficace per proteggere una rete anche da server DHCP non autorizzati.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.