Risolvere i problemi di connettività TCP/IP

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

Si applica a: Versioni supportate di client Windows e Windows Server

Questo articolo fornisce una guida completa per la risoluzione degli errori di connettività TCP/IP.

Sintomi e analisi

È possibile che si verifichino problemi di connettività a livello di applicazione o si verifichino errori di timeout. Ecco alcuni scenari comuni:

• Connettività dell'applicazione a un server di database
• Errori di timeout SQL
• Errori di timeout dell'applicazione BizTalk
• Errori di Remote Desktop Protocol (RDP)
• Errori di accesso alla condivisione file
• Connettività generale

Quando si sospetta un problema correlato alla rete, è consigliabile raccogliere un'acquisizione di pacchetti di rete. Questa acquisizione può essere filtrata per identificare la connessione TCP problematica e determinare la causa dell'errore.

Durante il processo di risoluzione dei problemi, potrebbe verificarsi una reimpostazione TCP nell'acquisizione di rete, che potrebbe indicare un problema di rete.

Introduzione a TCP

TCP è caratterizzato da un protocollo affidabile e orientato alla connessione. Garantisce l'affidabilità tramite il processo di handshake. Una sessione TCP viene avviata con un handshake a tre vie, seguito dal trasferimento dei dati e termina con una chiusura a quattro vie.

• Una chiusura a quattro vie, in cui sia il mittente che il destinatario accettano di chiudere la sessione, è noto come chiusura normale. Viene identificato dal flag FIN nell'intestazione TCP impostato su 1.

• Dopo la chiusura a quattro vie, il computer attende 4 minuti (per impostazione predefinita) prima di rilasciare la porta. Questo viene definito come TIME_WAIT stato. Durante questo TIME_WAIT stato, è possibile elaborare tutti i pacchetti in sospeso per la connessione TCP. Al termine dello stato TIME_WAIT, vengono rilasciate tutte le risorse allocate per la connessione.

• Una reimpostazione TCP è una chiusura brusca della sessione, causando il rilascio immediato delle risorse allocate e la cancellazione di tutte le informazioni di connessione. Viene identificato dal flag RESET nell'intestazione TCP impostato su 1. Una traccia di rete raccolta simultaneamente nell'origine e nella destinazione consente di determinare il flusso del traffico e di identificare il punto di errore.

Le sezioni seguenti illustrano gli scenari in cui può verificarsi un ripristino.

Perdita di pacchetti in rete

Quando un peer TCP invia pacchetti senza ricevere una risposta, il peer ritrasmette i dati. Se non è ancora presente alcuna risposta, la sessione termina con ACK RESET, a indicare che l'applicazione riconosce i dati scambiati ma chiude la connessione a causa della perdita di pacchetti.

Le tracce di rete simultanee in corrispondenza dell'origine e della destinazione possono verificare questo comportamento. Sul lato di origine è possibile visualizzare i pacchetti ritrasmessi. Sul lato di destinazione, questi pacchetti non sono presenti. Questo scenario indica che un dispositivo di rete tra l'origine e la destinazione elimina i pacchetti.

Scenario 1: Perdita di pacchetti durante l'handshake TCP iniziale

Se l'handshake TCP iniziale non riesce a causa di una perdita di pacchetti, il pacchetto TCP SYN viene ritrasmesso tre volte per impostazione predefinita.

Note

Il numero di volte in cui il pacchetto TCP SYN viene ritrasmesso può essere diverso in base al sistema operativo. Questo valore è determinato dal valore Max SYN Retransmissions in TCP Global parameters, che può essere visualizzato usando il comando netsh int tcp show global.

Si supponga che un computer di origine con indirizzo IP 10.10.10.1 si connetta alla destinazione con indirizzo IP 10.10.10.2 sulla porta TCP 445. Di seguito è riportato uno screenshot della traccia di rete raccolta nel computer di origine, che mostra l'handshake TCP iniziale in cui viene inviato il pacchetto TCP SYN e quindi ritrasmesso dall'origine perché non è stata ricevuta alcuna risposta dalla destinazione.

La stessa conversazione TCP visualizzata nella traccia di rete raccolta nella destinazione mostra che nessuno dei pacchetti precedenti è stato ricevuto dalla destinazione. Ciò implica che il pacchetto TCP SYN è stato eliminato sulla rete intermedia.

Se i pacchetti TCP SYN raggiungono la destinazione, ma la destinazione non risponde, verificare se la porta TCP connessa è nello stato LISTENING nel computer di destinazione. Questa operazione può essere archiviata nell'output del comando netstat -anob.

Se la porta è in ascolto e non c'è ancora risposta, potrebbe esserci un calo nella piattaforma windows filtering platform (WFP).

Scenario 2: Perdita di pacchetti durante il trasferimento dei dati dopo la connessione TCP

