Problembehandlung für TCP/IP-Verbindung

Testen Sie unseren Virtual Agent – Er kann Ihnen helfen, häufige Probleme bei der Active Directory-Replikation schnell zu erkennen und zu beheben.

Gilt für: Unterstützte Versionen von Windows-Client und Windows Server

Dieser Artikel enthält ein umfassendes Handbuch zur Problembehandlung bei TCP/IP-Konnektivitätsfehlern.

Symptome und Analyse

Möglicherweise treten Konnektivitätsprobleme auf Anwendungsebene auf, oder es treten Timeoutfehler auf. Hier einige gängige Szenarios:

• Anwendungskonnektivität mit einem Datenbankserver
• SQL-Timeoutfehler
• BizTalk-Anwendungstimeoutfehler
• RDP-Fehler (Remote Desktop Protocol)
• Dateifreigabezugriffsfehler
• Allgemeine Konnektivität

Wenn ein netzwerkbezogenes Problem vermutet wird, empfehlen wir das Sammeln einer Netzwerkpaketerfassung. Diese Erfassung kann gefiltert werden, um die problematische TCP-Verbindung zu identifizieren und die Ursache des Fehlers zu bestimmen.

Während des Problembehandlungsprozesses tritt möglicherweise ein TCP-RESET in der Netzwerkaufnahme auf, was auf ein Netzwerkproblem hindeuten könnte.

Einführung von TCP

TCP ist als verbindungsorientiertes und zuverlässiges Protokoll gekennzeichnet. Sie sorgt für Zuverlässigkeit durch den Handshake-Prozess. Eine TCP-Sitzung beginnt mit einem Drei-Wege-Handshake, gefolgt von der Datenübertragung und endet mit einer vierseitigen Schließung.

• Eine vierwegige Schließung, bei der sowohl der Absender als auch der Empfänger zustimmen, die Sitzung zu schließen, wird als ordnungsgemäßer Abschluss bezeichnet. Dies wird durch das FIN-Flag im TCP-Header identifiziert, der auf 1 festgelegt wird.

• Nach dem vierwegigen Schließen wartet der Computer 4 Minuten (standardmäßig), bevor der Port losgelassen wird. Dies wird als TIME_WAIT Zustand bezeichnet. Während dieses TIME_WAIT Zustands können alle ausstehenden Pakete für die TCP-Verbindung verarbeitet werden. Sobald der TIME_WAIT Zustand abgeschlossen ist, werden alle ressourcen, die der Verbindung zugeordnet sind, freigegeben.

• Eine TCP-Zurücksetzung ist eine abrupte Sitzungsschließung, wodurch die sofortige Freigabe der zugeordneten Ressourcen und die Löschung aller Verbindungsinformationen verursacht wird. Dies wird durch das RESET-Flag im TCP-Header identifiziert, der auf 1 festgelegt wird. Eine gleichzeitige Netzwerkablaufverfolgung auf der Quelle und dem Ziel hilft Ihnen, den Datenverkehrsfluss zu ermitteln und den Fehlerpunkt zu identifizieren.

In den folgenden Abschnitten werden Szenarien beschrieben, in denen ein RESET auftreten kann.

Paketverlust über das Netzwerk

Wenn ein TCP-Peer Pakete sendet, ohne eine Antwort zu empfangen, überträgt der Peer die Daten erneut. Wenn noch keine Antwort vorhanden ist, endet die Sitzung mit einem ACK RESET, der angibt, dass die Anwendung die ausgetauschten Daten bestätigt, aber die Verbindung aufgrund von Paketverlust schließt.

Gleichzeitige Netzwerkablaufverfolgungen an der Quelle und am Ziel können dieses Verhalten überprüfen. Auf der Quellseite können Sie die erneut übertragenen Pakete sehen. Auf der Zielseite sind diese Pakete nicht vorhanden. Dieses Szenario gibt an, dass ein Netzwerkgerät zwischen Der Quelle und dem Ziel die Pakete abbricht.

