NetworkManager Crash Course: nmcli en Keyfiles voor RHEL-servers

Wat NetworkManager is, en of je het al draait

NetworkManager is de daemon die bepaalt wat je netwerkinterfaces doen: welke adressen ze dragen, via welke gateway ze routeren, en tegen welke DNS-servers ze resolven. Bij de RHEL-familie (RHEL, en de community-rebuilds AlmaLinux en Rocky) is het de standaard, en sinds het network-scripts-pakket is losgelaten is het de enige netwerkstack die Red Hat ondersteunt. Draai je RHEL 8, 9 of 10 of een van hun rebuilds, dan draait NetworkManager al en bevat het al jouw configuratie, of je er nu aan hebt gezeten of niet.

Deze crash course is geschreven voor één opstelling: een dedicated server met een statisch publiek IPv4-adres, misschien een geroute IPv6-blok, geen Wi-Fi, alleen bereikbaar via SSH. Dat is een ander verhaal dan het laptopscenario waar de meeste NetworkManager-tutorials van uitgaan, dus we beginnen met statische adressering en het command-line-tool nmcli, en behandelen de grafische onderdelen als voetnoot. Aan het eind heb je een statisch IPv4- en IPv6-profiel dat je kunt plakken en aanpassen, een helder beeld van waar de configuratie leeft, en genoeg van het model om het te debuggen wanneer een wijziging niet aanslaat. De nmcli-commando's hier zijn stabiel over releases heen, dus de exacte versie maakt voor het vervolg zelden uit; op het moment van schrijven is de actuele stabiele reeks NetworkManager 1.56 (februari 2026). Bekijk de release notes voor wat jouw distributie meelevert.

Eén thema loopt door dit hele verhaal: op een externe machine sluit een netwerkfout je buiten. Het ontwerp van NetworkManager geeft je hier een veiligheidsmarge, en out-of-band console-toegang (IPMI, iKVM, of een seriële console van je provider) is het vangnet voor wanneer die marge niet genoeg is. Beide komen verderop terug waar ze relevant zijn.

Aannames voor de voorbeelden:

• Eén Ethernet-interface, enp1s0. Bij jou heet die misschien eno1, ens3 of iets dergelijks; nmcli device status toont de echte naam.
• Roottoegang via SSH, of een gebruiker met sudo.
• Adressen uit de documentatiereeksen van RFC 5737 en RFC 3849, dus niets hiervan routeert. Vervang ze overal door je eigen waarden.

Devices, profielen en de twee statussen

De meeste verwarring rond nmcli komt doordat twee onderscheiden ontbreken. Leer ze en de commando's voelen niet langer willekeurig.

Het eerste is device versus verbindingsprofiel. Een device is de hardware: enp1s0, de fysieke NIC. Een verbindingsprofiel is een opgeslagen set instellingen die op een device kan worden toegepast: een adres, een gateway, DNS, en een lange lijst andere eigenschappen. De relatie is one-to-many. Eén device kan meerdere profielen tegelijk opgeslagen hebben (één statisch, één DHCP, één voor een onderhouds-VLAN), en er is er maar één tegelijk actief. Wanneer je nmcli con up uitvoert, kies je welk opgeslagen profiel het device nu moet dragen. "Het netwerk configureren" in NetworkManager is dus twee stappen: een profiel bewerken, en het vervolgens activeren.

Het tweede is opgeslagen status versus actieve status. Een profiel bewerken met nmcli con mod schrijft naar schijf. Het raakt de live interface niet aan. De interface behoudt wat ze kreeg toen het huidige profiel voor het laatst werd geactiveerd, totdat je opnieuw activeert. Dat gat is geen eigenaardigheid om te omzeilen; het is de veiligheidsfunctie. Je kunt het adres, de gateway of een route herschrijven op het profiel dat je SSH-sessie draagt, precies teruglezen wat je hebt gewijzigd, en pas dan committen door opnieuw te activeren. Niets van wat je hebt getypt bereikt de kabel voordat dat moment aanbreekt.

Houd beide ideeën samen vast en de workflow leest zich vanzelf. Kies of maak een profiel. Wijzig de eigenschappen ervan, wat wordt opgeslagen maar inert blijft. Activeer het, wat live gaat. Alles voorbij dit punt gaat over welke eigenschappen en welke flags.

