Leitfaden zur Problembehandlung bei der TCP/IP-Kommunikation

Dieser Artikel soll Ihnen bei der Behandlung von Problemen mit der TCP/IP-Kommunikation helfen.

Tools zur Problembehandlung

Der Ping-Befehl ist nützlich, um die grundlegende Konnektivität zu testen. Sie sollten sich jedoch nicht darauf verlassen, um die Gesamtkonnektivität nachzuweisen. Telnet und PsPing sind aus folgenden Gründen nützlicher:

• Diese Tools können die Konnektivität mit der Anwendungsschicht mithilfe von TCP oder UDP (nur PsPing) als Transportprotokoll testen.
• Sie können angeben, welcher Port verwendet wird. Daher können Sie durch geöffnete Ports in einer Firewall navigieren.
• Sie können eine Verbindung mit jedem "lauschenden" Port auf dem Zielknoten herstellen, um den Zugriff auf den Port einer bestimmten Anwendung zu überprüfen.

Checkliste zur Problembehandlung

Schritt 1: Erfassen eines Netzwerkdiagramms

Erfassen Sie ein Netzwerkdiagramm, in dem die Geräte aufgeführt sind, die sich im Pfad zum betroffenen Bereich befinden. Beachten Sie insbesondere die folgenden Geräte:

• Firewalls
• IPS (Intrusion Protection/Prevention Systems)
• DPI (Deep Packet Inspection)
• WAN-Optimierung

Das Diagramm kann Ihnen helfen, zu visualisieren und zu ermitteln, wo Sie nach der Ursache des Problems suchen müssen.

Schritt 2: Netzwerkablaufverfolgungen

Netzwerkablaufverfolgungen sind nützlich, um zu sehen, was auf Netzwerkebene auftritt, wenn das Problem auftritt.

Schritt 3: Pingen der lokalen IP-Adresse des Computers

Versuchen Sie, die lokale IP-Adresse des Computers zu pingen.

Wenn der Knoten seine lokale IP-Adresse nicht pingen kann, funktioniert der lokale Stapel nicht. Notieren Sie sich alle angezeigten Fehlermeldungen.

Wenn Sie einen Allgemeinen Fehler erhalten, bedeutet dieser Fehler, dass keine gültigen Schnittstellen zum Verarbeiten der Anforderung vorhanden sind. Dieses Problem kann durch ein Hardwareproblem oder ein Stapelproblem verursacht werden.

Überprüfen Sie, ob auf dem Symbol " Netzwerkverbindung " in der Taskleiste ein rotes "X" oder ein gelbes Ausrufezeichen angezeigt wird. Ein rotes X gibt an, dass Windows keine Netzwerkverbindung erkennt. Ein gelbes Ausrufezeichen gibt an, dass der Netzwerkverbindungsstatusindikator (Network Connection Status Indicator, NSCI) eine Überprüfung nicht bestanden hat.

Um dieses Problem zu beheben, überprüfen Sie, ob der Netzwerkadapter die Konnektivität meldet. Stellen Sie sicher, dass der Netzwerkadapter angeschlossen ist und dass sich der Switchport, an dem der Knoten verbunden ist, nicht im Fehlerzustand befindet. Sie können Kabel, Switchports und Netzwerkadapter ändern, um einzugrenzen, wo dieses Problem auftritt. Letztendlich liegt das Problem jedoch außerhalb des Betriebssystems. Wenden Sie sich an die Hardwarehersteller, um weitere Untersuchungen durchzuführen.

Es kann auch ein Problem zwischen dem Netzwerktreiber und Windows auftreten. Dieses Problem ist in der Regel auf eine Beschädigung im Stapel zurückzuführen. Führen Sie die folgenden Schritte zur Problembehandlung aus:

1. Stellen Sie sicher, dass die neuesten Bits auf dem Knoten (TCP/IP, NDIS, AFD, Winsock usw.) vorhanden sind.

2. Setzen Sie IP und Winsock zurück, indem Sie die folgenden Befehle ausführen. Sichern Sie die gesamte Netzwerkkonfiguration.

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

3. Starten Sie den Knoten neu.

