[Articolo] Il comando netstat in Windows: come interpretare le connessioni

Analizziamo oggi il comando netstat, uno dei principali comandi per fare troubleshooting delle reti in ambiente Windows e per controllare quali connessioni sono stabilite.

Vediamo i 5 casi di utilizzo più importanti e da tenere sott’occhio. […]

Difficoltà articolo (0->10): 6

Analizziamo oggi il comando netstat, uno dei principali comandi per fare troubleshooting delle reti in ambiente Windows e per controllare quali connessioni sono stabilite.

Vediamo i 5 casi di utilizzo più importanti e da tenere sott’occhio.

1 – Lista connessioni e porte in ascolto: netstat -an

Questo è il caso più semplice di utilizzo del comando che elenca tutte le connessioni comprese quelle attive (stato ESTABLISHED), e quelle con una porta in ascolto (stato LISTENING). L’opzione n non è essenziale, ma è secondo me utile perché effettua un DNS lookup andando a mostrare indirizzo IP al posto di ogni hostname. I possibili stati in cui una connessione può trovarsi sono quelli mostrati nella tabella seguente.

Stato Descrizione
CLOSED Indica che il server ha ricevuto dal client un messaggio ACK e la connessione è chiusa.
CLOSE_WAIT Indica che il server ha ricevuto dal client il primo FIN e la connessione è in fase di chiusura.
ESTABLISHED Indica che il server ha ricevuto dal client un SYN e la sessione è stata stabilita.
FIN_WAIT_1 Indica che la connessione è ancora attiva ma al momento non è usata e verrà chiusa.
FIN_WAIT_2 Indica che il client ha ricevuto l’ACK del server, dopo che il server ha ricevuto il primo FIN dal client.
LAST_ACK Indica che il server sta per inviare il proprio messaggio FYN.
LISTENING Indica che il server è in ascolto e pronto ad accettare una nuova connessione.
SYN_RECEIVED Indica che il server ha ricevuto il SYN inviato dal client.
SYN_SEND Indica che la connessione è attiva.
TIME_WAIT Indica che la connessione è in fase di chiusura, ma è ancora attiva.
screen_netstat1
netstat -an

Tutti zero nella colonna “Foreign” significa che ancora non ci sono indirizzi remoti, e pertanto la linea rappresenta un servizio in ascolto. Nel momento in cui un servizio riceve una connessione in ingresso, allora verrà stabilita una nuova connessione e dunque verrà mostrata una linea specifica all’interno della lista di connessioni.

Su questo sito si trova un’ottima spiegazione degli stadi e delle transizioni nel protocollo TCP, e il diagramma mostrato è veramente ben fatto:

TCP-StateTransitionDiagram-NormalTransitions

2 – Fully qualified domain name: netstat -f

Con questo parametro il comando mostra il nome intero (FQDN) di ogni indirizzo IP, risolvendolo internamente o se possibile esternamente.

netstat -f
netstat -f

3 – Tabella di routing: netstat -r

L’opzione permette di mostrare la tabella di routing del sistema, ed è l’analogo del comando route print.

netstat -r
netstat -r

4 – Processo per ogni porta: netstat -aon oppure nestat -b

In questo modo per ogni porta aperta nel sistema vengono elencati lo stato e l’identificativo del processo (PID) che ha aperto la porta. L’opzione b è migliore perché mostra direttamente l’eseguibile del processo in esecuzione ma richiede i permessi di amministratore per poter essere eseguita.

netstat -aon
netstat -aon

5 – Statistiche di rete: netstat -s -p IP

Mostra le statistiche di rete relative al livello 3, ossia IP. E’ possibile in questo modo vedere eventuali errori o problemi di connessione.

netstat -s -p IP
netstat -s -p IP

Sono utili anche la possibilità di mantenere la lista aggiornata ad un certo intervallo (ad esempio ogni 5 secondi):

nestat -an 5

e quella di salvare l’output del comando in un file:

netstat -an >> C:\connections_list.txt

roghan

Come risolvere i problemi di connessione, il DNS – parte 2

Se la connessione ad Internet o la navigazione sul web non funzionano i motivi potrebbero essere molti, ed uno di questi potrebbe essere legato al server DNS utilizzato. Ad esempio non vengono più caricate le pagine web ma la connessione sembra stabilita? Come risolviamo il problema? Spesso quando la rete non va si pensa a tutto meno che a verificare il funzionamento del server DNS. Questo post rappresenta la seconda parte di un altro in cui spiegavo come risolvere i problemi in una rete locale senza l’uso del DNS. In questo articolo invece ci spostiamo ai problemi di connessione anche verso la grande Rete. […]

Se la connessione ad Internet o la navigazione sul web non funzionano i motivi potrebbero essere molti, ed uno di questi potrebbe essere legato al server DNS utilizzato. Ad esempio non vengono più caricate le pagine web ma la connessione sembra stabilita? Come risolviamo il problema? Spesso quando la rete non va si pensa a tutto meno che a verificare il funzionamento del server DNS. Questo post rappresenta la seconda parte di un altro POST in cui spiegavo come risolvere i problemi in una rete locale senza l’uso del DNS. In questo articolo invece ci spostiamo ai problemi di connessione anche verso la grande Rete.

