joetoe
Goto Top

Monitoring öffentliche IP mit PRTG

Moin.

In der Firma vor Ort führen zwei Wege ins Internet: eine Glasfaserleitung und zusätzlich DSL als Backupleitung. Glasfaser hat eine statische öffentliche IP und wird defaultmäßig genutzt. Die DSL-Leitung hat ebenfalls eine statische öffentliche IP.

Cisco ASA regelt den Verkehr auf den Anschlüssen: Bei Ausfall der Glasfaserleitung soll das langsamere DSL einspringen und sobald wieder verfügbar automatisch dem Glasfaser die Vorfahrt gewähren. Soweit die Einstellungen.

Nun möchte ich Ausfälle protokollieren, bzw. wissen, welche Leitung aktuell genutzt wird. Noch viel interessanter finde ich, nachsehen zu können, welche Leitung um 00:07 Uhr am Dienstag vor einer Woche genutzt wurde.

Wie baue ich ein solches Monitoring mit Gedächstnis gescheit auf? Die Idee ist, von einem der Clients aus die öffentliche IP getaktet abzufragen und diese abzuspeichern.

Über die Shell bekomme ich mittels
curl ifconfig.me
schonmal die public ip. Diese könnte man mit einem Zeitstempel versehen und im brauchbaren Rhythmus wegsichern.

PRTG hätte ich auch noch als am Start. Auf Anhieb hier keine Möglichkeit gefunden, die öffentliche IP zu monitoren.
Hat jemand mit PRTG ein ähnliches Konstrukt am laufen und kann helfen?
Auch eine elegantere Lösung ist natürlich herzlich willkommen.

Gruß
JoeToe

Content-ID: 3876602926

Url: https://administrator.de/contentid/3876602926

Ausgedruckt am: 04.12.2024 um 09:12 Uhr

Doskias
Lösung Doskias 08.09.2022 um 17:06:28 Uhr
Goto Top
Moin,

Mach ein ein eigenes PS-Skript, welches du im PRTG ausführst. Mit
Invoke-RestMethod -Uri http://checkip.amazonaws.com/
erhältst du deine eigene öffentliche IP.

Die Vergleichst du mit deinen vorhanden und lässt das Skript zum Beispiel einfach folgendes ausgeben:
0= fehlschlag der Abfrage
1= Glasfaser IP
2= Backup DSL IP

Dann kannst du im PRTG nachvollziehen, wann das Ergebnis 1 oder 2 war und damit, welche Leitung genutzt wurde.

Gruß
Doskias
Dani
Dani 08.09.2022 um 17:11:00 Uhr
Goto Top
Moin,
du könntest dafür den Sensor Traceroute/Hops dafür hernehmen. Damit verbunden eine Benachrichtigung für den Sensor einrichten, die sobald ausgelöst wird wenn die Hops sich ändern.


Gruß,
Dani
Coreknabe
Coreknabe 08.09.2022 um 17:18:59 Uhr
Goto Top
Moin,

schon was älter, keine Ahnung, ob noch aktuell:
https://kb.paessler.com/en/topic/21883-prtg-to-check-public-ip

Gruß
Benandi
Lösung Benandi 08.09.2022 um 21:06:18 Uhr
Goto Top
Hallo,

auch denkbar wäre (zusätzlich) das Abfragen der Sensoren "SNMP Traffic" auf der ASA für die beiden WAN-Interfaces. Wenn der Schwenk sauber funktioniert und der Ausfall früh genug erkannt wird, kann man das hinterher in den Graphen von PRTG schön sehen. Sprich, wenn der Traffic auf dem Glasfaserinterface gegen Null tendiert und zeitgleich jener des DSL-Interfaces sprunghaft ansteigt, dürfte ein Ausfall vorliegen.
Auch kannst du eine Alarmierung einrichten, falls der Traffic auf dem DSL-Interface mehr als 0,1 Kb/s (oder eine andere Schwelle) beträgt. Dann kriegst du zeitnah mit, wenn geschwenkt wurde.
Faktisch ist das eher ein Workaround bzw. ergänzt die Vorschläge der Kollegen, weil nicht die Leitung an sich überwacht wird, sondern man sich voll auf die ASA verlässt.

Was du aber zwingend berücksichtigen solltest, sofern nicht bereits im Hinterkopf:
Von wo überwachst du die Leitungen? Daran geknüpft sind je nach Methode die Möglichkeiten und blinden Stellen. Exemplarisch am Ping:
Monitoring von extern -> Ping auf beide IPs. Ein Ausfall ist nur dann sichtbar, wenn einer der beiden Router nicht mehr erreichbar ist.
Monitoring von intern -> Ping auf beide IPs. Ein Ausfall ist nur dann sichtbar, wenn das Routing von intern auf das externe Interface wegbricht oder (und nun der Witz) das Routing auf z. B. die Backupleitung schwenkt, der Ping ins WAN geht und der andere Router von extern nicht mehr ereichbar ist.
Ich hoffe, ich konnte diesbezüglich einen Denkanstoß geben. Reiner Ping ist natürlich kein probates Mittel für gutes Leitungsmonitoring. PRTG gibt da viel mehr her ;)

Basierend auf deinem eingänglichen Wunsch hat @Doskias vermutlich die sinnigste Lösung geliefert. Da kriegst du wirklich nur die IPs zurück (oder beim Totalausfall eben auch nicht).

Grüße