Freigeben über

Anleitung zur Problembehandlung bei der TCP/IP-Kommunikation

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

Dieser Artikel soll Ihnen bei der Behandlung von TCP/IP-Kommunikationsproblemen helfen.

Problembehandlungstools

Der Ping-Befehl ist nützlich, um die grundlegende Konnektivität zu testen. Sie sollten ihn aber nicht nutzen, um die Gesamtkonnektivität sicherzustellen. Aus den folgenden Gründen sind Telnet und PsPing für diesen Zweck besser geeignet:

  • Mit diesen Tools kann die Konnektivität mit der Anwendungsschicht getestet werden, indem TCP oder UDP (nur PsPing) als Transportprotokoll genutzt wird.
  • Sie können angeben, welcher Port verwendet wird. Daher können Sie zu geöffneten Ports einer Firewall navigieren.
  • Sie können eine Verbindung mit einem beliebigen „Lauschport“ 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 mit Details zu den Geräten, die sich auf dem Weg zum betroffenen Bereich befinden. Beachten Sie insbesondere die folgenden Geräte:

  • Firewalls
  • IPS (Systeme für Eindringschutz/-verhinderung)
  • Eingehende Paketuntersuchung (Deep Packet Inspection, DPI)
  • WAN-Beschleuniger

Anhand des Diagramms können Sie visualisieren und ermitteln, wo Sie nach der Ursache des Problems suchen sollten.

Schritt 2: Netzwerkablaufverfolgungen

Netzwerkablaufverfolgungen sind nützlich, um anzuzeigen, was beim Auftreten des Problems auf der Netzwerkebene passiert.

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 nicht pingen kann, funktioniert der lokale Stapel nicht. Beachten Sie alle angezeigten Fehlermeldungen.

Wenn sie einen Fehler "Allgemeiner 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 in der Taskleiste für das Symbol Netzwerkverbindung ein rotes „X“ oder ein gelbes Ausrufezeichen angezeigt wird. Ein rotes X gibt an, dass Windows keine Netzwerkverbindung erkennt. Ein gelbes Ausrufezeichen zeigt an, dass bei einer Überprüfung des Netzwerkverbindungsstatus (Network Connection Status Indicator, NSCI) ein Fehler aufgetreten ist.

Um dieses Problem zu beheben, überprüfen Sie, ob vom Netzwerkadapter eine erfolgreiche Verbindungsherstellung gemeldet wird. Stellen Sie sicher, dass der Netzwerkadapter angeschlossen ist und dass sich der Switchport, an dem der Knoten angeschlossen ist, nicht im Fehlerzustand befindet. Sie können Kabel, Switchports und Netzwerkadapter ändern, um den Ort dieses Problems einzugrenzen. Letztendlich liegt das Problem aber außerhalb des Betriebssystems. Wenden Sie sich zur weiteren Untersuchung an die Hardwareanbieter.

Es kann auch ein Problem zwischen dem Netzwerktreiber und Windows auftreten. Dieses Problem liegt in der Regel an einer Beschädigung im Stapel. Verwenden Sie die folgenden Problembehandlungsschritte:

  1. Stellen Sie sicher, dass die neuesten Komponenten (TCP/IP, NDIS, Azure Front Door, Winsock usw.) auf dem Knoten vorhanden sind.

  2. Setzen Sie die IP-Adresse 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 sich die Schnittstellennamen nicht geändert haben oder das Skript aktualisiert wird, um die neuen Namen zu verwenden.

    netsh -f C:\netConfig.txt

  5. Führen Sie je nach Bedarf die Installation oder Deinstallation des Netzwerkadapter-Treibers durch.

  6. Suchen und entfernen Sie Filtertreiber von Drittanbietern (z. B. Antivirensoftware).

  7. Versuchen Sie, den Computer im abgesicherten Modus mit Netzwerktreibern zu starten. Wenn der abgesicherte Modus mit Netzwerk funktioniert, führen Sie einen "sauberen Start"-Prozess aus, indem Sie alle Drittanbieter-Apps und -Dienste innerhalb von MSConfig deaktivieren, und aktivieren Sie sie dann nacheinander, bis das Problem zurückgegeben wird. Sie können sich dann an den Anbieter wenden, um Support zu erhalten.

    1. Wenn keiner dieser Ansätze erfolgreich ist, ist der Grund für 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 in einer zuvor funktionierenden Konfiguration wiederherzustellen. Das Abfangen der Ursache der Korruption kann schwierig und extrem zeitaufwändig sein. Auch wenn die Korruption gefunden wird, ist es noch schwieriger zu wissen, was dazu geführt hat. Wenn der beschädigte Registrierungsschlüssel manuell geändert wird, wird der Knoten in einen nicht unterstützten Zustand versetzt. Daher empfehlen wir, dass der Kunde den Knoten wiederherstellt oder erneut lädt, um die Beschädigung zu beseitigen.

