Rete

Individuazione dei problemi di rete più elusivi

Christopher Stoneff

Panoramica:

• Cause comuni dei problemi di rete
• Oltre l'ovvio
• Quando gli strumenti per la risoluzione dei problemi sono inefficaci
• Perché è necessario configurare i limiti di connessione

Capita di frequente di trovarsi in una situazione in cui un computer non riesce a comunicare con gli altri computer della rete senza alcun motivo apparente. Il sistema di gestione risiede su un segmento di una rete di routing connessa ad altri segmenti di rete tramite un router, ad esempio Microsoft Internet

Security and Acceleration (ISA) Server o un altro dispositivo di rete. In uno scenario che prevede la gestione di 10, 20 o persino 100 sistemi, esistono buone probabilità che non si verifichi alcun problema. Tuttavia, quando si tenta di gestire 500 sistemi, il computer non sarà in grado di comunicare con tutti i computer della rete, ma solo con quelli con cui ha già aperto delle connessioni. Non si riesce a comunicare con nessun altro sistema, né a connettersi a Internet, anche se nessun altro computer sul proprio segmento di rete presenta lo stesso problema. Come procedere in una situazione di questo tipo?

Diagnosi del problema

In questo tipo di situazione si parte, in genere, dal presupposto che il software di gestione sia difettoso. Molti strumenti di gestione proattiva si connettono ai sistemi e li gestiscono, ma a volte gli stessi strumenti possono causare il problema che si sta tentando di individuare. Il motivo è che uno strumento di gestione proattiva a volte genera migliaia di connessioni ai dispositivi, in nome di una migliore gestione. Per impostazione predefinita, in Windows® le connessioni vengono tenute aperte per due minuti anche quando sono inattive, a meno che lo strumento, l'applicazione o il servizio non preveda una maggiore durata del periodo di attività delle connessioni aperte. Ne consegue che, sebbene il sistema di gestione non abbia comunicato con altri computer nel corso del periodo predefinito di due minuti, potrebbero essere ancora presenti più di 1.000 connessioni aperte. Per visualizzare le connessioni aperte, è possibile eseguire NETSTAT in un prompt dei comandi. Il comando NETSTAT consente di visualizzare tutte le connessioni aperte, in sospeso e chiuse da e verso il proprio sistema e di fornirne lo stato. Descrizioni dei messaggi di stato sono disponibili nella specifica RFC 793 all'indirizzo tools.ietf.org/html/rfc793.

Per escludere il software di gestione malfunzionante, è possibile creare un file batch che consenta di stabilire connessioni ai sistemi remoti. Se lo stesso problema si verifica durante l'esecuzione del file batch, la causa non va ricercata nel malfunzionamento del software di gestione e dei relativi thread. Di seguito viene riportato un esempio del contenuto del file batch necessario:

Net use \\system01\ipc$
Net use \\system02\ipc$
Net use ...

Se il programma di gestione in questione ha implementato il proprio stack di rete e di autenticazione, è probabile che la causa del problema sia lo strumento stesso; tuttavia, nelle soluzioni senza agente, come la maggior parte di questi pacchetti di gestione, per eseguire le operazioni di rete, lo strumento utilizza gli stack di rete e di autenticazione del sistema operativo. L'utilizzo di un file batch che avvia esattamente lo stesso numero di connessioni senza causare l'errore dimostrerà che il problema non è il risultato dell'utilizzo degli stack di rete e di autenticazione del sistema operativo da parte del programma di gestione, poiché gli stack vengono utilizzati anche dal file batch.

Registri e messaggi di errore non risolutivi

Quando si sono manifestati i problemi di connessione, è possibile che si siano ricevuti informazioni erronee sull'errore: errore 53 - Impossibile trovare il percorso di rete, errore 64 - Nome di rete cancellato ed errore 1203 - Nessun provider di rete ha accettato il percorso di rete specificato. Tutti questi messaggi in genere indicano problemi di risoluzione dei nomi, anche se tutti gli altri computer non presentano affatto problemi di risoluzione dei nomi e di connessione agli stessi sistemi. Per verificare che le impostazioni del computer siano corrette, è sufficiente eseguire ipconfig.

Successivamente, poiché il problema sembra essere circoscritto al proprio sistema di gestione, è opportuno esaminare i registri eventi. Anche se una ricerca nei registri applicazioni non porta alcun frutto, tuttavia nel registro eventi di sistema è possibile rilevare l'evento di avviso 4226 generato dall'origine eventi TCP/IP che indica che è stato raggiunto il numero massimo di connessioni consentite (vedere la Figura 1).

