Problembehandlung bei der TCP/IP-Konnektivität

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

Gilt für: Windows 10

Möglicherweise treten Konnektivitätsfehler beim Anwendungsende oder Timeoutfehler auf. Im Folgenden sind die häufigsten Szenarien aufgeführt:

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

Wenn Sie vermuten, dass das Problem im Netzwerk liegt, erfassen Sie eine Netzwerkablaufverfolgung. Die Netzwerkablaufverfolgung wird dann gefiltert. Bei der Problembehandlung von Konnektivitätsfehlern können Sie bei einer Netzwerkerfassung auf die TCP-Zurücksetzung stoßen, die auf ein Netzwerkproblem hinweisen kann.

• TCP ist als verbindungsorientiertes und zuverlässiges Protokoll definiert. Eine der Möglichkeiten, wie TCP die Zuverlässigkeit sicherstellt, ist der Handshakeprozess. Das Einrichten einer TCP-Sitzung würde mit einem Drei-Wege-Handshake beginnen, gefolgt von einer Datenübertragung und einem vierseitigen Abschluss. Der vierseitige Abschluss, bei dem sowohl Absender als auch Empfänger sich auf das Schließen der Sitzung einigen, wird als ordnungsgemäßer Abschluss bezeichnet. Nach dem vierseitigen Schließen lässt der Server 4 Minuten Zeit (Standard) zu, während der alle ausstehenden Pakete im Netzwerk verarbeitet werden sollen. Dieser Zeitraum ist der TIME_WAIT Zustand. Nach Abschluss des TIME_WAIT Zustands werden alle für diese Verbindung zugeordneten Ressourcen freigegeben.
• DIE TCP-Zurücksetzung ist ein abrupter Abschluss der Sitzung. Dadurch werden die der Verbindung zugeordneten Ressourcen sofort freigegeben, und alle anderen Informationen zur Verbindung werden gelöscht.
• Die TCP-Zurücksetzung wird durch das RESET-Flag im TCP-Header identifiziert, der auf 1 festgelegt ist.

Eine Netzwerkablaufverfolgung für die Quelle und das Ziel hilft Ihnen, den Datenverkehrsfluss zu bestimmen und zu sehen, an welchem Punkt der Fehler beobachtet wird.

In den folgenden Abschnitten werden einige der Szenarien beschrieben, in denen ein ZURÜCKSETZEN angezeigt wird.

Paketverluste

