Der livespotting Repeater verbindet IP-Kameras sicher mit Monitoring, VPN und Fernwartung.
Wie ein kleiner Minicomputer aus jeder Kamera vor Ort eine fernüberwachte, fernwartbare und fernsichere Komponente unserer Infrastruktur macht — und warum das für Installation, Betrieb und Service ein echter Gamechanger ist.

Alle wichtigen livespotting Links im Treelink. #madeforlive
IP-Kameras stehen selten dort, wo es bequem ist. Sie hängen am Lifthaus im Skigebiet, auf dem Hallendach einer Industrieanlage, am Mast über dem Hafenbecken. Das Netzwerk dahinter gehört dem Kunden, nicht uns. Und die klassische Frage am Montagetag lautet immer gleich:
„Ist die Kamera jetzt eigentlich online — oder sehe ich erst morgen im Leitstand, dass irgendwas nicht stimmt?"
Genau diese Lücke schließt der livespotting Repeater. Er ist ein Raspberry Pi (Pi 4 oder Pi 5), der im Kunden-LAN sitzt, sich über verschlüsselte Tunnel mit unserer zentralen livespotting-Infrastruktur verbindet und die LAN-Kameras sicher nach außen verfügbar macht. Vor allem aber: Er sagt dem Errichter sofort vor Ort, ob die Verbindung steht, ob die Kamera erreichbar ist und ob die Bandbreite reicht. Kein Rückruf in die Zentrale, kein Blindflug.
Das Beste daran: Es ist eine einzige App, ein einziges Binary, ein einziges Gerät. Alles, was unten beschrieben wird, steckt in dieser Box.
Wer die Box öffnet — egal ob Techniker, NOC-Mitarbeiter oder Kunde — sieht keinen Konfigurations-Wust, sondern einen FlowGraph: eine kleine Topologie-Karte vom VPN-Tunnel über den Repeater bis zur Kamera.

Die grünen Kreise an den Verbindungen sagen auf einen Blick: alles steht. Wird ein Kreis rot oder orange, klickt man drauf und bekommt eine klassifizierte Fehlermeldung — kein kryptisches Log, sondern „Kamera nicht erreichbar", „VPN-Handshake fehlt" oder „Temperatur zu hoch".
Jede Box trägt ihre Live-Werte direkt im Kopf:
Unten im Footer laufen permanent die Kennzahlen der Box selbst: ID, Version, CPU, RAM, Disk, Temperatur, Uptime und ein Update-Indikator. Das ist kein Schmuck — das ist die Antwort auf „läuft das Ding sauber?", ohne sich einloggen zu müssen.
Zwei Ansichten, ein Bild. Es gibt diese Oberfläche zweimal: eine Admin-UI mit Login und allen Stellschrauben, und eine öffentliche Monitor-UI ohne Login, die nur lesen darf. Letztere ist für Kunden-Dashboards, Wartungstechniker und NOC-Großbildschirme gedacht — gleiche Optik, kein Risiko.
Das Szenario, das den Unterschied macht: Der Errichter steht auf der Leiter, die Kamera ist montiert, das Kabel liegt. Jetzt will er wissen, nicht hoffen.
Die Box macht aus sich selbst per Knopfdruck einen offenen WLAN-Hotspot (cmr-<hostname>). Der Techniker verbindet sein Handy, ruft http://10.42.0.1/ auf und sieht denselben FlowGraph wie oben — die komplette Konnektivitätsdiagnose in der Hosentasche. Kein Notebook, kein Patchkabel, kein Zugang zum Kunden-LAN nötig.
Und das ist sicher gebaut: Der Hotspot ist isoliert — die verbundenen Geräte erreichen nur den Pi (das Monitoring), nicht das Internet und nicht das Kundennetz. Außerdem beantwortet die Box die Captive-Portal-Checks von iOS und Android so, dass sich kein nerviges „Anmelden"-Popup öffnet und kein „Kein Internet"-Hinweis erscheint. Das WLAN verhält sich wie ein normales Netz, nur dass dahinter eben das Diagnose-Dashboard liegt.
Für die Praxis heißt das: Der Errichter sieht grün, bevor er die Leiter wieder runtersteigt. Steht ein Kreis auf Rot, weiß er sofort, ob es am Netzwerk, am Tunnel oder an der Kamera liegt — und kann es im selben Termin lösen.
Das zweite große Praxisproblem: Ein Pi soll an einem fremden Standort installiert werden, den man vom eigenen Setup-LAN aus gar nicht erreicht. Sobald man die Zielnetz-Adresse setzt, fliegt der Pi aus dem eigenen Netz — und man kann weder den VPN-Handshake bestätigen noch die (noch gar nicht angeschlossenen) Kameras testen.
Die Lösung ist die Erst-Einrichtung — ein geführter 5-Schritt-Wizard.

