ESP8266 steuern ohne Portweiterleitung: ein ausgehender MQTT-Pfad

Das Gerät sitzt hinter einem Heimrouter ohne Portweiterleitung und ohne öffentliche Adresse, und trotzdem muss es seine Konfiguration innerhalb von Sekunden erhalten. Der Trick ist kein Loch in der Firewall. Es ist eine Verbindung, die das Gerät nach außen zu einem Broker öffnet, den es erreichen kann, und der die Nachrichten dann über denselben aufgebauten Pfad zurückreicht. Jede Eigenschaft, die man an diesem Entwurf schätzt, und jede Falle darin stammt aus dieser Umkehrung.

Was tatsächlich durch das NAT kommt

Wenn das Gerät eine TCP-Verbindung zum Broker öffnet, legt der Heimrouter eine Zuordnung an und hält sie für die Lebensdauer des Flusses aufrecht. Antworten auf diesem Fluss kehren zum Gerät zurück, weil die Zuordnung bereits existiert. Der Broker initiiert nie etwas in Richtung Haus, also gibt es kein unaufgefordertes eingehendes Paket, das der Router abweisen müsste. Das ist das gesamte Netzwerkargument, und deshalb funktioniert der Ansatz in Netzen, die man nicht kontrolliert.

Das Gerät muss die Verbindung am Leben halten oder neu aufbauen, und das wird zur Zuverlässigkeitsfrage, sobald die Architektur feststeht.

Der Broker leitet Topics weiter, er proxyt kein HTTP

MQTT definiert Veröffentlichungs- und Abo-Austausche: Das Gerät abonniert einen Topic-Filter, den es lesen darf, und ein autorisierter Controller veröffentlicht in ein passendes Topic. Der Broker gleicht Veröffentlichungen mit Abonnements ab und stellt Kopien zu. Er weiß nicht, was eine Browseranfrage ist, und er leitet kein HTTP GET an den Webserver des Geräts weiter. Wenn die vorhandene Firmware nur HTTP spricht, braucht der Broker-Entwurf eine Anwendungsänderung oder eine bewusste Übersetzungskomponente.

Topic-Namen sind auch keine Autorisierung. Die meisten Broker unterstützen Zugriffskontrolllisten pro Client, und Geräte sollten auf ihre eigenen Veröffentlichungs- und Abo-Bäume beschränkt werden, statt einen globalen Namensraum zu teilen.

Die Geräteressourcen bestimmen die TLS-Form

Ein ESP8266 hat begrenzten RAM, und ein TLS-Handshake ist das Teuerste, was er tut. Der Arduino-Kern liefert BearSSL genau wegen dieser Einschränkung, und die Wahl zwischen der Prüfung einer CA und dem Anheften eines Fingerabdrucks verändert sowohl den Speicherbedarf als auch das, was ein Angreifer mit einem gültigen Zertifikat für einen anderen Namen tun kann. Die CA des Brokers zu prüfen ist die stärkere Option, wenn der Heap es zulässt. Auch die Nutzlastgröße zählt: Der MQTT-Client hält einen Puffer, und größere Nachrichten werden still abgeschnitten, wenn der Puffer nicht bewusst erhöht wird.

Keepalive und Socket-Timeouts gehören zum selben Budget, denn ein Client, der eine tote Verbindung nie bemerkt, bekommt keine Befehle mehr, ohne einen Fehler zu melden.

Die Nachrichtensemantik, die beißt

Eine zurückgehaltene Nachricht wird vom Broker gespeichert und späteren passenden Abonnenten zugestellt, was für den aktuellen Zustand hervorragend und für Einmalbefehle gefährlich ist: Ein Gerät, das sich neu verbindet, kann den Befehl von gestern erhalten, als wäre er neu. QoS 1 garantiert die Zustellung mindestens einmal, also sind Duplikate normal, und die Anwendung muss wiederholungssicher sein, idealerweise mit einer Kennung oder einem Zeitstempel, den sie ablehnen kann. Das letzte Testament gibt ein Statussignal, wenn das Gerät ausfällt, aber nur, wenn die Verbindung wirklich fehlschlägt und nicht hängt.

Das Verhalten einer sauberen Sitzung entscheidet, ob der Broker die Abonnements behält, während man weg ist, und genau dieser Fehler ist der Grund, warum manche Geräte nach jeder Neuverbindung die erste Nachricht verpassen.

TLS schützt die Strecke zum Broker. Es ist keine Ende-zu-Ende-Verschlüsselung der Nutzlast gegenüber dem Brokerbetreiber, der alles lesen kann, was man über ihn veröffentlicht.

Begrenze den Lebenszyklus und teste ihn mit harmlosen Daten

Plane die Neuverbindung mit Backoff statt einer engen Wiederholungsschleife, abonniere ausdrücklich neu, wenn die Sitzung nicht persistent ist, und protokolliere das Verbindungsergebnis, damit ein stilles Offline-Gerät Spuren hinterlässt. Teste den Neuverbindungspfad mit Beispielnutzlasten, die nichts tun, denn der erste Produktionstest eines Befehlskanals sollte kein echter Befehl sein. Bestätige dann, was eine veraltete zurückgehaltene Nachricht bei der Neuverbindung bewirkt, und entscheide, ob dieses Verhalten für jedes Topic akzeptabel ist.

So umgesetzt entfernt der Entwurf eine eingehende Netzwerkanforderung und lässt die Gerätesoftware, die Broker-Richtlinie und die Nachrichtensemantik als sichtbare Arbeit statt als versteckte Annahmen zurück.