Sie sagen die Wahrheit, es sei denn, sie sind falsch aufgezeichnet. In diesen Fällen können Pakete tatsächlich dreiste Lügen erzählen.
Bei der Suche in Protokolldateien stoßen wir möglicherweise auf Symptome in den Paketen, die viele überraschen würden. Es handelt sich dabei um Ereignisse, die auf den ersten Blick seltsam erscheinen und uns sogar vorübergehend von der Fehlersuche ablenken können. Einige dieser Probleme haben tatsächlich zu irreführenden Ergebnissen geführt. network Analysten verbringen Stunden, wenn nicht Tage, damit, Probleme und Ereignisse zu verfolgen, die schlichtweg nicht existieren. network.
Die meisten dieser Beispiele lassen sich leicht vermeiden, indem Pakete von einem System erfasst werden. network Testen Sie den Zugriffspunkt (TAP) anstatt auf dem Rechner, auf dem der Datenverkehr generiert wird. Mit einem network Tippen Sie, um die Aufnahme zu starten. network Daten transparent und unverändert erhalten und sehen, was tatsächlich über die Leitung übertragen wird.
In den meisten Fällen sollten Pakete das Ethernet-Maximum von 1518 Bytes oder die angegebene Link-MTU nicht überschreiten. Dies gilt jedoch nur, wenn keine 802Q-Tags verwendet werden oder eine Jumbo-Frame-Umgebung vorliegt.
Wie können Pakete größer sein als das Ethernet-Maximum? Einfach ausgedrückt: Wir erfassen sie, bevor sie von der Netzwerkkarte segmentiert werden. Viele TCP/IP-Stacks verwenden heute TCP Segmentation Offload, wodurch die Segmentierung der Pakete an die Netzwerkkarte delegiert wird. Der WinPcap- oder Libpcap-Treiber erfasst die Pakete, bevor dieser Prozess stattfindet. Daher erscheinen manche Pakete möglicherweise viel zu groß, um legitim zu sein.
Wenn dieselbe Aktivität auf dem networkDiese großen Rahmen würden für den Transport in mehrere kleinere Teile zerlegt.
Zero Delta Zeiten
Null-Delta-Zeiten bedeuten, dass zwischen den Paketen keine gemessene Zeit liegt. Wenn diese Pakete das Erfassungsgerät erreichen, erhalten sie einen Zeitstempel und eine messbare Delta-Zeit. Der Eingangszeitstempel auf dem Erfassungsgerät konnte mit dem Paketaufkommen nicht Schritt halten. Würden diese Pakete hingegen mit einem externen Tap-Server erfasst, könnten wir wahrscheinlich einen fehlerfreien Zeitstempel erhalten.
Vorherige Pakete nicht erfasst
Diese Warnung wird angezeigt, weil Wireshark eine Lücke im TCP-Datenstrom festgestellt hat. Anhand der sequenzierten Nummern kann es erkennen, dass ein Paket fehlt. Manchmal ist dies auf einen Paketverlust im Upstream zurückzuführen. Es kann aber auch ein Symptom dafür sein, dass der Analysator oder SPAN das Paket verworfen hat, weil es mit der Last nicht Schritt halten konnte.
Nach dieser Warnung sollten Sie nach einer Reihe doppelter ACK-Pakete anstelle eines defekten Pakets suchen. Dies deutet darauf hin, dass ein Paket tatsächlich verloren gegangen ist und erneut gesendet werden muss. Wenn Sie keine erneute Übertragung oder defekte Pakete sehen, konnte der Analysator oder SPAN wahrscheinlich mit dem Datenstrom nicht Schritt halten. Das Paket befand sich tatsächlich auf dem networkAber wir haben es nicht gesehen.
Unbemerkte Segmente mit TCP-ACK
In diesem Fall wird eine Bestätigung für ein nicht erkanntes Datenpaket angezeigt. Das Datenpaket könnte einen anderen Weg genommen haben oder vom erfassenden Gerät schlicht nicht bemerkt worden sein.
Kürzlich habe ich diese Ereignisse in Trace-Dateien gesehen, die von Switches, Routern und Firewalls erfasst wurden. Da die Erfassung des Datenverkehrs eine niedrigere Priorität hat als die Weiterleitung (Gott sei Dank!), kann es sein, dass das Gerät einige Frames im Datenstrom einfach verpasst. Sobald wir die Bestätigung sehen, wissen wir, dass das Paket sein Ziel erreicht hat.
In den meisten Fällen liefern die Daten die Wahrheit. Sie können uns zur eigentlichen Ursache unseres Problems führen. network und Anwendungsprobleme. Da sie so klare und detaillierte Daten liefern, ist es sehr wichtig, dass wir sie so genau wie möglich aufzeichnen. network so schnell wie möglich. Das bedeutet, dass wir sie während der Übertragung und nicht erst auf dem Server erfassen müssen. Dadurch vermeiden wir Zeitverluste durch falsch-negative Ergebnisse.
Wenn Sie mehr erfahren network Visualisierungsüberlegungen für Profis, laden Sie unsere kostenlose Infografik herunter: TAP vs SPAN.
Teilen Sie diesen Blog:
Timur ist Gründer und CEO von NEOX Networks, Ein führender Anbieter von network Lösungen für Transparenz und Sicherheit. Mit über 25 Jahren Erfahrung in diesem Bereich verfügt Timur über ein tiefes Verständnis für die Herausforderungen, denen sich die heutigen IT- und OT-Teams gegenübersehen. network und Sicherheitsdomänen. Er setzt sich leidenschaftlich dafür ein, Technologie zur Lösung komplexer Probleme zu nutzen und glaubt, dass effektive network Transparenz ist für den Erfolg jedes Unternehmens im Hinblick auf Verfügbarkeit und Sicherheit von Geschäftsanwendungen entscheidend. Timur hat sich der Entwicklung innovativer Lösungen verschrieben, die den sich wandelnden Bedürfnissen der NEOX-Kunden gerecht werden.