» continua
» continua
» continua
» continua
Questo articolo descrive un metodo strutturato per risolvere i problemi di troubleshooting inerenti le reti TCP/IP. Si tratta del primo di una serie di articoli sul troubleshooting TCP/IP: i futuri articoli si focalizzeranno sui punti chiave evidenziati di seguito.
In teoria, il TCP/IP troubleshooting dovrebbe essere una procedura semplice. Dopo tutto è soltanto un protocollo, una serie di passaggi volti a trasferire i bit sulla rete. Ma non è un protocollo qualsiasi: parliamo di quattro strati, con protocolli multipli su ogni strato.
Il metodo di troubleshooting tradizionale
Il troubleshooting del TCP/IP può
essere visto come un metodo basato su un semplice approccio per punti,
volto a risolvere i problemi riguardanti la ricerca dei guasti. In pratica, un
metodo simile al seguente:
- Digitate ipconfig per controllore se sono corretti indirizzo IP, subnet mask e gateway di default.
- Ora fate il ping all'indirizzo 127.0.0.1 per vedere se il vostro adattatore di rete sta funzionando correttamente.
- Fate il ping all'indirizzo IP del vostro computer.
- Ora provate a fare ping all'indirizzo IP di un altro computer sulla stessa sottorete.
- Provare a fare ping al vostro gateway di default
- Fate quindi ping all'indirizzo IP di un computer su una sottorete differente.
- E così via.
Questo metodo è piuttosto inefficiente, dato che automaticamente presuppone che con tutta probabilità il problema riguardi il vostro computer e che risieda nelle vostre vicinanze (la vostra scheda di rete, la configurazione dell'indirizzo IP del vostro computer, la vostra sottorete locale) piuttosto che in dispositivi remoti (altre sottoreti). Ed è un metodo che probabilmente è stato messo a punto prima del reale sviluppo di Internet - prima che il DNS diventasse ubiquitario per la name resolution e prima che i firewall e le VPN si trasformassero in un fattore vitale per la maggior parte delle reti aziendali.
Supponiamo che uno dei vostri utenti dica: “non posso collegarmi al server ora”. Quale potrebbe essere il problema? Quanto esposto aiuta ad analizzare questa semplice affermazione per capire i problemi che potrebbero esserne la causa. Per esempio:
"Non posso…"
È questo l'unico utente che ha segnalato problemi della
rete? Se ce ne sono altri, hanno problemi simili?
La questione più probabilmente riguarda qualche luogo “esterno” e questo potrebbe significare che
forse il vostro server di DNS è spento oppure i servizi del
vostro provider di DNS stiano incontrando delle difficoltà. O forse un
router sulla vostra rete interna non funziona. Oppure il server a cui i
vostri utenti stanno provando di collegarsi può aver avuto un crash.
Dovreste anche fermarvi e pensare a ogni elemento comunue che questi utenti potrebbero avere. Per esempio, le loro macchine sono tutte collegate alla stessa sottorete? Se la risposta è affermativa, allora forse il gateway di default per tale sottorete è configurato in modo errato o il router si è bloccato. O magari qualche malintenzionato ha installato un falso server DHCP su quella sottorete e sta usando illecitamente le macchine al fine di attivare l'assegnamento di indirizzi unroutable per generare una tipica condizione denial of service.
"… collegarmi a…"
Una buona domanda da porre a tale utente è “Cosa
significa essere collegato?” Ci sono generi differenti di connessioni, comprese
le comunicazioni di livello MAC, le sessioni TCP, l'autenticazione delle
password, i diritti di accesso e i privilegi, la connessione trasversale NAT, i
pass-through dei firewall, le sessioni dell'application level e così via. Che
genere di problema di connessione stanno realmente avendo gli utenti? Cosa
stanno tentando di fare quando dicono che desiderano “collegarsi” al server?
Stanno provando ad accedere a una risorsa condivisa sul server? Gli utenti
ottengono un messaggio di “accesso negato” quando eseguono questa operazione?
Visualizzano un box di login che domanda di digitare le proprie credenziali?
Questo box sta rifiutando le loro credenziali? Stanno avendo difficoltà a trovare la
condivisione nell'Active Directory ? È un drive mappato quello con il quale stanno avendo dei
problemi? Stanno provando a effettuare il browsing per individuare il server nelle “Connessioni di
rete”? E così via.
In più, è soltanto quel determinato server che dà loro problemi di connessione, o stanno avendo i medesimi problemi con qualunque dispositivo sulla rete? La definizione della portata del problema è importante: la connettività manca solo in un unico senso oppure in diverse direzioni?
"… al server…"
Avete gli utenti da
una parte, il server dall'altra e la rete nel mezzo. Non possono collegarsi.
Perché? Dove si trova esattamente quel server? È sulla sottorete
dell'utente? Su una sottorete adiacente? In un reparto differente o su un diverso piano?
In un altro edificio? Che genere di rete collega l'utente con quel
particolare server? Una LAN Ethernet cablata? Una LAN wireless (WLAN)? Una linea
frazionata T1, un Frame Relay, un tunnel VPN over Internet, una connessione
modem dial-up, un cable modem oppure una linea DSL?
In primo luogo, determinate il tipo di connessione (possibilmente diversi tipi) fra l'utente e il server e quindi considerate dove tale connessione potrebbe essersi interrotta. Se state utilizzando switch gestiti, controllate per vedere se avete ricevuto un messaggio di allarme dal vostro software di amministrazione di rete. Forse è mancata la corrente elettrica nel branch office remoto in cui quel server è situato. Chiamate la sede distaccata e verificate cosa sta accadendo.
È un solo server o sono diversi server? L'utente ha avuto difficoltà a collegarsi soltanto a quel server o anche ad altri server? Anche altri utenti hanno avuto problemi a collegarsi ad altri server? Quali sono i punti in comune (se ce ne sono) tra tutti i server che sono interessati?
"… ora."
L'elemento tempo è cruciale nell'analisi guasti. Il
problema è appena successo? Quando è stata l'ultima volta che vi siete collegati
con successo al server? Per quanto tempo ? Il malfunzionamento è continuo o
intermittente? I problemi intermittenti della rete che coinvolgono collegamenti
Wan inaffidabili e altre questioni possono essere difficili da individuare con
un troubleshooting, in particolare se sono transitori, cioè brevi e occasionali.
Il tempo può anche aiutarvi a mettere in relazione i problemi con altre circostanze che potrebbero avere effetto sulla vostra rete. Il problema è cominciato questa mattina alle 10? Che altro allora è accaduto sulla vostra rete? Sono state applicate le patch da un server? La manutenzione prevista sul domain controller è stata fatta? Sono stati fatti dei lavori sull'edificio?
Il nostro approccio all'analisi dei guasti TCP/IP si struttura in tre aree critiche:
1. Definizione degli elementi del problema. Ciò significa:
- Il lato client: i client che stanno incontrando una o più difficoltà.
- Il lato server: server, stampanti o altre risorse di rete (come Internet) con cui i client stanno incontrando delle difficoltà.
- La rete che sta nel mezzo: i cavi (se la rete non è wireless), gli hub, gli switch, i router, i firewall, i proxy server e qualunque altra infrastruttura di rete compresa fra il client e il server.
- L'ambiente: circostanze esterne che possono interessare la rete, come le variazioni nella tensione di alimentazione, la manutenzione dell'edificio e così via.
- Il contesto: uno o più client/server coinvolti.
- Il fattore tempo: continuo, intermittente, occasionale; quando è iniziato e così via.
- Tipo del problema di connessione: fisico, di rete, dello strato di trasporto o dell'applicazione; controllo di accesso o di autenticazione e così via.
- Segnali: messaggi di
errore sulle macchine client; box di login e così via.
2. Definizione di quali step del troubleshooting potrebbero applicarsi ai suddetti elementi del problema. Questo include:
- Verifica della connettività dei media fisici per i client, i server e l'infrastruttura hardware di rete coinvolta. Ciò significa controllare i cavi, assicurarsi che gli adattatori di rete siano disposti correttamente e cercare altre cause tra i possibili collegamenti di rete che potrebbero portare a visualizzare una disconnessone tra i media.
- Verifica della configurazione TCP/IP dei client, dei server e dell'infrastruttura hardware della rete in questione. Sui client e sui server, questo significa indirizzi IP, subnet mask, gateway di default, le regolazioni del DNS e così via. Per l'infrastruttura hardware della rete, tipicamente significa le tabelle di routing sui router e sui gateway Internet.
- Verifica della connettività di percorso fra i client e i server coinvolti. Ciò significa usare ping, pathping, tracert e altri tool simili per verificare la connettività end-to-end del TCP/IP a livello di rete; sniffing del pacchetto per controllare le sessioni dello strato di trasporto; usare nslookup, telnet e altri tool per il troubleshooting di malfunzionamenti inerenti l'application layer che coinvolgono problemi di name resolution, di autenticazione e così via.
3. Capire, interrogare ed esaminare.
- E' più che mai critico capire come funzionano i protocolli, come i pacchetti sono spediti dalle tabelle di routing e cosa possono dirvi tool come Netdiag.exe. Un troubleshooting del TCP/IP di successo è fondato su una buona comprensione del funzionamento del TCP/IP stesso e sui tool che possono essere utilizzati per esaminarlo.
- Anche fare le domande giuste è essenziale per un buon troubleshooting. Imparare quando si deve essere metodici e quando "creativi" è l'essenza dell'arte del troubleshooting
- Infine gettatevi nella ricerca della soluzione effettuando test e tentando di isolare il problema. In questo senso, avrete bisogno di un insieme di tool per il troubleshooting che sapete usare bene. Non c'è niente di più utile di un sacco di esperienza per aiutarvi a risolvere un problema difficile, anche se è qualcosa che non avete mai visto prima.