Man konfiguriert die Box bequem am Schreibtisch komplett vor — Netzwerk, WireGuard, optional OpenVPN, alle Kameras mit ihren Port-Weiterleitungen — und der Wizard speichert alles, ohne es sofort scharfzuschalten. Erst beim ersten Boot am Zielstandort wird die Konfiguration aktiv, und zwar in der richtigen Reihenfolge: Kameras zuerst, dann die Tunnel, das Netzwerk als allerletztes (weil das die Verbindung kontrolliert umlegt).
Am Ende zeigt der Wizard den WireGuard-Public-Key des Pi an — den braucht der Hub-Admin, um den Pi als Peer freizuschalten. Vor Ort heißt es dann nur noch: anstecken, Strom dran, fertig.
Brownfield-freundlich: Läuft auf dem Pi schon eine alte, per Bash-Skript gebaute VPN-Konfiguration, übernimmt der Wizard sie sauber, statt sie zu zerstören — inklusive Snapshot der bestehenden Firewall-Regeln als Rettungsanker.
Das Herz der Box ist die VPN-Bridge. Sie kann bis zu vier Tunnel gleichzeitig fahren: WireGuard primär und sekundär (wg0/wg1) sowie OpenVPN primär und sekundär (tun0/tun1). Jeder Tunnel läuft als eigener Systemdienst und übersteht damit auch einen Absturz der App selbst.

Die Konfiguration ist bewusst zugänglich gehalten: Man kann eine fertige wg-quick- oder .ovpn-Konfiguration einfach hineinkopieren, und die Felder füllen sich automatisch. Den privaten Schlüssel erzeugt die Box selbst, sodass das Geheimnis das Gerät nie verlässt.
Auf der LAN-Seite (eth0) beherrscht die Box vollwertiges Dual-Stack (IPv4 + IPv6), statische und DHCP-Adressen, zusätzliche Aliase und — besonders wichtig — einen 30-Sekunden-Trial-Commit mit Auto-Rollback.
Dieser Trial-Commit ist ein Sicherheitsnetz, das man erst zu schätzen weiß, wenn man sich schon mal selbst ausgesperrt hat: Ändert man die Netzwerkeinstellungen, bekommt die neue Konfiguration 30 Sekunden „auf Probe". Bestätigt ein Verify-Ping in dieser Zeit nicht, dass die Box noch erreichbar ist, wird automatisch auf die alte Konfiguration zurückgerollt. Ein Tippfehler in der Gateway-Adresse macht den Pi also nicht unerreichbar.
Dazu kommen kontinuierliche WAN-Messungen: RTT (Latenz zum Hub), Path-MTU und ein Sättigungs-Detektor, der aus dem tatsächlichen Durchsatz und der hinterlegten Upload-Bandbreite erkennt, wenn die Leitung am Anschlag läuft.
Damit die Zentrale die Kameras erreicht, leitet die Box deren Ports über die Tunnel weiter — sauber per nftables, parallel auf allen Interfaces (alle VPN-Tunnel und dem LAN), und das für IPv4 wie IPv6.

