Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Nixcheck]

Hallo,

ich habe Iobroker ganz neu auf einem Ubuntu Webserver (Proxmox VM) installiert und würde gerne statt der IP:8081 eine Subdomain mit offiziellem Zertifikat (TLD liegt auf einem Webserver) ohne Webserver und ohne Zugriff von außen verwenden.

Dazu hatte ich den Adapter Admin installiert und den Port von 8081 auf 443 gesetzt und mit PIhole habe ich die subdomain iobroker.meine-domain.de auf die IP des Servers gesetzt.

Durch den Aufruf von https://iobroker.meine-domain.de, sollte somit auf IP:443 durchgereicht werden...

Aber... :open_mouth:
Iobroker setzt hier seltsamerweise IP:443 und erzeugt einen Fehler, wodurch nicht einmal mehr der Admin aufrufbar ist.
Nach etwas Recherche und testen, konnte ich über die Konsole wieder den Admin mit dem Port 8081 herstellen.

Kann mir bitte jemand sagen wie das mit Iobroker funktioniert, damit ich auschliesslich lokal und ohne Zugriff von außen die Subdomain mit dem entsprechenden SSL-Zertifikat verwenden kann?

Vielen Dank.

[MartinP]

@nixcheck Eine Bedingung für die Nutzung eines Ports (z.B 443) ist, dass er noch nicht bereits von einem anderen Prozess verwendet wird.
Ist das gewährleistet?

netstat -ano |grep "443"

Sagt?

[Nixcheck]

@martinp
Nix / Nada...
Gegentest: 22 & 80 sind wie erwartet belegt.

[MartinP]

@nixcheck Hmm Versuche doch mal einen anderen Nicht-Standard Port, z.B 8443.

Bei allen Beispielen, die ich bisher gesehen habe, läuft der Admin auf 8081, da sollte man ausschließen, dass es da einen Bug geben könnte, und der Admin nur auf 8081 funktioniert.

[Dr. Bakterius]

@nixcheck Ich habe das mit einer eigenen Domain über desec.io gelöst. Dort werden die Aufrufe nur mit angelegten Subdomains auf meinen Proxmox-Rechner geschickt. Alles andere läuft ins leere.

