Sterowanie ESP8266 bez przekierowania portów: wychodząca ścieżka MQTT

Urządzenie stoi za domowym routerem bez przekierowania portów i bez publicznego adresu, a mimo to musi otrzymać konfigurację w ciągu sekund. Sztuczka nie jest dziurą w zaporze ogniowej. To połączenie, które urządzenie otwiera na zewnątrz do brokera, do którego może dotrzeć, a ten następnie odsyła wiadomości tą samą ustaloną ścieżką. Każda właściwość, którą ludzie lubią w tym projekcie, i każda pułapka w nim, bierze się z tego odwrócenia.

Co faktycznie przechodzi przez NAT

Gdy urządzenie otwiera połączenie TCP do brokera, domowy router tworzy mapowanie i utrzymuje je przez cały czas trwania przepływu. Odpowiedzi na tym przepływie wracają do urządzenia, ponieważ mapowanie już istnieje. Broker nigdy nie inicjuje niczego w stronę domu, więc nie ma niechcianego pakietu przychodzącego, który router musiałby odrzucić. To cały argument sieciowy i dlatego to podejście działa w sieciach, których nie kontrolujesz.

Urządzenie musi utrzymywać połączenie przy życiu lub je odtwarzać, co staje się kwestią niezawodności, gdy architektura jest ustalona.

Broker kieruje tematami, nie pośredniczy w HTTP

MQTT definiuje wymiany publikowania i subskrypcji: urządzenie subskrybuje filtr tematów, który wolno mu czytać, a upoważniony kontroler publikuje w pasującym temacie. Broker dopasowuje publikacje do subskrypcji i dostarcza kopie. Nie wie, czym jest żądanie przeglądarki, i nie przekaże HTTP GET do serwera WWW urządzenia. Jeśli istniejący firmware mówi tylko HTTP, projekt z brokerem wymaga zmiany aplikacji lub celowego komponentu tłumaczącego.

Nazwy tematów też nie są autoryzacją. Większość brokerów obsługuje listy kontroli dostępu dla każdego klienta, a urządzenia powinny być ograniczone do własnych drzew publikowania i subskrypcji, zamiast dzielić jedną globalną przestrzeń nazw.

Zasoby urządzenia decydują o kształcie TLS

ESP8266 ma ograniczoną RAM, a uścisk dłoni TLS jest najdroższą rzeczą, jaką wykonuje. Rdzeń Arduino dostarcza BearSSL właśnie z powodu tego ograniczenia, a wybór między weryfikacją CA a przypięciem odcisku palca zmienia zarówno ślad pamięciowy, jak i to, co może zrobić atakujący z ważnym certyfikatem na inną nazwę. Weryfikacja CA brokera jest mocniejszą opcją, gdy sterta na to pozwala. Rozmiar ładunku też ma znaczenie: klient MQTT trzyma bufor, a większe wiadomości są po cichu obcinane, chyba że bufor zostanie świadomie zwiększony.

Keepalive i limity czasu gniazda są częścią tego samego budżetu, ponieważ klient, który nigdy nie zauważy martwego połączenia, przestaje otrzymywać polecenia bez zgłaszania błędu.

Semantyka wiadomości, która gryzie

Wiadomość zatrzymana jest przechowywana przez brokera i dostarczana późniejszym pasującym subskrybentom, co jest świetne dla bieżącego stanu i niebezpieczne dla poleceń jednorazowych: urządzenie, które połączy się ponownie, może otrzymać wczorajsze polecenie tak, jakby było nowe. QoS 1 gwarantuje dostarczenie co najmniej raz, więc duplikaty są normalne, a aplikacja musi być odporna na powtórzenia, najlepiej z identyfikatorem lub znacznikiem czasu, który może odrzucić. Ostatnia wola daje sygnał stanu, gdy urządzenie wypadnie, ale tylko wtedy, gdy połączenie naprawdę zawiedzie, a nie zawiesi się.

Zachowanie czystej sesji decyduje o tym, czy broker zachowa twoje subskrypcje podczas nieobecności, i właśnie błąd w tym jest powodem, dla którego niektóre urządzenia tracą pierwszą wiadomość po każdym ponownym połączeniu.

TLS chroni odcinek do brokera. To nie jest szyfrowanie ładunku od końca do końca wobec operatora brokera, który może czytać wszystko, co przez niego publikujesz.

Ogranicz cykl życia i przetestuj go nieszkodliwymi danymi

Planuj ponowne połączenie z wycofywaniem, a nie ciasną pętlą ponowień, jawnie subskrybuj ponownie, jeśli sesja nie jest trwała, i rejestruj wynik połączenia, aby ciche urządzenie offline zostawiło dowody. Przetestuj ścieżkę ponownego połączenia przykładowymi ładunkami, które nic nie robią, ponieważ pierwszy test produkcyjny kanału poleceń nie powinien być prawdziwym poleceniem. Następnie potwierdź, co robi nieaktualna zatrzymana wiadomość przy ponownym połączeniu, i zdecyduj, czy takie zachowanie jest dopuszczalne dla każdego tematu.

Zrobiony w ten sposób projekt usuwa jeden przychodzący wymóg sieciowy i pozostawia oprogramowanie urządzenia, politykę brokera i semantykę wiadomości jako widoczną pracę zamiast ukrytych założeń.