Netplan crash course voor Ubuntu dedicated servers

Wat Netplan is, en of je het gebruikt

Netplan is de netwerkconfiguratielaag die Ubuntu standaard meelevert sinds 17.10. Je schrijft je interfaces, adressen, routes en DNS als YAML in /etc/netplan/, en een generator zet die ene beschrijving om in configuratie voor welke backend het netwerk daaronder ook aanstuurt: systemd-networkd op Ubuntu Server, NetworkManager op Ubuntu Desktop. Je bewerkt één bestandsformaat; Netplan rendert daaronder de backend-specifieke config.

Als je een dedicated server hebt gehuurd en er Ubuntu op hebt geïnstalleerd, heb je Netplan. Deze gids is geschreven voor precies die machine: één server, een statisch publiek IPv4-adres (en vaak ook een IPv6-toewijzing), geen wifi, en SSH als enige toegang. Dat laatste detail bepaalt de toon van het hele artikel, want een netwerkfout op een remote server is precies hoe je jezelf erbuiten sluit. Netplan heeft een specifiek hulpmiddel om dat te voorkomen, en daar leunen we elke keer op als we iets live wijzigen.

Deze crash course behandelt:

• waar de configuratiebestanden staan, en de permissieregel waar mensen over struikelen
• het two-backend-model, en wat er verandert als je config overneemt uit een tutorial die voor de andere backend is geschreven
• een volledige statische IPv4- en IPv6-configuratie die je regel voor regel kunt aanpassen
• de commando's die je dagelijks gebruikt: generate, try, apply en status
• VLANs, LACP-bonds, en een bridge voor VM-hosts
• waarom je aanpassingen soms verdwijnen na een reboot, en de cloud-init-instelling die dat oplost

Kort een opmerking over versies. Ubuntu 26.04 LTS "Resolute Raccoon", uitgebracht op 23 april 2026, levert de Netplan 1.2-reeks. De vorige LTS, 24.04 "Noble Numbat", leverde Netplan 1.0, de eerste stabiele release, gedateerd 29 februari 2024. De upstream-reeks is op het moment van schrijven 1.2.x; kijk op de releasepagina voor de actuele versie. Alles hier is op beide van toepassing, met de verschillen aangegeven waar ze voorkomen. Kies je nog welke release je gaat draaien, dan behandelt de Ubuntu Server LTS-gids de supporttermijnen.

Waar de configuratie staat

Elk *.yaml-bestand in /etc/netplan/ telt mee. Twee andere mappen leveren ook input: /run/netplan/ voor runtime-configuratie en /lib/netplan/ voor vendor-standaardinstellingen. Bestanden worden in lexicografische volgorde op naam gelezen en samengevoegd tot één model. Als dezelfde sleutel twee keer wordt ingesteld, wint het laatste bestand. Bestaat een bestand met dezelfde naam in meer dan één map, dan heeft de kopie in /run/netplan/ voorrang op /etc/netplan/, dat op zijn beurt voorrang heeft op /lib/netplan/.

Deze volgorde is waarom een bestand met de naam 50-cloud-init.yaml ertoe doet. Op de meeste cloud- en dedicated-server-images schrijft cloud-init je initiële netwerkinstellingen precies naar dat bestand, en het 50--voorvoegsel staat vroeg in de sorteervolgorde. Zet je eigen 90-static.yaml ernaast, dan wint die bij het samenvoegen, maar cloud-init kan zijn eigen bestand bij de volgende boot herschrijven en zo je aannames ongedaan maken. De nette oplossing volgt verderop, bij troubleshooting. Weet voor nu dat 50-cloud-init.yaml gegenereerd is, niet handmatig geschreven, en behandel het ook zo.