Im Kamera-Modal legt man pro Kamera Name, Ziel-IP und die einzelnen Weiterleitungen an — mit externem Port, internem Port und Protokoll (TCP/UDP, plus die semantischen Marker HTTP/HTTPS, die im FlowGraph das praktische Browser-Link-Icon erzeugen). Vergibt man versehentlich denselben externen Port zweimal, fängt das die Oberfläche mit einer klaren Meldung ab.
Hier wird aus „Repeater" ein echtes Monitoring-Gerät. Pro Kamera lässt sich SNMP-Polling aktivieren — und das nicht als Bastellösung, sondern mit Hersteller-Presets für Axis, Hikvision und Dahua.

Die Box liest direkt aus der Kamera: Temperatur, Link-Status und Fehler pro Minute — bei Hikvision über die Enterprise-MIB zusätzlich CPU-, RAM- und Disk-Auslastung. Diese Werte erscheinen live in der Kamera-Box im FlowGraph und werden rot markiert, sobald etwas aus dem Ruder läuft.
Das Entscheidende sind die Schwellwerte pro Kamera: Temperatur, Fehler/min, CPU %, RAM %, Disk %. Überschreitet ein Wert seine Schwelle, schreibt die Box automatisch ein Incident — und jede Box hat einen „Verlauf"-Button, der die komplette Vorfallshistorie zeigt: wann war was wie lange down, wann schlug welche Schwelle an. Das gilt nicht nur für Kameras, sondern auch für die Systemthemen (VPN-Slots, Internet, System-Updates).
Clever gelöst: Bei Axis und Dahua, wo es keine CPU/RAM/Disk-OID gibt, sind diese Schwellen still inaktiv — keine Fehlalarme aus Werten, die das Gerät gar nicht liefert.
Dazu kommt ein Link-Monitor, der über die Hersteller-APIs alle 60 Sekunden Speed und Duplex der Kamera-NIC ausliest. Fällt eine Verbindung von „1 Gbit/full" auf „100/full" oder gar „10/half", ist das oft der Frühindikator für ein verschleißendes PoE-Kabel — man sieht den Ausfall kommen, bevor das Bild ruckelt.
Besonders praktisch: Das Vendor-Auto-Setup konfiguriert eine frische Kamera über deren Hersteller-API selbst. Ein Klick im Kamera-Modal erkennt das Modell, aktiviert SNMP mit einem zufälligen Community-String, setzt den NTP-Server auf den Pi, schreibt einheitliche Video-Profile (1080p Haupt-/720p Substream, 25 fps) und schlägt direkt die passenden Port-Weiterleitungen vor. Aus Stunden manueller Kamera-Einrichtung wird ein Knopfdruck.
Eine Besonderheit für Standorte am Wasser: Mit einem aufgesteckten AIS-Empfänger wird die Box zur AIS-Empfangsstation. Sie liest die Funksätze vorbeifahrender Schiffe, dekodiert sie und zeigt im AIS-Tab eine Live-Schiffsliste (Name, Position, Kurs, Geschwindigkeit, Typ) samt Empfangsstatistik und Signalstärke — letztere mit Farbcode, was das Ausrichten der Antenne zum Kinderspiel macht. So liefert dieselbe Box neben dem Kamerabild auch gleich die Schiffsbewegungen im Bildausschnitt.
Eine Box, die an unzugänglichen Standorten jahrelang läuft, muss sich um sich selbst kümmern. Genau das tut sie.

Sicherheitsupdates installiert die Box täglich automatisch — aber nur aus dem Security-Archiv und ohne automatischen Reboot, damit nie überraschend ein Standort neu startet. Im UI sieht man, was ansteht und wann der letzte Lauf war, und kann Updates oder einen Neustart manuell auslösen. Vor jedem Update prüft die Box, ob überhaupt Internet da ist — der „Installieren"-Knopf ist offline sauber deaktiviert statt in einen Timeout zu laufen.
Die App selbst aktualisiert sich über ein A/B-Verfahren: Das neue Binary landet in einem zweiten Slot, der Umschalter erfolgt atomar, und kommt die neue Version nicht sauber hoch, schaltet die Box beim Boot automatisch auf die alte zurück. Ein fehlgeschlagenes Update legt also keinen Standort lahm.

