VPN Tunnel Status & DynDNS Status über telnet auslesen

elcravo

Neuer User
Mitglied seit
23 Jul 2014
Beiträge
8
Punkte für Reaktionen
0
Punkte
0
Hallo,

ist es möglich den ipsec Tunnel Status bzw den Status von DynDNS irgendwie über telnet auf der Shell auszugeben? Oder geht das möglicherweise sogar über UPnP?
Hintergrund ist, dass ich das in meine Nagios Monitoring einbauen will.
Im Moment mache ich das so, dass ich den Inhalt der entsprechenden lua Seite in der Fritzbox WebGUI als html parse und mir dann die Informationen da rausfiltere. Das finde ich aber unschön und außerdem funktioniert das z.B. im Fall VPN nur wenn nur eine VPN Verbindung konfiguriert ist. Zwischen mehreren VPNs kann ich nicht differenzieren.

Deshalb wäre es cool wenn ich das direkt über telnet oder eben UPnP abfragen könnte. Kennt da jemand einen Weg oder kann mich auf entsprechende Dokumentationen verweisen?
Leider unterstützt die Fritzbox ohne freetz ja kein SNMP :roll:

Viele Grüße

elcravo
 
Deshalb wäre es cool wenn ich das direkt über telnet oder eben UPnP abfragen könnte.
IPSec-Verbindungen lassen sich über die Anzahl der SAs in der Ausgabe von
Code:
cat /proc/kdsld/dsliface/internet/ipsec/assocs
mit einiger Wahrscheinlichkeit detektieren. Einfacher ist aber die Abfrage des VPN-Status (5 ist glaube ich "connected") über queries.lua (oder auch, wenn Du ein passendes Monitor-Plugin mit Login in die FB schreibst, über das Webinterface und den Aufruf von query.lua), eine mögliche VPN-Liste habe ich als Beispiel da irgendwo angeführt.

Der Status der DynDNS-Registrierung ist über "ddns:settings/account0/ip6state" bzw. "ddns:settings/account0/state" abfragbar, aber da funktioniert offenbar kein Array und jeder weitere Account bleibt "unsichtbar".

Wobei ein passendes Monitor-Plugin für das Webinterface nicht ganz trivial ist, denn je nach Frequenz der Checks sollte man (imho) ständige Logins vermeiden und lieber eine Möglichkeit der Übergabe einer gültigen SID zwischen aufeinanderfolgenden Aufrufen des Monitor-Plugins schaffen. Ansonsten schreibt man sich das Log selbst voll ... und die wirklich wichtigen Nachrichten sind dann u.U. nicht mal mehr in der täglichen Push-Mail enthalten.
[EDIT]Wenn man sich auf diesem Weg eine längerfristig verwendbare SID sichert (das kann über Tage und Wochen gehen), dann sollte man natürlich die Zugriffe auf die FRITZ!Box über HTTPS ausführen, damit ein Sniffer keine Chance hat, die SID zu erfahren und in den Pausen zwischen Abfragen per ARP-Spoofing zu mißbrauchen, ohne daß der Monitor-Server das überhaupt bemerkt.[/EDIT]

Theoretisch sollte man diese ganzen Informationen tatsächlich auch über TR-064 abfragen können (das wäre ja dann Dein UPnP), aber da kann ich nicht weiterhelfen und ich sehe ehrlich gesagt auch den Unterschied zwischen dem Parsen der Werte aus der JSON-Struktur (im Falle der query.lua) bzw. jeder anderen beliebigen Form (die Ausgabe von queries.lua kannst Du ja nach Deinen eigenen Bedürfnissen frei gestalten, wenn Du das Script anpaßt) und der Abfrage in XML-Form bei TR-064 nicht so richtig, wenn das am Ende ein Nagios-/Icinga-Plugin werden soll.