4. Stellen Sie die Netzwerkeinstellungen nach dem Neustart wieder her. Dieser Vorgang funktioniert nur, wenn die Schnittstellennamen nicht geändert wurden oder das Skript aktualisiert wird, um die neuen Namen zu verwenden.

   netsh -f C:\netConfig.txt
   

5. Deinstallieren Sie den Netzwerkadaptertreiber, oder installieren Sie ihn erneut.

6. Suchen Sie nach Filtertreibern von Drittanbietern (z. B. Antivirensoftware), und entfernen Sie diese.

7. Versuchen Sie, den Computer im abgesicherten Modus mit Netzwerk zu starten. Wenn der abgesicherte Modus mit Netzwerk funktioniert, führen Sie einen sauber-Startprozess aus, indem Sie alle Apps und Dienste von Drittanbietern in MSConfig deaktivieren und diese dann einzeln erneut aktivieren, bis das Problem zurückkehrt. Sie können sich dann an den Anbieter wenden, um Support zu erhalten.

   1. Wenn keines dieser Elemente erfolgreich ist, ist das Problem wahrscheinlich eine Beschädigung der Registrierung.
   2. Wenn Sie über eine Sicherungskopie der Registrierung verfügen (z. B. eine physische Sicherung oder einen Systemwiederherstellungspunkt), können Sie versuchen, den Knoten auf einer zuvor funktionierenden Konfiguration wiederherzustellen. Die Ursache der Beschädigung zu ermitteln, kann schwierig und extrem zeitaufwändig sein. Selbst wenn die Korruption gefunden wird, ist es noch schwieriger zu wissen, was sie verursacht hat. Durch manuelles Ändern des beschädigten Registrierungsschlüssels wird der Knoten in einen nicht unterstützten Zustand versetzt. Daher wird empfohlen, den Knoten wiederherzustellen oder neu zu laden, um die Beschädigung zu beheben.

Wenn die NSCI ihre Testüberprüfung (gelbes Ausrufezeichen) nicht besteht, weist dies nicht unbedingt auf ein Konnektivitätsproblem hin. Stellen Sie sicher, dass die typische Kommunikation so erfolgt, wie sie sollte.

• Wenn ja, sollte sich die Untersuchung speziell darauf konzentrieren, warum das NCSI seine Überprüfungen nicht erfolgreich durchgeführt hat. Die Details dazu werden in einem separaten Thema behandelt.
• Wenn dies nicht der Fall ist, untersuchen Sie zuerst die Konnektivitätsprobleme, da dies wahrscheinlich nach der Wiederherstellung der Konnektivität behoben wird.

Schritt 4: Problembehandlung bei Fehlermeldungen, die während des Ping- oder Telnet-Tests auftreten

Wenn der Knoten Ping oder Telnet an Knoten im gleichen Subnetz oder Netzwerksegment senden kann, würde dies bestätigen, dass die externe Konnektivität funktioniert. Weitere Tests sind weiterhin erforderlich, um zu verstehen, ob ein grundlegendes Konnektivitätsproblem vorliegt.

Wenn der Knoten nicht an Knoten im gleichen Subnetz/Netzwerksegment pingen/telnet kann. Notieren Sie sich alle angezeigten Fehlermeldungen.

1. Der Fehler "Zielhost nicht erreichbar " bedeutet, dass die vom Knoten gesendeten ARP-Anforderungen keine Antwort erhalten.

2. Sammeln Sie eine zweiseitige Ablaufverfolgung von den Knoten, zwischen denen Sie testen. Stellen Sie sicher, dass die vom Quellknoten gesendete ARP-Anforderung den Zielknoten erreicht und der Zielknoten entsprechend antwortet. Diese Antwort sollte in der Quellablaufverfolgung angezeigt werden. Wenn dieser Prozess fehlschlägt, ist das Problem wahrscheinlich eine Fehlkonfiguration oder andere Probleme, die sich auf die Infrastruktur auswirken.

   Mögliche Ursachen:

   1. Falsche oder nicht übereinstimmende VLANs.
   2. Eine falsche Switchportkonfiguration (Trunk im Vergleich zum Zugriffsport).
   3. Andere Hardwareprobleme.

