Netzwerküberprüfung mit PRTG - Ergebnisse korrekt umsetzen

[willy-goergen 0]

Hallo,

 

ich habe die Tage das Firmennetz auf Fehler mit Hilfe diverser Tools untersucht. Eigentlich wollte ich es ja nicht machen. Mir hat es aber keine Ruhe gelassen. Nur sollte ich als Administrator über den aktuellen Zustand bescheid wissen, meine ich. Wenn was nicht funktioniert, soll ich ja nach Möglichkeit auch in die Bresche springen. 

 

Ich habe den primären DC ein ganzes Stück weit mit Wireshark untersucht. Dort sieht es ganz gut aus. Der Verbindungsaufbau mit dem DC klappt und es werden keine Pakete verworfen.

 

Danach bin ich mit PRTG an das ganze Netzwerk gegangen. Ist echt ein klasse Werkzeug! Danke für den Tipp! :)

Haben will...

 

Mit PRTG sind zwei Dinge aufgefallen.

Einerseits wird keine Verschlüsselung innerhalb der Domäne für die Kommunikation zwischen Clients und Servern genutzt. Ich dachte jetzt an TLS 1.2. Für mich stellt sich nur die Frage was passiert, wenn ein Client den Standard vielleicht gerade nicht unterstützt? Ist dann kein Verbindungsaufbau möglich oder gibt es da eine Art Fallback-Modus? (die beiden DCs laufen mit 2008 R2, Win 2000 Domäne)

 

Andererseits ist ein sehr kleines Segment im Netzwerk aufgefallen, in dem es offenbar Verbindungsprobleme gibt. Dort liegt die Reaktionszeit der Clients auf Pings zwischen 80ms und 200ms.

Woran könnte das liegen? (Strecke zu weit?)

Bei dem Segment handelt es sich um einen Programmierarbeitsplatz für eine CNC-Maschine. Daran angeschlossen ist die Maschine selbst und das Bedienfeld. (hat jeweils alles eine eigene IP)

Dabei handelt es sich um eine einzige Leitung, die von einer der Verteilungen weiter läuft und immer weiter durchgeschliffen wird.

 

Die größeren Verteiler im Haus / Switches selbst stehen noch an. Ich meine, die müssten alle "managed" sein. Für eine Auswertung, z.B. über PTRG sind sie aber nicht konfiguriert.

 

Ich hoffe, ich habe mit meinem Beitrag das Umfeld hier im Forum nicht allzu sehr gestört. 

 

Grüße

bearbeitet 1. Juni 2015 von willy-goergen

[daabm 1.334]

Verschlüsselung: Wozu? Such mal ein wenig nach "Secure Channel" :) Oder auf deutsch: Daten des sicheren Kanals verschlüsseln - "Immer". Wenn Du generell verschlüsseln willst, bietet sich IPSec als Inbox-Lösung an.

 

Und das mit dem lahmen Segment: Naja, entweder Starkstromleitung neben dem LAN-Kabel oder Klingeldraht statt Cat5 aufwärts. Wie Du ja schon erkannt hast - "Durchschleifen" ist keine gute Lösung.

[willy-goergen 0]

Irgendwo war meine Eingangsfragestellung scheinbar nicht ganz richtig. Das ist nicht die Ursache für die Rückmeldung von PRTG.

Anbei ein Screenshot. Die Sensoren habe ich nicht selbst definiert. Sie wurden automatisch angelegt. Mit dabei eben der "komische" SSL-Sensor, der noch im BETA-Stadium ist und dem Paessler selbst offenbar keine hohe Bedeutung einräumt.

 

Mich würde interessieren, was sie damit auswerten wollen. Port 8080 ist in jedem Fall offen.

Den "Secure Channel" habe ich, erst mal testweise nur für meinen Arbeitsrechner, auch aktiviert.

 

Etwas OT: Macht es Sinn, sich durch den IT-Grundschutzkatalog des BSI zu arbeiten? Bin durch die Sache mit dem "Secure Channel" mal wieder drauf gestoßen. Ich finde die Zusammenstellung ja ganz nett. Ob man das alles berücksichtigt, sei mal dahingestellt...

bearbeitet 2. Juni 2015 von willy-goergen

[zahni 550]

Und hoffentlich hast Du Dir keinen Loop gebaut. Leg doch mal die ganzen Tools beiseite und erstelle einen vernünftigen Netzplan.

Bei Wireshark muss man schon ein wenig wissen, was dort passiert. 

[daabm 1.334]

Der Grundschutzkatalog ist was für eine längere Zugreise oder ein paar gemütliche Nachmittage im Straßencafe :)

[willy-goergen 0]

Und hoffentlich hast Du Dir keinen Loop gebaut. 

 

Was meinst du damit?

 

 

Leg doch mal die ganzen Tools beiseite und erstelle einen vernünftigen Netzplan.

 

 

