Utilizziamo Network Monitor per scoprire i segreti del traffico di rete quando consultiamo le pagine di un sito internet o quando inviamo una e-mail.

Con alcune nozioni del protocollo TCP/IP e di un programma sniffer gratuito come Network Monitor, potrete visualizzare il traffico di rete della vostra scheda Wi Fi o Ethernet.

In breve tempo potrete risolvere con facilità i più comuni errori di connessione della vostra rete locale LAN o internet.
I primi passi con Network Monitor

Testo del video

Risoluzione dell’indirizzo IP

vai al minuto 00:00

Ciao a tutti e ben venuti alla seconda parte del tutorial su Network Monitor. Nella prima parte abbiamo visto come scaricare e installare il programma e come si cattura il traffico su una determinata interfaccia di rete. Nella prima parte abbiamo anche visto come avviene la risoluzione dell’URL in un indirizzo IP. Se vi ricordate questo è l’URL che abbiamo inserito nella barra degli indirizzi del browser.

vai al minuto 00:21

I più attenti di voi avranno sicuramente notato che l’URL da noi inserito è stato corretto dal browser nella barra degli indirizzo aggiungendo la stringa www all’inizio del nome di dominio. Questo è quello che abbiamo inserito ed è stato risolto con questo indirizzo. Quello corretto è stato risolto con questo indirizzo IP.

vai al minuto 00:43

Siccome questa è stata la risoluzione ultima di questo dominio, la seguente richiesta al sito di Google verrà effettuata utilizzando l’indirizzo IP .
Per chi non lo sapesse, i computer, per scambiare dati tra loro, fanno riferimento esclusivamente agli indirizzi IP, i nomi vengono utilizzati solo dagli esseri umani perché più amichevoli e più facilmente memorizzabili dei numeri.

Analisi traffico HTTP

vai al minuto 01:10

Se ora andiamo a spulciare tra il traffico generato dal browser troveremo proprio l’indirizzo di Google. In questo caso abbiamo trovato con facilità il traffico che ci interessava, ma nell’eventualità di dover analizzare una quantità di dati maggiore potremo utilizzare i filtri che ci mette a disposizione il programma.

vai al minuto 01:28

Dopo alcuni pacchetti sulla porta 80 con protocollo HTTP non crittografato, Google forza l’utilizzo del protocollo HTTPS sulla porta 443. Infatti se analizziamo il dettaglio del frame, Google risponde allo nostra richiesta sulla porta 80 con il codice 302 e ci comunica la nuova posizione del documento che utilizza il protocollo HTTPS.

Risorse esterne incorporate nelle pagine WEB

vai al minuto 01:54

Un’altro cosa interessante da notare è il traffico proveniente da altri host sempre di Google che forniscono contenuti esterni alla pagina da noi richiesta. Che siano host di Google si intuisce dal fatto che iniziano tutti con 172.217 e il terzo ottetto è 18 o 19. Se selezioniamo la conversazione possiamo anche vedere il nome di dominio che corrisponde all’indirizzo IP.

Analisi traffico dell’invio e-mail

vai al minuto 02:24

Ora voglio farvi vedere cosa succede quando si invia una mail. Questo è il traffico catturato durante l’invio di una mail sulla porta 465 che utilizza il protocollo TLS per crittografare i dati. Siccome TCP è un protocollo orientato alla connessione, prima di ogni trasmissione vedremo questi tre frame, rispettivamente con i flags impostati a S, A ed S e il terzo ad A.

vai al minuto 02:51

Seguiranno i pacchetti di dati crittografati e altri pacchetti TCP per il controllo della comunicazione. Cliccando nella colonna di sinistra possiamo isolare i pacchetti TLS. Il sotto insieme SSL e TLS filtra gli stessi pacchetti.
Anche questo protocollo prima di trasmettere i dati ha bisogno di scambiarsi alcune informazioni. Vengono scambiati alcuni pacchetti di HandShake, stretta di mano in italiano: Client Hello, Server Hello e altri.

vai al minuto 03:23

Se visualizzo nuovamente anche i pacchetti TCP, prima della fine della comunicazione, posso notare alcuni pacchetti con l’impostazione del flag A ed F, che stanno per ACK e FIN. Il server di posta, con l’impostazione di questi flags comunica che intende terminare la comunicazione TCP. Anche il nostro client di posta acconsente alla chiusura della comunicazione son l’impostazione dei flags ACK e FIN.

Capire gli erorri nell’invio delle e-mail

vai al minuto 03:50

Dopo che abbiamo compreso grosso modo cosa avviene quando inviamo una mail, diamo uno sguardo a un tentativo non riuscito di inviare la mail. Il tentativo di invio è stato fatto da un DVR di video sorveglianza.
Questi dispositivi solitamente hanno una funzionalità che vi permette di testare la configurazione della mail senza, però, fornire indicazioni utili nel caso in cui il test fallisce, vi avvisa solamente che l’invio della mail di prova non è riuscito.
Un’altro limite di certi dispositivo è la mancanza di alcune opzioni di configurazione rispetto ad un client di posta come Thunderbird.

vai al minuto 04:28

Grazie a Network Monitor riesco a capire perché il mio dispositivo non riesce a inviare la mail di prova. Qua posso vedere che il DVR utilizza il protocollo SSL versione v3 per inviare l’HandShake: Client Hello ma il server non risponde con l’HandShake: Server Hello che abbiamo potuto vedere nell’esempio precedente. Il server risponde sempre con il protocollo TLS più recente e sicuro di SSL v3. La comunicazione fallisce a livello applicazione nel concordare l’utilizzo del protocollo.

vai al minuto 05:02

Grazie a Network Monitor sappiamo quale parametro della configurazione dobbiamo modificare. Con questi due video vi ho mostrato le potenzialità di Network Monitor e con qualche nozione di TCP/IP e dei filtri messi a disposizione del programma potrete risparmiare molto tempo nella ricerca degli errori di rete.