Figura 1** Il limite di connessione TCP è stato raggiunto **

Se si esegue una ricerca completa all'interno della Microsoft® Knowledge Base per verificare i limiti di connessione, si scoprirà che esistono limitazioni di connessione per le connessioni non completate, ma non per le connessioni completate. Per controllare i fattori sopra menzionati è possibile modificare le seguenti voci del Registro di sistema in HKLM\System\CurrentControlSet\Services\TCPIP\Parameters: TcpNumConnections viene utilizzato per impostare il numero massimo di connessioni aperte disponibili per TCP contemporaneamente (il valore predefinito è 10). TCPTimedWaitDelay imposta il periodo di tempo in cui una connessione resta nello stato TIME_WAIT durante la chiusura. Il valore predefinito è 120 secondi, che indica che una connessione è sostanzialmente in uso per 4 minuti. Infine, anche MaxFreeTcbs gioca un ruolo nel numero massimo di connessioni. Se tutti i blocchi di controllo TCP sono in uso, TCP deve rilasciare le connessioni nello stato TIME_WAIT per creare ulteriori connessioni anche se il parametro TCPTimedWaitDelay non è ancora scaduto. TCPTimedWaitDelay prevede un intervallo di valori compreso tra 30 e 300 secondi (0x1E - 0x12C).

A seconda dello scenario specifico, queste modifiche al Registro di sistema potrebbero determinare un lieve miglioramento delle prestazioni globali. Un'altra operazione che è possibile tentare consiste nell'applicazione di patch al file TCPIP.sys per rimuovere questi limiti, ma questo tentativo garantisce dei miglioramenti solo nelle applicazioni P2P.

Acquisizioni di rete

Dopo altri tentativi di risoluzione dei problemi di connessione non riusciti, un'acquisizione di rete dai computer coinvolti potrebbe consentire di ottenere risultati positivi. Quando si è eseguito Microsoft Network Monitor (Netmon), sono state create delle acquisizioni che mostravano gli stessi risultati visualizzati negli strumenti di gestione e negli script di test: dopo i primi risultati positivi, si registra una serie di problemi, senza alcuna ulteriore indicazione di errore.

Nella Figura 2 viene illustrato il risultato dell'esecuzione di Netmon, che indicava la corretta comunicazione tra i primi n sistemi. È possibile osservare inoltre che si sono ottenuti acknowledgment relativi alle richieste RPC. Ecco il risultato che si desidera ottenere: comunicazione bidirezionale senza errori.