3. Der Anforderungstimeoutfehler bedeutet, dass die ARP-Anforderung eine Antwort erhalten hat, aber die vom Knoten gesendete ICMP-Echoanforderung keine ICMP-Echoantwort erhält. Dies allein deutet nicht auf ein Problem hin. ICMP-Datenverkehr kann durch die Netzwerk- oder Firewallsoftware auf den Knoten blockiert werden. Es kann von Vorteil sein, die Firewallprofile (Windows) zu deaktivieren oder sie über die vom Firewallanbieter unterstützte Methode zum Testen von ICMP zu deaktivieren.

   1. Telnet und PsPing eignen sich besser für Tests. Führen Sie Telnet oder PsPing vom Quellknoten zum Zielknoten auf einem Lauschport (z. B. 445) aus.
   2. Wenn Schritt 1 erfolgreich ist, funktioniert die externe Konnektivität. Fahren Sie mit dem Testen der grundlegenden Konnektivität fort.
   3. Wenn Schritt 1 nicht erfolgreich ist (und Firewallprofile deaktiviert sind), erstellen Sie eine zweiseitige netsh netconnection Szenarioablaufverfolgung, um weitere Problembehandlungen durchzuführen.

Schritt 5: Pingen oder Telnet an das Standardgateway

Wenn der Knoten sein Standardgateway pingen kann, ist externe Konnektivität (z. B. Off-Box-Konnektivität) vom Quellknoten möglich. Weitere Tests wären weiterhin erforderlich, um zu verstehen, ob ein grundlegendes Konnektivitätsproblem vorliegt. Wenn der Knoten oder Telnet nicht an sein Standardgateway pingen kann, bedeutet dies, dass die ICMP-Antworten auf dem Router deaktiviert sind.

Schritt 6: Überprüfen von Problemen, die sich auf den bestimmten Zielknoten auswirken

Wenn der Quellknoten Ping, Telnet oder PsPing an andere Knoten im Zielsubnetz senden kann, funktionieren grundlegende Konnektivität und Routing innerhalb der Infrastruktur. Dieses Ergebnis weist auf ein Problem hin, das sich auf den spezifischen Zielknoten auswirkt.

1. Versuchen Sie, Telnet oder PsPing an den bestimmten Port zu senden, an dem die Anwendung lauscht (z. B. TCP-Port 445 für SMB). Wenn die Verbindung erfolgreich hergestellt wurde, kann die grundlegende Konnektivität auf Anwendungsebene bestätigt werden. In diesem Fall müssen Sie sich an den Anwendungsanbieter wenden, um zu ermitteln, warum die Anwendung keine Verbindung herstellt.

   Hinweis

   Der Anwendungsanbieter könnte Microsoft sein, wenn das Problem beispielsweise ein Fehler beim Herstellen einer Verbindung mit einer Freigabe ist. In diesen Situationen ist es nützlich, eine zweiseitige Netsh netconnection-Szenarioablaufverfolgung zu verwenden, um zusätzliche Informationen zu sammeln und sicherzustellen, dass keine Probleme im Netzwerkstapel vorliegen.

2. Wenn die Verbindung mit dem bestimmten Port nicht erfolgreich ist:

   1. Stellen Sie sicher, dass sich der Port im Zustand "Lauscht" befindet:
      CMD: netstat -nato | findstr :<port>
      Powershell: Get-NetTcpConnection -LocalPort <port>
   2. Deaktivieren Sie vorübergehend alle Firewallprofile. (Hinweis: Deaktivieren Sie nur die Profile. Deaktivieren Sie den Dienst nicht.)
      Wenn dies erfolgreich ist, muss die Firewall neu konfiguriert werden, um den Anwendungsdatenverkehr an ihrem spezifischen Port zuzulassen.
   3. Entfernen Sie alle Anwendungen von Drittanbietern einzeln, und testen Sie zwischen den einzelnen Entfernungen.
      Wenn dies erfolgreich ist, wenden Sie sich an den Anbieter der problematischen Software.
   4. Probieren Sie den abgesicherten Modus mit Netzwerk aus.
      Wenn dies erfolgreich ist, isolieren Sie die Ursache, indem Sie einen "sauber Start" des Knotens mithilfe von MSConfig ausführen und dann Anwendungen und Dienste von Drittanbietern einzeln aktivieren, bis das Problem erneut auftritt.
   5. Wenn Sie den Verbindungsversuch reproduzieren, sollten Sie eine Netsh netconnection-Szenarioablaufverfolgung von der Quelle zum betroffenen Zielknoten ausführen. Ein Netzwerk-SDP wäre auch von Vorteil.