Wenn ein TCP-Peer TCP-Pakete sendet, für die keine Antwort vom anderen Ende empfangen wird, würde der TCP-Peer die Daten am Ende erneut übertragen, und wenn keine Antwort empfangen wurde, würde er die Sitzung beenden, indem er eine ACK RESET sendet (dieses ACK RESET bedeutet, dass die Anwendung alle bisher ausgetauschten Daten bestätigt, aufgrund von Paketverlusten ist die Verbindung jedoch geschlossen.

Die gleichzeitigen Netzwerkablaufverfolgungen für Quelle und Ziel helfen Ihnen dabei, dieses Verhalten zu überprüfen, wenn auf der Quellseite die Pakete erneut übertragen werden und auf dem Ziel keines dieser Pakete angezeigt wird. Dieses Szenario gibt an, dass das Netzwerkgerät zwischen Quelle und Ziel die Pakete verwirft.

Wenn der anfängliche TCP-Handshake aufgrund von Paketausfällen fehlschlägt, sehen Sie, dass das TCP-SYN-Paket nur dreimal erneut übertragen wird.

Quellseitige Verbindung über Port 445:

Zielseite: Wenn Sie denselben Filter anwenden, werden keine Pakete angezeigt.

Für die restlichen Daten übergibt TCP die Pakete fünfmal neu.

Quelle 192.168.1.62 Seitenablaufverfolgung:

Ziel 192.168.1.2-Seitenablaufverfolgung:

Die oben genannten Pakete werden nicht angezeigt. Engage Ihr Netzwerkteam, um mit den verschiedenen Hops zu untersuchen und zu prüfen, ob einer von ihnen potenziell Zuverluste im Netzwerk verursacht.

Wenn Sie feststellen, dass die SYN-Pakete das Ziel erreichen, das Ziel aber immer noch nicht reagiert, überprüfen Sie, ob sich der Port, mit dem Sie eine Verbindung herstellen möchten, im Lauschzustand befindet. (Netstat-Ausgabe ist hilfreich). Wenn der Port lauscht und trotzdem keine Antwort vorhanden ist, kann es zu einem WFP-Drop kommen.

Falscher Parameter im TCP-Header

Dieses Verhalten wird angezeigt, wenn die Pakete im Netzwerk von mittleren Geräten geändert werden und TCP am empfangenden Ende das Paket nicht akzeptieren kann, z. B. wenn die Sequenznummer geändert wird, oder wenn Pakete vom mittleren Gerät durch Ändern der Sequenznummer wiedergegeben werden. Auch hier kann die gleichzeitige Netzwerkablaufverfolgung für Quelle und Ziel Ihnen mitteilen, ob einer der TCP-Header geändert wurde. Vergleichen Sie zunächst die Quellablaufverfolgung und die Zielablaufverfolgung. Sie können feststellen, ob sich die Pakete selbst ändern oder ob neue Pakete das Ziel im Namen der Quelle erreichen.

In diesem Fall benötigen Sie erneut Hilfe vom Netzwerkteam, um jedes Gerät zu identifizieren, das Pakete ändert oder Pakete an das Ziel wiedergibt. Die häufigsten sind RiverBed-Geräte oder WAN-Beschleuniger.

Anwendungsseitiges Zurücksetzen

Wenn Sie festgestellt haben, dass die Zurücksetzungen nicht auf Neuübertragungen oder falsche Parameter oder Pakete zurückzuführen sind, die mithilfe der Netzwerkablaufverfolgung geändert werden, haben Sie sie auf das Zurücksetzen auf Anwendungsebene beschränkt.

Bei den Zurücksetzungen der Anwendung wird das Bestätigungsflag zusammen mit dem Zurücksetzungsflag auf 1 festgelegt. Diese Einstellung würde bedeuten, dass der Server den Empfang des Pakets bestätigt, aber aus irgendeinem Grund die Verbindung nicht akzeptiert. Diese Phase ist, wenn der Anwendung, die das Paket empfangen hat, etwas nicht gefallen hat, das sie empfangen hat.

In den folgenden Screenshots sehen Sie, dass die Pakete, die auf der Quelle und dem Ziel angezeigt werden, ohne Änderungen oder Abbrüche identisch sind, aber Sie sehen eine explizite Zurücksetzung, die vom Ziel an die Quelle gesendet wird.

Quellseite

Auf der Zielseite der Ablaufverfolgung

Außerdem wird ein ACK+RST-Flagpaket angezeigt, wenn das TCP-Einrichtungspaket SYN gesendet wird. Das TCP SYN-Paket wird gesendet, wenn der Client eine Verbindung an einem bestimmten Port herstellen möchte, aber wenn das Ziel bzw. der Server das Paket aus irgendeinem Grund nicht akzeptieren möchte, würde er ein ACK+RST-Paket senden.

Die Anwendung, die das Zurücksetzen verursacht (identifiziert durch Portnummern), sollte untersucht werden, um zu verstehen, was dazu führt, dass die Verbindung zurückgesetzt wird.

Hinweis

Die obigen Informationen beziehen sich auf Zurücksetzungen aus TCP-Sicht und nicht auf UDP. UDP ist ein verbindungsloses Protokoll, und die Pakete werden unzuverlässig gesendet. Bei Verwendung von UDP als Transportprotokoll würden keine Neuübertragungen oder Zurücksetzungen angezeigt. UDP verwendet jedoch ICMP als Fehlerberichtsprotokoll. Wenn das UDP-Paket an einen Port gesendet wurde und für das Ziel kein Port aufgeführt ist, sehen Sie, dass das Ziel den ICMP-Zielhost nicht erreichbar sendet: Port unreachable message unmittelbar nach dem UDP-Paket.

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 Behandlung von Konnektivitätsproblemen sehen Sie möglicherweise auch in der Netzwerkablaufverfolgung, dass ein Computer Pakete empfängt, aber nicht darauf reagiert. In solchen Fällen kann es zu einem Rückgang auf Serverebene kommen. Um zu verstehen, ob die lokale Firewall das Paket verwirft, aktivieren Sie die Firewallüberwachung auf dem Computer.

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

Sie können dann die Sicherheitsereignisprotokolle überprüfen, um eine Paketverknipung für eine bestimmte Port-IP-Adresse und eine zugeordnete Filter-ID zu ermitteln.

Führen Sie nun den Befehl aus netsh wfp show state. Diese Ausführung generiert eine wfpstate.xml Datei. Nachdem Sie diese Datei geöffnet und nach der ID gefiltert haben, die Sie im obigen Ereignis (2944008) finden, können Sie einen Firewallregelnamen sehen, der dieser ID zugeordnet ist, die die Verbindung blockiert.