Wenn die NSCI die Prüfpunktprüfung nicht erfüllt (gelbes Ausrufezeichen), weist dies nicht unbedingt auf ein Verbindungsproblem hin. Stellen Sie sicher, dass die typische Kommunikation wie erforderlich erfolgt.

  • Wenn ja, sollte der Schwerpunkt der Untersuchung darauf liegen, warum die NCSI-Tests nicht bestanden werden. Die Details hierzu werden in einem separaten Thema behandelt.
  • Falls nicht, sollten Sie zuerst die Konnektivitätsprobleme untersuchen, da das Problem wahrscheinlich behoben ist, nachdem die Konnektivität wiederhergestellt wurde.

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

Wenn der Knoten die anderen Knoten desselben Subnetzes oder Netzwerksegments per Ping oder Telnet erreichen kann, ist dies die Bestätigung, dass die externe Konnektivität funktioniert. Es sind noch weitere Tests erforderlich, um zu ermitteln, ob ein grundlegendes Konnektivitätsproblem besteht.

Wenn der Knoten keine Ping-/Telnet-Ping-/Telnet-Knoten im selben Subnetz-/Netzwerksegment ausführen kann. Beachten Sie alle angezeigten Fehlermeldungen.

  1. Fehler beim Zielhost, der nicht erreichbar ist, 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 zu sehen sein. Wenn bei diesem Prozess ein Fehler auftritt, basiert das Problem wahrscheinlich auf einer Fehlkonfiguration oder anderen Fehlern, die sich auf die Infrastruktur auswirken.

    Mögliche Ursachen:

    1. Falsche oder nicht übereinstimmende VLANs
    2. Falsche Switchportkonfiguration (Trunk/Zugriffsport)
    3. Andere Hardwareprobleme

  3. Der Timeoutfehler "Anforderung" bedeutet, dass die ARP-Anforderung eine Antwort erhalten hat, aber die ICMP-Echoanforderung, die vom Knoten gesendet wird, keine ICMP-Echoantwort erhält. Dies allein weist nicht auf ein Problem hin. ICMP-Datenverkehr wird ggf. durch die Netzwerk- oder Firewallsoftware auf den Knoten blockiert. Es kann vorteilhaft sein, die Firewallprofile (Windows) zu deaktivieren oder über die vom Firewallanbieter unterstützte Methode für ICMP-Tests zu deaktivieren.

    1. Telnet und PsPing sind besser für Tests geeignet. Führen Sie Telnet oder PsPing über einen Lauschport (z. B. 445) vom Quell- zum Zielknoten 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 wenn Firewallprofile deaktiviert sind), sammeln Sie eine zweiseitige netsh netconnection Szenarioablaufverfolgung, um weitere Probleme zu beheben.

Schritt 5: Pingen oder Telnet an das Standardgateway

Wenn der Knoten sein Standardgateway pingen kann, ist die externe Konnektivität (z. B. Off-Box-Konnektivität) vom Quellknoten aus möglich. Es sind trotzdem noch weitere Tests erforderlich, um zu ermitteln, ob ein grundlegendes Konnektivitätsproblem besteht. Wenn der Knoten kein Ping oder Telnet an das Standardgateway senden kann, bedeutet dies, dass die ICMP-Antworten auf dem Router deaktiviert sind.

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