Resilienz ist hier mehrstufig gebaut. Neben dem Hardware-Watchdog des Raspberry Pi (der Kernel- und Systemhänger abfängt) läuft ein Software-Watchdog in der App: Er probt alle 30 Sekunden das eigene /healthz und einen Disk-Schreibzugriff. Drei Fehlschläge in Folge — und die Box startet sich selbst neu, notfalls über einen direkten Kernel-Aufruf, falls sogar der normale Reboot-Befehl hängt.
Das fängt genau den fiesen Fall ab, bei dem ein Gerät zwar noch auf Ping antwortet, aber innerlich tot ist — der „ping ok, alles andere wedged"-Zustand, gegen den ein reiner Hardware-Watchdog blind ist. Der Grund eines Watchdog-Reboots wird festgehalten und im UI angezeigt, damit man hinterher weiß, was passiert ist.
Das System-Journal überlebt jeden Reboot (200 MB, 14 Tage), die letzten Fehler erscheinen direkt im UI mit roter Badge, falls in den letzten 24 Stunden etwas schiefging. Und ein Backup der kompletten Konfiguration (Datenbank, VPN-Configs, Incident- und Audit-Log) ist ein einziger Download — Wiederherstellung genauso einfach.
Weil die Box im fremden Netz steht und Tunnel in unsere Infrastruktur hält, ist Sicherheit mehrschichtig eingebaut — ohne den Betrieb zu verkomplizieren.

Wichtig und bewusst: Der SSH-Notzugang über LAN bleibt immer erhalten — falls das UI mal streikt, kommt ein Techniker vor Ort trotzdem an die Box.
Ein Detail, das im Feld Gold wert ist: Die gesamte Oberfläche — HTML, CSS, JavaScript, sogar die Schriftart — steckt im Binary. Keine externen CDN- oder Google-Fonts-Requests. Die Box funktioniert vollständig, auch wenn am Montagetag noch kein Internet anliegt. Genau dann, wenn man die Diagnose am dringendsten braucht.
Fassen wir zusammen, was diese eine Box leistet:
| Für den Errichter | Für den Betrieb | Für die Sicherheit |
|---|---|---|
| Konnektivitäts-Check vor Ort per Handy-Hotspot | Live-Monitoring von Kamera & System im FlowGraph | Mehrschichtige Firewall pro Interface |
| Geführter Wizard, Box am Schreibtisch vorkonfiguriert | SNMP-Werte, Schwellwerte & Incident-Verlauf | Gehärtetes SSH, fail2ban, Audit-Log |
| Ein-Klick-Kamera-Setup über Hersteller-API | Automatische Sicherheitsupdates | VPN-Bridge mit bis zu 4 Tunneln |
| Grün sehen, bevor man die Leiter runtersteigt | Selbstheilung per mehrstufigem Watchdog | Self-hosted, offline-fähig, keine Cloud-Abhängigkeit |
Früher war der Montagetag ein Vertrauensvorschuss: Kabel rein, hoffen, am nächsten Tag im Leitstand nachsehen. Heute steht der Errichter vor der Kamera, öffnet das Dashboard auf dem Handy und sieht, dass alles läuft — oder behebt das Problem im selben Termin. Der Betrieb bekommt obendrauf ein Gerät, das sich selbst überwacht, selbst aktualisiert und im Zweifel selbst neu startet.
Das ist keine Bastellösung auf einem Bastelrechner. Das ist eine durchdachte, getestete und gehärtete Komponente unserer Infrastruktur — in der Größe einer Zigarettenschachtel, am entscheidenden Punkt zwischen Kamera und Welt.
Technische Basis: SBC jeglicher Art, ein einzelnes Go-Binary mit eingebettetem Web-Frontend (FlowGraph), WireGuard- und OpenVPN-Tunnel, nftables-Port-Forwarding, SNMP-Polling über Standard- und Hersteller-MIBs. Zwei Oberflächen: gesicherte Admin-UI und öffentliche Read-only-Monitor-UI.

Alle wichtigen livespotting Links im Treelink. #madeforlive



