Control d'ESP8266 sense redirecció de ports: un camí de sortida MQTT

El dispositiu és darrere d'un router domèstic sense redirecció de ports i sense adreça pública, i tot i així ha de rebre la configuració en qüestió de segons. El truc no és un forat al tallafoc. És una connexió que el dispositiu obre cap a fora vers un broker al qual pot arribar, que després retorna els missatges pel mateix camí ja establert. Totes les propietats que agraden d'aquest disseny, i totes les trampes que conté, vénen d'aquesta inversió.

Què passa realment pel NAT

Quan el dispositiu obre una connexió TCP cap al broker, el router de casa crea una assignació i la manté viva mentre dura el flux. Les respostes d'aquest flux tornen al dispositiu perquè l'assignació ja existeix. El broker no inicia mai res cap a la casa, de manera que no hi ha cap paquet entrant no sol·licitat que el router hagi de rebutjar. Aquest és tot l'argument de xarxa, i per això l'enfocament funciona en xarxes que no controleu.

El dispositiu ha de mantenir la connexió viva o tornar-la a establir, cosa que es converteix en la qüestió de fiabilitat un cop fixada l'arquitectura.

El broker encamina temes, no fa de proxy HTTP

MQTT defineix intercanvis de publicació i subscripció: el dispositiu se subscriu a un filtre de temes que té permís per llegir, i un controlador autoritzat publica en un tema coincident. El broker aparella les publicacions amb les subscripcions i lliura còpies. No sap què és una petició de navegador i no reenviarà un HTTP GET al servidor web del dispositiu. Si el firmware existent només parla HTTP, el disseny amb broker necessita un canvi d'aplicació o un component de traducció deliberat.

Els noms dels temes tampoc no són autorització. La majoria de brokers admeten llistes de control d'accés per client, i els dispositius s'haurien de limitar als seus propis arbres de publicació i subscripció en lloc de compartir un únic espai de noms global.

Els recursos del dispositiu decideixen la forma de TLS

L'ESP8266 té una RAM limitada, i l'encaixada de mans TLS és la cosa més cara que fa. El nucli d'Arduino inclou BearSSL precisament per aquesta restricció, i l'elecció entre verificar una CA i fixar una empremta digital canvia tant el consum de memòria com el que pot fer un atacant amb un certificat vàlid per a un altre nom. Verificar la CA del broker és l'opció més forta quan el heap ho permet. La mida de la càrrega útil també importa: el client MQTT manté un búfer, i els missatges més grans que ell es trunquen en silenci tret que el búfer s'augmenti deliberadament.

El keepalive i els temps d'espera del sòcol formen part del mateix pressupost, perquè un client que mai no nota una connexió morta deixa de rebre ordres sense informar d'un error.

La semàntica dels missatges que mossega

Un missatge retingut el guarda el broker i el lliura als subscriptors coincidents posteriors, cosa excel·lent per a l'estat actual i perillosa per a ordres d'un sol ús: un dispositiu que es reconnecta pot rebre l'ordre d'ahir com si fos nova. QoS 1 garanteix el lliurament almenys una vegada, així que els duplicats són normals i l'aplicació ha de ser segura davant de repeticions, idealment amb un identificador o una marca temporal que pugui rebutjar. L'última voluntat us dona un senyal d'estat quan el dispositiu cau, però només si la connexió falla de veritat en lloc de quedar penjada.

El comportament de sessió neta decideix si el broker conserva les vostres subscripcions mentre sou fora, i equivocar-se en això és la raó per la qual alguns dispositius perden el primer missatge després de cada reconnexió.

TLS protegeix el tram fins al broker. No és xifratge de la càrrega útil d'extrem a extrem contra l'operador del broker, que pot llegir tot el que publiqueu a través seu.

Limiteu el cicle de vida i proveu-lo amb dades innòcues

Planifiqueu la reconnexió amb retrocés en lloc d'un bucle de reintents atapeït, torneu-vos a subscriure explícitament si la sessió no és persistent, i registreu el resultat de la connexió perquè un dispositiu fora de línia i silenciós deixi proves. Proveu el camí de reconnexió amb càrregues d'exemple que no facin res, perquè la primera prova de producció d'un canal d'ordres no hauria de ser una ordre real. Després confirmeu què fa un missatge retingut obsolet en reconnectar-se, i decidiu si aquest comportament és acceptable per a cada tema.

Fet així, el disseny elimina un requisit de xarxa d'entrada i deixa el programari del dispositiu, la política del broker i la semàntica dels missatges com a feina visible en lloc d'assumpcions ocultes.