Wenn der Quellknoten Ping, Telnet oder PsPing an andere Knoten im Zielsubnetz senden kann, funktioniert die grundlegende Konnektivität und das Routing innerhalb der Infrastruktur. Dieses Ergebnis ist ein Hinweis auf ein Problem, das den jeweiligen Zielknoten betrifft.

  1. Versuchen Sie, den Port, über den die Anwendung lauscht (z. B. TCP-Port 445 für SMB), per Telnet oder PsPing zu erreichen. 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 nachzufragen, warum die Verbindung für die Anwendung nicht hergestellt wird.

    Notiz

    Der Anwendungsanbieter könnte Microsoft sein, wenn das Problem ein Fehler beim Herstellen einer Verbindung mit einer Freigabe ist, beispielsweise. In diesen Situationen wäre es hilfreich, Daten mit einer beiderseitigen „netsh netconnection“-Ablaufverfolgung zu erfassen, um zusätzliche Informationen zu sammeln und sicherzustellen, dass im Netzwerkstapel keine Probleme bestehen.

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

    1. Stellen Sie sicher, dass sich der Port in einem "Überwachungszustand" befindet:
      CMD: netstat -nato | findstr :<port>
      PowerShell: Get-NetTcpConnection -LocalPort <port>
    2. Deaktivieren Sie vorübergehend alle Firewallprofile. (Hinweis: Nur die Profile deaktivieren. Deaktivieren Sie den Dienst nicht.)
      Wenn dies erfolgreich ist, muss die Firewall neu konfiguriert werden, damit der Datenverkehr der Anwendung über den entsprechenden Port zulässig ist.
    3. Entfernen Sie einzeln nacheinander alle Drittanbieteranwendungen, und führen Sie nach jeder Entfernung einen Test durch.
      Wenden Sie sich an den Hersteller der Software mit dem Problem, falls diese Vorgehensweise erfolgreich ist.
    4. Probieren Sie es mit dem abgesicherten Modus mit Netzwerktreibern.
      Wenn dies erfolgreich ist, isolieren Sie die Ursache, indem Sie einen "sauberen Start" des Knotens mithilfe von MSConfig ausführen, und aktivieren Sie dann Anwendungen und Dienste von Drittanbietern nacheinander, bis das Problem erneut auftritt.
    5. Wenn Sie den Verbindungsversuch reproduzieren, sollten Sie eine „netsh netconnection“-Ablaufverfolgung von der Quelle zum betroffenen Zielknoten ausführen. Ebenfalls hilfreich ist ein SDP-Vorgang für das Netzwerk.

  3. Wenn der Knoten keine Ping-, Telnet- oder PsPing-Ping-Knoten an andere Knoten im Zielsubnetz senden kann, kann das Problem wahrscheinlich infrastrukturbezogen sein. Auch hier kann es sein, dass ICMP innerhalb der Umgebung blockiert wird. Überprüfen Sie daher die Konnektivität, indem Sie Telnet oder PsPing verwenden, um eine Verbindung mit bekannten Lauschports herzustellen. An diesem Punkt ist eine beiderseitige Netzwerkablaufverfolgung erforderlich, um zu ermitteln, wo der Paketverlust im Netzwerk auftritt. Stellen Sie sicher, dass beide Ablaufverfolgungen ausgeführt werden, bevor Sie den Konnektivitätstest starten, damit das Problem erfasst wird.

Bekannte Probleme und Lösungen

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

Dieses Problem tritt auf, da entweder Daten in TCP- und UDP-Warteschlangen blockiert werden, oder es gibt Probleme mit Netzwerk- oder Softwareverzögerung auf Benutzerebene.This issue because either data is blocked in TCP and UDP queues or there are network or user-level software delay problems.

