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.