Waar de configuratie leeft, en de ifcfg-geschiedenis

Opgeslagen profielen zijn keyfiles: kleine bestanden in INI-stijl onder /etc/NetworkManager/system-connections/, één per profiel, elk genoemd <profile>.nmconnection. Ze kunnen geheimen bevatten zoals een Wi-Fi-PSK of 802.1X-credentials, dus NetworkManager weigert elk bestand te lezen dat niet van root is en niet is vergrendeld op permissie 0600. Een profiel dat je met nmcli aanmaakt krijgt die rechten gratis mee; een bestand dat je handmatig neerzet heeft chown root:root en chmod 600 nodig, anders negeert de daemon het.

Draai je al een paar jaar RHEL, dan herinner je je een andere locatie: /etc/sysconfig/network-scripts/ifcfg-*. De overstap van die bestanden gebeurde in fases, en welke fase jouw server heeft bereikt bepaalt wat je aantreft.

• RHEL 8 verklaarde de oude network-scripts-service deprecated. NetworkManager werd de standaard en ifup/ifdown werden omgeleid om het aan te roepen, maar de standaard op schijf was nog steeds het oude formaat: nieuwe profielen werden geschreven als ifcfg-*-bestanden.
• RHEL 9 draaide die standaard om. Nieuwe profielen worden geschreven als keyfiles onder system-connections/. Bestaande ifcfg-*-bestanden worden nog gelezen via een compatibiliteitsplugin, zodat een geüpgradede machine blijft werken, maar het formaat werd formeel deprecated verklaard en nmcli connection migrate werd toegevoegd om profielen over te zetten.
• RHEL 10, uitgebracht in mei 2025, maakte het werk af. De ifcfg-plugin is verdwenen, NetworkManager negeert alles in /etc/sysconfig/network-scripts/, en er is geen in-place-conversie meer aanwezig op de machine. Keyfiles zijn het enige formaat dat het leest.