Szenario 1: Paketverlust während des anfänglichen TCP-Handshakes

Wenn der anfängliche TCP-Handshake aufgrund von Paketabbrüchen fehlschlägt, wird das TCP SYN-Paket standardmäßig dreimal erneut übertragen.

Notiz

Die Häufigkeit, mit der das TCP SYN-Paket erneut übertragen wird, kann je nach Betriebssystem unterschiedlich sein. Dies wird durch den Wert Max SYN Retransmissions unter TCP Global-Parametern bestimmt, der mithilfe des Befehls netsh int tcp show globalangezeigt werden kann.

Angenommen, ein Quellcomputer mit IP-Adresse 10.10.10.1 stellt eine Verbindung mit dem Ziel mit der IP-Adresse 10.10.10.2 über TCP-Port 445 her. Es folgt ein Screenshot der auf dem Quellcomputer gesammelten Netzwerkablaufverfolgung, die den anfänglichen TCP-Handshake anzeigt, wobei tcp SYN-Paket gesendet und dann von der Quelle erneut gesendet wird, da keine Antwort vom Ziel empfangen wurde.

Die gleiche TCP-Unterhaltung, die in der im Ziel erfassten Netzwerkablaufverfolgung angezeigt wird, zeigt, dass keine der oben genannten Pakete vom Ziel empfangen wurde. Dies bedeutet, dass das TCP SYN-Paket über das Zwischennetzwerk verworfen wurde.

Wenn die TCP SYN-Pakete das Ziel erreichen, aber das Ziel nicht antwortet, überprüfen Sie, ob sich der TCP-Port, der verbunden ist, im ÜBERWACHUNGszustand auf dem Zielcomputer befindet. Dies kann in der Ausgabe des Befehls netstat -anobeingecheckt werden.

Wenn der Port überwacht wird und es noch keine Antwort gibt, könnte es einen Drop auf der Windows-Filterplattform (WFP) geben.

Szenario 2: Paketverlust während der Datenübertragung nach der TCP-Verbindungseinrichtung

In einem Szenario, in dem ein nach dem Herstellen der TCP-Verbindung gesendetes Datenpaket über das Netzwerk verworfen wird, überschreibt TCP das Paket standardmäßig fünfmal.

Angenommen, ein Quellcomputer mit IP-Adresse 192.168.1.62 hat eine Verbindung mit dem Zielcomputer mit IP-Adresse 192.168.1.2 über TCP-Port 445 hergestellt. Der Quellcomputer sendet Daten (SMB Negotiate-Paket), die fünfmal neu übersetzt werden, wie unten dargestellt. Nach keiner Antwort vom Ziel sendet der Quellcomputer eine ACK-RST, um diese TCP-Verbindung zu schließen.

Quelle 192.168.1.62 Seitenablaufverfolgung:

Es wird keins der oben genannten Pakete angezeigt, die das Ziel erreichen.

Sie müssen Ihr internes Netzwerkteam einbeziehen, um die verschiedenen Hops zwischen der Quelle und dem Ziel zu untersuchen und zu überprüfen, ob eine der Hops möglicherweise Paketverluste verursacht.

Falscher Parameter im TCP-Header

Dieses Verhalten tritt auf, wenn zwischengeschaltete Geräte im Netzwerk Pakete ändern, wodurch TCP am empfangenden Ende abgelehnt wird. Beispielsweise kann die TCP-Sequenznummer geändert werden, oder Pakete können von einem Zwischengerät mit einer geänderten TCP-Sequenznummer wiedergegeben werden.

Eine gleichzeitige Netzwerkablaufverfolgung auf der Quelle und dem Ziel kann dabei helfen, änderungen an den TCP-Headern zu identifizieren.

Vergleichen Sie zunächst die Quell- und Zielablaufverfolgungen, um Änderungen in den Paketen oder das Vorhandensein neuer Pakete zu erkennen, die das Ziel im Auftrag der Quelle erreichen.

