Indicazioni per la risoluzione dei problemi di comunicazione TCP/IP

Questo articolo è progettato per semplificare la risoluzione dei problemi di comunicazione TCP/IP.

Strumenti per la risoluzione dei problemi

Il comando ping è utile per testare la connettività di base. Tuttavia, non è consigliabile basarsi su di esso per dimostrare la connettività complessiva. Telnet e PsPing sono più utili per i motivi seguenti:

• Questi strumenti possono testare la connettività al livello applicazione usando TCP o UDP (solo PsPing) come protocollo di trasporto.
• È possibile specificare la porta da usare. È quindi possibile spostarsi tra le porte aperte in un firewall.
• È possibile connettersi a qualsiasi porta "in ascolto" nel nodo di destinazione per verificare l'accesso alla porta di un'applicazione specifica.

Elenco di controllo per la risoluzione dei problemi

Passaggio 1: Acquisire un diagramma di rete

Acquisire un diagramma di rete che descrive in dettaglio i dispositivi che si trovano nel percorso dell'area interessata. In particolare, prendere nota dei dispositivi seguenti:

• Firewall
• IPS (Intrusion Protection/Prevention Systems)
• DPI (Deep Packet Inspection)
• Acceleratori WAN

Il diagramma consente di visualizzare e identificare dove cercare la causa del problema.

Passaggio 2: Tracce di rete

Le tracce di rete sono utili per vedere cosa accade a livello di rete quando si verifica il problema.

Passaggio 3: Effettuare il ping dell'indirizzo IP locale del computer

Provare a effettuare il ping dell'indirizzo IP locale del computer.

Se il nodo non riesce a eseguire il ping dell'IP locale, lo stack locale non funziona. Prendere nota di eventuali messaggi di errore visualizzati.

Se viene visualizzato un errore di errore generale , questo errore indica che non sono presenti interfacce valide per elaborare la richiesta. Questo problema potrebbe essere causato da un problema hardware o da uno stack.

Controllare se viene visualizzato un carattere "X" rosso o un punto esclamativo giallo nell'icona Connessione di rete nella barra degli strumenti. Una X rossa indica che Windows non rileva una connessione di rete. Un punto esclamativo giallo indica che l'indicatore di stato della connessione di rete (NSCI) non è riuscito a controllare un probe.

Per risolvere questo problema, verificare che la scheda di rete riporti la connettività. Assicurarsi che la scheda di rete sia collegata e che la porta del commutatore in cui è connesso il nodo non sia in stato di errore. È possibile modificare cavi, porte di commutazione e schede di rete per restringere la posizione in cui si verifica questo problema. Tuttavia, in definitiva, il problema è esterno al sistema operativo. Per ulteriori indagini, contattare i fornitori di hardware.

Potrebbe verificarsi anche un problema tra il driver di rete e Windows. Questo problema è in genere causato da un danneggiamento nello stack. Seguire questa procedura di risoluzione dei problemi:

1. Assicurarsi che i bit più recenti nel nodo (TCP/IP, NDIS, AFD, Winsock e così via).

2. Reimpostare IP e Winsock eseguendo i comandi seguenti. Eseguire il backup di tutta la configurazione di rete.

   netsh -c interface dump > C:\netConfig.txt
   netsh int ip reset
   netsh winsock reset
   

3. Riavviare il nodo.

4. Ripristinare le impostazioni di rete dopo il riavvio. Questa operazione funziona solo se i nomi di interfaccia non sono stati modificati o se lo script viene aggiornato per usare i nuovi nomi.

   netsh -f C:\netConfig.txt
   

5. Disinstallare o reinstallare il driver della scheda di rete, in base alle esigenze.

6. Verificare e rimuovere i driver di filtro di terze parti ,ad esempio antivirus.

