Styre ESP8266 uten port forwarding: en utgående MQTT-vei
En broker som er tilgjengelig fra internett lar en enhet hjemme bli styrt over en tilkobling den selv åpnet. Hva det endrer for TLS-minne, emner og gjentakelse.
Enheten sitter bak en hjemmeruter uten port forwarding og uten offentlig adresse, og den må likevel motta konfigurasjon innen sekunder. Trikset er ikke et hull i brannmuren. Det er en tilkobling som enheten åpner utover mot en broker den kan nå, og som deretter sender meldingene tilbake langs den samme etablerte veien. Enhver egenskap folk liker ved dette designet, og enhver felle i det, kommer fra denne inverteringen.
Hva som faktisk kommer gjennom NAT
Når enheten åpner en TCP-tilkobling til brokeren, oppretter hjemmeruteren en mapping og holder den i live så lenge strømmen varer. Svar på den strømmen kommer tilbake til enheten fordi mappingen allerede finnes. Brokeren starter aldri noe mot huset, så det finnes ingen uoppfordret innkommende pakke som ruteren må avvise. Det er hele nettverksargumentet, og derfor fungerer tilnærmingen på nettverk du ikke kontrollerer.
Enheten må holde tilkoblingen i live eller gjenopprette den, noe som blir pålitelighetsspørsmålet når arkitekturen er fastlagt.
Brokeren ruter emner, den proxyer ikke HTTP
MQTT definerer utvekslinger for publisering og abonnement: enheten abonnerer på et emnefilter den har lov til å lese, og en autorisert kontroller publiserer til et samsvarende emne. Brokeren matcher publiseringer mot abonnementer og leverer kopier. Den vet ikke hva en nettleserforespørsel er, og den vil ikke videresende en HTTP GET til enhetens webserver. Hvis den eksisterende fastvaren bare snakker HTTP, trenger brokerdesignet en applikasjonsendring eller en bevisst oversettelseskomponent.
Emnenavn er heller ikke autorisasjon. De fleste brokere støtter tilgangskontrollister per klient, og enheter bør begrenses til sine egne publiserings- og abonnementstrær i stedet for å dele ett globalt navnerom.
Enhetens ressurser bestemmer TLS-formen
En ESP8266 har begrenset RAM, og et TLS-håndtrykk er det dyreste den gjør. Arduino-kjernen leverer BearSSL nettopp på grunn av denne begrensningen, og valget mellom å verifisere en CA og å pinne et fingeravtrykk endrer både minneavtrykket og hva en angriper med et gyldig sertifikat for et annet navn kan gjøre. Å verifisere brokerens CA er det sterkere alternativet når heapen tillater det. Nyttelastens størrelse betyr også noe: MQTT-klienten holder en buffer, og meldinger som er større enn den, kuttes stille med mindre bufferen økes bevisst.
Keepalive og socket-tidsavbrudd er en del av samme budsjett, fordi en klient som aldri merker en død tilkobling, slutter å motta kommandoer uten å rapportere en feil.
Meldingssemantikken som biter
En beholdt melding lagres av brokeren og leveres til senere samsvarende abonnenter, noe som er utmerket for gjeldende tilstand og farlig for engangskommandoer: en enhet som kobler til på nytt, kan motta gårsdagens kommando som om den var ny. QoS 1 garanterer levering minst én gang, så duplikater er normale, og applikasjonen må være trygg mot gjentakelse, ideelt med en identifikator eller et tidsstempel den kan avvise. Det siste testamentet gir deg et statussignal når enheten faller ut, men bare hvis tilkoblingen faktisk feiler i stedet for å henge.
Atferden til en ren sesjon avgjør om brokeren beholder abonnementene dine mens du er borte, og å gjøre det feil er grunnen til at noen enheter mister den første meldingen etter hver gjenoppkobling.
TLS beskytter strekningen til brokeren. Det er ikke ende-til-ende-kryptering av nyttelasten mot brokeroperatøren, som kan lese alt du publiserer gjennom den.
Begrens livssyklusen og test den med ufarlige data
Planlegg gjenoppkobling med backoff i stedet for en tett gjentakelsesløkke, abonner eksplisitt på nytt hvis sesjonen ikke er vedvarende, og logg tilkoblingsresultatet slik at en stille frakoblet enhet etterlater bevis. Test gjenoppkoblingsveien med eksempelnyttelaster som ikke gjør noe, fordi den første produksjonstesten av en kommandokanal ikke bør være en ekte kommando. Bekreft deretter hva en utdatert beholdt melding gjør ved gjenoppkobling, og bestem om den atferden er akseptabel for hvert emne.
Gjort på denne måten fjerner designet ett innkommende nettverkskrav og lar enhetsprogramvaren, brokerpolicyen og meldingssemantikken stå igjen som synlig arbeid i stedet for skjulte antakelser.