Community-Lösung

UniFi auf ZimaOS: LAN-IP, Bridge-Modus und Inform-Host

A user wanted UniFi to have a 192.168.x address instead of a 172.x Docker IP; the real issue is understanding bridge, host, and Inform Host behavior.

Deine UniFi Network Application benötigt keine eigene 192.168.x.x-Adresse, nur weil Docker dem Container eine 172.x-Bridge-Adresse zuweist. Im normalen Bridge-Modus veröffentlichst du die erforderlichen Host-Ports und konfigurierst UniFi „Inform Host“ mit einem im LAN erreichbaren Hostnamen oder einer IP-Adresse. Geräte im LAN kommunizieren mit der Host-Adresse, während Docker den Container in seinem privaten Netzwerk belässt.

Im Quellthread von 2026 wurde die interne Bridge-IP des Containers mit der Adresse verwechselt, die LAN-Geräte verwenden sollen. Die aktuelle Dokumentation von LinuxServer behandelt dies ausdrücklich: Der UniFi-Container kann im Bridge-Modus bleiben, und die Geräteübernahme wird durch die Einstellung eines erreichbaren Inform Host sowie die Beibehaltung von Port 8080 ermöglicht.

Warum du eine 172.x-Adresse siehst

Docker-Bridge-Netzwerke weisen Containern normalerweise private Adressen wie 172.17.x.x zu. Diese Adresse dient der Container-Kommunikation und ist nicht die Adresse, die deine Switches und Access Points im physischen LAN verwenden müssen.

Verwende die ZimaOS-Host-IP für veröffentlichte Ports

Wenn der ZimaOS-Server 192.168.1.20 verwendet und UniFi die Ports 8443 und 8080 veröffentlicht, greifst du über den Host auf die Benutzeroberfläche und den Inform-Endpunkt zu:

https://192.168.1.20:8443
http://192.168.1.20:8080/inform

Lege den UniFi-Inform-Host fest

Die aktuelle UniFi-Dokumentation von LinuxServer besagt, dass Docker-Nutzer den Inform Host bzw. die Überschreibung auf einen für UniFi-Geräte erreichbaren Hostnamen oder eine IP-Adresse setzen sollten.

Das ist normalerweise die LAN-IP-Adresse von ZimaOS oder ein stabiler lokaler DNS-Name.

Ordne Port 8080 1:1 zu

LinuxServer weist darauf hin, dass die Kommunikation mit UniFi-Geräten 8080:8080 erwartet, sofern du nicht auch entsprechende Änderungen in den Systemeigenschaften von UniFi vornimmst. Ordne den Host-Port 18080 nicht einfach dem Container-Port 8080 zu und erwarte, dass die Geräteübernahme weiterhin stabil funktioniert.

Der Host-Modus ist nicht dasselbe wie eine eigene LAN-IP für den Container

Im Docker-Host-Modus verwendet der Container denselben Netzwerk-Namensraum wie der Host. Dadurch erhält der Container keine zweite 192.168.x.x-Adresse.

Wenn du tatsächlich eine separate LAN-IP benötigst, handelt es sich um ein macvlan-/ipvlan-Design, das zusätzliche Routing- sowie Einschränkungen bei der Kommunikation zwischen Host und Container mit sich bringt.

Der Bridge-Modus ist normalerweise die einfachere Wahl

Der Bridge-Modus hält die Anwendung isoliert, macht die Portbelegung eindeutig und funktioniert mit der dokumentierten Inform-Host-Überschreibung. Für die Übernahme und Verwaltung von Controllern ist er normalerweise ausreichend.

Denke an die Anforderung einer externen MongoDB

Die aktuelle UniFi Network Application von LinuxServer erfordert eine externe MongoDB-Instanz. Wenn der Host-Modus fehlschlägt, während der Bridge-Modus funktioniert, überprüfe, ob der Hostname der MongoDB und der Netzwerkpfad im ausgewählten Netzwerkmodus weiterhin gültig sind.

Setze den Controller nicht direkt dem Internet aus

Beschränke die Verwaltung auf das LAN oder ein privates Netzwerk für den Fernzugriff. Der Leitfaden zum privaten Netzwerk bietet den sichereren Netzwerkkontext.

Verwende eine stabile Host-Adresse

Da den übernommenen Geräten mitgeteilt wird, wo sie den Controller finden, solltest du dem ZimaOS-Host über eine DHCP-Reservierung im Router oder eine sorgfältig verwaltete statische Adresse eine stabile LAN-IP zuweisen. Wenn sich die Adresse des Controller-Hosts von 192.168.1.20 in eine andere Adresse ändert, können die Geräte weiterhin versuchen, den alten Inform-Endpunkt zu kontaktieren.

Verstehe, welche Ports welche Aufgabe haben

Die UniFi-Weboberfläche auf Port 8443 ist nur ein Teil der Konfiguration. Die Inform-Kommunikation der Geräte verwendet Port 8080, während weitere Erkennungs- und STUN-Dienste je nach Bereitstellung zusätzliche Ports nutzen. Ein Controller kann daher im Browser ordnungsgemäß erscheinen, während die Geräteübernahme fehlschlägt.

Verwende die aktuelle Porttabelle von LinuxServer und veröffentliche nur die Ports, die deine Umgebung benötigt. Die erforderlichen Ports für die Geräteverwaltung müssen jedoch exakt beibehalten werden.

Stelle die Sicherung von Synology sorgfältig wieder her

Wenn du den Controller von Synology migrierst, stelle ein UniFi-Backup erst wieder her, nachdem der neue ZimaOS-Container und die externe MongoDB ordnungsgemäß funktionieren. Überprüfe anschließend den Inform Host und den Gerätestatus, bevor du den alten Controller abschaltest.

Betreibe während der Migration nicht zwei aktive Controller, die dieselben Sites bzw. Geräte beanspruchen, es sei denn, du kennst die Folgen für die Geräteübernahme.

Wann eine dedizierte LAN-IP tatsächlich sinnvoll ist

Eine macvlan-/ipvlan-Adresse kann für eine strikte Firewall-Segmentierung, zur Vermeidung von Portkonflikten oder dafür sinnvoll sein, den Controller wie ein separates Gerät erscheinen zu lassen. Sie ist jedoch nicht erforderlich, nur weil Docker eine interne 172.x-Adresse anzeigt.

Wenn du macvlan verwendest, plane die häufige Einschränkung der Kommunikation zwischen Host und macvlan ein und überprüfe, ob MongoDB vom Controllernetzwerk aus weiterhin erreichbar ist.

FAQ

Benötigt der UniFi-Container eine 192.168-LAN-IP?

Nein. Der Bridge-Modus mit veröffentlichten Ports und einem erreichbaren Inform Host ist in vielen Bereitstellungen ausreichend.

Warum schlagen Geräteübernahmen von UniFi in Docker fehl?

Eine häufige Ursache ist, dass eine nicht erreichbare Container-IP bekanntgegeben wird. Setze den Inform Host auf die LAN-Adresse von ZimaOS oder einen anderen erreichbaren Hostnamen.

Sollte ich das Host-Netzwerk verwenden?

Nur, wenn du dafür einen konkreten Grund hast. Im Host-Modus wird das Netzwerk des ZimaOS-Hosts gemeinsam genutzt; eine dedizierte LAN-IP wird dadurch nicht erstellt.

Wann sollte ich macvlan verwenden?

Verwende macvlan nur, wenn der Container tatsächlich eine eigene Identität im LAN benötigt und du die zusätzliche Komplexität bei Routing und Host-Zugriff verstehst.