7. Provare ad avviare il computer in modalità provvisoria con Rete. Se la modalità provvisoria con la rete funziona, eseguire un processo di "avvio pulito" disabilitando tutte le app e i servizi di terze parti all'interno di MSConfig, quindi riattivarli uno per uno fino a quando il problema non viene restituito. È quindi possibile contattare il fornitore per ottenere supporto.

   1. Se nessuno di questi elementi ha esito positivo, il problema è probabilmente un danneggiamento del Registro di sistema.
   2. Se si dispone di una copia di backup del Registro di sistema , ad esempio un backup fisico o un punto di ripristino del sistema, è possibile provare a ripristinare il nodo in una configurazione in precedenza funzionante. Catturare la causa radice del danneggiamento può essere difficile ed estremamente dispendioso in termini di tempo. Anche se il danneggiamento viene trovato, sapere cosa ha causato è ancora più difficile. Se si modifica manualmente la chiave del Registro di sistema danneggiata, il nodo viene inserito in uno stato non supportato. Di conseguenza, si consiglia al cliente di ripristinare o ricaricare il nodo per correggere il danneggiamento.

Se il NSCI non riesce a controllare il probe (punto esclamativo giallo), questo non indica necessariamente un problema di connettività. Assicurarsi che la comunicazione tipica si verifichi come dovrebbe.

• In tal caso, l'indagine deve concentrarsi in modo specifico sul motivo per cui il ncsi non riesce a eseguire i controlli probe. I dettagli sono trattati in un argomento separato.
• In caso contrario, esaminare prima i problemi di connettività perché è probabile che questa operazione venga corretta dopo il ripristino della connettività.

Passaggio 4: Risolvere i problemi relativi ai messaggi di errore che si verificano durante il test ping o telnet

Se il nodo può effettuare il ping o il telnet ai nodi nella stessa subnet o segmento di rete, ciò confermerebbe il funzionamento della connettività esterna. Sono ancora necessari ulteriori test per capire se esiste un problema di connettività di base.

Se il nodo non è in grado di effettuare il ping/telnet ai nodi nello stesso segmento di subnet/rete. Prendere nota di eventuali messaggi di errore visualizzati.

1. L'errore non raggiungibile dell'host di destinazione indica che le richieste ARP inviate dal nodo non ricevono una risposta.

2. Raccogliere una traccia a due lati dai nodi tra cui si sta testando. Assicurarsi che la richiesta ARP inviata dal nodo di origine raggiunga il nodo di destinazione e che il nodo di destinazione risponde di conseguenza. Questa risposta dovrebbe essere visualizzata di nuovo nella traccia di origine. Se questo processo ha esito negativo, il problema è probabilmente una configurazione errata o altri problemi che influiscono sull'infrastruttura.

   Le possibili cause potrebbero essere:

   1. VLAN non corrette o non corrispondenti.
   2. Configurazione errata della porta del commutatore (trunk rispetto alla porta di accesso).
   3. Altri problemi hardware.

3. L'errore di timeout della richiesta indica che la richiesta ARP ha ricevuto una risposta, ma la richiesta ECHO ICMP inviata dal nodo non riceve una risposta echo ICMP. Questo, da solo, non indica un problema. Il traffico ICMP potrebbe essere bloccato dal software di rete o firewall nei nodi. Potrebbe essere utile disattivare i profili firewall (Windows) o disabilitarli tramite il metodo supportato dal fornitore del firewall per il test di ICMP.

   1. Telnet e PsPing sono più adatti per i test. Eseguire Telnet o PsPing dal nodo di origine al nodo di destinazione su una porta in ascolto ,ad esempio 445.
   2. Se il passaggio 1 ha esito positivo, la connettività esterna funziona. Continuare a testare la connettività di base.
   3. Se il passaggio 1 non ha esito positivo (e se i profili firewall sono disabilitati), raccogliere una traccia dello scenario a due lati netsh netconnection per risolvere ulteriormente i problemi.

Passaggio 5: Effettuare il ping o Telnet nel gateway predefinito

Quando il nodo può eseguire il ping del gateway predefinito, la connettività esterna (ad esempio la connettività predefinita) è possibile dal nodo di origine. Ulteriori test sarebbero comunque necessari per capire se esiste un problema di connettività di base. Se il nodo non è in grado di effettuare il ping o Telnet nel gateway predefinito, significa che le risposte ICMP sono disabilitate nel router.

Passaggio 6: Controllare i problemi che interessano il nodo di destinazione specifico