3. Wenn der Knoten keine Ping-, Telnet- oder PsPing-Ping-Ping-Vorgänge an andere Knoten im Zielsubnetz durchführen kann, könnte das Problem wahrscheinlich infrastrukturbedingt sein. Auch hier könnte ICMP innerhalb der Umgebung blockiert werden. Überprüfen Sie daher die Konnektivität mithilfe von Telnet oder PsPing, um eine Verbindung mit bekannten Überwachungsports herzustellen. An diesem Punkt ist eine zweiseitige Netzwerkablaufverfolgung erforderlich, um anzuzeigen, wo der Paketverlust im Netzwerk auftritt. Stellen Sie sicher, dass beide Ablaufverfolgungen ausgeführt werden, bevor Sie den Konnektivitätstest ausprobieren, damit das Problem erfasst wird.

Häufige Probleme und Lösungen

TCP/IP-Verbindung mit einem Host scheint beendet zu sein

Dieses Problem tritt auf, weil entweder Daten in TCP- und UDP-Warteschlangen blockiert sind oder probleme mit Der Softwareverzögerung auf Netzwerk- oder Benutzerebene auftreten.

Um dieses Problem zu beheben, verwenden Sie den netstat -a Befehl, um die status aller Aktivitäten auf TCP- und UDP-Ports auf dem lokalen Computer anzuzeigen.
Der Zustand einer guten TCP-Verbindung wird hergestellt, während in den Sende- und Empfangswarteschlangen null (0) Bytes vorhanden sind. Wenn Daten in einer Warteschlange blockiert sind oder der Zustand unregelmäßig ist, ist die Verbindung wahrscheinlich fehlerhaft. Wenn dies nicht der Fall ist, tritt wahrscheinlich eine Softwareverzögerung auf Netzwerk- oder Benutzerebene auf.

Lange Verbindungszeiten bei Verwendung von Lmhosts für die Namensauflösung

Dieses Problem tritt auf, weil die Lmhosts-Datei sequenziell analysiert wird, um Einträge ohne die Option #PRE zu suchen.

Um dieses Problem zu beheben, platzieren Sie häufig verwendete Einträge am Anfang der Datei und die #PRE Einträge unten. Wenn am Ende einer großen Lmhosts-Datei ein Eintrag hinzugefügt wird, markieren Sie den Eintrag in Lmhosts mit der Option #PRE als vorab geladenen Eintrag. Führen Sie dann den nbtstat -R Befehl aus, um den lokalen Namenscache sofort zu aktualisieren.

Systemfehler 53 ist aufgetreten.

Systemfehler 53 wird zurückgegeben, wenn die Namensauflösung für einen bestimmten Computernamen fehlschlägt, wenn der net use Befehl verwendet wird.

Wenn sich der Computer im lokalen Subnetz befindet, überprüfen Sie, ob der Name richtig geschrieben ist und dass auf dem Zielcomputer auch TCP/IP ausgeführt wird. Wenn sich der Computer nicht im lokalen Subnetz befindet, stellen Sie sicher, dass der Name und die IP-Adresszuordnung in der Lmhosts-Datei oder in der WINS-Datenbank verfügbar sind. Wenn alle TCP/IP-Elemente anscheinend ordnungsgemäß installiert sind, verwenden Sie den ping Befehl zusammen mit dem Remotecomputer, um zu überprüfen, ob die TCP/IP-Software funktioniert.

Herstellen einer Verbindung mit einem bestimmten Server nicht möglich

Dieses Problem tritt auf, weil entweder die NetBIOS-Namensauflösung den Namen nicht auflöst oder die falsche IP-Adresse aufgelöst wird.

