Netstat
a cura di Stefano Barni
Windows 95 implementa il comando netstat, praticamente standard nei
sistemi Unix, utile per indagare la configurazione di rete ed il suo
stato. Quella di Windows 95 appare una versione ridotta rispetto al
netstat diffuso sotto Unix, ma comunque utile per curiosare e magari
diagnosticare lo stato della rete.
Il comando netstat riconosce diverse opzioni, particolarmente
interessante è -a, che visualizza lo stato di tutte le connessioni
di rete.
Un output del comando netstat -a visualizza tipicamente una riga
per ogni servizio attivo (il servizio, in parole poverissime e
largamente approssimative, è un socket, o numero di connessione,
attraverso il quale due processi - in genere su macchine
diverse - comunicano), come il seguente:
Active Connections
Proto Local Address Foreign Address State
UDP zeta-:nbname *:*
UDP zeta-:nbdatagram *:*
UDP zeta-:nbname *:*
UDP zeta-:nbdatagram *:*
Il significato è che sul computer zeta- (il nome attribuito alla macchina via
pannello di controllo) sono attive due interfacce di rete, e su
entrambe sono attivi i servizi NetBiosName e NetBiosDatagram. Il
fatto che si tratti di due interfacce di rete appare più chiaro se insieme all'opzione -a si usa anche l'opzione -n, che richiede a
netstat la visualizzazione dell'output in formato numerico (senza
cioè utilizzare C:\WINDOWS\HOSTS per i nomi delle macchine e
C:\WINDOWS\SERVICES per i nomi dei servizi):
Active Connections
Proto Local Address Foreign Address State
UDP 150.100.190.11:137 *:*
UDP 150.100.190.11:138 *:*
UDP 193.76.58.131:137 *:*
UDP 193.76.58.131:138 *:*
L'indirizzo 150.100.190.11 è l'indirizzo della mia macchina sulla
LAN, mentre 193.76.58.131 è l'indirizzo internet atribuito
automaticamente dal provider; 137 e 138 sono i numeri dei servizi
NetBiosName e NetBiosDatagram (standard anche su Unix). UDP indica
che si tratta di servizi di tipo User Datagram Protocol, cioè di
servizi privi di un vero e proprio protocollo di sincronia tra
processi in grado di garantire che tutti i pacchetti spediti siano
arrivati effettivamente a destinazione e in una sequenza
prestabilita (in altre parole, manca una negoziazione tra i processi
all'inizio della trasmissione).
Ecco come cambia l'output nel momento in cui effettuo una connessione
FTP (ad esempio mediante il programma FTP.EXE) verso una macchina
della rete locale:
Active Connections
Proto Local Address Foreign Address State
TCP zeta-:1136 pippo:ftp ESTABLISHED
UDP zeta-:nbname *:*
UDP zeta-:nbdatagram *:*
UDP zeta-:nbname *:*
UDP zeta-:nbdatagram *:*
Come si vede è comparsa una nuova riga in testa alla lista di
connessioni, la quale indica che la macchina zeta- ha aperto un nuovo
socket (un nuovo canale di comunicazione, il numero 1136) e si è
connessa al servizio ftp della macchina pippo; la connessione è
attiva (ESTABLISHED) ed è di tipo TCP. TCP sta per Transport Control
Protocol e, a differenza dello UDP, è un vero e proprio protocollo
che implementa controlli interprocesso per verificare l'integrità e
la completezza della trasmissione.
Ancora una volta, l'opzione -n mi permette di verificare su quale
interfaccia è attiva la connessione, infatti la prima linea sarà
Proto Local Address Foreign Address State
TCP 150.110.190.11:1136 150.113.150.11:21 ESTABLISHED
si nota, tra l'altro, che la porta standard ftp è la 21; inoltre,
dato che l'indirizzo della macchina target evidenzia un net address
(150.113) diverso da quello della mia macchina (150.110), se ne
deduce che da qualche parte ci deve essere un router che mette in
comunicazione le due reti.
Una rapida verifica, oltre che con il programma ROUTE.EXE, può
essere fatta con lo stesso netstat, mediante l'opzione -r. L'output
del comando netstat -r sarà il seguente (i puntini indicano che ho
eliminato alcune righe non significative ai fini dell'esempio):
Route Table
Active Routes:
Net Address Netmask Gateway Address Interface Metric
150.13.0.0 255.255.0.0 150.110.12.54 150.110.190.11 1
Il router (o gateway) che consente ai pacchetti indirizzati a
macchine sulla rete 150.13 è la macchina con indirizzo
150.110.12.54, e l'interfaccia (scheda di rete) che la vede
direttamente è quella LAN (150.110.190.11): infatti il net address
è il medesimo (150.110).
Se mi connetto al mail server per ricevere e spedire le mie email,
nell'output di netstat compariranno righe analoghe alle seguenti:
Proto Local Address Foreign Address State
TCP 194.166.51.92:1137 193.76.58.158:110 ESTABLISHED
TCP 194.166.51.92:1138 193.76.58.158:25 ESTABLISHED
La prima è quella relativa al servizio POP (ricezione delle email),
mentre la seconda è relativa al servizio SMTP (spedizione delle
mail); anche questi servizi sono uno standard dettato da Unix. Come
era prevedibile, si tratta di sockets TCP.
Un'altra interessante opzione di netstat è la -e, che visualizza le
statistiche relative all'attività su rete ethernet. Ecco un output di
esempio:
Interface Statistics
Received Sent
Bytes 30540632 335893
Unicast packets 4598 4401
Non-unicast packets 61379 302
Discards 0 0
Errors 0 0
Unknown protocols 13
Oltre al numero di bytes complessivamente ricevuti e inviati, viene
visualizzato il numero di pacchetti, suddivisi in Unicast (pacchetti
indirizzati da una macchina ad un altra, anche conosciuti come
point-to-point) e Non-unicast (pacchetti inviati da una macchina a
piu' di una macchina, i cosiddetti broadcast e multicast, che sono,
in genere, di tipo UDP).
L'opzione -s forza netstat a visualizzare statistiche raggruppate per
tipo di pacchetto e può essere filtrata con l'opzione -p, che
consente di specificare il tipo di pacchetto. Ad esempio, per
visualizzare le statistiche relative ai pacchetti UDP, si può dare
il comando netstat -sp UDP.
Infine, netstat offre la possibilità di specificare un intervallo
(in secondi) per ottenere la ripetizione delle statistiche di rete:
ad esempio il comando netstat -a 2 visualizza un output analogo a
quelli esaminati sin qui per l'opzione -a ogni 2 secondi: in tal modo
è possibile tenere sotto osservazione i diversi servizi utilizzati
e la loro evoluzione nel tempo, cioé il mutare del loro State, che
oltre a ESTABLISHED può assumere diversi valori, tra cui, ad esempio
TIME_WAIT (quando è in attesa di risposta dalla macchina remota) e
CLOSE_WAIT (quando la macchina remota ha appena chiuso il servizio).
|