ESP8266 vezérlése porttovábbítás nélkül: kifelé menő MQTT-útvonal

Az eszköz egy otthoni router mögött ül porttovábbítás és nyilvános cím nélkül, és mégis másodperceken belül meg kell kapnia a konfigurációt. A trükk nem egy lyuk a tűzfalban. Ez egy kapcsolat, amelyet az eszköz kifelé nyit egy elérhető broker felé, és az továbbítja vissza az üzeneteket ugyanazon a kiépített útvonalon. Minden tulajdonság, amit az emberek szeretnek ebben a tervezésben, és minden csapda benne, ebből a megfordításból ered.

Mi jut át valójában a NAT-on

Amikor az eszköz TCP-kapcsolatot nyit a broker felé, az otthoni router létrehoz egy leképezést, és életben tartja a folyam élettartama alatt. Az ezen a folyamon érkező válaszok visszajutnak az eszközhöz, mert a leképezés már létezik. A broker soha nem kezdeményez semmit a ház felé, így nincs olyan kéretlen bejövő csomag, amelyet a routernek el kellene utasítania. Ez az egész hálózati érv, és ezért működik a megközelítés olyan hálózatokon, amelyeket nem te irányítasz.

Az eszköznek életben kell tartania a kapcsolatot, vagy újra kell építenie, ami az architektúra rögzítése után a megbízhatóság kérdésévé válik.

A broker témákat irányít, nem HTTP-proxy

Az MQTT közzétételi és feliratkozási cseréket határoz meg: az eszköz feliratkozik egy témaszűrőre, amelyet olvashat, és egy jogosult vezérlő egy megfelelő témára tesz közzé. A broker összeveti a közzétételeket a feliratkozásokkal, és példányokat kézbesít. Nem tudja, mi a böngészőkérés, és nem továbbít HTTP GET-et az eszköz webszerverének. Ha a meglévő firmware csak HTTP-t beszél, a brokeres tervezéshez alkalmazásmódosítás vagy szándékos fordítási komponens kell.

A témák nevei sem jelentenek jogosultságot. A legtöbb broker támogatja az ügyfelenkénti hozzáférés-vezérlési listákat, és az eszközöket a saját közzétételi és feliratkozási fáikra kell korlátozni ahelyett, hogy egy globális névteret osztanának meg.

Az eszköz erőforrásai döntik el a TLS formáját

Az ESP8266 RAM-ja korlátozott, és a TLS-kézfogás a legdrágább dolog, amit tesz. Az Arduino-mag kifejezetten ezért a korlát miatt szállítja a BearSSL-t, és a CA ellenőrzése és az ujjlenyomat rögzítése közötti választás megváltoztatja a memórialábnyomot és azt is, mit tehet egy másik névre érvényes tanúsítvánnyal rendelkező támadó. A broker CA-jának ellenőrzése az erősebb lehetőség, amikor a kupac engedi. A hasznos teher mérete is számít: az MQTT-ügyfél puffert tart, és az annál nagyobb üzenetek csendben levágódnak, hacsak a puffert szándékosan nem növelik.

A keepalive és a socket-időtúllépések ugyanahhoz a költségvetéshez tartoznak, mert az az ügyfél, amely soha nem veszi észre a halott kapcsolatot, hiba jelentése nélkül hagyja abba a parancsok fogadását.

Az üzenet-szemantika, amely harap

A megtartott üzenetet a broker tárolja, és későbbi megfelelő feliratkozóknak kézbesíti, ami kiváló a jelenlegi állapothoz és veszélyes az egyszeri parancsokhoz: az újracsatlakozó eszköz megkaphatja a tegnapi parancsot, mintha új lenne. A QoS 1 legalább egyszeri kézbesítést garantál, ezért a duplikátumok normálisak, és az alkalmazásnak ismétlésbiztosnak kell lennie, ideális esetben olyan azonosítóval vagy időbélyeggel, amelyet el tud utasítani. A végrendelet állapotjelzést ad, amikor az eszköz kiesik, de csak akkor, ha a kapcsolat valóban meghiúsul, és nem lóg.

A tiszta munkamenet viselkedése dönti el, hogy a broker megtartja-e a feliratkozásaidat, míg távol vagy, és ezt elrontani az oka annak, hogy egyes eszközök minden újracsatlakozás után lemaradnak az első üzenetről.

A TLS a brokerig tartó szakaszt védi. Ez nem a hasznos teher végponttól végpontig tartó titkosítása a broker üzemeltetőjével szemben, aki mindent olvashat, amit rajta keresztül közzétesz.

Határold be az életciklust, és ártalmatlan adatokkal teszteld

Tervezd az újracsatlakozást visszalépéssel, ne szoros újrapróbálkozási ciklussal, iratkozz fel újra kifejezetten, ha a munkamenet nem tartós, és naplózd a kapcsolat eredményét, hogy a csendes, offline eszköz nyomot hagyjon. Teszteld az újracsatlakozási útvonalat olyan mintahasznos teherrel, amely semmit nem tesz, mert egy parancscsatorna első éles tesztje nem valódi parancs kell legyen. Ezután erősítsd meg, mit tesz egy elavult megtartott üzenet újracsatlakozáskor, és döntsd el, elfogadható-e ez a viselkedés minden témánál.

Így téve a tervezés eltávolít egy bejövő hálózati követelményt, és látható munkaként hagyja az eszköz szoftverét, a broker házirendjét és az üzenet-szemantikát rejtett feltevések helyett.