6.10.2025

MQTTS v praxi

MQTTS v praxi

Neviem, či sa tento príspevok vôbec dá nazvať blogom. V podstate budem písať o jedinej snímke obrazovky :).

Keď som pred časom písal blog MQTT v praxi, popisoval som použitie utility Stunnel na TLS kryptovanie MQTT komunikácie a tak vytvorenie MQTTS komunikácie – podobne, ako sa z HTTP dá zabalením do TLS obálky vytvoriť HTTPS.

V ďalšom blogu Komunikácia - kryptovanie som popisoval rozšírenie konfigurácie liniek typu TCP/IP-TCP a TCP/IP-TCP Redundant. V konfigurácii pribudla možnosť zadať certifikát a súkromný kľúč pre D2000 KOM proces ako aj certifikát komunikačného partnera. Pokiaľ sú zadané, D2000 KOM proces vytvorí TLS spojenie. Ak je zadaný aj certifikát komunikačného partnera, overí identitu druhej strany.

Alternatívou je zadanie zdieľaného kľúča použitého na kryptovanie komunikácie (v tomto prípade sa ale nedá overiť identita druhej strany).

Dnes teda chcem ukázať snímku obrazovky od kolegu, ktorý v novej produkčnej aplikácii nakonfiguroval linku typu TCP/IP-TCP Redundant tak, aby komunikácia bola kryptovaná. Na linke sú stanice s MQTT protokolom, pomocou ktorého sa riadi batériové úložisko PIXII.

Obrázok 1 - Konfigurácia linky TCP/IP-TCP Redundant s TLS kryptovaním.

Môžete si všimnúť cestu k certifikátom a súkromnému kľúču. Symbolická konštanta #APPDIR# sa nahradí názvom aplikačného adresára, napr. /opt/d2000/app/tlfc na platfome Linux, na ktorej je táto konkrétna aplikácia (tlfc) prevádzkovaná.

Do budúcna je ešte možné zvýšiť ochranu súkromného kľúča jeho zaheslovaním a zadaním hesla do poľa “Zdieľaný kľúč”. Pokiaľ by došlo k odcudzeniu kľúča z disku servera, ochrana heslom zredukuje možnosť jeho zneužitia.

A ďalšia novinka: Aby mohla byť na linke TCP/IP-TCP Redundant stanica s MQTT protokolom, tak do tohto protokolu musela byť podpora redundantnej TCP linky implementovaná.

To sa udialo počas leta. Aktuálne je teda možné nakonfigurovať redundantné spojenia – teda v jednom čase sa vytvárajú dve TCP spojenia, každé voči jednému MQTT brokerovi. Ak obaja MQTT brokeri nemajú certifikát podpísaný tou istou certifikačnou autoritou, je možné zadať v konfigurácii linky viacero certifikátov partnera (oddelených čiarkou); prípadne sa v CRT súbore môže nachádzať viacero certifikátov.

Načo sú dobré dve paralelné TCP spojenia voči dvom MQTT brokerom? Umožňujú na vytvorenie redundantného systému (2 x D2000 Server, 2 x MQTT broker) použiť aj jednoduchý MQTT broker typu Eclipse Mosquitto (návod na jeho konfiguráciu včítane vytvárania certifikátov a nastavenia prístupových práv je v našej dokumentácii). Nie je teda nutné použiť niektorý z komerčných MQTT brokerov, ktorí sú prepojení medzi sebou, vymieňajú si správy a vytvárajú tak MQTT cluster. Keďže D2000 KOM proces sa dokáže paralelne pripojiť k obidvom MQTT brokerom, pre iných MQTT klientov (napr. PLC) postačuje, aby sa dokázali pripojiť k jednému z nich (t.j. v konfigurácii musia mať možnosť zadať aspoň 2 IP adresy, ale v jednom čase je vytvorené iba jediné TCP spojenie na jedného z MQTT brokerov).

Mimochodom, aj D2000 KOM dokáže skúšať viacero IP adries alebo symbolických mien. Je možné ich zadať v konfigurácii linky TCP/IP-TCP alebo TCP/IP-TCP Redundant do poľa Host, oddelené čiarkou alebo bodkočiarkou. Takže ak máme dvoch redundantných MQTT brokerov, ktorí sú spolu s D2000 Servermi na dvoch redundantných sieťach, tak každý z MQTT brokerov má dve IP adresy, ktoré je možné zadať do poľa Host. V každom čase tak môžu byť otvorené dve TCP spojenia, pričom každé z nich je na jednu z dvoch IP adries redundantných MQTT brokerov.

Situácia teda bude podobná ako na nasledovnom obrázku, zapožičanom z našej dokumentácie protokolu IEC 870-5-104. SrvA a SrvB môžu reprezentovať MQTT servery, ClientC a ClientD zase D2000 Servery.

Obrázok 2 - Redundantné MQTT servery a D2000 servery na redundantných sieťach

Konfigurácia linky by vyzerala nasledovne:

Obrázok 3 - Konfigurácia MQTT spojenia na 2 redundantné MQTT servery, každý s 2 IP adresami

Ešte poznámka k redundancii D2000. Konfigurácia linky by vyzerala identicky bez ohľadu na to, či D2000 systém by bol neredundantný, alebo či by obsahoval 2, 3 alebo viac redundantných D2000 serverov. V každom prípade by nadväzoval spojenia na MQTT brokerov iba aktívny D2000 KOM proces (pripojený k aktívnemu D2000 Serveru). To isté platí aj v konfigurácii s viacerými inštančnými D2000 KOM procesmi (napr. umiestnenými na dedikovaných komunikačných serverov). V každom čase komunikuje s MQTT brokerom iba aktívna inštancia D2000 KOM procesu.

Záver

Dnešný blog ukázal dve nové vlastnosti v D2000 použité v praxi. Podpora linky typu TCP/IP-TCP Redundant v protokole MQTT ako aj podpora kryptovania na tejto linke umožňujú vytvárať redundantné a bezpečné komunikácie so zariadeniami - či už protokolom MQTT alebo inými protokolmi, napr. spomenutým IEC 870-5-104. A tak prispievať k zlepšovaniu bezpečnosti riadiacich systémov postavených na technológii aplikačného servera reálneho času Ipesoft D2000.

A čerešnička na záver: Pomocou čerstvo implementovaného tell príkazu CHECK CERTS je možné skontrolovať všetky certifikáty nakonfigurované na linkách príslušného D2000 KOM procesu. Na konzole a do logu sú vypísané časové obdobie platnosti, vydavateľ (Issuer) a subjekt (Subject). Môžete si tak jednoducho overiť, či nehrozí exspirácia niektorého z certifikátov.

26.9.2025, Ing. Peter Humaj, www.ipesoft.com

Iné blogy