Con questo articolo passiamo in rassegna alcuni comandi basilari di Windows utili a fare diagnosi e troubleshooting di rete. Questi pochi comandi, opportunamente usati permettono di giungere velocemente a conclusioni utili a risolvere la maggior parte delle problematiche di rete che si possono riscontrare.
Molto spesso presi dallo sconforto perchè un servizio o applicazione non risponde, non si rimane sufficientemente lucidi da procedere a seguire i dovuti step nel troubleshooting di rete.
Vediamo come muoversi razionalmente.
SCENARIO
Il sito Internet che abbiamo su un nostro web server windows non funziona.
Chiaramente diamo per scontato che la nostra linea internet funzioni, navighiamo tranquillamente su altri siti, il firewall di rete interno non ci sta bloccando e l'antivirus locale del pc non interferisce. Tutti questi elementi di solito non sono da dare affatto per scontati!
MAGICO Ping
Chi non conosce il Ping? Probabilmente è il comando in assoluto maggiormente utilizzato dal prompt dei comandi di Windows e forse anche di Linux, anche dai neofiti.
Il Ping è magico perchè ci da subito un riscontro sulla raggiungibilità di un host, che sia nella rete locale o dall'altra parte del mondo. Questo comando ha una ventina di opzioni, ma ci accontentiamo proprio della base.
Nello scenario descritto, da un qualsiasi pc si fa subito il test col Ping.
ping www.example.com
Subito dovremmo avere delle informazioni utili.
I risultati infatti possono essere:
1- Esecuzione di Ping www.example.com [90.90.90.91] con 32 byte di dati:
Fermiamoci un secondo alla prima riga. E' importantissima, perchè ci dice che il nome del vostro sito viene risolto a livello di DNS con l'ip 90.90.90.91
A questo punto dovremmo confrontare se questo IP corrisponde all'ip del server web che ospita il nostro sito web o per qualche ragione dobbiamo andare a rivedere la configurazione della zona DNS per il dominio www.example.com
In questo scenario consideriamo che a livello di DNS sia tutto corretto e che l'indirizzo IP del sito sia giusto.
Andiamo avanti.
Le righe sotto la prima possono essere:
1- Richiesta Scaduta
2- Risposta da 90.90.90.91: byte=32 durata=50ms TTL=50
Nel primo caso Richiesta Scaduta, ci dice tutto e niente. Infatti Richiesta Scaduta si può verificare per via di diverse condizioni. Potrebbe dipendere dall'antivirus locale che blocca del traffico, dal nostro firewall di rete locale che non fa passare il traffico ICMP, dal firewall che protegge il vostro web server, la linea Internet che non va o effettivamente dal fatto che il vostro web server è KO.
Alcune cause le abbiamo escluse nel nostro scenario, però è importante tenere presenti questi elementi per altre circostanze.
Nel secondo caso Risposta da... ci solleva un pò il morale, perchè almeno ci da l'informazione sul fatto che il nostro computer riesce a raggiungere l'indirizzo IP del sito web.
Ma anche in questo caso questa informazione non deve illuderci troppo, visto che l'IP potrebbe essere assegnato ad un firewall e non direttamente al Web server. Nel primo caso sarebbe il firewall che protegge il Web server a rispondere...quindi quello che ci direbbe in tal caso il Ping è che il nostro computer arriva fino al firewall.
Poniamo in questo scenario che la risposta al Ping ci sia e andiamo avanti con il troubleshooting.
TELNET
Questo comando scende drasticamente invece nella classifica dei comandi più utilizzati, anche se dovrebbe essere sempre preso in enorme considerazione specialmente per fare troubleshooting di rete.
L'uso del comando telnet è abbastanza semplice
telnet www.example.com 80
Cosa significa?
Telnet è un comando che avvia un software di comunicazione. Nel caso si voglia fare troubleshooting di rete viene utilizzato solo, si fa per dire, per verificare che dall'altra parte ci sia un Server che risponde. Per Server si intende un servizio che risponde su una determinata porta.
Infatti come si vede nell'esempio, segue al nome dell'host (www.example.com) il numero 80.
Questo numero rappresenta la porta 80 utilizzata dal protocollo HTTP. Sarebbe potuta essere anche la porta 25 SMTP di un server di posta.
Quando dall'altra parte c'è qualcosa in ascolto, non appena darete invio al comando telnet www.example.com 80, il prompt dei comandi diventerà tutto nero e il cursore inizierà a lampeggiare, nell'angolo in alto a sinistra.
Purtroppo nel caso di web server non è che ci vengono restituite altre informazioni (mentre nel caso di mail server di solito c'è un responso diverso)
Diversamente appare:
telnet ww.example.com 80
Connessione a www.example.com...
e dopo un pò che la connessione non si avvia
telnet www.example.com 80
Connessione a www.example.com...Impossibile aprire una connessione con l'host. sulla porta 80: Connessione non riuscita
In questa circostanza avremmo un indizio abbastanza chiaro. O il firewall che protegge il vostro web server non ha la porta aperta per far passare il protocollo HTTP (che lavora come detto su porta 80) oppure il vostro web server non ha il servizio attivo.
Poniamo che otteniamo risposta e il cursore del telnet lampeggi. Ecco, già con questa prova riusciamo a capire se c'è qualcosa in ascolto sul web server (e se ci arriviamo).
Non prendiamo per assoluto anche questa sentenza, perchè in alcuni casi a rispondere potrebbe non essere realmente il web server, ma il firewall che fa NAT dall'ip pubblico ad esso assegnato (e corrispondente al sito web), verso l'indirizzo IP reale (privato) del web server su cui è presente il nostro sito.
In questa occasione diamo però per più probabile che se il telnet inizia a comportarsi come sopra descritto, non sia il firewall a rispondere ma il web server.
In questo caso abbiamo appurato che la connettività dal vostro client usato per fare i test, verso il web server, funziona correttamente e il firewall gira la connessione verso un host interno che ha la porta 80 in ascolto.
Il sito però continua a non funzionare. Sono appositamente un pò superficiale sul termine "non funzionare" proprio per dare un senso allo scenario, perchè ad essere pignoli... ed un sistemista deve necessariamente essere pignolo, all'affermazione "il sito non funziona", dovrebbe approfondire e rispondere a domande del tipo "in che senso non funziona, che messaggio di errore da il browser?". Ma per dare un senso a questo scenario andiamo avanti con un po' di superficialità iniziale.
Si rende a questo punto necessario un controllo sul web server e per forza di cose è il caso di accedervi remotamente.
Cosa facciamo una volta saliti sul web server?
Appuriamo prima di tutto che il web server abbia effettivamente la porta 80 in ascolto.
NETSTAT
Ci viene in aiuto un comando anch'esso poco utilizzato, Netstat!
Netstat è un comando molto potente ci da informazioni sulle connessioni di rete del computer su cui si lancia il comando.
Se c'è il servizio Web server attivo sulla vostra macchina, bisogna aspettarsi che ci sia la porta 80 in ascolto.
Lanciamo netstat con le opzioni -na per avere
a ->visualizzate tutte le connessioni e le porte di ascolto
n ->visualizza indirizzi e numeri di porta in formato numerico
netstat -na
Connessioni attive
Proto Indirizzo locale Indirizzo esterno Stato
TCP 0.0.0.0:7 0.0.0.0:0 LISTENING
TCP 0.0.0.0:9 0.0.0.0:0 LISTENING
-> TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3306 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8081 0.0.0.0:0 LISTENING
TCP 10.29.252.7:21 0.0.0.0:0 LISTENING
TCP 10.29.252.7:21 5.235.162.249:50585 ESTABLISHED
-> TCP 10.29.252.7:80 7.196.43.49:47132 TIME_WAIT
TCP 10.29.252.7:80 7.196.43.49:47135 TIME_WAIT
TCP 10.29.252.7:80 66.249.66.17:57638 ESTABLISHED
TCP 10.29.252.7:80 193.243.55.129:12007 TIME_WAIT
TCP 10.29.252.7:80 207.46.13.173:16816 ESTABLISHED
TCP 10.29.252.7:139 0.0.0.0:0 LISTENING
TCP 10.29.252.7:50383 0.0.0.0:0 LISTENING
TCP 10.29.252.7:50769 141.1.252.8:80 LAST_ACK
TCP 10.29.252.7:50794 141.1.252.8:80 CLOSE_WAIT
TCP 10.29.252.7:50799 159.122.189.53:5938 ESTABLISHED
TCP 10.29.252.7:50803 168.63.124.19:443 TIME_WAIT
TCP 10.29.252.7:50806 141.1.252.8:80 ESTABLISHED
Come si vede dall'esempio abbiamo in localhost (IP 0.0.0.0) un servizio in ascolto sulla porta 80
infatti si legge 0.0.0.0:80
e sull'indirizzo locale del server (IP 10.29.252.7) sempre il servizio web in ascolto sulla porta 80
infatti si legge 10.29.252.7:80
Rispolveriamo Telnet per scrupolo.
Dal server apriamo il prompt dei comandi
telnet 10.29.252.7 80
Nel nostro scenario scopriamo che il servizio risponde (il prompt lampeggia nell'angolo in alto a sinistra dopo l'invio del comando).
Qualcuno potrebbe pensare di provare a navigare il sito con il browser del server per vedere se funziona. Ma è una prova che può dare esito positivo solo in determinate configurazioni del servizio di Web Server.
Non è detto che se apriamo il browser e al posto dell'indirizzo www.example.com mettiamo l'indirizzo IP 10.29.252.7, il sito si apra o meglio il web server risponda poichè potrebbe ospitare ben più di un sito. Dato che questo argomento richiederebbe un articolo a se stante sul funzionamento dei web server, considerate questa cosa come assunto e muovetevi come di seguito indicato.
Per andare sul sicuro, è necessario che il web server risolva www.example.com come indirizzo locale (10.29.252.7) e non come indirizzo pubblico (90.90.90.91)
Apriamo il command prompt
ping www.example.com
Esecuzione di Ping www.example.com [90.90.90.91] con 32 byte di dati:
Il web server risolve il sito con IP pubblico. Quindi per testare il funzionamento del web server dobbiamo cambiare le carte in tavola. Per modificare questa condizione è necessario modificare il file hosts in "C:\Windows\System32\drivers\etc" (assumiamo che si sia in grado di fare questa attività, dovrete aprire naturalmente Notepad o il vostro editor preferito eseguendolo come amministratore o non avrete i permessi per modificarlo).
Aggiungiamo una riga
10.29.252.7 www.example.com
chiudiamo, salviamo.
rieseguiamo il ping
ping www.example.com
Esecuzione di Ping www.example.com [10.29.252.7] con 32 byte di dati:
OK perfetto.
Ora possiamo provare ad aprire il browser e usare come url http://www.example.com
Sorpresa il sito funziona correttamente.
(la scheda di rete del web server è configurata correttamente infatti siamo riusciti a salirci remotamente con il nostro software di controllo remoto)
RICAPITOLIAMO
Dall'esterno a livello di rete l'ip pubblico è raggiungibile, la risoluzione DNS è corretta e il Telnet verso il web server risponde. Salendo sul web server scopriamo che i servizi sono in ascolto e anzi ancora meglio verifichiamo che il sito in locale funziona.
Dove sta il problema?
Potremmo dire che non ci sono dubbi. Il problema è a livello di Firewall! Il web server come visto ha un IP privato e in locale il sito funziona (cioè dal web server stesso); l'IP pubblico è assegnato al firewall che protegge il web server.
Tutti gli step visti sopra con questi comandi "elementari" ma di fatto non utilizzati propriamente dalla maggior parte dei sistemisti, si eseguono in meno di 5 minuti.
Quando si arriva a determinare che il problema è sul firewall è più "semplice" muoversi perchè ci si può concentrare unicamente su di esso. Le possibili cause possono essere molteplici.
La regola di NAT sbagliata. Magari la regola anzichè nattare l'ip pubblico 90.90.90.91 verso l'ip privato 10.29.252.7, erroneamente gira verso un'altro ip che guarda caso è un'altro web server.
(Eh no….non è che se tentate di andare su www.example.com e il firewall punta al web server sbagliato, vi si aprirà la pagina web dell’altro web server…non funziona così!)
Oppure il protocol inspector non digerisce l'output del vostro web server e ne interrompe il flusso dati.
Arrivati a questo punto bisognerebbe avere da una parte accesso al firewall in una delle funzioni che consente di vedere in tempo reale le connessioni attive e dall’altra la connessione al web server, magari con il prompt dei comandi aperto e il comando netstat attivo per vedere se arrivano le chiamate dall’esterno.
Questo però diventerebbe già un troubleshooting avanzato. Per il momento consolidate l’uso sistematico di questo approccio sistemistico, facendo riferimento ai comandi citati. Esistono anche nel corrispettivo Linux e l’approccio sistemistico è esattamente lo stesso.