Prima di affrontare la problematica ricordiamo che il DNS, acronimo di Domain Name System, è un protocollo di comunicazione che traduce i nomi delle macchine in indirizzi IP, ed è quindi fondamentale per la navigazione sul web. Infatti, durante la navigazione su Internet vengono solitamente digitati sul browser i nomi dei siti che vogliamo visitare, i quali vengono poi tradotti dal protocollo DNS in indirizzi IP. Ciò avviene in modo del tutto automatico e trasparente per l’utente, difatti è il sistema operativo stesso che si occupa di interrogare uno dei server DNS impostati e di ottenere come risposta l’indirizzo IP del sito da visitare. Per conoscere i server DNS configurati è sufficiente digitare da terminale: ipconfig /all in ambiente Windows, e ifconfig in Linux.

Vediamo adesso gli step da fare.

  1. ping verso Internet. L’operazione “classica” è di effettuare un ping verso un sito Internet. Importante è effettuare due prove con il comando ping, una utilizzando come destinazione il nome completo di un sito Internet (FQDN), l’altra utilizzando l’indirizzo IP diretto del sito. Nel caso in cui entrambi i ping non ricevano risposta, il problema è da ricercarsi nella connessione stessa e non c’entra niente il DNS. I problemi potrebbero essere dovuti al proprio fornitore di connettività, al router mal configurato, ai driver/moduli della scheda di rete, al sistema operativo, … Nel caso in cui invece il ping con il nome completo di un sito non funzioni, mentre viene restituita la risposta utilizzando l’indirizzo IP, il problema è da ricercarsi nel DNS (passare al punto successivo). Ecco un esempio esplicativo, in cui il server DNS configurato è errato oppure non è funzionante.

    ping_senza_dns
    Esempio con DNS errato o non impostato
  2. verifica del server DNS. Verificato che la connessione a Internet non risponde (e il ping di un sito utilizzando il nome completo), nonostante il comando ping abbia ricevuto almeno una risposta, controlliamo le impostazioni del DNS. Apriamo un terminale, digitiamo il comando nslookup e osserviamo l’output. Se viene segnalato un errore allora abbiamo trovato il problema: l’indirizzo IP del server DNS è errato oppure non funziona il server stesso! Attenzione, perché nel caso in cui non venga restituito errore ma solo “server unknown” il server DNS impostato è corretto, ma non è semplicemente abilitato il reverse lookup, una funzionalità dei server che può essere abilitata o meno. Qualora ci sia un errore nel server DNS impostato, è opportuno verificare manualmente la configurazione del sistema e provare a cambiare i server DNS utilizzati, ad esempio con quelli di OpenDNS: 208.67.222.222 e 208.67.220.220. Se viene invece visualizzato un output simile al seguente allora il DNS funziona perfettamente e ancora non abbiamo trovato il problema:

    nslookup
    Server DNS impostato correttamente
  3. Risoluzione FQDN locale. Dunque, facciamo il punto della situazione: il ping verso Internet funziona, i server DNS sono correttamente impostati e rispondono al comando nslookup. Nel caso in cui il server DNS utilizzato si trovi nella rete interna a cui siamo collegati, effettuiamo un local FQDN, ossia interroghiamo il server DNS chiedendo di risolvere il nome completo di una macchina locale. Se la richiesta ha esito negativo, ossia viene generato un errore, il problema è del server DNS. Contattare l’amministratore del server DNS (ad esempio in una rete aziendale) oppure cambiarlo nel caso in cui sia un indirizzo pubblico. Vediamo un esempio:
    local_fqdn
    Risoluzione FQDN locale con nslookup

    Nell’esempio è stata effettuata una richiesta al server DNS utilizzando il nome completo di un host, ed è stata ricevuta correttamente la risposta. Ricordo che il nome completo di un host, FQDN, è il nome intero che identifica la risorsa in rete, ad esempio hostname.dominio.it.

  4. Risoluzione hostname locale (se il server DNS è nella rete interna). Provare a risolvere un hostname senza suffisso (ad esempio pc1 è l’hostname di pc1.esempio.it), sempre utilizzando il comando nslookup. Nel caso in cui venga restituito un errore il problema non è del server DNS ma della componente client del proprio sistema operativo. Ecco un esempio, in cui nslookuprestituisce correttamente la risposta:

    query_local_hostname
    Risoluzione hostname locale con nslookup
  5. Risoluzione FQDN esterno. Proviamo a risolvere sempre tramite il comando nslookup un nome completo, FQDN, della rete esterna (ad esempio un sito Internet). Se viene restituito un errore il problema è nel server DNS utilizzato, quindi provare a cambiarlo o contattare l’amministratore del server/ISP. Se invece la risoluzione del nome restituisce esito positivo, ma comunque la navigazione non funziona, il problema è della macchina client.

Nei punti 4 e 5, se il test ha esito negativo, il problema è il servizio DNS del sistema che non funziona correttamente. Per risolvere il problema in Windows ci sono 3 step:

  1. aprire il terminale dei comandi e digitare ipconfig /flushdns;
  2. digitare net stop dnscache;
  3. digitare infine net start dnscache.

Il comando ipconfig /displaydns visualizza la cache del client DNS.

Nel caso di Linux invece la soluzione è più semplice perché basta riavviare il servizio nscd.

roghan