Eén regel pakt vrijwel iedereen minstens één keer. Elk bestand onder /etc/netplan/ moet eigendom zijn van root en alleen leesbaar voor root, mode 600. Netplan bewaart in deze bestanden gegevens zoals wifi-wachtwoorden en tunnelsleutels, dus een config die voor iedereen leesbaar is lekt geheimen. Sinds versie 0.106 toont de tool een waarschuwing zodra hij een bestand vindt dat door meer dan alleen root gelezen kan worden:

** (generate:1234): WARNING **: Permissions for /etc/netplan/50-cloud-init.yaml
are too open. Netplan configuration should NOT be accessible by others.

Los het op met één commando:

chmod 600 /etc/netplan/*.yaml

Die waarschuwing is makkelijk te negeren omdat het netwerk gewoon blijft werken, maar het aanscherpen van de permissies hoort bij elke server hardening-ronde en kost niets.

Eén YAML-bron, twee backends

Netplan beheert zelf geen enkele interface. Het genereert configuratie voor een renderer, en de renderer doet het werk. Er zijn er twee, en welke standaard draait hangt af van hoe Ubuntu is geïnstalleerd:

Op een server verander je dit zelden. systemd-networkd start vroeg tijdens het opstarten, heeft geen GUI-afhankelijkheden, en is de juiste backend voor een machine die je via SSH benadert. Je kunt hem expliciet benoemen met renderer: networkd bovenaan het bestand, al is dat op Ubuntu Server toch al de standaard.

Waarom dit onderscheid ertoe doet: config die je overneemt uit een op desktops gerichte tutorial kan renderer: NetworkManager instellen of afhankelijk zijn van sleutels die alleen voor NetworkManager gelden, en die gedraagt zich anders, of weigert toe te passen, op een networkd-server. Controleer welke backend een snippet veronderstelt voordat je hem plakt.

Een volledige statische configuratie

Hier is een volledige statische opzet voor één interface met zowel IPv4 als IPv6. Deze wijst de adressen toe, stelt de standaardroutes in en configureert DNS. Interfacenamen op moderne Ubuntu-systemen volgen het voorspelbare schema, dus die van jou heet waarschijnlijk enp1s0, eno1, of iets vergelijkbaars; draai ip -br link om te zien hoe je kernel hem noemt.

# /etc/netplan/90-static.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.0.2.10/24
        - "2001:db8::10/64"
      routes:
        - to: default
          via: 192.0.2.1
        - to: default
          via: "2001:db8::1"
      nameservers:
        addresses:
          - 192.0.2.53
          - 2001:db8::53
        search:
          - example.com

version: 2 is de Netplan-formaatversie en is verplicht. dhcp4: false is al de standaard zodra je statische adressen opgeeft, maar het expliciet vermelden maakt je bedoeling duidelijk voor de volgende lezer. Elk adres draagt zijn prefixlengte in CIDR-vorm. Het routes-blok is het deel dat het waard is om twee keer te lezen.

Je komt oudere tutorials tegen die de gateway zo instellen:

      gateway4: 192.0.2.1

Die sleutel is deprecated. Netplan waarschuwt al sinds versie 0.103 tegen gateway4 en gateway6, en de melding is direct:

gateway4 has been deprecated, use default routes instead.

De vervanging is de routes-entry met to: default, precies zoals in het volledige voorbeeld hierboven. Die doet hetzelfde werk, werkt voor IPv4 en IPv6 via één mechanisme, en laat je later niet-standaardroutes toevoegen zonder van stijl te wisselen. Gebruik die, en sla gateway4 over, ook al werkt die nog steeds.

Hergebruik de exacte IP's en interfacenamen hier niet. De adressen komen uit de TEST-NET- en documentatiereeksen die voor voorbeelden zijn gereserveerd; vul de waarden in die je provider je heeft gegeven.

De commandoset: generate, try, apply

Netplan doet niets met je live netwerk totdat je een van drie commando's uitvoert. Het verschil tussen die drie kennen is wat een remote sessie in leven houdt.

netplan generate rendert je YAML naar backend-configuratie onder /run/systemd/network/ (voor networkd) zonder het draaiende netwerk aan te raken. Het dient ook als validator: heeft je YAML een syntaxfout of een onbekende sleutel, dan mislukt generate en vertelt het je waar, en is er nog niets veranderd. Draai dit eerst zodra je twijfelt.

Het commando dat het live systeem wijzigt is netplan apply. Het genereert de config opnieuw en past die vervolgens in één keer toe, waarbij de interface direct wordt geherconfigureerd bij een wijziging van een statisch adres. Op een remote machine is het gevaar direct: is de nieuwe config fout, dan heb je zojuist je eigen SSH-sessie afgesneden, en is er geen undo vanaf waar jij zit.

netplan try is het antwoord op dat gevaar, en op een remote server is dit het commando waar je standaard naar grijpt. Het past de configuratie toe en start dan een aftelling; bevestig je niet binnen de timeout, dan draait het de wijziging terug naar wat er daarvoor stond. De standaardtimeout is 120 seconden, aan te passen met --timeout:

netplan try --timeout 90

Druk op Enter om de wijziging te behouden, of wacht en laat hem terugdraaien. Breekt je nieuwe config de connectiviteit, dan verlies je de sessie, bevestig je nooit, en twee minuten later heeft de server de werkende configuratie hersteld en is je SSH weer bereikbaar. Die automatische terugdraai is het hele punt van het commando. Perfect is het niet: sommige wijzigingen met interface-hernoemingen of bepaalde backend-overgangen draaien niet netjes terug, en juist daar bewijst een dedicated server met een IPMI- of iKVM-console zijn waarde. Out-of-band consoletoegang is het vangnet voor de dag dat try je niet kan redden, en het is de moeite waard om te bevestigen dat je die hebt voordat je hem nodig hebt.

Zodra het netwerk actief is, laat netplan status zien wat de backend met je config heeft gedaan:

     Online state: online
    DNS Addresses: 192.0.2.53
       DNS Search: example.com

●  2: enp1s0 ethernet UP (networkd: enp1s0)
      MAC Address: 52:54:00:11:22:33
        Addresses: 192.0.2.10/24
                   2001:db8::10/64
           Routes: default via 192.0.2.1 (static)
                   default via 2001:db8::1 (static)

(Output is illustratief.) netplan status kwam erbij in versie 0.106. Vanaf 1.0 laat netplan status --diff ook zien waar de draaiende status afwijkt van je YAML, wat de snelste manier is om een config te betrappen die wel gegenereerd is maar niet volledig is toegepast.

Nog twee commando's lezen en schrijven het samengevoegde model zonder dat je een editor hoeft te openen. netplan get toont de huidige configuratie als YAML, en netplan set wijzigt één waarde via een dotted path:

netplan get ethernets.enp1s0.addresses
netplan set ethernets.enp1s0.dhcp4=false

netplan set schrijft standaard naar /etc/netplan/90-netplan-set.yaml, wat handig is voor scripts en verwarrend als je vergeet dat het dat doet; kijk in dat bestand als er een waarde uit het niets lijkt te verschijnen.

Spiekbriefje

De taken die je herhaalt, en het YAML-fragment of commando voor elk:

VLANs, bonds en bridges

Drie constructies komen op servers vaak genoeg voor om binnen handbereik te houden. Elke bouwt voort op hetzelfde bestand; de interfacetypes krijgen elk hun eigen top-level blok.

Een tagged VLAN op één uplink

Krijg je van je provider een tagged VLAN voor een privénetwerk, definieer die dan als een vlans-entry die via zijn link naar de fysieke interface verwijst:

network:
  version: 2
  ethernets:
    enp1s0: {}
  vlans:
    enp1s0.100:
      id: 100
      link: enp1s0
      addresses:
        - 198.51.100.10/24

De id is de 802.1Q-tag, en link benoemt de parent-interface, die gedefinieerd blijft (hier met een lege {}) zodat Netplan hem opbrengt. Untagged verkeer gebruikt nog steeds de parent; tagged frames voor VLAN 100 reizen over de nieuwe logische interface.

Twee NIC's gebonded met LACP

Een bond bundelt meerdere links tot één logische interface voor bandbreedte of redundantie. Mode 802.3ad is LACP, en die vereist dat de switchkant overeenkomstig is geconfigureerd:

network:
  version: 2
  ethernets:
    eno1: {}
    eno2: {}
  bonds:
    bond0:
      interfaces: [eno1, eno2]
      addresses:
        - 192.0.2.20/24
      routes:
        - to: default
          via: 192.0.2.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100

LACP is een afspraak met twee kanten. Zitten de upstream switchpoorten niet in een overeenkomende LACP-groep, dan komt de bond niet omhoog, dus stem dit af met wie de switch beheert voordat je dit toepast.

Een bridge voor virtuele machines

Is de server een KVM- of LXD-host, dan laat een bridge guests de fysieke NIC delen alsof die op een switch is aangesloten. Het host-adres verhuist naar de bridge, en de fysieke interface wordt een bridge-poort zonder eigen adres:

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp1s0]
      addresses:
        - 192.0.2.30/24
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [192.0.2.53]
      parameters:
        stp: false
        forward-delay: 0

Dit is hetzelfde idee dat Proxmox implementeert met zijn vmbr0, als je die kent. Spanning-tree en de forward delay uitschakelen past bij een host-bridge met één uplink; laat ze alleen aan staan wanneer de bridge meerdere fysieke poorten heeft die een lus zouden kunnen vormen.

Als de configuratie niet beklijft: troubleshooting

De meeste Netplan-problemen vallen in een paar categorieën uiteen.

YAML-indentatie. De YAML van Netplan gebruikt spaties voor indentatie en wijst tabs botweg af. Eén verdwaalde tab, of een inconsistente inspringing, levert een parse error op. Draai netplan generate na elke wijziging: het is de goedkoopste validator die je hebt, en het weigert kapotte config weg te schrijven in plaats van die toe te passen.

De wijziging is gegenereerd, maar de interface ziet er verkeerd uit. Vraag het de backend in plaats van de YAML te vertrouwen. ip addr en ip route tonen de adressen en routes die op de link zijn geïnstalleerd; networkctl status enp1s0 toont het beeld van systemd-networkd; resolvectl status toont de DNS-servers die actief zijn. Meldt netplan status --diff een verschil tussen je bestand en de draaiende status, dan is de apply niet volledig doorgekomen, en een van die commando's laat zien waar.

Je aanpassingen verdwijnen na een reboot. Dit is de cloud-init-overschrijving, de meest voorkomende verrassing op een dedicated of cloud server. cloud-init genereert /etc/netplan/50-cloud-init.yaml bij het opstarten opnieuw vanuit zijn eigen databron, en overschrijft alles waarvan het denkt dat het daarvan de eigenaar is. De ondersteunde oplossing is om cloud-init eenmalig te vertellen te stoppen met het beheren van het netwerk:

echo 'network: {config: disabled}' | \
  tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Daarna laat cloud-init /etc/netplan/ met rust en wordt je eigen bestand de single source of truth. Je kunt 50-cloud-init.yaml daarna verwijderen of herschrijven, en het blijft zo. Doe dit voordat je tijd steekt in een handgeschreven config, niet nadat je twee keer tegen dezelfde reboot hebt gevochten.

Als je geen Netplan hebt

Netplan is een Ubuntu-standaard, geen Linux-universeel gegeven. Bij de RHEL-familie (RHEL, AlmaLinux, Rocky) en bij de meeste desktopdistributies is er geen Netplan-laag: NetworkManager beheert interfaces rechtstreeks, en je configureert het met nmcli, nmtui, of connection files. Is jouw machinepark gemengd, dan behandelt de begeleidende NetworkManager crash course die kant met dezelfde focus op servers.

Debian is de net-mis. Het pakket netplan.io staat in Debians repositories, dus je kunt het installeren en gebruiken, maar Debian gebruikt het niet standaard; een kale Debian-server configureert het netwerk nog steeds via ifupdown en /etc/network/interfaces, of via NetworkManager op de desktop. Twijfel je tussen de twee, dan behandelt de vergelijking tussen Ubuntu en Debian waar elk goed in past, en de bredere gids voor het kiezen van een distro zet Netplan-als-standaard tegenover de alternatieven.

Uitrollen op Serverside

Netplan is precies zo nuttig als het netwerk eronder. Een Serverside dedicated server draait op ons eigen netwerk (AS55285), dus de statische IPv4- en IPv6-adressen die je in die YAML schrijft, zitten achter routing die wij beheren, met always-on DDoS-mitigatie voor de publieke interface. Provisioning duurt minder dan een minuut: een verse Ubuntu-server staat binnen een minuut, een LTS-image met Netplan al aanwezig, klaar voordat jij klaar bent met het opstellen van de config die erop gaat draaien.

Veelgestelde vragen

Wat is het verschil tussen netplan apply en netplan try?

netplan apply genereert de backend-config opnieuw en past die direct toe op het live systeem, zonder terugweg als het je verbinding breekt. netplan try past dezelfde config toe, maar start een aftelling van 120 seconden en draait de wijziging automatisch terug tenzij je op Enter drukt om te bevestigen. Grijp op een remote server naar try zodra je iets wijzigt dat de verbinding waarover je verbonden bent kan raken, en bewaar apply voor wijzigingen waar je zeker van bent of die je vanaf de console doet.

Waarom verdwijnen mijn netwerkwijzigingen na een reboot?

Bijna altijd cloud-init. Op cloud- en dedicated-server-images genereert cloud-init /etc/netplan/50-cloud-init.yaml bij elke boot opnieuw vanuit zijn eigen databron en overschrijft het aanpassingen waarvan het denkt dat ze van hemzelf zijn. Zet dit stop door /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg aan te maken met de inhoud network: {config: disabled}, en beheer /etc/netplan/ daarna zelf. Daarna blijven je bestanden behouden na een reboot.

Hoe stel ik DNS-servers in Netplan in?

Voeg een nameservers-blok toe aan de interface, met een addresses-lijst en optioneel een search-lijst met domeinen. De resolvers worden actief zodra je netplan apply of netplan try uitvoert, en je kunt ze controleren met resolvectl status. Op systemd-networkd-systemen wordt DNS afgehandeld door systemd-resolved, dus de servers die je instelt verschijnen daar, niet rechtstreeks in /etc/resolv.conf.

Is Netplan hetzelfde als NetworkManager?

Nee. Netplan is een configuratielaag die config voor een backend genereert; NetworkManager is een van de twee backends waarop het kan richten, de andere is systemd-networkd. Ubuntu Server gebruikt standaard de networkd-backend, Ubuntu Desktop gebruikt NetworkManager, en beide worden aangestuurd via dezelfde Netplan-YAML. Op systemen zonder Netplan, zoals servers uit de RHEL-familie, configureer je NetworkManager rechtstreeks.

Ik migreer vanaf /etc/network/interfaces. Vervangt Netplan dat?

Ja, op Ubuntu. De oude ifupdown-stack en het bijbehorende bestand /etc/network/interfaces zijn wat Netplan verving toen Ubuntu het in 17.10 invoerde. Je bewerkt niet allebei: zet elke iface-stanza om in de bijbehorende Netplan ethernets-entry met adres, routes en nameservers, en laat Netplan de backend-config renderen. Debian gebruikt nog steeds standaard /etc/network/interfaces, wat een verschil is om rekening mee te houden als je tussen de twee wisselt.