Condividi tramite

Materiale sussidiario per la risoluzione dei problemi di comunicazione TCP/IP

  • Articolo

Provare l'agente virtuale: consente di identificare e risolvere rapidamente i problemi comuni di replica di Active Directory.

Questo articolo è progettato per risolvere i problemi di comunicazione TCP/IP.

Strumenti per la risoluzione dei problemi

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

  • Questi strumenti possono testare la connettività a livello dell'applicazione usando TCP o UDP (solo PsPing) come protocollo di trasporto.
  • È possibile specificare quale porta verrà usata. Pertanto, è 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 illustra in dettaglio i dispositivi presenti nel percorso dell'area interessata. In particolare, notare i dispositivi seguenti:

  • Firewall
  • IPS (sistema di protezione/prevenzione intrusioni)
  • DPI (Deep Packet Inspection)
  • Acceleratori WAN

Il diagramma consente di visualizzare e identificare il punto in cui cercare la causa del problema.

Passaggio 2: Traccia di rete

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

Passaggio 3: Eseguire 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 effettuare il ping dell'INDIRIZZO IP locale, lo stack locale non funziona. Annotare tutti i 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 può essere causato da un problema hardware o da un problema di stack.

Controllare se viene visualizzata una "X" rossa o un punto esclamativo giallo sull'icona Connessione di rete nell'area di notifica. 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 non ha superato il controllo del probe.

Per risolvere questo problema, verificare che la scheda di rete segnali la connettività. Assicurarsi che la scheda di rete sia collegata e che la porta del commutatore in cui il nodo è connesso non sia in uno stato di errore. È possibile modificare cavi, porte switch e schede di rete per restringere la posizione in cui si verifica questo problema. In definitiva, tuttavia, il problema non si trova nel sistema operativo. Per ulteriori indagini, contattare i fornitori dell'hardware.

Potrebbero verificarsi problemi anche tra il driver di rete e Windows. Questo problema si verifica in genere a causa di un danneggiamento nello stack. Usare la procedura di risoluzione dei problemi seguente:

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

  2. Reimpostare l'IP e Winsock eseguendo i comandi seguenti. Eseguire il backup di tutte le configurazioni 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 dell'interfaccia non sono stati modificati o 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. Cercare e rimuovere i driver del filtro di terze parti, ad esempio l'antivirus.

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

    1. Se nessuna di queste operazioni riesce, il problema dipende probabilmente da un danneggiamento del registro.
    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 funzionante in precedenza. Intercettare la causa radice del danneggiamento può essere difficile ed estremamente dispendioso in termini di tempo. Anche se viene trovata la corruzione, sapere cosa ha causato è ancora più impegnativo. La modifica manuale della chiave del Registro di sistema danneggiata imposta il nodo come non supportato. Di conseguenza, è consigliabile che il cliente ripristini o ricarichi il nodo per correggere il danneggiamento.

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

  • In tal caso, l'analisi deve concentrarsi in modo specifico sul motivo per cui l'istanza dell'indicatore di stato della connessione di rete non supera il controllo del probe. I relativi dettagli vengono approfonditi in un argomento diverso.
  • In caso contrario, esaminare prima di tutto i problemi di connettività, perché è probabile che si risolvano in seguito al 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 è in grado di effettuare il ping o di usare telnet sui nodi nella stessa subnet o nello stesso segmento di rete significa che la connettività esterna funziona correttamente. Per capire se esiste un problema di connettività di base è necessario eseguire altri test.

Se il nodo non riesce a effettuare il ping/telnet ai nodi nello stesso segmento di subnet/rete. Annotare tutti i messaggi di errore visualizzati.

  1. 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 eseguire il test. Assicurarsi che la richiesta ARP inviata dal nodo di origine raggiunga il nodo di destinazione e che il nodo di destinazione risponda di conseguenza. Questa risposta deve essere nuovamente visibile nella traccia di origine. Se il processo non riesce, è probabile che si sia verificato un errore di configurazione o un altro tipo di problema che interessa l'infrastruttura.

    Le possibili cause sono:

    1. VLAN non corrette o non corrispondenti.
    2. Una configurazione non corretta della porta del commutatore (trunk o porta di accesso).
    3. Altri problemi di 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 dalla rete o dal software del firewall nei nodi. Può essere utile disattivare i profili firewall (Windows) o disabilitarli tramite il metodo supportato del fornitore del firewall per testare ICMP.

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

Passaggio 5: Effettuare il ping o Telnet nel gateway predefinito

