μthosch

Seit einiger Zeit verfolge ich die Strategie, alle Geräte, die sich nicht aus technischen gründen im gleichen (W)LAN-Segment wie unsere Rechner, Smartphones und Tablets befinden müssen, in eigenen Netzwerksegmente zu verbannen. Dabei geht es nicht nur darum, die Geräte vom restlichen (W)LAN zu treffen, sondern ihnen ggf. auch den Zugang zum Internet zu sperren.

In einem solchen isolierten Netzwerksegment ist ein Teil der Smart-Home- oder IoT-Devices gelandet. In diesem Segment ist grundsätzlich¹ der Zugang zum Internet gesperrt, um den Geräten die Möglichkeit des Nach-Hause-Telefonierens zu blockieren.

Nun gibt es bestimmte Aktionen (zwingend cloudbasierte Konfigurationsarbeiten, Firmware-Updates), die einen offenen Internetzugang notwendig machen bzw. durch diesen einfacher durchzuführen sind.

Nach dem Abschluss dieser Arbeiten aktiviere ich die entsprechende Firewall-Regel wieder. Oder auch nicht…

Damit der Zugang nicht tage- oder wochenlang offen bleibt, musste ein entsprechendes Monitoring her: Es muss geprüft werden, ob ein Verbindungsaufbau aus dem Subnetz zum Monitoringserver im Internet möglich ist und ggf. eine Alarmierung ausgelöst werden.

Hier bestehen zwei Anforderungen:

1. Kommt es zum erfolgreichen Verbindungsaufbau, dann ist das der fehlerhafte Zustand, der die Alarmierung iauszulöst.²
2. Der Test muss von Innen (aus dem LAN-Subnetz) nach Außen (ins Internet) erfolgen.

Als Lösung bietet sich ein Push-Monitoring im umgekehrten Modus mit Uptime Kuma an.

• Beim Push-Monitoring schickt Uptime Kuma nicht selbst Pakete, sondern erwartet einen Request auf eine URL (ähnlich wie Healthchecks.io).
• Beim umgekehrten Modus wird der erfolgreiche Verbindungsaufbau als Fehler gewertet.

Bereits der zweite Punkt entscheidet die Wahl zu Gunsten von Uptime Kuma, weil der umgekehrte Modus hier entscheidend ist, und meine sonst für Push-Monitoring bevorzugte Lösung Healthcheks.io dies nicht bietet. Hinzu kommt, dass Uptime Kuma die Option bietet, bei dauerhaft nicht erfolgreichen Checks mehrfach Benachrichtigungen zu schicken.³

Für das Von-Innen-nach-Außen-Senden wird neben einer Monitoringlösung, die die Push-Monitoring unterstützt, eine Komponente im Subnetz benötigt, die entsprechende http(s)-Request erstellen kann. Hier habe ich mich dafür entschieden, die Script-Funktion einer bereits im Subnet vorhandenen Gen4-Shelly-Hardware zu nutzen.

Softwareseitig habe ich mir ein Script generieren lassen und dann angepasst:

/*
  Shelly Script: Periodisches Aufrufen einer Monitoring-URL
  Zweck: Dieses Script ruft in einem frei definierbaren Intervall eine vorgegebene URL per HTTP GET auf.
  Verwendung: Intervall in Sekunden in der Variable 'interval_seconds' einstellen,
             URL in der Variable 'url' anpassen.
  Hinweise: Läuft als Timer regelmäßig.
*/

let interval_seconds = 180; // Intervall in Sekunden
let url = "https://ziel-url.com/endpunkt"; // die gewünschte URL


function callUrl() {
  Shelly.call(
    "HTTP.GET",
    { url: url },
  );
}

Timer.set(
  interval_seconds * 1000,  // Sekundengenaue Vorgabe
  true,
  callUrl
);

Das Fehlerhandling und -logging in die Konsole habe ich nach der Fertigstellung entfernt.

Das Script lässt sich für jedwede Push-basierte Monitoringansätze nachnutzen bzw. anpassen.