Um dieses Problem zu beheben, verwenden Sie den nbtstat -n Befehl auf dem Server, um zu ermitteln, welche Namen der Server im Netzwerk registriert hat. Der Computername des Computers, mit dem Sie eine Verbindung herstellen möchten, sollte in der angezeigten Liste enthalten sein. Wenn der Name nicht aufgeführt ist, versuchen Sie es mit einem der anderen eindeutigen Computernamen, die von nbtstatangezeigt werden. Wenn der name, der von einem Remotecomputer verwendet wird, mit dem Namen identisch ist, der nbtstat -n vom Befehl angezeigt wird, stellen Sie sicher, dass der Remotecomputer über einen Eintrag für den Servernamen verfügt, der sich auf dem WINS-Server oder in seiner Lmhosts-Datei befindet.

Hinzufügen eines Standardgateways nicht möglich

Dieses Problem tritt auf, weil sich die IP-Adresse des Standardgateways nicht auf der gleichen IP-Netzwerk-ID wie Ihre IP-Adresse befindet.

Um dieses Problem zu beheben, ermitteln Sie, ob sich das Standardgateway im selben logischen Netzwerk wie der Netzwerkadapter des Computers befindet, indem Sie die IP-Adresse des Standardgateways mit den Netzwerk-IDs eines der Netzwerkadapter des Computers vergleichen.

Beispielsweise verfügt ein Computer über einen einzelnen Netzwerkadapter, der mit einer IP-Adresse von 192.168.0.33 und einer Subnetzmaske von 255.255.0.0 konfiguriert ist. Dies erfordert, dass das Standardgateway das Format "192.168.<y>.<z>", da der Netzwerk-ID-Teil der IP-Schnittstelle 192.168.0.0 ist.

Datensammlung

Bevor Sie sich an den Microsoft-Support wenden, können Sie Informationen zu Ihrem Problem sammeln.

Voraussetzungen

1. TSS muss von Konten mit Administratorrechten auf dem lokalen System ausgeführt werden, und die EULA muss akzeptiert werden (sobald die EULA akzeptiert wurde, wird TSS nicht mehr aufgefordert).
2. Es wird die PowerShell-Ausführungsrichtlinie für den lokalen Computer RemoteSigned empfohlen.

Sammeln Sie wichtige Informationen, bevor Sie sich an den Microsoft-Support wenden.

1. Laden Sie TSS auf alle Knoten herunter, und entpacken Sie es im Ordner C:\tss .

2. Öffnen Sie den Ordner C:\tss über eine PowerShell-Eingabeaufforderung mit erhöhten Rechten.

3. Starten Sie die Ablaufverfolgungen auf dem Quell- und Zielserver mit dem folgenden Cmdlet:

   TSS.ps1 -Scenario NET_General
   

4. Akzeptieren Sie den Lizenzvertrag, wenn die Ablaufverfolgungen zum ersten Mal auf dem Quell- oder Zielserver ausgeführt werden.

5. Aufzeichnung zulassen (PSR oder Video).

6. Reproduzieren Sie das Problem, bevor Sie Y eingeben.

   Hinweis

   Wenn Sie Protokolle sowohl auf dem Client als auch auf dem Server sammeln, warten Sie auf diese Meldung auf beiden Knoten, bevor Sie das Problem reproduzieren.

7. Geben Sie Y ein, um die Protokollsammlung abzuschließen, nachdem das Problem reproduziert wurde.

Die Ablaufverfolgungen werden in einer ZIP-Datei im Ordner C:\MS_DATA gespeichert, der zur Analyse in den Arbeitsbereich hochgeladen werden kann.

Referenz

• Problembehandlung bei der TCP/IP-Konnektivität
• Behandeln von Problemen mit der Portauslastung
• Problembehandlung bei RPC-Fehlern (Remote Procedure Call, Remoteprozeduraufruf)
• Sammeln von Daten mithilfe des Netzwerkmonitors
• Fehler beim Öffnen der TCP/IP-Eigenschaften des Netzwerkadapters
• Direkter Host-SMB über TCP/IP
• Konfigurieren von TCP/IP-Netzwerken, während NetBIOS deaktiviert ist
• TCP-Datenverkehr wird beendet.
• Der dynamische Standardportbereich für TCP/IP wurde geändert.
• TCP/IP-Eigenschaften rückgängig machen den Standardeinstellungen