Gdy sterownik, czujnik albo aplikacja nie może połączyć się z brokerem, jednym z pierwszych podejrzanych jest port MQTT. Najczęściej chodzi o wybór między portem 1883 bez szyfrowania a 8883 z TLS, ale znaczenie mają też WebSockety, zapora sieciowa, adres nasłuchu i ustawienia klienta. Poniżej porządkuję te kwestie tak, aby można było szybko dobrać właściwą konfigurację i znaleźć przyczynę problemów z komunikacją.
Najważniejsze ustawienia portów MQTT w jednym miejscu
- 1883 służy zwykle do standardowej komunikacji MQTT bez szyfrowania.
- 8883 jest typowym portem dla MQTT zabezpieczonego protokołem TLS.
- WebSockety korzystają z osobnego, konfigurowalnego portu, często 8083, 8084, 8000 lub 443.
- Sam otwarty port nie wystarczy. Broker musi również nasłuchiwać na właściwym adresie.
- W instalacjach dostępnych z internetu najlepiej używać TLS, uwierzytelniania i reguł zapory.
Port 1883 czy 8883 - który wybrać
Port 1883 jest domyślnym portem dla klasycznego MQTT działającego przez TCP. Broker przyjmuje na nim połączenia klientów, a urządzenia mogą publikować dane i odbierać komunikaty w ramach tematów MQTT. To dobry wybór do testów w odizolowanej sieci lokalnej, na przykład przy pracy z ESP32, PLC albo komputerem w tej samej sieci LAN.
Problem polega na tym, że komunikacja na 1883 jest przesyłana bez szyfrowania. Hasło, dane pomiarowe i treść wiadomości mogą zostać przechwycone przez osobę mającą dostęp do odpowiedniego fragmentu sieci. Nie oznacza to, że port 1883 jest zawsze błędem, ale wystawianie go bezpośrednio do internetu uważam za bardzo ryzykowny skrót.
Port 8883 jest przeznaczony dla MQTT przez TLS, czyli połączenia szyfrowanego certyfikatem. Klient musi wtedy używać właściwego trybu SSL/TLS, a broker musi mieć skonfigurowany certyfikat, klucz prywatny i odpowiedni listener. Samo wpisanie numeru 8883 w aplikacji nie włączy zabezpieczeń, jeśli serwer nadal obsługuje zwykłe MQTT.
| Port | Transport | Szyfrowanie | Typowe zastosowanie |
|---|---|---|---|
| 1883 | MQTT przez TCP | Nie | Testy i zamknięta sieć lokalna |
| 8883 | MQTT przez TCP i TLS | Tak | Internet, instalacje produkcyjne, zdalne urządzenia |
| 8083 lub 8000 | MQTT przez WebSocket | Zależnie od konfiguracji | Aplikacje uruchamiane w przeglądarce |
| 8084 lub 443 | MQTT przez bezpieczny WebSocket | Tak, przez TLS | Przeglądarki i systemy za reverse proxy |
Numery 1883 i 8883 są standardowo kojarzone odpowiednio z komunikacją MQTT bez TLS i z MQTT zabezpieczonym TLS. Broker może jednak działać na dowolnym wolnym porcie, jeśli tak ustawisz konfigurację. Zmiana numeru nie zastępuje szyfrowania, dlatego traktuję ją wyłącznie jako element organizacji sieci, a nie zabezpieczenie.
Dlaczego WebSocket potrzebuje innego portu
Klasyczny klient MQTT, taki jak program na mikrokontrolerze lub sterownik automatyki, łączy się bezpośrednio przez TCP. Przeglądarka internetowa nie może natomiast otworzyć dowolnego gniazda TCP, dlatego stosuje się MQTT over WebSocket. Jest to MQTT przeniesione przez połączenie WebSocket, które przeglądarka potrafi obsługiwać.
Port WebSocket nie ma jednego obowiązkowego numeru. W zależności od brokera i gotowego obrazu kontenera można spotkać 8000, 8083, 8084, 443 albo inny port określony przez administratora. W dokumentacji konkretnego systemu trzeba sprawdzić nie tylko numer, lecz także ścieżkę połączenia, na przykład `/mqtt`, oraz to, czy używany jest wariant `ws://` czy `wss://`.
Wariant wss:// oznacza WebSocket zabezpieczony TLS. To właściwa opcja, gdy panel sterowania działa w przeglądarce i jest dostępny przez HTTPS. Przeglądarka często blokuje zwykłe `ws://` uruchomione z bezpiecznej strony HTTPS, więc pozornie poprawny port może nie wystarczyć do nawiązania połączenia.
Przykład konfiguracji klienta
W programie korzystającym z klasycznego MQTT podajesz adres brokera, port oraz dane logowania. Dla połączenia szyfrowanego musisz dodatkowo włączyć TLS i wskazać certyfikat urzędu certyfikacji, jeśli biblioteka tego wymaga.
broker: 192.168.1.50
port: 8883
tls: true
username: automat
password: ********Dla aplikacji przeglądarkowej ustawienia będą inne, ponieważ klient potrzebuje adresu WebSocket i ścieżki. Nie wolno mieszać portu TCP z portem WebSocket. Próba połączenia zwykłego klienta MQTT z listenerem WebSocket zwykle kończy się odrzuceniem połączenia albo komunikatem o nieprawidłowym pakiecie.
Jak poprawnie skonfigurować broker i zaporę
Najczęstszy błąd polega na otwarciu portu w routerze lub zaporze, mimo że broker nasłuchuje wyłącznie na `127.0.0.1`. Taki adres oznacza dostęp tylko z tego samego komputera. Aby urządzenia w sieci lokalnej mogły się połączyć, broker musi nasłuchiwać na adresie interfejsu LAN albo na wszystkich interfejsach, przy czym ta druga opcja wymaga szczególnie ostrożnych reguł dostępu.
W Mosquitto czytelna konfiguracja może wyglądać tak:
listener 1883 192.168.1.50
protocol mqtt
listener 8883 192.168.1.50
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.keyPrzy wdrożeniu produkcyjnym nie wystawiałbym anonimowego listenera na 1883. Lepiej ograniczyć go do sieci lokalnej lub całkowicie wyłączyć, a urządzenia zdalne kierować na 8883 z uwierzytelnianiem. Trzeba też pamiętać o trzech miejscach, w których port może być blokowany:
- zaporze systemu Linux, Windows lub urządzenia brzegowego,
- routerze wykonującym translację adresów NAT,
- regułach dostawcy chmurowego albo serwera VPS.
Jeżeli broker działa w Dockerze, port kontenera i port hosta nie muszą być takie same. Przykładowe mapowanie `1883:1883` oznacza przekazanie portu 1883 hosta do portu 1883 w kontenerze. Przy mapowaniu `31883:1883` klient z sieci łączy się z 31883, chociaż sam broker wewnątrz kontenera nadal pracuje na 1883.
Jak sprawdzić, czy port MQTT działa
Zanim zacznę zmieniać certyfikaty, biblioteki i ustawienia urządzenia, sprawdzam najpierw, czy na serwerze rzeczywiście działa listener. W systemie Linux można użyć polecenia:
ss -lntp | grep -E '1883|8883|8083|8084'Wynik powinien pokazać proces nasłuchujący na wybranym porcie. Jeśli widzisz tylko `127.0.0.1:1883`, połączenie z innego komputera nie zadziała. Adres `0.0.0.0:1883` oznacza nasłuch na wszystkich interfejsach IPv4, ale nie mówi jeszcze, czy firewall przepuszcza ruch.
Z innego urządzenia możesz wykonać prosty test dostępności TCP:
nc -vz 192.168.1.50 1883
nc -vz 192.168.1.50 8883Udane połączenie TCP nie potwierdza jeszcze poprawnej konfiguracji MQTT, ale szybko pokazuje, czy problem leży w routingu lub zaporze. Następny krok to test publikacji i subskrypcji za pomocą narzędzi Mosquitto:
mosquitto_sub -h 192.168.1.50 -p 1883 -t test/odczyt -v
mosquitto_pub -h 192.168.1.50 -p 1883 -t test/odczyt -m "18.6"Dla TLS dodaj parametry certyfikatu i użyj portu 8883. Jeżeli połączenie zostaje odrzucone, zwróć uwagę na nazwę hosta w certyfikacie, datę ważności certyfikatu oraz zgodność ustawień TLS po stronie klienta i brokera. Błąd certyfikatu nie jest tym samym co zamknięty port, choć w aplikacji oba problemy mogą wyglądać podobnie.
Przeczytaj również: Moduł SFP do switcha - jak dobrać właściwy i uniknąć problemów
Typowe objawy i ich przyczyny
| Objaw | Najbardziej prawdopodobna przyczyna | Co sprawdzić |
|---|---|---|
| Connection refused | Brak listenera lub zły port | Konfigurację brokera i wynik polecenia ss
|
| Timeout | Firewall, NAT albo błędny adres IP | Trasę, reguły zapory i dostęp z tej samej sieci |
| Błąd certyfikatu | Nieprawidłowy certyfikat lub nazwa hosta | CA, CN/SAN, datę ważności i zegar urządzenia |
| Malformed packet | Klient MQTT trafił na WebSocket lub odwrotnie | Protokół listenera, port i ścieżkę WebSocket |
| Połączenie działa lokalnie, ale nie zdalnie | Broker jest związany z localhostem albo blokuje go NAT | Adres nasłuchu, przekierowanie i firewall |
Bezpieczna konfiguracja dla automatyki i IoT
W warsztacie lub małej instalacji domowej komunikacja przez 1883 może być wystarczająca, jeśli broker pozostaje w odseparowanej sieci VLAN i nie jest dostępny z internetu. Gdy dane opuszczają lokalną sieć, wybieram TLS na 8883, indywidualne konta urządzeń i uprawnienia ograniczone do konkretnych tematów.
Warto rozdzielić urządzenia według funkcji. Czujnik temperatury nie potrzebuje prawa do publikowania w całym brokerze, a panel operatorski nie powinien automatycznie otrzymywać uprawnień administratora. Takie ograniczenia zmniejszają skutki przejęcia jednego urządzenia, szczególnie gdy pracuje ono na starszym firmware.
Nie zalecam też przekierowywania 1883 z publicznego adresu routera bez dodatkowej warstwy ochronnej. Bezpieczniejsze rozwiązania to VPN, TLS, reverse proxy dla WebSocketów albo dostęp wyłącznie przez sieć prywatną. Zmiana standardowego portu na przypadkowy numer może ograniczyć liczbę prostych skanów, ale nie zastąpi uwierzytelniania ani szyfrowania.
W instalacjach przemysłowych trzeba dodatkowo uwzględnić segmentację sieci, reguły komunikacji między sterownikami oraz wymagania utrzymania ruchu. Port powinien być otwierany tylko tam, gdzie jest potrzebny, a jego użycie dobrze odnotować w dokumentacji. Ułatwia to później diagnostykę i ogranicza ryzyko przypadkowego udostępnienia brokera.
Port MQTT dobiera się razem z trybem połączenia
Najkrótsza praktyczna odpowiedź brzmi: dla zwykłego MQTT użyj 1883, dla MQTT z TLS wybierz 8883, a dla aplikacji w przeglądarce sprawdź osobny listener WebSocket. Jeśli połączenie nie działa, zacznij od potwierdzenia portu, adresu nasłuchu i zapory, dopiero później analizuj certyfikaty oraz uprawnienia.
Sam numer portu nie określa całej konfiguracji. Liczą się jeszcze protokół, szyfrowanie, sposób uwierzytelniania i miejsce, z którego łączy się urządzenie. Takie podejście oszczędza czas, bo pozwala od razu odróżnić problem sieciowy od błędu ustawień MQTT.