Figura 2** Corretta comunicazione in Netmon **(Fare clic sull'immagine per ingrandirla)

A questo punto, è necessario esaminare le acquisizioni dal sistema di gestione e dai computer remoti su cui sembra si sia verificato l'errore 53/1203. Come ci si può aspettare, non viene visualizzato nulla, in quanto i computer non stanno comunicando. Nell'acquisizione di rete nella Figura 3, il sistema di gestione ha risolto l'indirizzo IP e tenta di connettersi al sistema tramite la porta 445 (la porta Microsoft SMB) ma non riceve alcuna risposta.

Figura 3** I tentativi di connessione al sistema tramite la porta 445 non producono alcuna risposta **(Fare clic sull'immagine per ingrandirla)

L'errore che si riceve quando si utilizza un numero di thread superiore a quello a cui il computer è attualmente in grado di connettersi non è sempre coerente. In alcuni casi, è possibile che nel sistema di origine venga visualizzato l'errore 53, che indica che si è ricevuta la risoluzione dei nomi ma che l'indirizzo IP non è stato trovato. Un errore di questo tipo indica che DNS ha fornito un indirizzo a cui non si è in grado di connettersi. È possibile che si riceva l'errore 1203, che indica che nessun computer ha risposto al nome o all'indirizzo IP richiesto. L'errore 1203, in questo caso, indica che DNS non è disponibile. A conferma di ciò è possibile eseguire nslookup.

A questo punto, non lasciarsi prendere dalla frustrazione, in quanto sono disponibili altre opzioni da prendere in considerazione. Data la modalità in cui questo problema si manifesta, la maggior parte degli utenti non pensa affatto di esaminare l'infrastruttura di connessione: il proprio computer è l'unico computer che non è in grado di connettersi al resto della rete e i registri eventi mostrano che è stato raggiunto il numero massimo di connessioni consentite, pertanto il problema non sembra essere correlato all'architettura del sistema.

Sebbene le migliaia di connessioni generate dalla soluzione di gestione non vengano avviate contemporaneamente, i keep-alive di trasmissione e i timeout di connessione possono indicare che sono presenti più connessioni simultanee aperte di quanto si possa pensare. Pertanto, è necessario esaminare anche i sistemi che connettono il resto della rete.

In altre parole, come si è affermato in precedenza, poiché il traffico di rete passa attraverso la rete, passerà anche attraverso switch, router e probabilmente firewall. In ognuno di questi punti, in genere il router o il firewall, è possibile che siano presenti sistemi di rilevamento delle intrusioni. È possibile inoltre che i router e gli switch gestiti utilizzino i filtri di traffico. Chiunque gestisca questi dispositivi dovrà controllare i registri per verificare se siano presenti errori o avvisi. Il problema di comunicazione potrebbe con molta probabilità risiedere in questi sistemi.

Poiché si sta eseguendo una connessione da un sistema interno ad altri sistemi interni, è possibile che non venga generato alcun messaggio di avviso, in quanto la funzionalità di avviso non è configurata nel dispositivo o perché il problema non sembra essere il risultato di un attacco di intrusione o Denial of Service (DoS). Ancora una volta, è consigliabile esaminare prima i registri. Utilizzando ISA Server come esempio, è possibile trovare questi registri nella console di gestione di ISA Server in Arrays\<NomeArray>\Monitoring\Logging.

Se il blocco è causato da un criterio, è possibile (nel caso di ISA Server) cercare i seguenti codici dei risultati dove l'IP di origine rappresenta il computer di gestione:

• 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
• 0xc004000d FWX_E_POLICY_RULES_DENIED
• 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED

Se si trovano questi risultati, questo significa che si è identificata la causa dei problemi di connettività.

Implementazione della soluzione

Una volta identificato il problema, la soluzione può essere semplice, ma la politica di reparto potrebbe renderne difficoltosa l'implementazione. Prima di apportare eventuali modifiche, assicurarsi di disporre delle autorizzazioni appropriate, in quanto la creazione di esclusioni nelle configurazioni di protezione nei propri firewall, router e/o sistemi di rilevamento delle intrusioni non è sempre consentita.

Utilizzando di nuovo ISA Server come esempio, nella procedura riportata di seguito viene illustrato come aumentare il numero massimo di connessioni per un determinato host o per tutti i computer della rete (come riportato nella Figura 4). Aprire la console di gestione di ISA Server e accedere alla directory Arrays\<NomeArray>\Configuration\General\Configure Flood Mitigation Settings.

Figura 4** Aumento del numero massimo di connessioni per un host o tutti i computer utilizzando ISA Server **

Le due impostazioni di interesse sono relative al numero massimo di connessioni TCP simultanee per ciascun indirizzo IP e al numero massimo di richieste di connessione TCP al minuto per ogni indirizzo IP. Il numero massimo di connessioni TCP simultanee per ciascun indirizzo IP viene in genere impostato su un valore che risulta sufficiente quando non viene eseguita una gestione attiva, ovvero quando nessun computer è attivamente connesso a migliaia di altri computer. In ISA Server, il limite predefinito per il numero massimo di connessioni TCP simultanee è 160. Il numero massimo di richieste di connessione TCP al minuto per ogni indirizzo IP ha lo scopo di limitare i danni e la visibilità delle scansioni di rete. Il limite predefinito per il numero massimo di richieste di connessione TCP al minuto per ogni indirizzo IP è 600.

Come affermato in precedenza, in Windows una connessione viene mantenuta attiva per un periodo predefinito di due minuti, purché nessun altro dispositivo tenti di mantenere attiva la connessione, anche se la connessione non è in uso. Ne consegue che, anche se si è già gestito un computer e non è più necessario comunicare con tale computer, la connessione rimarrà attiva. Questa connessione aperta viene conteggiata nel numero totale delle connessioni consentite. Se si ripete questo processo più di 160 volte senza rimuovere le connessioni si rileverà che tutti i tentativi di connessione verranno negati dal router. Anche se il programma di gestione termina attivamente una sessione, è possibile che in Windows la connessione venga lasciata nello stato time_wait in attesa che il computer di destinazione accetti di disconnettere la sessione.

Il primo passaggio da eseguire è apportare modifiche al colpevole più probabile: il numero massimo di connessioni TCP simultanee per ciascun indirizzo IP. È consigliabile impostare questo numero in modo che il computer di gestione sia in grado di creare tutte le connessioni necessarie per gestire i sistemi senza che l'accesso venga negato. Fare clic sul pulsante Edit accanto all'impostazione e modificare i valori.

Il prompt successivo (vedere la Figura 5) include una casella Limit che rappresenta il limite predefinito, applicabile a tutti i client. Il limite Custom si applica a tutti i computer, le reti e altri sistemi definiti nella scheda IP Exceptions della finestra di dialogo Flood Mitigation. Se si desidera consentire a ogni computer di creare più connessioni, modificare il valore della casella Limit. Per configurare l'eccezione solo per il computer di gestione in uso, modificare il limite Custom e aggiungere il computer alla scheda IP Exceptions. In generabile, è preferibile consentire l'eccezione solo per il computer in uso.

Figura 5** Limite di connessione predefinito e limite di connessione personalizzato **

Se si desidera utilizzare il limite personalizzato per modificare questo valore solo per specifici sistemi, modificare il valore nel campo Custom limit e fare clic su OK. Aggiungere quindi il computer alla scheda IP Exceptions nella finestra di dialogo Flood Mitigation. Per aggiungere il computer in uso all'elenco delle eccezioni, in IP Exceptions fare clic su Add per visualizzare la finestra di dialogo Computer Sets. Fare clic su New per creare un nuovo gruppo di reti che contenga il sistema in uso, se un gruppo di reti contenente questi computer non esiste già. Selezionare questo gruppo di reti e fare clic su Add per aggiungere il gruppo di reti Internal Networks, quindi scegliere Close. Selezionare di nuovo il gruppo di reti Internal Networks e fare clic su Edit. Verranno visualizzate le proprietà per Internal Networks (vedere la Figura 6). In questa finestra di dialogo fare clic su Add per visualizzare un sottomenu in cui è possibile scegliere di aggiungere un computer, un intervallo di indirizzi o una subnet; scegliere di aggiungere il computer. Immettere un nome per identificare la voce, l'indirizzo IP del computer e una descrizione in modo da impedire a chiunque visualizzi questa voce in futuro di rimuovere il sistema (vedere la Figura 7). Fare clic su OK per aggiungere il sistema, quindi fare di nuovo clic per aggiungere l'eccezione. Una volta apportate queste modifiche, è necessario applicare le impostazioni.

Figura 6** Impostazioni della finestra di dialogo Internal networks properties **

Figura 7** Inserire il nome del computer, l'indirizzo IP e la descrizione per assicurare che il sistema non venga rimosso **

Se si esegue di nuovo lo strumento di gestione proattiva si rileverà che le prestazioni sono notevolmente migliorate e che non si verificano problemi di connessione, almeno non in conseguenza del traffico di rete. Alla fine, si è scoperto che la causa del problema non risiedeva nel numero di connessioni avviate dal software, ma nella mancanza di una corretta pianificazione delle connessioni.

Esperienza acquisita

Uno dei grattacapi principali nel settore IT è sperimentare e successivamente risolvere problemi caratterizzati da elevata ambiguità. Si tratta di problemi non creati dall'utente finale, non causati dal team del server, della cui esistenza il supporto tecnico è inconsapevole e la cui correzione è, fortunatamente, responsabilità dell'utente. Sono disponibili diversi strumenti che consentono di isolare e risolvere specifici problemi, ma talvolta gli strumenti non sono sufficienti. Gli strumenti a volte possono essere suscettibili di errore. E a volte è necessario adottare un approccio più intelligente rispetto a quello fornito dagli strumenti.

Qualora capiti di trovarsi in una situazione in cui non si è in grado di stabilire connessioni tra diversi computer della rete senza alcuna ragione apparente, provare e eseguire la procedura descritta in questo articolo. Vi sono buone possibilità che seguendo questa procedura, esaminando attentamente il software di gestione e impostando le connessioni consentite in modo appropriato si sarà in grado di risolvere il problema nel modo corretto.

Christopher Stoneff è Product Manager presso Lieberman Software (liebsoft.com), nonché uno sviluppatore di software per la gestione della protezione e dei sistemi. In questi anni Chris ha ottenuto moltissime certificazioni. Il suo obiettivo principale sul lavoro consiste nel comprendere non solo il "come" ma soprattutto il "perché" ogni cosa funziona in un certo modo.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.