Quando il nodo riesce a effettuare il ping del gateway predefinito, è possibile stabilire la connettività esterna, ad esempio la connettività off-box, dal nodo di origine. Per capire se esiste un problema di connettività di base è necessario eseguire altri test. Se il nodo non riesce a effettuare il ping o Telnet al gateway predefinito, significa che le risposte ICMP sono disabilitate nel router.

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

Se il nodo di origine può effettuare 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 indica un problema che interessa il nodo di destinazione specifico.

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

    Note

    Il fornitore dell'applicazione potrebbe essere Microsoft se il problema non riesce a connettersi a una condivisione, ad esempio. In questo caso, sarebbe utile usare la traccia doppia dello scenario netsh netconnection per raccogliere informazioni aggiuntive e verificare che non ci siano problemi nello stack di rete.

  2. Se la connessione alla porta specifica non riesce:

    1. Assicurarsi che la porta sia in uno stato di 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.
      Se l'operazione riesce, il firewall deve essere riconfigurato per consentire il traffico dell'applicazione sulla porta specifica.
    3. Rimuovere le applicazioni di terze parti una alla volta ed eseguire il test dopo ogni rimozione.
      Se l'operazione riesce, contattare il fornitore del software con problemi.
    4. Provare a usare la modalità provvisoria con Rete.
      Se l'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 alla ripetizione del problema.
    5. Quando si riproduce il tentativo di connessione, è necessario eseguire una traccia dello scenario netsh netconnection dall'origine nel nodo di destinazione interessato. Potrebbe essere utile anche un SDP di rete.

  3. Se il nodo non riesce a eseguire il ping, Telnet o PsPing ad altri nodi nella subnet di destinazione, è probabile che il problema sia correlato all'infrastruttura. Anche in questo caso, ICMP potrebbe essere bloccato nell'ambiente. Verificare quindi la connettività usando Telnet o PsPing per connettersi alle porte in ascolto note. A questo punto, è necessaria una traccia di rete doppia per mostrare dove si verifica la perdita di pacchetti nella rete. Assicurarsi che entrambe le tracce siano in esecuzione prima di provare a eseguire il test di connettività in modo da individuare il problema.

Problemi noti e soluzioni

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 o 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à sulle 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 è non è quello normale, è probabile ci sia un errore di connessione. In caso contrario, è probabile che si verifichi un ritardo di rete o software a livello di 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, inserire le voci usate di frequente nella parte superiore del file e le #PRE voci nella parte inferiore. Se viene aggiunta una voce alla fine di un file Lmhosts di grandi dimensioni, contrassegnare la voce in Lmhosts come voce precaricata usando l'opzione #PRE. Eseguire quindi il comando nbtstat -R 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 determinato nome computer quando viene usato il net use comando.

Se il computer si trova nella subnet locale, verificare che il nome sia digitato correttamente e che il computer di destinazione esegua anche TCP/IP. Se il computer non si trova nella subnet locale, assicurarsi che il 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 correttamente.

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 registrati nel server in rete. Il nome computer del computer a cui si sta tentando di connettersi deve trovarsi 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 corrisponde al nome visualizzato dal nbtstat -n comando, assicurarsi che il computer remoto abbia una voce per il nome del server che si trova nel server WINS o nel relativo file Lmhosts.

Non è possibile aggiungere un gateway predefinito

Questo problema si verifica perché l'indirizzo IP del gateway predefinito non si trova 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 sola scheda di rete configurata con un indirizzo IP 192.168.0.33 e un subnet mask di 255.255.0.0. Ciò richiede che il gateway predefinito sia nel formato "192.168.<y>.<z>" perché la parte dell'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. Il TSS deve essere eseguito dagli account con privilegi di amministratore nel sistema locale e il contratto di licenza deve essere accettato (una volta accettato il contratto di licenza, il TSS non richiederà di nuovo).
  2. È consigliabile usare i criteri di esecuzione di PowerShell del computer RemoteSigned locale.

Note

Se i criteri di esecuzione correnti di PowerShell non consentono l'esecuzione di TSS, eseguire le azioni seguenti:

  • Impostare i RemoteSigned criteri di esecuzione per il livello di processo eseguendo il cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
  • Per verificare se la modifica ha effetto, eseguire il cmdlet PS C:\> Get-ExecutionPolicy -List.
  • Poiché le autorizzazioni a livello di processo si applicano solo alla sessione di PowerShell corrente, dopo la chiusura della finestra di PowerShell specificata in cui viene eseguita TSS, l'autorizzazione assegnata per il livello di processo tornerà allo stato configurato in precedenza.

Raccogliere le 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 nel server di destinazione.

  5. Consenti registrazione (PSR o video).

  6. Riprodurre il problema prima di immettere Y.

    Note

    Se si raccolgono i log sia sul client che sul 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.

Riferimenti