In uno scenario in cui un pacchetto di dati inviato dopo che viene stabilita la connessione TCP viene eliminato in rete, TCP ritrasmette il pacchetto cinque volte per impostazione predefinita.

Si supponga che un computer di origine con indirizzo IP 192.168.1.62 abbia stabilito una connessione con il computer di destinazione con indirizzo IP 192.168.1.2 sulla porta TCP 445. Il computer di origine invia i dati (pacchetto SMB Negotiate) che vengono ritrasmessi cinque volte, come illustrato di seguito. Dopo nessuna risposta dalla destinazione, il computer di origine invia un ACK-RST per chiudere questa connessione TCP.

Traccia lato origine 192.168.1.62:

Non verranno visualizzati i pacchetti precedenti che raggiungono la destinazione.

È necessario coinvolgere il team di rete interno per analizzare i diversi hop tra l'origine e la destinazione e verificare se uno degli hop causa potenziali perdite di pacchetti.

Parametro non corretto nell'intestazione TCP

Questo comportamento si verifica quando i dispositivi intermedi nella rete modificano i pacchetti, causando il rifiuto di TCP alla fine della ricezione. Ad esempio, il numero di sequenza TCP potrebbe essere modificato o i pacchetti potrebbero essere riprodotti da un dispositivo intermedio con un numero di sequenza TCP modificato.

Una traccia di rete simultanea nell'origine e nella destinazione consente di identificare eventuali modifiche alle intestazioni TCP.

Per iniziare, confrontare le tracce di origine e di destinazione per rilevare eventuali modifiche nei pacchetti o la presenza di nuovi pacchetti che raggiungono la destinazione per conto dell'origine.

In questi casi, è consigliabile richiedere assistenza al team di rete interno per identificare tutti i dispositivi che stanno modificando o riproducendo pacchetti nella destinazione. I responsabili comuni includono dispositivi Riverbed o acceleratori WAN.

Reimpostazione a livello di applicazione

Dopo aver determinato che le reimpostazioni non sono dovute a eliminazioni di pacchetti, parametri non corretti o modifiche ai pacchetti (come identificato tramite tracce di rete), è possibile concludere che il problema è una reimpostazione a livello di applicazione.

Le reimpostazioni a livello di applicazione sono caratterizzate dal flag Acknowledgementment (ACK) impostato su 1 insieme al flag Reset (R). Ciò indica che il server riconosce la ricezione del pacchetto, ma non accetta la connessione per qualche motivo. Questo problema si verifica in genere quando l'applicazione che riceve il pacchetto trova qualcosa di inaccettabile nei dati.

Negli screenshot seguenti è possibile osservare che i pacchetti in corrispondenza dell'origine e della destinazione sono identici, senza modifiche o eliminazioni. Tuttavia, una reimpostazione esplicita viene inviata dalla destinazione all'origine.

Traccia sul lato origine:

Traccia sul lato destinazione:

Un pacchetto TCP contrassegnato da ACK+RST può verificarsi anche quando viene inviato un pacchetto TCP SYN. Il pacchetto TCP SYN viene avviato dal computer di origine per stabilire una connessione su una porta specifica. Tuttavia, se il server di destinazione non vuole accettare il pacchetto per qualsiasi motivo, il server risponde con un pacchetto ACK+RST.

In questi casi, è essenziale analizzare l'applicazione che causa la reimpostazione (identificata dai numeri di porta) per comprendere perché la connessione viene reimpostata.

Note

Le informazioni precedenti riguardano la reimpostazione da una prospettiva TCP e non UDP. UDP è un protocollo senza connessione e i pacchetti vengono inviati in modo non permanente. Di conseguenza, le ritrasmissioni o le reimpostazioni non vengono osservate quando si usa UDP come protocollo di trasporto. Tuttavia, UDP usa ICMP come protocollo di segnalazione errori. Quando un pacchetto UDP viene inviato a una porta non elencata nella destinazione, la destinazione risponderà immediatamente con un messaggio ICMP "Destination Host Unreachable: Port Unreachable".

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

Durante la risoluzione dei problemi di connettività TCP/IP, è possibile osservare nella traccia di rete che un computer riceve pacchetti, ma non risponde. Ciò potrebbe indicare un calo nello stack di rete del server di destinazione.

Per determinare se Windows Firewall locale elimina il pacchetto, abilitare il controllo per windows Filtering Platform (WFP) nel computer usando il comando seguente.

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

È quindi possibile esaminare i registri eventi di sicurezza per identificare un rilascio di pacchetti su una porta TCP e un indirizzo IP specifici, insieme a un ID filtro WFP associato.

Eseguire quindi il comando netsh wfp show state che genera un file wfpstate.xml .

È possibile aprire questo file usando Blocco note e filtrare l'ID trovato nei registri eventi, ad esempio 2944008 nell'evento di esempio. Il risultato rivela il nome della regola del firewall associato all'ID filtro che blocca la connessione.