Schwierige Netzwerkfrage kann jemand helfen?
Wie löst du Netzwerkconnectivitätsprobleme in einem Layer 2 Netzwerk wenn du weißt welcher Computer das TCP SYN Frame an die anderen Server im Netzwerk senden würde? Ziel ist es die funktionalität vom Sende PC wiederherzustellen. Alle anderen Maschinen/Server mit denen der Sende PC nicht kommuniziert sind egal. Alle Antworten beinhalten die Verwendung eines Netzwerk Sniffers Wireshark. Das Netzwerk ist ein /22 OT Netzwerk und es wird NIE DNS verwendet. Der Sende PC ist der einzige PC der Fix an einem Switch hängt wo es keine Interface Probleme gibt. Alle anderen Server haben ein defektes Netzwerkkabel bzw. Interface am Switch im DOWN Status. Der Sende PC kommuniziert nicht mit allen Servern. Du hast keinen Zugang zur Client Applikation weil die OT Typisch nur mit einem Passwort zu öffnen ist das du nicht hast und auch nicht erfragen kannst weil es 2.00 am morgen ist.
A) Du suchst nach Pakete mit SYN Flag ohne ACK und nach Retransmissions davon mit der source IP von dem Sende PC.
B) Du suchst mit arp -a die Arp Table ab und machst vorher einen IP Scan über das /22 Netzwerk.
C) Du filterst nach ARP Pakete im Netzwerk mit der Source IP des Sende Rechners und hälst nach ARP requests ausschau die sich wiederholen.
D) Du schaust dir die Statistiken in Wireshark an und erhältst die Info wo der Sende PC verbindungen aufgebaut hat.
Noch etwas: Der Anwender hat wie die ganzen Interfaces DOWN waren am Anlagenswitch den Sende PC bereits mehrmals neu gestartet.
Der Fragesteller hat die Frage jetzt nochmal umformuliert:Aufgabe: Finde die benötigen Switchports der relevanten OPC UA Server.
Intro:
In einem Produktionsunternehmen ist Flüssigmetall in die Netzwerk Kabelschächte geflossen und viele Switchports sind deshalb jetzt offline.
Es gibt eine Prio Reihenfolge und zwar soll ein spezieller Anlagenverbund so bald wie möglich wieder laufen.
Das Produktionsnetzwerk ist ein sehr flaches Layer 2 Netzwerk mit nur einem IPv4-Subnetz.
Die Anlage ist so aufgebaut dass es einen Client-PC gibt der sich zu verschiedenen OPC UA Servern verbinden soll damit er von dort die Daten abgreifen.
Allerdings ist die Config von dieser OPC UA Client Applikation nicht zugänglich für dich und der Programmierer ist gerade nicht erreichbar.
Jetzt liegt an dir herauszufinden mit welchen OPC UA Servern der Client eine Verbindung aufbauen will. Versuche mit den Hilfsmitteln die Switchports herauszufinden damit man die Kabel dann schnell austauschen kann.
Bedingungen:
-Sehr viele Interfaces am Switch sind im DOWN Status.
-Es gibt leider um die 100 OPC UA Server in diesem VLAN bzw. /22 IPv4-Subnetz und nicht alle sind dem OPC UA Client zugeordnet. Das heißt in diesem Netzwerk gibt es andere OPC UA Clients die aber hier nicht relevant sind.
-Der OPC UA Client-PC wurde leider schon neugestartet und somit wurde auch jeglicher Cache gelöscht.
-Wireshark ist am OPC UA Client installiert.
-Du hast eine Netzwerkverwaltungssoftware wo du MAC und IP und den zugeordneten Switchport siehst jeweils aktuell und auch die Historie davon.
-Der OPC UA Client PC versucht alle paar Sekunden via OPC UA eine Verbindung zu allen Servern herzustellen.
Wie gehst du vor? (Nur 1 Antwort richtig!)
A) Du suchst nach Pakete mit SYN Flag ohne ACK und nach Retransmissions davon mit der Source IP von dem Sende PC und Ziel TCP-Port 4840 (OPC UA).
Anschließend suchst du in der Netzwerkinventarisierungssoftware nach den Ziel IP Adressen und du kennst anschließend den Switchport.
B) Du suchst mit arp -a die Arp Table ab und machst vorher einen IP Scan über das /22 Netzwerk.
C) Du filterst nach ARP Requests im Netzwerk mit der ARP Sende-IP des OPC UA Client-Rechners und hältst nach ARP requests zur selben Destination ausschau die sich wiederholen.
Anschließend suchst du in der Netzwerkinventarisierungssoftware nach den IPv4 Adressen die im ARP Paket bei WHO HAS x.x.x.x vorkommt
D) Du schaust dir die Statistiken in Wireshark an und erhältst die Info wo der Sende PC verbindungen aufgebaut hat.
2 Antworten
Ich habe früher als IT-Ingenieur gearbeitet und bin heute Chief Officer auf einem Containerschiff. Trotz meiner Position an Bord übernehme ich auch weiterhin IT-seitige Aufgaben, kümmere mich um Netzwerkstörungen und sorge regelmäßig dafür, dass wir selbst in den abgelegensten Regionen der Weltmeere stabile und leistungsfähige Kommunikationsnetze auf dem Schiff haben. Gerade auf See, weit entfernt von jeder IT-Abteilung an Land, ist es entscheidend, dass jemand an Bord die Netzwerke versteht und in der Lage ist, Probleme eigenständig zu lösen und Upgrades durchzuführen.
In dem geschilderten Fall ist für mich als jemand mit dieser doppelten Erfahrung klar: Die einzige technisch saubere und zielführende Vorgehensweise ist es, mit Wireshark gezielt nach TCP-SYN-Paketen ohne SYN-ACK-Antwort zu suchen, die vom Sende-PC abgesetzt werden.
Da wir es hier mit einem /22 OT-Netzwerk ohne DNS und mehreren Server-Interfaces im DOWN-Status zu tun haben, sind weder ARP-Scans noch ARP-Table-Abfragen sinnvoll — es gibt schlicht keine Antworten von diesen Zielsystemen. ARP-Requests ins Leere und veraltete ARP-Tabellen bringen dich nicht weiter.
Mit folgendem Wireshark-Filter finde ich gezielt heraus, zu welchen IP-Adressen Verbindungsversuche erfolgen und ob Retransmissions auftreten:
Okay aber wie ich weiter unten gelesen habe ist es in IPv4 Netzwerken doch so dass zuerst ein WHO HAS TELL passieren muss bevor ein Sende PC überhaupt ein TCP SYN ausschicken kann oder habe ich da was falsch verstanden.
Sorry, ich starre jetzt seit 20 Minuten diese Frage an und obwohl ich fast alle Wörter kenne, sieht sie für mich wie Gibberish aus. Ich bin nicht mal sicher, was denn nun eigentlich gefragt ist. Entweder bin ich einfach zu schon zu lange aus dem Spiel raus oder das ist einfach nur Wortsalat...
Wie löst du Netzwerkconnectivitätsprobleme
In einem Netzwerk, in dem bis auf einen Host alle wegen defekter Hardware down sind? Ich ersetze die defekte Hardware, mit wem soll der eine(!) Überlebende denn sonst kommunizieren? (Und hoffe dann, daß ich gegen Blitzschäden versichert bin.)
in einem Layer 2 Netzwerk wenn du weißt welcher Computer das TCP SYN Frame
Gar nicht, weil TCP Layer 4 ist und deshalb auch keine Frames, sondern Segmente hat.
Kenne ich denn wenigstens den Zielport oder weiß ich nur, daß irgendeine TCP-Verbindung aufgebaut wird?
an die anderen Server im Netzwerk senden würde?
Hä? Wieso "würde"? Sendet er oder nicht? Daß sie nicht ankommen und deshalb der TCP-Handshake nicht zustande kommt, geschenkt. Aber wenn er sie nicht sendet, dann sehe ich auch nichts im Netzwerk. (Wo hänge ich eigentlich? Auch an einem kaputten Switchport? An einem funktionierenden? Ist es ein Mirroring-Port?) Und außerdem, auch wenn ich mich wiederhole: Was soll ich für Netzwerkprobleme lösen, wenn alle potentiellen Empfänger nicht erreichbar sind?
Ziel ist es die funktionalität vom Sende PC wiederherzustellen.
Welche Funktionalität ist denn verlorengegangen? Sendet er noch oder nicht? Ich würde ja sagen, das ist egal, weil ihn wegen gegrillter Hardware eh keiner hören kann, aber:
Alle anderen Maschinen/Server mit denen der Sende PC nicht kommuniziert sind egal.
Und was ist mit denen, mit denen er kommuniziert? Welche sollen das sein, wenn doch alle anderen Server down sind?
Alle Antworten beinhalten die Verwendung eines Netzwerk Sniffers Wireshark.
Nein, Antwort B nicht.
Das Netzwerk ist ein /22 OT Netzwerk
Ah, also offenbar IPv4. Auch mal gut zu wissen. Ich gestehe, von OT habe ich keine Ahnung, vielleicht ist das der Grund für meine Verwirrung. Aber IP ist IP und TCP ist TCP. Dachte ich.
und es wird NIE DNS verwendet.
Was ist NIE DNS? Ist das eine spezielle DNS-Variante, von der weder ich noch die Suchmaschine meiner Wahl jemals etwas gehört haben, oder ist bloß gemeint, daß keine Namensauflösung stattfindet?
Der Sende PC ist der einzige PC der Fix an einem Switch hängt wo es keine Interface Probleme gibt.
"Fix" im Sinne von "sicher" oder in dem Sinne, daß der Kollege gerade am Patchfeld unterwegs ist und die restlichen Server hektisch umstöpselt, auf der Suche nach einem funktionierenden Port, und die deshalb eher... volatil-variable Konnektivität haben?
Und nochmal: Wo hängt meine Maschine?
Alle anderen Server haben ein defektes Netzwerkkabel bzw. Interface am Switch im DOWN Status.
Aber die Feuerwehr ist schon fertig mit Löschen, ja? Ansonsten gehen Menschenrettung und Eigenschutz vor!
(Obwohl das Bild geil ist: RZ im Vollbrand, mehrere Löschzüge vor Ort, und der Admin sitzt im Homeoffice und versucht remote, die seltsame Häufung von Netzwerkproblemen in den Griff zu bekommen...)
Der Sende PC kommuniziert nicht mit allen Servern.
Wir hatten doch schon festgestellt, daß die gerade geschlossen wegen einer gewitterbedingten unbeabsichtigen Layer-1-Fire<sic!>wall nicht erreichbar sind. Da ist "nicht mit allen" ein Bißchen euphemistisch, oder?
Du hast keinen Zugang zur Client Applikation
Wo läuft die?
weil die OT Typisch nur mit einem Passwort zu öffnen ist das du nicht hast und auch nicht erfragen kannst weil es 2.00 am morgen ist.
Das komplette Netzwerk ist gegrillt, ich schlage mir die Nacht um die Ohren und seine hochwohlgeborene Hoheit von und zu Teamleiter darf telefonisch keine zwei Minuten aus ihrem Schönheitsschlaf gerissen werden? "Hello Sir, this is Microsoft support. We urgently need your password, Sir."
A) Du suchst nach Pakete mit SYN Flag ohne ACK und nach Retransmissions davon mit der source IP von dem Sende PC.
Dann weiß ich, mit welchen Hosts er TCP-Verbindungen aufbauen will. Wenn das die Frage war: Win. Hilft mir doch aber nichts, weil laut Aufgabenstellung aus deren Netzwerkkabeln ja gerade der Magic Smoke entfleucht.
Wireshark-Filter: "tcp.flags.syn && tcp.flags.ack == 0 && ip.src == <PC-IP>"
B) Du suchst mit arp -a die Arp Table ab und machst vorher einen IP Scan über das /22 Netzwerk.
Das kann nicht die richtige Antwort sein, denn dazu brauche ich kein Wireshark. Den IP-Sweep mache ich mit nmap und auf einem halbwegs aktuelle Linux schaue ich mir die ARP-Tabelle mit "ip nei" und nicht mit "arp -a" an. Oder reden wir von Windows? Ich hätte schon bei der Sache mit der Nachtschicht kündigen sollen...
Vorausgesetzt, das ganze /22er-Subnetz hängt in einer Broadcast-Domain, habe ich jetzt die MAC- und IP-Adressen aller Kisten, die trotz Technikbrand nach Blitzeinschlag noch erreichbar sind. Sicher nützlich, aber soweit ich die Aufgabenstellung erraten habe, nicht zielführend.
Aber wenigstens sind wir uns jetzt mit IPv4 sicher, denn IPv6 benutzt ja kein ARP.
C) Du filterst nach ARP Pakete im Netzwerk mit der Source IP des Sende Rechners und hälst nach ARP requests ausschau die sich wiederholen.
Oh, richtig. Der PC wurde ja neu gebootet und deshalb ist seine ARP-Tabelle leer. Dann wird Antwort A ins Leere laufen, wenn (und so habe ich den Sachverhalt verstanden) alle potentielle Zielrechner nicht erreichbar sind. Aber an den traurig ungehört verhallenden ARP-Requests können wir leider nicht erkennen, ob unser einziger Überlebender nach Zielen für seine mysteriösen TCP-Verbindungen sucht oder nur den NTP-Server nach der (End)Zeit fragen will.
(Und nur für den Fall, daß ich die Aufgabe falsch verstanden habe und sein Ziel außerhalb des Netzes liegt: Dann arpt er nur nach dem zuständigen Gateway, das hilft uns nicht weiter. Und selbst das setzt voraus, daß sein Netzwerkinterface manuell konfiguriert ist, denn mangels erreichbarer Server in der Broadcast-Domain wird er per DHCP nichts bekommen, und falls er auf APIPA zurückfällt <brrrr!>, kennen wir seine IP nicht. Was nicht schlimm wäre, er ist ja der einzige, der überhaupt noch was senden kann, aber die Antwort setzt voraus, daß wir seine IP kennen, deshalb...)
Falle allerdings: ARP setzt nicht auf IP auf, deshalb können wir nicht "ip.src" benutzen, sondern müssen den Filter auf die Quell-IP im ARP-Paket (oder die MAC-Adresse des PC) ansetzen.
Wireshark-Filter: "arp.opcode == 1 && arp.src.proto_ipv4 == <PC-IP>" oder "arp.opcode == 1 && eth.src == <PC-MAC>"
Sieht nach unserem Gewinner aus -- wie gesagt, falls ich die Frage richtig verstanden habe, denn jetzt wissen wir, nach wem er fragt. Aber damit haben wir ja die Konnektivität noch nicht wiederhergestellt. Weil es die Netzwerkhardware heißoxidiert hat! WLAN vielleicht? Bluetooth? IrDA (falls der Rauch nicht zu dicht ist)?
D) Du schaust dir die Statistiken in Wireshark an und erhältst die Info wo der Sende PC verbindungen aufgebaut hat.
Welche? Wireshark kann eine Menge verschiedene Statistiken anzeigen. Und ich sehe den Informationsgewinn nicht so richtig. Die Statistiken geben mir ja nicht mehr Informationen als der Packet Dump, und nachdem wir uns jetzt C) als der vermutlich richtigen Antwort genähert haben, finde ich auch keine Statistik, die uns überhaupt irgendwas hilfreiches zeigt.
Aber Moment: "wo" er Verbindungen aufgebaut hat? Ist der PC flüchtig? Ich dachte, er hängt Fix an seinem funktionierenden Switchport? Oder ist "wohin" gemeint? Außerdem, er kann doch keine Verbindungen aufbauen, sondern nur verzweifelt in die Stille rufen, weil allen anderen das Token aus dem Ring gefallen ist?
Also, falls das überhaupt eine Multiple-Choice-Frage war, würde ich C ankreuzen. Und dann verständlichere Aufgaben verlangen. Das ist doch kein Zustand so...
(Wir hatten in der Oberstufe so ein Mathebuch: Da stand bei den Aufgaben immer irgendwelches Zeug und dann keine Frage. Was sollte man da schreiben? "Aha. Schön"?)