Wie das Dingens aussieht, habe ich mittlerweile so halbwegs im Kopf. Vermutlich wäre eine Visualisierung des Ganzen kein größeres Problem für mich. Was an welchem Port hängt, habe ich mir mittlerweile dokumentiert, wenn zunächst auch nur handschriftlich.

 

Meinst du, ich könnte durch einen Netzplan eventuell Dinge sehen, die für mich im Moment gerade noch nicht so offensichtlich sind?

 

Mit den Tools geb ich dir schon fast recht. Hatte heute selbst schon ein Stück weit das Gefühl, dass es vielleicht ein bisschen zu viel wird. Mittlerweile kann ich bald jeden f*** in irgendeiner Form erfassen und ggf. etwas daran ändern. Die Server, das Netzwerk und, seit heute, die Switches selbst, sind alle über ihre eigene Weboberfläche zur Auswertung zu erreichen.

 

BTW @ daabm:

Ich habe die Firmware der Switches heute aktualisiert. Die war schon recht alt gewesen und es gab seitdem etliche neuere Versionen. Das scheint echt was gebracht zu haben, zumindest performancemäßig.

bearbeitet 3. Juni 2015 von willy-goergen

[zahni 550]

http://de.wikipedia.org/wiki/Switching-Loop

[willy-goergen 0]

Danke... again what learned! :)

 

Es ist ziemlich unwahrscheinlich, dass es solche "Switching-Loops" im Netzwerk gibt. Bei dem Durcheinander, das in der Produktion herrscht, würde ich es aber nicht ganz ausschließen wollen. Das gilt nach meinem Verständnis aber gerade nur für direkte Verbindungen an einem Switch, die von einem Port zu einem anderen gelegt wurden.

 

Wie kommst du jetzt drauf, dass sowas durch das Monitoring mit PTRG auf einem Server zustande kommt, wenn ich das richtig verstehe? 

bearbeitet 3. Juni 2015 von willy-goergen

[zahni 550]

Wo habe ich das geschrieben?

[willy-goergen 0]

Wo habe ich das geschrieben?

 

 

Du hast jetzt nirgends geschrieben, dass so ein Loop durch die Auswertung mit PTRG entstehen kann.

Warum und wieso kommst du da gerade überhaupt drauf? Müsste ich ggf. nochmals etwas überdenken?

bearbeitet 3. Juni 2015 von willy-goergen

[zahni 550]

Du sollst einfach prüfen, Ob Du im Netz einen Loop hast. Das doch nix mit der Software zu tun, sondern mit der Verfolgung der Kabel.

Oder Deine Switche helfen dabei. Oder eine Fachfirma...

[willy-goergen 0]

Du sollst einfach prüfen, Ob Du im Netz einen Loop hast. Das doch nix mit der Software zu tun, sondern mit der Verfolgung der Kabel.

Oder Deine Switche helfen dabei. Oder eine Fachfirma...

 

Möglicherweise helfen die Switche dabei, seit dem Update heute.

Da sollte normalerweise kein Loop sein. Den Wildwuchs in der Produktion habe ich nicht vollständig unter Kontrolle.

 

Ich hab da meine Finger drauf... glaub es oder nicht. :)

[zahni 550]

 

Da sollte normalerweise kein Loop sein. Den Wildwuchs in der Produktion habe ich nicht vollständig unter Kontrolle.

 

 

Wo hattest Du nochmal Probleme?

[willy-goergen 0]

War wieder mal sehr unglücklich von mir ausgedrückt.

 

Ich wollte eigentlich nur sagen: Recht du hast! Ich überprüfe (oder lasse es ggf. machen) das mit dem Loop nochmal und ein Netzplan scheint bei dem Durcheinander auch recht sinnvoll zu sein. 

 

Es ist schwierig in der Firma den Überblick zu behalten. Selbst die Lagepläne für Netzwerkdosen, die ich von meinem Vorgänger bekommen habe, passen durch diverse Umbauten gar nicht mehr. Teils war er sich selbst auch nicht sicher, was er da dokumentiert hat. Manche Anschlüsse tauchen doppelt und dreifach in den alten Aufzeichnungen auf, manchmal sinnigerweise mit einem Fragezeichen dahinter. Das Zeug war absolut unbrauchbar. Es hat auch niemand für nötig gehalten, die Änderungen an dem sowieso unbrauchbaren Müll fest zu halten. Als ich das vor ein paar Wochen überprüft habe, kam es mir so vor, als hätte sich damit noch überhaupt keiner auseinander gesetzt.

 

Deswegen gibt es jetzt dann z.B. den komischen Zustand, dass Dosen, die sich im gleichen Raum befinden, an zwei unterschiedlichen Verteilungen hängen. Netzwerkdose A hängt an der Zwischenverteilung im Gebäude, die sich im gleichen Raum befindet. Dose B hängt mit an der Hauptverteilung in der Verwaltung. Sowas in der Art gibt es in der Produktion an vielen Stellen. Bereiche lassen sich dort recht schlecht abgrenzen.

bearbeitet 4. Juni 2015 von willy-goergen