Mein eigener Monitor-Server überwacht allerdings die FRITZ!Boxen nicht aktiv (denn er sitzt bei allen überwachten Anschlüssen auf der WAN- und nicht auf der LAN-Seite), da setze ich persönlich einfach auf regelmäßige wget-Aufrufe zu einem Webserver als "Heartbeat" und dabei werden dann gleich die interessanten Statuswerte (ermittelt wie oben über queries.lua) mit übermittelt. Der Icinga-Server liest dann diese Ergebnisse mit einem aktiven Check aus einer Status-DB aus oder prüft nur die Aktualität eines passiven Check-Results, das vom Webserver über das Schreiben in die Command-Pipe gesetzt wird. Das ginge selbstverständlich auch "nach innen", denn die FB kann ja auch eine URL eines internen Servers aufrufen (ob mit wget oder nc als Tool hängt am Ende davon ab, was man zur Verfügung hat - nc ist wohl künftig bei AVM-Firmware nicht mehr dabei in der Busybox). Weil man dann keine fremden Interfaces bzw. deren Ausgaben parsen muß und die aktive Anmeldung an der Box entfällt (egal ob per Telnet oder per GUI), kann man auf diese Art u.U. leichter ein genau passendes Monitoring realisieren.

Die ganzen anderen Möglichkeiten, wie z.B. das regelmäßige Erstellen einer Statusdatei und deren Bereitstellung per 'nc' oder auch die Ausführung eines Abfrage-Scripts über eine nc-Instanz als Listener auf einem passenden Port der Box (das geht dann auch wieder ohne Login-Geraffel, denn solange da nur Abfragen möglich sind, ist das - je nach Brisanz bereitgestellter Informationen - ja harmlos), kennst Du sicherlich selbst. Ich würde in den meisten Fällen jedenfalls versuchen, ohne ein Login (und die damit notwendige Speicherung der dafür benötigten Credentials an einer (weiteren) Stelle) auszukommen. So ist dann auch der erfolgreiche oder fehlgeschlagene Abruf von Informationen gleich noch als "Host-Check" zu "mißbrauchen", während einzelne Services - dank der automatischen Abhängigkeit vom Host - dann bei komplett fehlgeschlagener Statusabfrage nicht alle einzeln "klingeln". Nach innen ist das ja problemlos möglich, solange ich noch einen Monitoring-Server im LAN hatte, habe ich das selbst auch mal so gemacht.

Wobei Du Dir natürlich genauso gut auch einen SNMP-Server im Userspace einrichten kannst, ohne gleich ein Freetz-Image verwenden zu müssen. Du kannst/mußt ja ohnehin irgendwelche Software/Scripts auf die Box bringen, dann kann das ja auch ein "SNMP-Stack" mit passenden dynamischen Abfragen von Box-Werten bei der Abfrage von eigenen OIDs sein. Ist halt unpraktischer bei der Abfrage mehrerer Einstellungen (sind dann i.d.R. mehrere Aufrufe der dynamischen Kollektoren auf der Box, je nachdem, wie man das realisiert), dafür spart man sich den - meines Erachtens aber weitaus geringeren - Aufwand der Erstellung eines passenden Plugins für das Monitor-System. Wenn man auch noch ein SNMP-basiertes Management-System am Start hat, ist natürlich der SNMP-Server im Userspace (damit meine ich eine Implementierung, die ohne direkte Zugriffe auf Kernel-Modules auskommt, wobei für den AVM-Packet-Accelerator bei manchen Boxen tatsächlich "rmon"-Statistiken geführt werden, die man über proc-Interface abfragen kann) wieder die bessere Lösung, selbst wenn man nur mit snmp-get arbeiten will/kann und keine snmp-sets verwendet.
 
Zuletzt bearbeitet:
Hallo,

vielen Dank für die ausführliche Antwort. Da sind echt sehr hilfreiche Informationen dabei.
Das hilft mr echt weiter. Danke!

Grüße

elcravo
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.