Ich habe einen LXC bei dem durch Portweiterleitungen im Router bei Aufruf von den bei desec Subdomains hin geroutet werden. Und darin läuft in einem Docker-Container der Nginx Proxy Manager der die Let`s encrypt Zertifikate verwaltet.

Der leitet dann die Anfragen je nach Subdomain an die diversen Dienste auf den LXC oder Container weiter. In ioBroker einen zweiten Admin angelegt, der per https aufgerufen wird. Für den habe ich mir ein eigenes privates Zertifikat erstellt.

So werden Anfragen per Subdomain über das Internet nur dann zu mir "durchgestellt", wenn diese bei desec angelegt wurde. Alle anderen Subdomains die in Nginx konfiguriert sind, sind nur im eigenen LAN zu erreichen.

[AlexHaxe]

Ports unterhalb von 1024 können unter Linux üblicherweise nur von root (oder anderweitig privilegierten Benutzern / Programmen) geöffnet werden.
Es gibt sicherlich Wege dies auch dem Iobroker zu erlauben, aber vermutlich ist der Einsatz eines Reverse Proxies eine empfehlenswertere Lösung.

[Homoran]

Portmanipulationen unter linux ist kein Thema für den Einstieg in ioBroker.

Ich hab das mal verschoben

[OliverIO]

@nixcheck

Ich verstehe zwar nicht für was für den Einsatz imLAN eine Transportverschlüsselung notwendig ist.

Aber so etwas würde ich mit einem Reverse Proxy machen

[Nixcheck]

@oliverio
Nun, gerade auch im Bereich Smarthome mit der heutigen Vielzahl an Unterschiedlichen Geräte und Add-Ons der unterschiedlichsten Hersteller und Protokolle, ist eine verschlüsselte Datenübertragung ein absolutes Muss.
Dann noch ein Gerät mit entsprechenden Apps im Netz, dann ist es wohl nur eine Frage der Zeit...
Somit ausschliesslich verschlüsselte Datenübertragung, alles andere ist fast schon blauäugig, oder?

@Homoran
Ich verstehe, dass das nicht gerade ein Einsteiger Thema ist.
Eine Nachfrage nach einer gesicherten Datenübertragung mit Iobroker jedoch auf "Off Topic" zu setzen, erstaunt mich doch etwas.

@All
Vielen Dank für euer Feedback.
Habe mir das mit dem Reverse Proxy für Iobroker mal angeschaut und bin fast vom Hocker gefallen, das hier für jedes Gerät bzw. für jede IP ein Eintrag gesetzt werden muss...
Das finde ich starker Tobak, um eigentlich nur mit selbstverständlichen Bordmitteln wie dem Port 443 für HTTPS auch lokal mit einem eigenen verifiziertem Domain-Zertifikat arbeiten zu können.
Das ist tatsächlich Premiere in den bisher getesteten Systemen... :thinking_face:

Wenn dem nun tatsächlich so ist, ist der Test mit Iobroker somit schon abgeschlossen bevor man überhaupt (gesichert) testen konnte.

[OliverIO]

@nixcheck sagte in Warum lässt sich der Port 8081 nicht in 443 ändern?:

@oliverio
Nun, gerade auch im Bereich Smarthome mit der heutigen Vielzahl an Unterschiedlichen Geräte und Add-Ons der unterschiedlichsten Hersteller und Protokolle, ist eine verschlüsselte Datenübertragung ein absolutes Muss.
Dann noch ein Gerät mit entsprechenden Apps im Netz, dann ist es wohl nur eine Frage der Zeit...
Somit ausschliesslich verschlüsselte Datenübertragung, alles andere ist fast schon blauäugig, oder?

um das in einem LAN abzusichern, wird normalerweise mit VLANs gearbeitet oder ganz sicher dann VPN-Tunnels.

SSL/TLS ist eine Ergänzung zum Https-Protokoll ( auch noch pop3s,ftps,imaps,smtps) und wirkt auch nur für dieses Protokolle
VLAN und und VPN wirkt auf den kompletten Netzwerkverkehr.
Bei UDP ist bspw nichts

im heimbereich ist da meistens mit günstiger hardware schon schluss. die meisten hier arbeiten dann mit vlan oder noch simpler mit netzwerksegmentierung und einrichtung von entsprechenden bridge routen

[OliverIO]

@nixcheck sagte in Warum lässt sich der Port 8081 nicht in 443 ändern?:

@All
Vielen Dank für euer Feedback.
Habe mir das mit dem Reverse Proxy für Iobroker mal angeschaut und bin fast vom Hocker gefallen, das hier für jedes Gerät bzw. für jede IP ein Eintrag gesetzt werden muss...
Das finde ich starker Tobak, um eigentlich nur mit selbstverständlichen Bordmitteln wie dem Port 443 für HTTPS auch lokal mit einem eigenen verifiziertem Domain-Zertifikat arbeiten zu können.
Das ist tatsächlich Premiere in den bisher getesteten Systemen...
Wenn dem nun tatsächlich so ist, ist der Test mit Iobroker somit schon abgeschlossen bevor man überhaupt (gesichert) testen konnte.

gerade noch den letzten absatz gesehen.
dem ist eigentlich nicht so
wenn man 1;1 nur den port umsetzt dann kann das so aussehen
https://forum.iobroker.net/topic/57534/iobroker-admin-hinter-reverseproxy-nginx

ggfs noch separat die visualisierung, vis läuft auf 8082
die ist da nicht berücksichtigt

[Homoran]

@nixcheck sagte in Warum lässt sich der Port 8081 nicht in 443 ändern?:

Eine Nachfrage nach einer gesicherten Datenübertragung mit Iobroker jedoch auf "Off Topic" zu setzen, erstaunt mich doch etwas.

das bezog sich auf

@homoran sagte in Warum lässt sich der Port 8081 nicht in 443 ändern?:

Portmanipulationen unter linux

aufgrund der damals letzten Antwort

@alexhaxe sagte in Warum lässt sich der Port 8081 nicht in 443 ändern?:

Ports unterhalb von 1024 können unter Linux üblicherweise nur von root

sowie der Diskussion um reverse Proxy / nginx.

Das hat nichts mehr mit Einstieg in die Grundlagen von ioBroker zu tun

siehe auch: https://forum.iobroker.net/topic/59411/hinweise-zu-dem-unterforum-einsteigerfragen/1

[Dr. Bakterius]

@nixcheck sagte in Warum lässt sich der Port 8081 nicht in 443 ändern?:

Das finde ich starker Tobak, um eigentlich nur mit selbstverständlichen Bordmitteln wie dem Port 443 für HTTPS auch lokal mit einem eigenen verifiziertem Domain-Zertifikat arbeiten zu können.

SSL funktioniert auch mit jedem anderen Port. Der einzige Nachteil ist, dass man dann diesen Port bei Aufruf mit angeben muss. Das ist bei Port 443 nicht notwendig. Diesen Nachteil gleicht ein Reverse Proxy mehr als aus. Der Aufruf erfolgt über Port 443 und der Proxy leitet das dann verschlüsselt oder unverschlüsselt (ganz wie man möchte) an das Endgerät mit einem beliebigen Port weiter. Wenn man vom WAN auf mehrere Geräte im LAN zugreifen möchte, dann ist ein Reverse Proxy sowieso Pflicht. Denn ein Port kann nur an ein Gerät geroutet werden. Außerdem erhöht man damit auch die Sicherheit.

[Homoran]

@Nixcheck
nach der Antwort von @Dr-Bakterius sehe ich deine Äußerungen in ganz anderem Licht.

Hast du vielleicht tatsächlich nur diese Einstellungen

in der Konfiguration übersehen?

Das würde erklären, warum du versuchst Ports auf Betriebssystemebene zu manipulieren, oder gar eine ngnx für gesicherte inhouse-Kommuninikation aufzubauen, was natürlich überdimensioniert ist.

Jedenfalls hat dich diese Richtung der Kommunikation ins OT befördert 😉