Um dieses Problem zu beheben, verwenden Sie den netstat -a Befehl, um den Status aller Aktivitäten auf TCP- und UDP-Ports auf dem lokalen Computer anzuzeigen.
Der Status einer guten TCP-Verbindung wird eingerichtet, während null (0) Bytes in den Sende- und Empfangswarteschlangen vorhanden sind. Wenn Daten in einer der beiden Warteschlangen blockiert werden oder ein irregulärer Zustand besteht, ist die Verbindung wahrscheinlich fehlerhaft. Andernfalls wird wahrscheinlich eine Softwareverzögerung auf Netzwerk- oder Benutzerebene auftreten.

Lange Verbindungszeiten bei Verwendung von Lmhosts zur Namensauflösung

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

Um dieses Problem zu beheben, platzieren Sie häufig verwendete Einträge am Oberen Rand der Datei und die #PRE Einträge am unteren Rand. Wenn am Ende einer großen Lmhosts-Datei ein Eintrag hinzugefügt wird, markieren Sie den Eintrag in Lmhosts als vorab geladenen Eintrag mithilfe der Option #PRE. Führen Sie anschließend den Befehl nbtstat -R aus, um sofort den lokalen Cache für Namen 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 ordnungsgemäß installiert sind, verwenden Sie den ping Befehl zusammen mit dem Remotecomputer, um zu überprüfen, ob die TCP/IP-Software funktioniert.

Es kann keine Verbindung mit einem Server hergestellt werden

Dieses Problem tritt auf, da entweder die NetBIOS-Namensauflösung den Namen nicht auflösen oder die falsche IP-Adresse behoben wird.

Um dieses Problem zu beheben, verwenden Sie den nbtstat -n Befehl auf dem Server, um zu bestimmen, welche Namen der Server im Netzwerk registriert ist. Der Computername des Computers, mit dem Sie eine Verbindung herstellen möchten, sollte sich in der angezeigten Liste befinden. Wenn der Name nicht aufgeführt ist, probieren Sie einen der anderen eindeutigen Computernamen aus, die angezeigt nbtstatwerden. 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 der Lmhosts-Datei befindet.

Ein Standardgateway kann nicht hinzugefügt werden

Dieses Problem tritt auf, da sich die IP-Adresse des Standardgateways nicht auf derselben 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.

Es kann beispielsweise sein, dass ein Computer nur über einen Netzwerkadapter verfügt, für den die IP-Adresse 192.168.0.33 und die Subnetzmaske 255.255.0.0 konfiguriert sind. Dies erfordert, dass das Standardgateway das Formular "192.168" aufweist.<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 im lokalen System ausgeführt werden, und EULA muss akzeptiert werden (sobald EULA akzeptiert wurde, wird TSS nicht mehr aufgefordert).
  2. Wir empfehlen die PowerShell-Ausführungsrichtlinie des lokalen Computers RemoteSigned .

Notiz

Wenn die aktuelle PowerShell-Ausführungsrichtlinie das Ausführen von TSS nicht zulässt, führen Sie die folgenden Aktionen aus:

  • Legen Sie die Ausführungsrichtlinie RemoteSigned für die Prozessebene fest, indem Sie das Cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSignedausführen.
  • Führen Sie das Cmdlet PS C:\> Get-ExecutionPolicy -Listaus, um zu überprüfen, ob die Änderung wirksam wird.
  • Da die Berechtigungen auf Prozessebene nur für die aktuelle PowerShell-Sitzung gelten, sobald das angegebene PowerShell-Fenster, in dem TSS ausgeführt wird, geschlossen ist, wird die zugewiesene Berechtigung für die Prozessebene auch wieder in den zuvor konfigurierten Zustand zurückgesetzt.

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

  1. Laden Sie TSS auf allen Knoten herunter, und entzippen 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 mithilfe des folgenden Cmdlets:

    TSS.ps1 -Scenario NET_General

  4. Akzeptieren Sie die EULA, 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.

    Notiz

    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 wiedergeben.

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

Die Ablaufverfolgungen werden in einer ZIP-Datei im Ordner "C:\MS_DATA " gespeichert, die zur Analyse in den Arbeitsbereich hochgeladen werden können.

Verweis