Ovládání ESP8266 bez přesměrování portů: odchozí cesta přes MQTT

Zařízení sedí za domácím routerem bez přesměrování portu a bez veřejné adresy, a přesto musí přijmout konfiguraci během několika sekund. Trik není díra ve firewallu. Je to spojení, které zařízení otevře ven k brokerovi, na který dosáhne, a ten pak předá zprávy zpět stejnou zavedenou cestou. Každá vlastnost, kterou lidé na tomto návrhu milují, i každá past v něm, pochází z tohoto obrácení.

Co skutečně projde přes NAT

Když zařízení otevře TCP spojení k brokerovi, domácí router vytvoří mapování a udržuje je živé po celou dobu toku. Odpovědi na tomto toku se vracejí zařízení, protože mapování už existuje. Broker nikdy nic neiniciuje směrem k domovu, takže neexistuje nevyžádaný příchozí paket, který by router musel odmítnout. To je celý síťový argument a proto tento přístup funguje v sítích, které neovládáte.

Zařízení musí udržovat spojení živé, nebo je znovu navazovat, což se po ustálení architektury stává otázkou spolehlivosti.

Broker směruje témata, neproxyuje HTTP

MQTT definuje výměny publikování a odběru: zařízení se přihlásí k filtru témat, který smí číst, a autorizovaný kontroler publikuje do odpovídajícího tématu. Broker porovnává publikace s odběry a doručuje kopie. Neví, co je požadavek prohlížeče, a nepředá HTTP GET webovému serveru zařízení. Pokud stávající firmware mluví jen HTTP, návrh s brokerem potřebuje změnu aplikace nebo záměrnou překládací komponentu.

Názvy témat také nejsou autorizace. Většina brokerů podporuje seznamy pro řízení přístupu pro každého klienta a zařízení by měla být omezena na své vlastní stromy publikování a odběru, místo aby sdílela jeden globální jmenný prostor.

Zdroje zařízení určují podobu TLS

ESP8266 má omezenou RAM a TLS handshake je to nejdražší, co dělá. Jádro Arduino dodává BearSSL právě kvůli tomuto omezení a volba mezi ověřením CA a připnutím otisku mění jak paměťovou stopu, tak to, co může útočník s platným certifikátem pro jiné jméno udělat. Ověření CA brokera je silnější možnost, když to halda dovolí. Na velikosti datové části také záleží: klient MQTT drží buffer a zprávy větší než on se tiše zkracují, pokud se buffer záměrně nezvětší.

Keepalive a časové limity socketu jsou součástí stejného rozpočtu, protože klient, který si nikdy nevšimne mrtvého spojení, přestane přijímat příkazy, aniž by hlásil chybu.

Sémantika zpráv, která kouše

Uchovanou zprávu broker uloží a doručí pozdějším odpovídajícím odběratelům, což je vynikající pro aktuální stav a nebezpečné pro jednorázové příkazy: zařízení, které se znovu připojí, může přijmout včerejší příkaz, jako by byl nový. QoS 1 zaručuje doručení alespoň jednou, takže duplikáty jsou normální a aplikace musí být bezpečná při opakování, ideálně s identifikátorem nebo časovým razítkem, které může odmítnout. Poslední vůle vám dá stavový signál, když zařízení vypadne, ale jen pokud spojení skutečně selže, místo aby viselo.

Chování čisté relace rozhoduje o tom, zda si broker ponechá vaše odběry, když jste pryč, a chyba v tom je důvod, proč některá zařízení zmeškají první zprávu po každém opětovném připojení.

TLS chrání úsek k brokerovi. Není to end-to-end šifrování datové části proti provozovateli brokera, který může číst vše, co přes něj publikujete.

Ohraničte životní cyklus a testujte ho neškodnými daty

Plánujte opětovné připojení s odkladem, ne těsnou smyčkou opakování, explicitně se znovu přihlaste, pokud relace není trvalá, a zaznamenejte výsledek připojení, aby tiché offline zařízení zanechalo důkaz. Otestujte cestu opětovného připojení vzorovými datovými částmi, které nic nedělají, protože první produkční test kanálu příkazů by neměl být skutečný příkaz. Poté ověřte, co zastaralá uchovaná zpráva udělá při opětovném připojení, a rozhodněte, zda je takové chování pro každé téma přijatelné.

Takto provedený návrh odstraňuje jeden příchozí síťový požadavek a nechává software zařízení, politiku brokera a sémantiku zpráv jako viditelnou práci místo skrytých předpokladů.