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

telnet5 impossible connect

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

netstat1Come 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

file hosts2

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.

banner5

fb icon evo twitter icon evo

Parola del giorno

L'acronimo SoC  (System on a Chip) nasce per descrivere quei circuiti integrati che, all'interno di un singolo chip fisico, contengono un...

>

YAML è un formato utilizzato per serializzare (ovvero salvare oggetti su supporti di memoria ad accesso seriale) dati, in modo...

>

Il termine Edge Computing descrive, all'interno di infrastrutture cloud-based, l'insieme di dispositivi e di tecnologie che permettono l'elaborazione dei dati ai...

>

L'acronimo FPGA  (Field Programmable Gate Array), descrive quei dispositivi hardware formati da un circuito integrato e con funzionalità programmabili tramite...

>

Il termine Agentless (computing) descrive operazioni dove non è necessaria la presenza e l'esecuzione di un servizio software (demone o...

>
Leggi anche le altre...

Download del giorno

Fiddler

Fiddler è un server proxy che può girare in locale per consentire il debug delle applicazioni e il...

>

Adapter Watch

Adapter Watch è uno strumento che permette di visualizzare un riepilogo completo e dettagliato delle informazioni riguardanti una determinata...

>

DNS DataView

DNS Lookup  è un tool a interfaccia grafica per effettuare il lookup DNS dal proprio PC, sfruttando i...

>

SolarWinds Traceroute NG

SolarWinds Traceroute NG è un tool a linea di comando per effettuare traceroute avanzati in ambiente Windows...

>

Network Inventory Advisor

Network Inventory Advisor  è uno strumento che permette di scansionare la rete e acquisire informazioni riguardanti tutti i...

>
Tutti i Download del giorno...

Archivio numeri

  • GURU advisor: numero 21 - maggio 2019

    GURU advisor: numero 21 - maggio 2019

  • GURU advisor: numero 20 - dicembre 2018

    GURU advisor: numero 20 - dicembre 2018

  • GURU advisor: numero 19 - luglio 2018

    GURU advisor: numero 19 - luglio 2018

  • GURU advisor: numero 18 - aprile 2018

    GURU advisor: numero 18 - aprile 2018

  • GURU advisor: numero 17 - gennaio 2018

    GURU advisor: numero 17 - gennaio 2018

  • GURU advisor: numero 16 - ottobre 2017

    GURU advisor: numero 16 - ottobre 2017

  • GURU advisor: numero 15 - luglio 2017

    GURU advisor: numero 15 - luglio 2017

  • GURU advisor: numero 14 - maggio 2017

    GURU advisor: numero 14 - maggio 2017

  • 1
  • 2
  • 3
  • Teslacrypt: rilasciata la chiave

    Gli sviluppatori del temuto ransomware TeslaCrypt hanno deciso di terminare il progetto di diffusione e sviluppo e consegnare al pubblico la chiave universale per decifrare i file. Read More
  • Proxmox 4.1 sfida vSphere

    Proxmox VE (da qui in avanti semplicemente Proxmox) è basato sul sistema operativo Debian e porta con sé vantaggi e svantaggi di questa nota distribuzione Linux: un sistema operativo stabile, sicuro, diffuso e ben collaudato. Read More
  • Malware: risvolti legali

    tutti i virus e in particolare i più recenti Ransomware, che rubano i vostri dati e vi chiedono un riscatto, violano la legge. Vediamo insieme come comportarsi, per capire anche se e quando bisogna sporgere denuncia. Read More
  • 1