6
SNMP Monitoring eines LAN aus dem WAN - Best practice?
Hallo zusammen,
ich plane ein LAN mit diversen Switches, NAS-Geräten, APs und LANCOM 1781VA Router per SNMP zu überwachen. Der SNMP Management Server mit PRTG befindet sich in einem RZ. Der LANCOM hängt an einem DTAG VDSL (Dual Stack).
Meine Frage ist nun: wie macht man das am Besten? Per IPv4 Port Forwarding für jedes Gerät? Per SNMP Proxy im LAN (auf einem RPi oder ähnlichem)? Per IPv6 direkt auf die globale Adresse der einzelnen Geräte? Hat das jemand schon mal gemacht und kann mir raten?
Besten Dank!
ich plane ein LAN mit diversen Switches, NAS-Geräten, APs und LANCOM 1781VA Router per SNMP zu überwachen. Der SNMP Management Server mit PRTG befindet sich in einem RZ. Der LANCOM hängt an einem DTAG VDSL (Dual Stack).
Meine Frage ist nun: wie macht man das am Besten? Per IPv4 Port Forwarding für jedes Gerät? Per SNMP Proxy im LAN (auf einem RPi oder ähnlichem)? Per IPv6 direkt auf die globale Adresse der einzelnen Geräte? Hat das jemand schon mal gemacht und kann mir raten?
Besten Dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 314044
Url: https://administrator.de/contentid/314044
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
Site-to-Site oder Client-to-Site VPN Verbindung und Regeln dafür entsprechend erstellen.
Gruß
Looser
Site-to-Site oder Client-to-Site VPN Verbindung und Regeln dafür entsprechend erstellen.
Gruß
Looser
Hallo,
richtig, das ist natürlich die beste Option ...
Vielen Dank!
richtig, das ist natürlich die beste Option ...
Vielen Dank!
Falls ein VPN nicht möglich ist, könnte man mit PRTG "Remote Probes" in den anderen Standorten arbeiten. Die Remote Probes fragen alle Geräte in dem Standort per SNMP ab, und schicken das Ergebnis an dem zentralen PRTG Server.
Hallo Kimberley,
vielen Dank für den Tip, daran hatte ich auch schon gedacht. VPN ist in der Tat schwierig, weil ich auf Seiten von AWS (dort läuft PRTG) eine feste IP als Customer Gateway des VPC brauche, die der LANCOM an diesem DTAG Anschluss nicht hat.
Experimentiert habe ich schon mit einem RPi und der PythonMiniProbe (https://github.com/PaesslerAG/PythonMiniProbe) unter Raspbian Linux. Das ist ganz vielversprechend, läuft aber leider nicht stabil und die Entwicklung scheint zu derzeit still zu stehen. Windows läuft ja auf dieser Plattform nicht, insofern wäre ich für einen Hardware-Tipp für eine Remote Probe unter Windows dankbar. Gibt es da Empfehlungen?
P.s.: Vielen Dank für die schönen Tutorials zu PRTG auf YT, wollte ich nur mal los werden.
vielen Dank für den Tip, daran hatte ich auch schon gedacht. VPN ist in der Tat schwierig, weil ich auf Seiten von AWS (dort läuft PRTG) eine feste IP als Customer Gateway des VPC brauche, die der LANCOM an diesem DTAG Anschluss nicht hat.
Experimentiert habe ich schon mit einem RPi und der PythonMiniProbe (https://github.com/PaesslerAG/PythonMiniProbe) unter Raspbian Linux. Das ist ganz vielversprechend, läuft aber leider nicht stabil und die Entwicklung scheint zu derzeit still zu stehen. Windows läuft ja auf dieser Plattform nicht, insofern wäre ich für einen Hardware-Tipp für eine Remote Probe unter Windows dankbar. Gibt es da Empfehlungen?
P.s.: Vielen Dank für die schönen Tutorials zu PRTG auf YT, wollte ich nur mal los werden.
1Experimentiert habe ich schon mit einem RPi und der PythonMiniProbe (https://github.com/PaesslerAG/PythonMiniProbe) unter Raspbian Linux. Das ist ganz vielversprechend, läuft aber leider nicht stabil und die Entwicklung scheint zu derzeit still zu stehen. Windows läuft ja auf dieser Plattform nicht, insofern wäre ich für einen Hardware-Tipp für eine Remote Probe unter Windows dankbar. Gibt es da Empfehlungen?
Eine konkrete Hardware Empfehlung haben wir leider nicht. Nur "es muss Windows sein". Diese Seite listet Hardware Anforderung für das Core Server, und die Empfehlungen für einen großeren Remote Probe wären ähnlich. Aber für einen kleinen Remote Probe wird kleinere Hardware auch gehen.
Du wirst vielleicht in Versuchung kommen, den Remote Probe auf Windows 10 IoT zu probieren. Leider unterstutzen wir Win10 IoT nicht -- es muss ein "richtiges" Windows sein.
Hast Du schon mit Tech Support Kontakt aufgenommen wegen dem Stabilitätsproblem mit dem Linux Remote Probe? Obwohl wir den Python Probe momentan nicht aktiv weiterentwickeln soll der Stand auf GitHub stabil laufen. Wir benutzen internen viele Python Probes auf dem Raspberry Pi. Vielleicht kann das Support Team mit Dir die Stabilität erhöhnen, so dass Du beim Python Probe bleiben kannst.
P.s.: Vielen Dank für die schönen Tutorials zu PRTG auf YT, wollte ich nur mal los werden.
Danke!
Eine konkrete Hardware Empfehlung haben wir leider nicht. Nur "es muss Windows sein". Diese Seite listet Hardware Anforderung für das Core Server, und die Empfehlungen für einen großeren Remote Probe wären ähnlich. Aber für einen kleinen Remote Probe wird kleinere Hardware auch gehen.
Danke dafür. Ich hatte gedacht, es gäbe vielleicht schon praktische Erfahrung mit bestimmter Hardware (Intel NUC fiele mir da beispielsweise ein). Dann muss ich selbst noch einmal schauen, aber ich bin kein Freund davon das Rad doppelt zu erfinden, deshalb die Frage ...
Du wirst vielleicht in Versuchung kommen, den Remote Probe auf Windows 10 IoT zu probieren. Leider unterstutzen wir Win10 IoT nicht -- es muss ein "richtiges" Windows sein.
In der Tat, das habe ich bereits versucht.
Hast Du schon mit Tech Support Kontakt aufgenommen wegen dem Stabilitätsproblem mit dem Linux Remote Probe? Obwohl wir den Python Probe momentan nicht aktiv weiterentwickeln soll der Stand auf GitHub stabil laufen. Wir benutzen internen viele Python Probes auf dem Raspberry Pi. Vielleicht kann das Support Team mit Dir die Stabilität erhöhnen, so dass Du beim Python Probe bleiben kannst.
Ja, ich habe unter Github an die Entwickler geschrieben. Ein Problem ist aber, dass gerade der automatisierte Scan und die Eintragung der Geräte beim Core Server mit der Linux Variante nicht implementiert ist. Da mein Projekt ein Testszenario ist, welches auch bei größeren (Kunden-)Netzen zum Einsatz kommen soll, ist das so leider nicht praxistauglich weil zu zeitintensiv. Unter Windows bringen wir schnell große Netze mit vielen Ports (Switches und Router) in das System und unter Kontrolle. Nur fehlt uns bisher eine einheitliche und kostengünstige Hardware Plattform für Windows, die wir in die Kunden-Netze bringen und dort dauerhaft in Betrieb lassen können.
1
