Ovládanie ESP8266 bez presmerovania portov: odchádzajúca cesta MQTT

Zariadenie stojí za domácim routerom bez presmerovania portu a bez verejnej adresy, a napriek tomu musí prijať konfiguráciu v priebehu sekúnd. Trik nie je diera vo firewalle. Je to spojenie, ktoré zariadenie otvára von k brokerovi, na ktorý dosiahne, a ten potom posiela správy späť tou istou zavedenou cestou. Každá vlastnosť, ktorú ľudia na tomto dizajne milujú, aj každá pasca v ňom, pochádza z tohto obrátenia.

Čo skutočne prechádza cez NAT

Keď zariadenie otvorí TCP spojenie k brokerovi, domáci router vytvorí mapovanie a udržiava ho živé po celý čas toku. Odpovede na tomto toku sa vracajú zariadeniu, pretože mapovanie už existuje. Broker nikdy nič neiniciuje smerom k domu, takže neexistuje nevyžiadaný prichádzajúci paket, ktorý by router musel odmietnuť. To je celý sieťový argument, a preto tento prístup funguje v sieťach, ktoré neovládate.

Zariadenie musí udržiavať spojenie živé alebo ho znovu nadväzovať, čo sa po ustálení architektúry stáva otázkou spoľahlivosti.

Broker smeruje témy, neproxyuje HTTP

MQTT definuje výmeny publikovania a odberu: zariadenie sa prihlási na filter tém, ktorý smie čítať, a autorizovaný kontrolér publikuje do zodpovedajúcej témy. Broker porovnáva publikácie s odbermi a doručuje kópie. Nevie, čo je požiadavka prehliadača, a neprepošle HTTP GET webovému serveru zariadenia. Ak existujúci firmware hovorí iba HTTP, návrh s brokerom potrebuje zmenu aplikácie alebo zámernú prekladovú komponentu.

Názvy tém tiež nie sú autorizácia. Väčšina brokerov podporuje zoznamy na riadenie prístupu pre každého klienta a zariadenia by mali byť obmedzené na svoje vlastné stromy publikovania a odberu namiesto zdieľania jedného globálneho menného priestoru.

Zdroje zariadenia určujú podobu TLS

ESP8266 má obmedzenú RAM a TLS handshake je to najdrahšie, čo robí. Jadro Arduino dodáva BearSSL práve preto, lebo toto obmedzenie, a voľba medzi overovaním CA a pripnutím odtlačku mení jednak pamäťovú stopu, jednak to, čo môže urobiť útočník s platným certifikátom na iné meno. Overenie CA brokera je silnejšia možnosť, keď to halda dovolí. Na veľkosti dátovej časti tiež záleží: klient MQTT drží buffer a správy väčšie ako on sa ticho skracujú, ak sa buffer zámerne nezvýši.

Keepalive a časové limity socketu sú súčasťou toho istého rozpočtu, pretože klient, ktorý si nikdy nevšimne mŕtve spojenie, prestane prijímať príkazy bez hlásenia chyby.

Sémantika správ, ktorá hryzie

Uchovanú správu broker uloží a doručí neskorším zodpovedajúcim odberateľom, čo je vynikajúce pre aktuálny stav a nebezpečné pre jednorazové príkazy: zariadenie, ktoré sa znova pripojí, môže prijať včerajší príkaz ako nový. QoS 1 zaručuje doručenie aspoň raz, takže duplikáty sú normálne a aplikácia musí byť bezpečná pri opakovaní, ideálne s identifikátorom alebo časovou značkou, ktorú môže odmietnuť. Posledná vôľa vám dá stavový signál, keď zariadenie vypadne, ale len ak spojenie skutočne zlyhá a nevisí.

Správanie čistej relácie rozhoduje o tom, či si broker ponechá vaše odbery, kým ste preč, a chyba v tom je dôvod, prečo niektoré zariadenia zmeškajú prvú správu po každom opätovnom pripojení.

TLS chráni úsek k brokerovi. Nie je to end-to-end šifrovanie dátovej časti proti prevádzkovateľovi brokera, ktorý môže čítať všetko, čo cez neho publikujete.

Ohraničte životný cyklus a testujte ho neškodnými dátami

Plánujte opätovné pripojenie s odstupom, nie tesnou slučkou opakovaní, explicitne sa znova prihláste, ak relácia nie je trvalá, a zaznamenávajte výsledok pripojenia, aby tiché offline zariadenie zanechalo dôkaz. Otestujte cestu opätovného pripojenia vzorovými dátovými časťami, ktoré nič nerobia, pretože prvý produkčný test kanála príkazov by nemal byť skutočný príkaz. Potom overte, čo urobí zastaraná uchovaná správa pri opätovnom pripojení, a rozhodnite, či je také správanie pre každú tému prijateľné.

Takto urobený návrh odstraňuje jednu prichádzajúcu sieťovú požiadavku a necháva softvér zariadenia, politiku brokera a sémantiku správ ako viditeľnú prácu namiesto skrytých predpokladov.