In solchen Fällen empfehlen wir, Unterstützung vom internen Netzwerkteam zu suchen, um alle Geräte zu identifizieren, die Pakete am Ziel ändern oder wiedergeben. Häufige Täter sind Riverbed-Geräte oder WAN-Zugriffstasten.

Zurücksetzen auf Anwendungsebene

Wenn Sie festgestellt haben, dass die Zurücksetzungen aufgrund von Paketabbrüchen, falschen Parametern oder Paketänderungen (wie durch Netzwerkablaufverfolgungen identifiziert) nicht zurückzuführen sind, können Sie schließen, dass das Problem eine Zurücksetzung auf Anwendungsebene ist.

Zurücksetzungen auf Anwendungsebene zeichnen sich durch das Flag "Bestätigung" (ACK) aus, das zusammen mit dem Reset-Flag (R) auf 1 festgelegt wird. Dies weist darauf hin, dass der Server den Empfang des Pakets bestätigt, die Verbindung jedoch aus irgendeinem Grund nicht akzeptiert. Dieses Problem tritt in der Regel auf, wenn die Anwendung, die das Paket empfängt, etwas inakzeptabel in den Daten findet.

In den folgenden Screenshots können Sie feststellen, dass die Pakete sowohl an der Quelle als auch am Ziel identisch sind, ohne Änderungen oder Tropfen. Eine explizite Zurücksetzung wird jedoch vom Ziel an die Quelle gesendet.

Quellseitige Ablaufverfolgung:

Zielseitige Ablaufverfolgung:

Ein mit ACK+RST gekennzeichnetes TCP-Paket kann auch auftreten, wenn ein TCP SYN-Paket gesendet wird. Das TCP SYN-Paket wird vom Quellcomputer initiiert, um eine Verbindung mit einem bestimmten Port herzustellen. Wenn der Zielserver das Paket jedoch aus irgendeinem Grund nicht akzeptieren möchte, antwortet der Server mit einem ACK+RST-Paket.

In solchen Fällen ist es wichtig, die Anwendung zu untersuchen, die die Zurücksetzung (identifiziert durch Portnummern) verursacht, um zu verstehen, warum die Verbindung zurückgesetzt wird.

Notiz

Die oben genannten Informationen beziehen sich auf Resets aus TCP-Perspektive und nicht auf UDP. UDP ist ein verbindungsloses Protokoll, und Pakete werden unzuverlässlich gesendet. Daher werden Bei Verwendung von UDP als Transportprotokoll keine Erneutübertragungen oder Zurücksetzungen beobachtet. UDP verwendet ICMP jedoch als Fehlerberichtsprotokoll. Wenn ein UDP-Paket an einen Port gesendet wird, der nicht am Ziel aufgeführt ist, antwortet das Ziel sofort mit einer ICMP-Nachricht "Zielhost nicht erreichbar: Port nicht erreichbar".

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

Während der Problembehandlung bei TCP/IP-Konnektivitätsproblemen können Sie in der Netzwerkablaufverfolgung feststellen, dass ein Computer Pakete empfängt, aber nicht darauf reagiert. Dies könnte auf einen Drop im Netzwerkstapel des Zielservers hinweisen.

Um zu ermitteln, ob die lokale Windows-Firewall das Paket abbricht, aktivieren Sie die Überwachung der Windows-Filterplattform (WFP) auf dem Computer mithilfe des folgenden Befehls.

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

Anschließend können Sie die Sicherheitsereignisprotokolle überprüfen, um ein Paketablage für einen bestimmten TCP-Port und eine BESTIMMTE IP-Adresse sowie eine zugeordnete WFP-Filter-ID zu identifizieren.

Führen Sie als Nächstes den Befehl netsh wfp show state aus, der eine wfpstate.xml Datei generiert.

Sie können diese Datei mit Editor öffnen und nach der ID filtern, die in den Ereignisprotokollen enthalten ist (z. B. 2944008 im Beispielereignis). Das Ergebnis zeigt den Firewallregelnamen an, der der Filter-ID zugeordnet ist, die die Verbindung blockiert.