Controlul ESP8266 fără redirecționare de porturi: o cale MQTT spre exterior

Dispozitivul stă în spatele unui router de acasă fără redirecționare de porturi și fără adresă publică, și totuși trebuie să primească configurația în câteva secunde. Trucul nu este o gaură în firewall. Este o conexiune pe care dispozitivul o deschide spre exterior către un broker pe care îl poate atinge, iar acela trimite apoi mesajele înapoi pe aceeași cale deja stabilită. Fiecare proprietate care place la acest design, și fiecare capcană din el, vine din această inversare.

Ce trece de fapt prin NAT

Când dispozitivul deschide o conexiune TCP către broker, routerul casei creează o mapare și o ține vie cât durează fluxul. Răspunsurile pe acel flux se întorc la dispozitiv pentru că maparea există deja. Brokerul nu inițiază niciodată nimic spre casă, așa că nu există niciun pachet de intrare nesolicitat pe care routerul să-l respingă. Acesta este întregul argument de rețea, și de aceea abordarea funcționează în rețele pe care nu le controlezi.

Dispozitivul trebuie să mențină conexiunea vie sau să o restabilească, ceea ce devine întrebarea de fiabilitate odată ce arhitectura este stabilită.

Brokerul rută subiecte, nu face proxy HTTP

MQTT definește schimburi de publicare și abonare: dispozitivul se abonează la un filtru de subiecte pe care are voie să îl citească, iar un controler autorizat publică într-un subiect potrivit. Brokerul potrivește publicările cu abonamentele și livrează copii. Nu știe ce este o cerere de browser și nu va transmite un HTTP GET către serverul web al dispozitivului. Dacă firmware-ul existent vorbește doar HTTP, designul cu broker necesită o modificare a aplicației sau o componentă de traducere deliberată.

Nici numele subiectelor nu sunt autorizare. Majoritatea brokerelor acceptă liste de control al accesului pe client, iar dispozitivele ar trebui limitate la propriii arbori de publicare și abonare în loc să partajeze un singur spațiu global de nume.

Resursele dispozitivului decid forma TLS

ESP8266 are RAM limitată, iar strângerea de mână TLS este cel mai scump lucru pe care îl face. Nucleul Arduino furnizează BearSSL exact din cauza acestei constrângeri, iar alegerea între verificarea unei CA și fixarea unei amprente schimbă atât amprenta de memorie, cât și ce poate face un atacator cu un certificat valid pentru alt nume. Verificarea CA a brokerului este opțiunea mai puternică atunci când heap-ul permite. Și dimensiunea încărcăturii utile contează: clientul MQTT ține un buffer, iar mesajele mai mari sunt trunchiate în tăcere dacă bufferul nu este mărit intenționat.

Keepalive și timeout-urile socketului fac parte din același buget, pentru că un client care nu observă niciodată o conexiune moartă nu mai primește comenzi fără să raporteze o eroare.

Semantica mesajelor care mușcă

Un mesaj reținut este stocat de broker și livrat abonaților potriviți mai târziu, ceea ce este excelent pentru starea curentă și periculos pentru comenzile de unică folosință: un dispozitiv care se reconectează poate primi comanda de ieri ca și cum ar fi nouă. QoS 1 garantează livrarea cel puțin o dată, așa că duplicatele sunt normale și aplicația trebuie să fie sigură la repetare, ideal cu un identificator sau o marcă temporală pe care o poate respinge. Ultima voință îți dă un semnal de stare când dispozitivul cade, dar numai dacă conexiunea eșuează cu adevărat în loc să atârne.

Comportamentul sesiunii curate decide dacă brokerul îți păstrează abonamentele cât timp ești plecat, iar greșeala aici este motivul pentru care unele dispozitive pierd primul mesaj după fiecare reconectare.

TLS protejează porțiunea până la broker. Nu este criptare a încărcăturii utile de la un capăt la altul față de operatorul brokerului, care poate citi tot ce publici prin el.

Limitează ciclul de viață și testează-l cu date inofensive

Planifică reconectarea cu retragere treptată în locul unei bucle strânse de reîncercări, abonează-te din nou explicit dacă sesiunea nu este persistentă, și înregistrează rezultatul conexiunii ca un dispozitiv offline și tăcut să lase dovezi. Testează calea de reconectare cu încărcături de exemplu care nu fac nimic, pentru că primul test de producție al unui canal de comenzi nu ar trebui să fie o comandă reală. Apoi confirmă ce face un mesaj reținut învechit la reconectare, și decide dacă acel comportament este acceptabil pentru fiecare subiect.

Făcut astfel, designul elimină o cerință de rețea de intrare și lasă software-ul dispozitivului, politica brokerului și semantica mesajelor ca muncă vizibilă în loc de presupuneri ascunse.