Communityoplossing

UniFi op ZimaOS: LAN-IP, bridge-modus en 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.

Je UniFi Network Application heeft geen eigen 192.168.x.x-adres nodig alleen omdat Docker de container een 172.x-bridgeadres geeft. Gebruik in de normale bridgemodus de vereiste gepubliceerde hostpoorten en configureer de Inform Host van UniFi met een hostnaam of IP-adres dat vanaf het LAN bereikbaar is. Apparaten op het LAN communiceren met het hostadres, terwijl Docker de container op zijn privénetwerk houdt.

In de brondiscussie uit 2026 werd het interne bridge-IP van de container verward met het adres dat LAN-apparaten moeten gebruiken. De huidige documentatie van LinuxServer behandelt dit expliciet: de UniFi-container kan in bridgemodus blijven werken en het koppelen van apparaten wordt geregeld door een bereikbare Inform Host in te stellen en poort 8080 te behouden.

Waarom je een 172.x-adres ziet

Docker-bridgenetwerken wijzen normaal gesproken privé-adressen toe aan containers, zoals 172.17.x.x. Dat adres is bedoeld voor containernetwerken, niet als adres dat je switches en accesspoints vanaf het fysieke LAN moeten gebruiken.

Gebruik het IP-adres van de ZimaOS-host voor gepubliceerde poorten

Als de ZimaOS-server 192.168.1.20 is en UniFi poorten 8443 en 8080 publiceert, open je de interface en het inform-eindpunt via de host:

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

Stel de UniFi Inform Host in

De huidige UniFi-documentatie van LinuxServer vermeldt dat Docker-gebruikers de Inform Host/Override moeten instellen op een hostnaam of IP-adres dat bereikbaar is voor UniFi-apparaten.

Dat is meestal het LAN-IP-adres van ZimaOS of een stabiele lokale DNS-naam.

Houd poort 8080 1-op-1 gemapt

LinuxServer waarschuwt dat UniFi-apparaatcommunicatie 8080:8080 verwacht, tenzij je ook overeenkomstige wijzigingen aanbrengt in de systeemeigenschappen van UniFi. Map niet zomaar hostpoort 18080 naar containerpoort 8080 en verwacht dat het koppelen stabiel blijft.

Hostmodus is niet hetzelfde als “de container een eigen LAN-IP geven”

In de hostmodus deelt de container de netwerknaamruimte van de host. Er wordt geen tweede 192.168.x.x-adres voor de container aangemaakt.

Als je echt een afzonderlijk LAN-IP-adres nodig hebt, is dat een macvlan/ipvlan-ontwerp. Daarbij krijg je extra aandachtspunten rond routering en communicatie tussen de host en de container.

Bridgemodus is meestal de eenvoudigste keuze

Bridgemodus houdt de app geïsoleerd, maakt poorttoewijzingen expliciet en werkt met de gedocumenteerde Inform Host-override. Voor het koppelen en beheren van de controller is dit doorgaans voldoende.

Vergeet de vereiste externe MongoDB niet

De huidige UniFi Network Application van LinuxServer vereist een externe MongoDB-instantie. Als de hostmodus niet werkt terwijl bridgemodus wel werkt, controleer dan of de MongoDB-hostnaam en het netwerkpad in de gekozen netwerkmodus geldig blijven.

Stel de controller niet rechtstreeks bloot aan internet

Houd het beheer op het LAN of achter een privénetwerk voor externe toegang. De gids voor privénetwerken biedt meer context voor veilig netwerken.

Gebruik een stabiel hostadres

Omdat gekoppelde apparaten te horen krijgen waar ze de controller kunnen vinden, moet je de ZimaOS-host een stabiel LAN-IP-adres geven via een DHCP-reservering op de router of een zorgvuldig beheerd statisch adres. Als het adres van de controllerhost verandert van 192.168.1.20 naar een ander adres, kunnen apparaten contact blijven opnemen met het oude inform-eindpunt.

Begrijp welke poorten waarvoor dienen

De UniFi-webinterface op 8443 is slechts één onderdeel. Apparaten gebruiken 8080 voor inform-verkeer en andere discovery-/STUN-services gebruiken, afhankelijk van de implementatie, aanvullende poorten. Een controller kan er in een browser dus goed uitzien, terwijl apparaten niet kunnen worden gekoppeld.

Gebruik de actuele poorttabel van LinuxServer en stel alleen de poorten bloot die je omgeving nodig heeft, maar behoud de vereiste poorten voor apparaatbeheer exact.

Herstel voorzichtig vanaf Synology

Als je de controller vanaf Synology migreert, herstel dan pas een UniFi-back-up nadat de nieuwe ZimaOS-container en externe MongoDB goed werken. Controleer daarna de Inform Host en de apparaatstatus voordat je de oude controller uitschakelt.

Laat tijdens de migratie niet twee actieve controllers dezelfde sites/apparaten claimen, tenzij je de gevolgen voor het koppelen begrijpt.

Wanneer een afzonderlijk LAN-IP-adres wél nuttig is

Een macvlan/ipvlan-adres kan nuttig zijn voor strikte firewallsegmentatie, het vermijden van poortconflicten of wanneer je wilt dat de controller zich gedraagt als een afzonderlijk apparaat. Het is niet nodig alleen omdat Docker een intern 172.x-adres toont.

Als je macvlan kiest, houd dan rekening met de gebruikelijke beperking voor communicatie tussen host en macvlan en controleer of MongoDB bereikbaar blijft vanaf het controllernetwerk.

Veelgestelde vragen

Heeft de UniFi-container een 192.168-LAN-IP-adres nodig?

Nein. Bridgemodus met gepubliceerde poorten en een bereikbare Inform Host is in veel implementaties voldoende.

Waarom kunnen UniFi-apparaten in Docker niet worden gekoppeld?

Een veelvoorkomende oorzaak is dat een onbereikbaar container-IP-adres wordt geadverteerd. Stel de Inform Host in op het LAN-adres van ZimaOS of een andere bereikbare hostnaam.

Moet ik hostnetwerken gebruiken?

Alleen als je daar een reden voor hebt. In de hostmodus wordt het netwerk van de ZimaOS-host gedeeld; er wordt geen afzonderlijk LAN-IP-adres aangemaakt.

Wanneer moet ik macvlan gebruiken?

Gebruik dit alleen wanneer de container echt een eigen LAN-identiteit nodig heeft en je de extra complexiteit rond routering en hosttoegang begrijpt.