Se il nodo di origine può eseguire il ping, Telnet o PsPing ad altri nodi nella subnet di destinazione, la connettività e il routing di base all'interno dell'infrastruttura funzionano. Questo risultato punta a un problema che interessa il nodo di destinazione specifico.

1. Provare a Telnet o PsPing sulla porta specifica su cui l'applicazione è in ascolto ,ad esempio la porta TCP 445 per SMB. Se la connessione ha esito positivo, è possibile confermare la connettività a livello di applicazione di base. In questo caso, è necessario contattare il fornitore dell'applicazione per analizzare il motivo per cui l'applicazione non si connette.

   Nota

   Il fornitore dell'applicazione potrebbe essere Microsoft se il problema è un errore di connessione a una condivisione, ad esempio. In queste situazioni, sarebbe utile eseguire la traccia dello scenario netsh netconnection a due lati per raccogliere informazioni aggiuntive e verificare che non ci siano problemi nello stack di rete.

2. Se la connessione alla porta specifica non ha esito positivo:

   1. Assicurarsi che la porta sia in uno stato "in ascolto":
      CMD: netstat -nato | findstr :<port>
      Powershell: Get-NetTcpConnection -LocalPort <port>
   2. Disabilitare temporaneamente tutti i profili del firewall. (Nota: disabilita solo i profili. Non disabilitare il servizio.
      In caso di esito positivo, il firewall deve essere riconfigurato per consentire il traffico dell'applicazione sulla porta specifica.
   3. Rimuovere le applicazioni di terze parti una alla volta e testare tra ogni rimozione.
      In caso di esito positivo, contattare il fornitore del software problematico.
   4. Provare la modalità provvisoria con Rete.
      Se questa operazione ha esito positivo, isolare la causa eseguendo un "avvio pulito" del nodo usando MSConfig e quindi abilitando applicazioni e servizi di terze parti uno per uno fino a quando il problema non si ripete.
   5. Quando si riproduce il tentativo di connessione, è necessario eseguire una traccia dello scenario netsh netconnection dall'origine al nodo di destinazione interessato. Anche un SDP di rete sarebbe vantaggioso.

3. Se il nodo non riesce a effettuare il ping, Telnet o PsPing ad altri nodi nella subnet di destinazione, il problema potrebbe essere correlato all'infrastruttura. Anche in questo caso, ICMP potrebbe essere bloccato all'interno dell'ambiente. Verificare pertanto la connettività usando Telnet o PsPing per connettersi alle porte in ascolto noto. A questo punto, è necessaria una traccia di rete a due lati per mostrare dove si verifica la perdita di pacchetti nella rete. Assicurarsi che entrambe le tracce siano in esecuzione prima di provare il test di connettività in modo che il problema venga acquisito.

Problemi e soluzioni comuni

La connessione TCP/IP a un host sembra essere stata arrestata

Questo problema si verifica perché i dati sono bloccati nelle code TCP e UDP oppure si verificano problemi di ritardo software a livello di rete o utente.

Per risolvere questo problema, usare il netstat -a comando per visualizzare lo stato di tutte le attività nelle porte TCP e UDP nel computer locale.
Lo stato di una connessione TCP valida viene stabilito con zero (0) byte nelle code di invio e ricezione. Se i dati sono bloccati in una coda o se lo stato è irregolare, la connessione è probabilmente in errore. In caso contrario, probabilmente si verifica un ritardo software a livello di rete o utente.

Tempi di connessione lunghi quando si usano Lmhosts per la risoluzione dei nomi

Questo problema si verifica perché il file Lmhosts viene analizzato in sequenza per individuare le voci senza l'opzione #PRE.

Per risolvere questo problema, posizionare le voci usate di frequente nella parte superiore del file e le voci #PRE nella parte inferiore. Se viene aggiunta una voce alla fine di un file Lmhosts di grandi dimensioni, contrassegnare la voce in Lmhosts come voce precaricato usando l'opzione #PRE. Eseguire quindi il nbtstat -R comando per aggiornare immediatamente la cache dei nomi locali.

Errore di sistema 53

L'errore di sistema 53 viene restituito se la risoluzione dei nomi non riesce per un nome computer specifico quando viene usato il net use comando.

Se il computer si trova nella subnet locale, verificare che il nome sia digitato correttamente e che anche il computer di destinazione esegua TCP/IP. Se il computer non si trovi nella subnet locale, assicurarsi che il relativo nome e il mapping degli indirizzi IP siano disponibili nel file Lmhosts o nel database WINS. Se tutti gli elementi TCP/IP sembrano essere installati correttamente, usare il ping comando insieme al computer remoto per verificare che il software TCP/IP funzioni.

Non è possibile connettersi a un server specifico

Questo problema si verifica perché la risoluzione dei nomi NetBIOS non risolve il nome o l'indirizzo IP errato viene risolto.

Per risolvere questo problema, usare il nbtstat -n comando sul server per determinare i nomi del server registrato nella rete. Il nome del computer a cui si sta tentando di connettersi deve essere presente nell'elenco visualizzato. Se il nome non è elencato, provare uno degli altri nomi di computer univoci visualizzati da nbtstat. Se il nome usato da un computer remoto è uguale al nome visualizzato dal nbtstat -n comando, assicurarsi che il computer remoto disponga di una voce per il nome del server nel server WINS o nel relativo file Lmhosts.

Impossibile aggiungere un gateway predefinito

Questo problema si verifica perché l'indirizzo IP del gateway predefinito non è nello stesso ID di rete IP dell'indirizzo IP.

Per risolvere questo problema, determinare se il gateway predefinito si trova nella stessa rete logica della scheda di rete del computer confrontando l'indirizzo IP del gateway predefinito con gli ID di rete di una delle schede di rete del computer.

Ad esempio, un computer ha una singola scheda di rete configurata con un indirizzo IP 192.168.0.33 e una subnet mask 255.255.0.0. Ciò richiede che il gateway predefinito sia nel formato "192.168.<y>.<z>" perché la parte relativa all'ID di rete dell'interfaccia IP è 192.168.0.0.

Raccolta dei dati

Prima di contattare il supporto tecnico Microsoft, è possibile raccogliere informazioni sul problema.

Prerequisiti

1. TSS deve essere eseguito da account con privilegi di amministratore nel sistema locale e il contratto di licenza deve essere accettato (una volta accettato il contratto di licenza, TSS non richiederà di nuovo).
2. È consigliabile usare i criteri di esecuzione di PowerShell per il computer RemoteSigned locale.

Raccogliere informazioni chiave prima di contattare il supporto tecnico Microsoft

1. Scaricare TSS in tutti i nodi e decomprimerlo nella cartella C:\tss .

2. Aprire la cartella C:\tss da un prompt dei comandi di PowerShell con privilegi elevati.

3. Avviare le tracce nel server di origine e di destinazione usando il cmdlet seguente:

   TSS.ps1 -Scenario NET_General
   

4. Accettare il contratto di licenza se le tracce vengono eseguite per la prima volta nel server di origine o di destinazione.

5. Consenti registrazione (PSR o video).

6. Riprodurre il problema prima di immettere Y.

   Nota

   Se si raccolgono i log sia nel client che nel server, attendere questo messaggio in entrambi i nodi prima di riprodurre il problema.

7. Immettere Y per completare la raccolta di log dopo la riproduzione del problema.

Le tracce verranno archiviate in un file ZIP nella cartella C:\MS_DATA , che può essere caricata nell'area di lavoro per l'analisi.

Riferimento

• Risolvere i problemi di connettività TCP/IP
• Risolvere i problemi di esaurimento delle porte
• Risolvere gli errori RPC (Remote Procedure Call)
• Raccogliere dati con Monitoraggio di rete
• Errore di apertura delle proprietà TCP/IP della scheda di rete
• SMB host diretto su TCP/IP
• Configurare la rete TCP/IP mentre NetBIOS è disattivato
• Il traffico TCP si arresta
• L'intervallo di porte dinamiche predefinito per TCP/IP è stato modificato
• Le proprietà TCP/IP ripristinano le impostazioni predefinite