Het praktische gevolg: behandel op alles vanaf RHEL 9 system-connections/*.nmconnection als source of truth. Eén addertje wanneer je die bestanden rechtstreeks bewerkt: NetworkManager houdt de directory niet in de gaten. Voer na een handmatige bewerking nmcli con reload uit om elk profiel opnieuw in te lezen, of nmcli con load <path> voor één bestand, en activeer daarna. Sla de reload over en de daemon werkt nog steeds met de kopie die hij het laatst heeft ingelezen.

Een complete statische configuratie

Hier is een volledig statisch profiel voor enp1s0: een IPv4-adres en gateway, twee DNS-servers, een statisch IPv6-adres en gateway, en autoconnect aan zodat het na een reboot terugkeert. Pas de waarden aan en voer het uit als één commando:

nmcli con add type ethernet con-name static-enp1s0 ifname enp1s0 \
  ipv4.method manual \
  ipv4.addresses 203.0.113.10/24 \
  ipv4.gateway 203.0.113.1 \
  ipv4.dns "1.1.1.1,9.9.9.9" \
  ipv6.method manual \
  ipv6.addresses 2001:db8:2:a::10/64 \
  ipv6.gateway 2001:db8:2:a::1 \
  ipv6.dns "2606:4700:4700::1111" \
  connection.autoconnect yes

ipv4.method manual is wat het statisch maakt; het DHCP-equivalent is auto. Adressen gebruiken CIDR-notatie. ipv4.dns neemt een lijst gescheiden door komma's. De IPv6-helft weerspiegelt de IPv4-helft eigenschap voor eigenschap, dus een dual-stack-server is één commando in plaats van twee profielen. connection.autoconnect yes is al de standaard, maar het expliciet vermelden is goedkope verzekering tegen een profiel dat werkt tot de eerste reboot en daarna niet meer.

con add maakt het profiel aan en slaat het op. Op de meeste geprovisionede servers heeft de interface al een actief profiel (vaak een DHCP-profiel uit de installatie), dus er verandert nog niets op de kabel. Lees het terug voordat je committeert:

root@server01:~# nmcli -f ipv4.addresses,ipv4.gateway,ipv6.addresses con show static-enp1s0
ipv4.addresses:                         203.0.113.10/24
ipv4.gateway:                           203.0.113.1
ipv6.addresses:                         2001:db8:2:a::10/64

Als het terugleest zoals je bedoelde, activeer het dan:

root@server01:~# nmcli con up static-enp1s0

Dit is de gevaarlijke regel, en de plek om vaart te minderen. Dit profiel activeren deactiveert wat je sessie ook droeg. Als de gateway fout is of het adres botst, valt SSH weg en komt niet terug, want het ding waarmee je het zou repareren is precies wat je net hebt gesloopt. Twee gewoontes houden dit veilig: zorg dat de waarden kloppen door ze eerst terug te lezen, en houd de IPMI of seriële console van de server in een ander venster open voordat je op enter drukt. NetworkManager rolt een kale nmcli con up niet voor je terug; de console is jouw undo.

Om later één eigenschap te wijzigen, pas aan en reactiveer:

root@server01:~# nmcli con mod static-enp1s0 ipv4.dns "9.9.9.9"
root@server01:~# nmcli con up static-enp1s0

De con mod-regel wordt opgeslagen maar blijft inert. De con up-regel is wat het op de kabel zet.

Uitlezen wat NetworkManager weet

Vier commando's beantwoorden bijna elke "wat is er aan de hand"-vraag.

nmcli device status is het eerste dat je op elke server draait. Eén regel per interface: het type, of NetworkManager het beheert, en welk profiel actief is.

root@server01:~# nmcli device status
DEVICE   TYPE      STATE                   CONNECTION
enp1s0   ethernet  connected               static-enp1s0
lo       loopback  connected (externally)  --

nmcli con show toont alle opgeslagen profielen, actief of niet. Voeg een naam toe om alle eigenschappen van één profiel te dumpen; zo zie je wat een profiel gaat doen voordat je het activeert:

root@server01:~# nmcli con show
NAME            UUID                                  TYPE      DEVICE
static-enp1s0   6d2c8f5a-1e3b-4a7d-9c11-2f0a7b3e5d84  ethernet  enp1s0

De -f-flag selecteert velden zodat je niet door tweehonderd regels hoeft te scrollen, en -g (get) print één waarde zonder header, precies wat je in een script wilt:

root@server01:~# nmcli -g ipv4.addresses con show static-enp1s0
203.0.113.10/24

De output hierboven is illustratief; UUID's en exacte kolombreedte verschillen per versie en host.

nmtui: een formulier in plaats van flags

Vul je liever een formulier in dan dat je eigenschapsnamen onthoudt, dan is nmtui de curses-frontend voor dezelfde engine. Draai het via SSH of op de console en je krijgt drie keuzes: een verbinding bewerken, een verbinding activeren, en de systeemhostname instellen. De verbindingseditor biedt IPv4- en IPv6-adressering, DNS, en de velden voor bonds, bridges en VLANs, dus een statische opstelling is mogelijk zonder nmcli ooit aan te raken. Spring er direct in met nmtui edit enp1s0 of nmtui connect.

De beperkingen zijn goed om te kennen. nmtui kun je niet scripten, en het toont niet elke eigenschap: routeringsregels, dispatcher scripts en de obscuurdere instellingen hebben nog steeds nmcli of een handmatige keyfile-bewerking nodig. Als begeleide weg terug wanneer je het netwerk kwijt bent en achter een console zit, verdient het zijn plek.

nmcli cheat sheet

De commando's die je het vaakst zult gebruiken, met static-enp1s0 als plaatsvervanger voor jouw profielnaam:

Wie standaard NetworkManager gebruikt

Welke stack je krijgt is grotendeels een gevolg van de distributie die je hebt geïnstalleerd, een aparte beslissing dan deze (behandeld in onze gids voor het kiezen van een Linux-distributie). De verdeling zoals die er in 2026 uitziet:

De Debian-serverrij is waar mensen op stuklopen. Installeer network-manager op een Debian-server die al ifupdown gebruikt, en het neemt de bestaande interfaces niet over; alles wat in /etc/network/interfaces is gedeclareerd blijft bij zijn oude renderer en verschijnt als unmanaged in nmcli. Dat is opzettelijk, en het is de veilige standaard.

VLANs, bonds en bridges

Drie serverpatronen gaan verder dan één plat adres. Elk is één profieltype, en de syntax rijmt met het statische voorbeeld.

Een VLAN zet getagd verkeer op een virtuele interface die over een fysieke heen ligt. Dit voegt VLAN 40 toe op enp1s0 met een eigen adres:

nmcli con add type vlan con-name vlan40 ifname enp1s0.40 dev enp1s0 id 40 \
  ipv4.method manual ipv4.addresses 198.51.100.10/24

De parent enp1s0 blijft ongetagd verkeer dragen. De switchpoort moet een trunk zijn die VLAN 40 doorlaat, anders komen de getagde frames nergens aan.

Een bond bundelt twee NICs tot één logische link. LACP (mode 802.3ad) is de gangbare serverkeuze voor doorvoer en link-failover:

nmcli con add type bond con-name bond0 ifname bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet con-name bond0-p1 ifname eno1 master bond0 slave-type bond
nmcli con add type ethernet con-name bond0-p2 ifname eno2 master bond0 slave-type bond

LACP wordt onderhandeld, niet eenzijdig opgelegd. De switch heeft een bijpassende link-aggregation-group nodig op die twee poorten, anders blijft de bond down. Zet de adressering op bond0, nooit op de member-poorten.

Een bridge maakt van de host een virtuele switch, wat een KVM-hypervisor nodig heeft zodat zijn guests rechtstreeks bij het netwerk kunnen. Het host-IP verhuist naar de bridge, en de fysieke NIC wordt een poort zonder eigen adres:

nmcli con add type bridge con-name br0 ifname br0 \
  ipv4.method manual ipv4.addresses 203.0.113.10/24 ipv4.gateway 203.0.113.1 ipv4.dns 1.1.1.1
nmcli con add type ethernet con-name br0-port ifname enp1s0 master br0 slave-type bridge

Het host-adres via SSH naar een bridge verhuizen is hetzelfde lockoutrisico als elke reactivering, alleen scherper omdat je de interface herstructureert waar de sessie op rijdt. Bouw het vanaf de console, of op een tweede NIC waar je niet via bent ingelogd. Dit is dezelfde bridge die Proxmox opzet als vmbr0; hier bouw je hem met de hand.

Troubleshooting

• Een device toont unmanaged. NetworkManager is verteld het te negeren. Kijk in /etc/NetworkManager/NetworkManager.conf en /etc/NetworkManager/conf.d/*.conf naar een regel managed=false of een [device-*]-sectie met managed=0. Op Debian tonen interfaces gedefinieerd in /etc/network/interfaces bewust als unmanaged. Om een device voor de sessie terug te geven: nmcli device set enp1s0 managed yes; om het blijvend te maken, verwijder je de config die het uitsloot.
• Een wijziging is niet toegepast. Bijna altijd een van twee dingen: je draaide con mod maar nooit con up, dus de wijziging is opgeslagen en inert, of je hebt een keyfile handmatig bewerkt en nooit nmcli con reload gedraaid, dus de daemon werkt nog met de oude kopie. Geen van beide faalt luidruchtig. Beide zijn opgelost zodra je activeert.
• Opgeslagen en live komen niet overeen. ip addr en ip route tonen wat de kernel op dit moment doet; nmcli -f all con show <name> toont wat het profiel gaat doen de volgende keer dat het opkomt. Komt het adres op de kabel niet overeen met het profiel, dan staat er een activering te wachten, geen bug.
• Niets van het bovenstaande verklaart het. Lees het eigen log van de daemon: journalctl -u NetworkManager -b voor deze boot, of -f om het live te volgen in één venster terwijl je in een ander venster con up draait. NetworkManager is spraakzaam over waarom een activering mislukte, en de reden staat meestal in de laatste paar regels.

nmstate, de declaratieve laag

Voor grote aantallen servers, en voor iedereen die de gewenste eindstatus liever beschrijft dan stappen uitvoert, levert Red Hat nmstate en het bijbehorende commando nmstatectl. Je schrijft het netwerk dat je wilt als YAML, draait nmstatectl apply, en nmstate stuurt NetworkManager (zijn enige backend) aan om dat te bereiken. Wat het de moeite waard maakt op een externe server is de rollback: pas een status toe die de connectiviteit breekt, en nmstate zet zichzelf terug naar de vorige, iets wat een kale nmcli con up niet doet. Het is beschikbaar op RHEL 8, 9 en 10, en het is wat de RHEL system role voor networking er onder de motorkap voor gebruikt. Voor één machine is nmcli genoeg. Moet dezelfde config identiek en veilig op vijftig servers landen, dan is nmstate de laag die daarvoor is gebouwd.

Ubuntu Server gebruikt Netplan, geen NetworkManager

Draai je ook Ubuntu-servers, dan is niets van de nmcli hierboven daar standaard van toepassing. Ubuntu Server levert Netplan dat naar systemd-networkd schrijft, geconfigureerd in /etc/netplan/*.yaml, zonder dat NetworkManager in beeld komt. Ubuntu Desktop gebruikt ook Netplan, maar met NetworkManager als renderer, dus daar werkt nmcli wel. De concepten komen terug (gedeclareerde config, een activeringsstap, een opgeslagen-versus-live-scheiding), maar de tool en de bestanden verschillen. De Netplan crash course is de zustergids voor die kant van het serverpark.

Uitrollen op Serverside

Een NetworkManager-profiel is maar zo nuttig als het netwerk waar het naar wijst. Serverside draait zijn eigen netwerk (AS55285), dus een RHEL-, AlmaLinux- of Rocky-server is binnen een minuut geprovisioned, en de publieke IPv4 en IPv6 die je configureert staan vanaf de eerste boot achter altijd-actieve DDoS-mitigatie. De RHEL dedicated-lijn levert de RHEL-familie kant-en-klaar voor de nmcli-workflow hierboven, en het bredere dedicated-aanbod dekt de rest.

Gerelateerde leesstof: de AlmaLinux versus RHEL abonnementsvergelijking als je een licentie afweegt tegen een gratis rebuild, en de Linux server hardening checklist om te draaien zodra de interface up en bereikbaar is.

Veelgestelde vragen

Waarom overleefde mijn IP-wijziging een reboot niet?

Drie gebruikelijke oorzaken. Het profiel heeft autoconnect uitstaan, dus er activeert niets bij het booten: zet connection.autoconnect yes. Je hebt het profiel gewijzigd met nmcli con mod maar nooit nmcli con up gedraaid, dus de wijziging is opgeslagen maar nooit toegepast. Of je hebt de keyfile handmatig bewerkt en nooit nmcli con reload gedraaid, dus NetworkManager bleef de kopie gebruiken die hij bij het opstarten had ingelezen. Het profiel activeren na de wijziging lost alle drie op.

Moet ik de .nmconnection-bestanden handmatig bewerken of nmcli gebruiken?

Beide werken, en de keyfile is in beide gevallen de source of truth. nmcli controleert de waarden die je opgeeft en herlaadt het profiel voor je, dus het is de veiligere standaardkeuze. Bewerk je het bestand rechtstreeks, houd het dan van root en op permissie 600, en draai daarna nmcli con reload zodat de daemon de wijziging oppikt. NetworkManager houdt de directory niet uit zichzelf in de gaten.

Hoe stop ik NetworkManager met het beheren van een interface?

Voor de huidige sessie draai je nmcli device set enp1s0 managed no. Om het over reboots heen te laten standhouden, voeg je een [device-*]-sectie met managed=0 toe aan een bestand onder /etc/NetworkManager/conf.d/. Dit komt vaak voor wanneer een andere tool een specifieke NIC bezit, of op Debian waar interfaces gedefinieerd in /etc/network/interfaces met opzet unmanaged blijven.

Heb ik op RHEL nog steeds ifcfg-bestanden?

Dat hangt van de versie af. RHEL 8 schreef standaard nog ifcfg-bestanden. RHEL 9 leest bestaande bestanden nog wel, maar schrijft nieuwe profielen als keyfiles en markeert het ifcfg-formaat als deprecated. RHEL 10 verwijderde vanaf mei 2025 de ifcfg-plugin volledig en negeert die bestanden. Op RHEL 9 en 10 tellen de keyfiles onder /etc/NetworkManager/system-connections.

NetworkManager of systemd-networkd voor een server?

Bij de RHEL-familie wordt de keuze voor je gemaakt: NetworkManager is de standaard en de enige ondersteunde stack, en het handelt statische serveradressering zonder problemen af. Ubuntu Server gaat de andere kant op, met systemd-networkd via Netplan. Beide zijn production-grade. Gebruik wat je distributie meelevert in plaats van het te vervangen.