MQTT in zakelijk product gebruiken

[Scott81]

Als vervolg op mijn vorige vraag, voor mijn IOT device (met ESP32) wat ik zelf ontwikkel en bij klanten ophang maak ik momenteel gebruik van http(s) requests.

Nu zitten hier een aantal nadelen aan en in een ander topic werd mij "geadviseerd" om eens naar MQTT te kijken.
Ik heb dit protocol al gebruikt op een ESP32 voor thuis om te communiceren met Home Assistant dus ik kan dit eventueel voor mijn huidige project ook gebruiken, echter vraag ik mij af of deze communicatie bij de meeste zakelijke klanten gebruikt kan worden.

Het kan een eis zijn om poort 1883? en 8883? niet geblokkeerd te mogen hebben, maar is dit iets wat normaal gesproken standaard geblokkeerd wordt of juist niet, m.a.w. krijg ik problemen als mijn apparaat afhankelijk gaat zijn van MQTT of werkt dit normaal gesproken altijd.

Als ik google op MQTT ports dan krijg ik poort 1883 of 80, of 8883 of 443. Wil dit zeggen dat ik MQTT ook via de standaard poort 80 of 443 kan benaderen?

Al het advies is welkom!
En alvast bedankt

[dion_b]

MQTT is een NAT-aware protocol, met uitgaande verbindingen vanaf de (IoT) device, dus exact het omgekeerde van hoe het met HTTP requests naar device zelf zou werken. Dat is waarschijnlijk waarom je de tip kreeg hiernaar te kijken: afhankelijk zijn van binnenkomende verbindingen betekent dat je nat gaat achter NAT tenzij je port forwards instelt, wat je niet wilt vanuit gebruiksgemak of trouwens security.

Clou is dus dat je de client niet hoeft te benaderen. Het is natuurlijk wel nodig dat de uitgaande verbindingen niet geblokkeerd worden. Die zullen inderdaad op 1883/8883 gebeuren. Een zeer strenge firewall houdt die dingen tegen, maar iemand die zo'n firewall draait kun je ook rustig vertellen welke verbindingen toegelaten moeten worden (bijvoorbeeld in ACL instellen dat uitgaand verkeer richting die poorten alleen naar jouw MQTT broker gaat).

[Scott81]

[b]dion_b in "MQTT in zakelijk product gebruiken"afhankelijk zijn van binnenkomende verbindingen betekent dat je nat gaat achter NAT tenzij je port forwards instelt, wat je niet wilt vanuit gebruiksgemak of trouwens security.

Gaat dit dan wel werken (eventueel met de juiste poorten ingesteld zodat mijn server benaderbaar is)?
Want vanuit de client moet mijn server benaderd worden, maar het hele idee van MQTT is toch de 2-richtingen? Nu weet ik niet direct of ik iets richting de client moet pushen maar betekend dit dat dit niet kan (of iig niet gewenst is) of begrijp ik je verkeerd?

Zodra er bijvoorbeeld een firmware update beschikbaar is zou ik de client kunnen pushen met de melding van firmware update. Of is dit niet wat je bedoeld

[Groentjuh]

Vele servers kun je natuurlijk configureren om via andere poorten te luisteren. Als je het OSI model kent, dan weet je dat op laag 4 de poorten worden geregeld. De applicatie staat daar een paar lagen boven. MQTT servers hebben doorgaans configuratie mogelijkheden om de poort waarop ze luisteren in te stellen.

Ik zou sowieso gaan voor MQTTs (MQTT over TLS) en als je dat via poort 443 wilt doen, dan zijn daar weinig technische problemen om dat te doen (zolang niets anders op poort 443 luistert).

Bij MQTT(s) maakt de client verbinding met de MQTT broker en houdt daarmee verbinding. Via de verbinding kan het berichten versturen en ontvangen.

[Scott81]

Met

(zolang niets anders op poort 443 luistert).

bedoel je ook de website (die wel op poort 443 luistert). Of staat dat hier los van?

[dion_b]

Scott81 schreef op dinsdag 14 februari 2023 @ 10:11:
[...]


Gaat dit dan wel werken (eventueel met de juiste poorten ingesteld zodat mijn server benaderbaar is)?
Want vanuit de client moet mijn server benaderd worden, maar het hele idee van MQTT is toch de 2-richtingen? Nu weet ik niet direct of ik iets richting de client moet pushen maar betekend dit dat dit niet kan (of iig niet gewenst is) of begrijp ik je verkeerd?

MQTT werkt (net zoals vergelijkbare protocollen als XMPP) met tweerichtingsverkeer binnen een uitgaande TCP thread. Dus de verbinding wordt altijd opgezet door de client. Binnen die door client opgezette verbinding kan verkeer van broker naar client verstuurd worden. Er hoeft (en kan!) dus nooit een verbinding van broker naar client opgezet worden.

Zodra er bijvoorbeeld een firmware update beschikbaar is zou ik de client kunnen pushen met de melding van firmware update. Of is dit niet wat je bedoeld

Die push gebeurt binnen een vanuit de client opgezette en opengehouden verbinding naar de broker. Als het IoT-apparaat niet altijd aan staat, zal op de broker de melding naar client vastgehouden worden totdat de client zich weer periodiek aanmeldt.

[Scott81]

Ah, ik snap nu wat je bedoeld!