# Stacks een eigen IP-adres geven (macvlan / ipvlan) Standaard publiceert een stack poorten op de host: Vaultwarden op `8222`, Mealie op `9925`, enzovoort. Dat werkt, maar levert op den duur een lange lijst poortnummers op die je moet onthouden, en twee apps die allebei poort 8080 willen gaan niet samen. Met een **macvlan**- of **ipvlan**-netwerk krijgt een stack een eigen IP-adres in je LAN. De app draait dan gewoon op zijn eigen standaardpoort: | Zonder | Met eigen IP | |--------|--------------| | `http://192.168.1.10:8222` | `http://192.168.1.240` | | `http://192.168.1.10:9925` | `http://192.168.1.241` | Je kunt er ook per app op firewallen, en een DNS-naam aan koppelen. --- ## ⚠️ Lees dit eerst: de host bereikt zijn eigen containers niet Dit is de bekendste valkuil van macvlan. De Docker-host kan **niet** bij een container die op een macvlan-netwerk draait, en andersom ook niet. Alle andere apparaten in je netwerk kunnen dat wél. Draait Server Up op dezelfde machine als de containers, dan zie je dus: - vanaf je laptop: `http://192.168.1.240` werkt - vanaf de server zelf: `curl http://192.168.1.240` loopt vast Heb je dat nodig (bijvoorbeeld voor een healthcheck of een reverse proxy die op de host draait), maak dan een shim-interface aan op de host: ```bash # Eenmalig; vervang eth0 en de adressen door die van jouw netwerk. ip link add shim link eth0 type macvlan mode bridge ip addr add 192.168.1.239/32 dev shim ip link set shim up ip route add 192.168.1.240/28 dev shim ``` Zet dat in een systemd-unit of in `/etc/network/interfaces`, anders is het na een herstart weg. **ipvlan (l2)** heeft dit probleem niet op dezelfde manier, maar vereist wel dat je switch en router er goed mee omgaan. Werkt macvlan niet, probeer dan ipvlan. --- ## Stap 1 — Netwerk aanmaken in Server Up Ga naar **Instellingen → Netwerken → Netwerk**. Server Up kijkt zelf welk netwerk je server gebruikt en toont dat bovenaan als voorstel: interface, subnet, gateway en een vrije IP-range. Eén klik vult het hele formulier. > Die detectie werkt door heel kort een container te starten die de > netwerknamespace van de host deelt en daar de routetabel uitleest. Server Up > zelf zit in een eigen namespace en ziet anders alleen zijn eigen bridge. Lukt detecteren niet, dan vul je het met de hand in. De vier velden: | Wat | Voorbeeld | Hoe kom je eraan | |-----|-----------|------------------| | Host-interface | `eth0` | `ip -br link` op de server | | Subnet | `192.168.1.0/24` | Je router; hetzelfde subnet als de server | | Gateway | `192.168.1.1` | `ip route \| grep default` | | IP-range | `192.168.1.240/28` | Een blok dat je **buiten je DHCP-bereik** houdt | ### Hoe die vier zich tot elkaar verhouden Dit is waar het meestal misgaat, dus expliciet: ``` ┌─────────────── subnet: 192.168.1.0/24 ───────────────┐ │ │ .1 .20 ──── DHCP ──── .239 .240 ── Docker ── .255 │ │ │ │ │ gateway je laptop, telefoon, einde begin einde (je router) printer, enz. DHCP IP-range IP-range ``` - **Subnet** — precies hetzelfde als je router gebruikt. Een ander subnet betekent dat je containers niemand kunnen bereiken. - **Gateway** — je router, bijna altijd het eerste adres (`.1`). Laat je dit leeg, dan kunnen de containers wel het LAN op maar niet het internet. - **IP-range** — het deel dat Docker mag uitdelen. Dit moet **buiten** het bereik liggen dat je router via DHCP uitgeeft, anders krijgt een container hetzelfde adres als een apparaat in huis. Het einde van het subnet is meestal vrij, vandaar `.240/28`. - **Host-interface** — de netwerkkaart waar het LAN op zit. Niet die van Docker (`docker0`, `br-…`) en niet wifi. **Belangrijk:** het instellen van de range in Server Up doet niets aan je router. Je moet dáár het DHCP-bereik verkleinen, bijvoorbeeld naar `192.168.1.20` – `192.168.1.239`. Doe je dat niet, dan blijven er dubbele adressen mogelijk. Terwijl je typt controleert Server Up de combinatie en toont hoeveel adressen je overhoudt (`192.168.1.240/28` → veertien bruikbare adressen, `.241` t/m `.254`). Klopt er iets niet, dan staat er in gewone taal bij waarom. ### Veelgebruikte ranges | Subnet | Gateway | Voorstel | Ruimte | |---|---|---|---| | `192.168.1.0/24` | `192.168.1.1` | `192.168.1.240/28` | 14 stacks | | `192.168.0.0/24` | `192.168.0.1` | `192.168.0.240/28` | 14 stacks | | `10.0.0.0/24` | `10.0.0.1` | `10.0.0.240/28` | 14 stacks | | `192.168.1.0/24` | `192.168.1.1` | `192.168.1.224/27` | 30 stacks | Meer nodig? Neem een groter blok: `/27` geeft 30 adressen, `/26` geeft 62. Zorg dan wel dat je DHCP-bereik navenant kleiner wordt. ## Stap 2 — Wat Server Up ermee doet Hetzelfde met de hand zou zijn: ```bash docker network create -d macvlan \ --subnet 192.168.1.0/24 \ --gateway 192.168.1.1 \ --ip-range 192.168.1.240/28 \ -o parent=eth0 \ lan ``` ## Stap 3 — Een stack installeren op een eigen IP Kies in de installatiemodal bij **Netwerk** je netwerk in plaats van "Poorten op de host". Server Up stelt het eerstvolgende vrije adres voor; je kunt het overschrijven. Bij het installeren gebeurt er dit met het compose-bestand: ```yaml # vóór # ná services: services: vaultwarden: vaultwarden: image: vaultwarden/server image: vaultwarden/server ports: networks: - "8222:80" default: lan: ipv4_address: 192.168.1.240 networks: lan: external: true ``` De poortmapping verdwijnt — die heeft geen functie meer. Vaultwarden luistert op poort 80 en is bereikbaar op `http://192.168.1.240`. Het `default`-netwerk blijft erbij staan: zodra een container een `networks`-blok krijgt, vervalt zijn lidmaatschap van het netwerk van de stack, en dan vindt hij zijn eigen database niet meer. ### Meerdere containers, meerdere adressen Bestaat een stack uit meerdere containers, dan kies je bij **Adres per container** wie er een eigen adres krijgt. Dat hoeft niet iedereen te zijn: geef Sonarr en Radarr een adres en laat de rest op zijn hostpoort staan. **Een container die je geen adres geeft, houdt zijn poortmapping.** Dat is precies het verschil met hoe dit eerder werkte: toen raakte élke container in de stack zijn poorten kwijt zodra er één een adres kreeg, en waren de andere daarna nergens meer te bereiken. Containers met `network_mode` — de downloadclients achter een VPN — slaat Server Up over. Die delen al de namespace van een andere container, en compose weigert `network_mode` en `networks` naast elkaar. --- ## Adresbeheer Server Up bewaart het toegekende adres in `.serverup.json` in de stackmap. Zo blijft het gereserveerd, ook als de stack gestopt is, en krijgt een volgende installatie het volgende vrije adres voorgesteld. Wil je het adres van een bestaande stack wijzigen, pas dan het compose-bestand aan via **compose bewerken** en werk `ipv4_address` bij. ## Verwijderen Een netwerk kan pas weg als er geen containers meer op draaien. Stop eerst de betreffende stacks; Server Up weigert het anders met een melding. ## Problemen oplossen | Symptoom | Oorzaak | |----------|---------| | `network ... not found` bij het starten | Netwerk verwijderd terwijl de stack er nog naar verwijst — maak het opnieuw aan | | Container krijgt geen verbinding | Verkeerde `parent`-interface, of de interface zit in een bond/bridge | | Adres al in gebruik | Het adres valt binnen je DHCP-bereik; verklein de DHCP-pool of kies een andere range | | Vanaf de server niet bereikbaar, vanaf laptop wel | Verwacht gedrag — zie de shim-interface bovenaan | | Werkt niet op WiFi | Klopt: macvlan werkt niet over een draadloze interface | --- ## Gedeelde netwerken tussen apps Naast een eigen IP-adres is er het gedeelde bridge-netwerk waarop apps elkaar op containernaam vinden. Tot v0.7.70 was dat er één (`serverup`) en hing élke app eraan: Vaultwarden kon bij je mediaserver, en andersom. Nu kies je per app aan welke netwerken hij meedoet, en kun je er bij het installeren zelf een maken. Laat je de naam leeg, dan wordt er een voorgesteld (`su-`). Het netwerk verschijnt daarna in de lijst bij elke andere app. ``` Stap 2 — Verbinden ☑ serverup standaard 12 containers ☑ su-media 3 containers ☐ su-beheer 2 containers [ media ] [+ Netwerk maken] ``` Een app kan aan meerdere netwerken tegelijk hangen — handig voor een reverse proxy die bij alles moet kunnen. Verwijderen kan alleen als er geen containers meer aan hangen, en het standaardnetwerk blijft altijd staan. --- ## Is dit adres nog vrij? Bij het invullen van een IP-adres controleert Server Up vier dingen: 1. valt het binnen het **subnet** van het netwerk; 2. valt het binnen het ingestelde **bereik** (buiten je DHCP-pool dus); 3. is het al **toegekend aan een container** in dit netwerk of gereserveerd door een andere stack; 4. heeft de host het adres recent **op het LAN gezien** — dat leest de ARP-tabel van de host, en vangt een fysiek apparaat met een DHCP-adres. Klopt er iets niet, dan staat erbij wat en krijg je een vrij adres voorgesteld. > Punt 4 is geen garantie: een apparaat dat uit staat, staat niet in de > ARP-tabel. Houd je macvlan-bereik daarom buiten wat je router uitdeelt. --- ## Is deze poort nog vrij? Poortvelden krijgen automatisch een vrij nummer voorgesteld. Daarbij wordt niet alleen gekeken naar wat Docker publiceert, maar ook naar wat er **rechtstreeks op de host luistert** — een nginx of DNS-server buiten Docker zag Server Up eerder niet, terwijl je er net zo goed mee botst. Dat laatste gaat via een korte hulpcontainer met `--network host`. Lukt dat niet, dan meldt het antwoord `host_checked: false`: "vrij" is dan een aanname op basis van Docker alleen.