NetworkManager Crash Course: nmcli und Keyfiles für RHEL-Server

Was NetworkManager ist, und ob Sie es bereits einsetzen

NetworkManager ist der Daemon, der entscheidet, was Ihre Netzwerkinterfaces tun: welche Adressen sie tragen, über welches Gateway sie routen, gegen welche DNS-Server sie auflösen. Bei der RHEL-Familie (RHEL sowie die Community-Rebuilds AlmaLinux und Rocky) ist es der Standard, und seit das network-scripts-Paket entfernt wurde, ist es der einzige von Red Hat unterstützte Netzwerk-Stack. Wenn Sie RHEL 8, 9 oder 10 oder einen ihrer Rebuilds einsetzen, läuft NetworkManager bereits und enthält bereits Ihre Konfiguration, ganz gleich, ob Sie es schon angefasst haben oder nicht.

Dieser Crash Course ist für ein bestimmtes Setup geschrieben: ein Dedicated Server mit statischer öffentlicher IPv4-Adresse, vielleicht einem gerouteten IPv6-Block, ohne Wi-Fi, nur über SSH erreichbar. Das ist ein anderer Fall als das Laptop-Szenario, von dem die meisten NetworkManager-Tutorials ausgehen, deshalb beginnen wir mit statischer Adressierung und dem Kommandozeilen-Tool nmcli und behandeln die grafischen Teile als Fußnote. Am Ende haben Sie ein statisches IPv4- und IPv6-Profil zum Einfügen und Anpassen, ein klares Bild davon, wo die Konfiguration liegt, und genug vom Modell, um es zu debuggen, wenn eine Änderung nicht greift. Die nmcli-Befehle hier sind über Releases hinweg stabil, daher spielt die genaue Version für das Folgende selten eine Rolle; zum Zeitpunkt der Erstellung ist NetworkManager 1.56 (Februar 2026) die aktuelle stabile Reihe. Die Release Notes zeigen, was Ihre Distribution mitbringt.

Ein Thema zieht sich durch alles: Auf einer entfernten Maschine sperrt ein Netzwerkfehler Sie aus. Das Design von NetworkManager gibt Ihnen hier eine Sicherheitsmarge, und Out-of-Band-Konsolenzugang (IPMI, iKVM oder eine serielle Konsole des Providers) ist das Auffangnetz für den Fall, dass diese Marge nicht reicht. Beide kommen weiter unten dort zur Sprache, wo sie relevant sind.

Annahmen für die Beispiele:

• Ein einzelnes Ethernet-Interface, enp1s0. Bei Ihnen heißt es vielleicht eno1, ens3 oder ähnlich; nmcli device status zeigt den echten Namen.
• Root-Zugang über SSH, oder ein Benutzer mit sudo.
• Adressen aus den Dokumentationsbereichen von RFC 5737 und RFC 3849, daher routet hier nichts. Ersetzen Sie sie durchgehend durch Ihre eigenen Werte.

Devices, Profile und die zwei Zustände

Die meiste Verwirrung rund um nmcli entsteht, weil zwei Unterscheidungen fehlen. Lernen Sie diese, und die Befehle wirken nicht mehr willkürlich.

Die erste ist Device versus Verbindungsprofil. Ein Device ist die Hardware: enp1s0, die physische NIC. Ein Verbindungsprofil ist eine gespeicherte Menge von Einstellungen, die auf ein Device angewendet werden kann: eine Adresse, ein Gateway, DNS und eine lange Liste weiterer Eigenschaften. Die Beziehung ist one-to-many. Ein einzelnes Device kann mehrere Profile gespeichert haben (eines statisch, eines DHCP, eines für ein Wartungs-VLAN), und immer nur eines ist aktiv. Wenn Sie nmcli con up ausführen, wählen Sie aus, welches gespeicherte Profil das Device jetzt tragen soll. "Das Netzwerk konfigurieren" bedeutet in NetworkManager also zwei Schritte: ein Profil bearbeiten, und es dann aktivieren.

Die zweite ist gespeicherter Zustand versus laufender Zustand. Ein Profil mit nmcli con mod zu bearbeiten schreibt auf die Festplatte. Es rührt das laufende Interface nicht an. Das Interface behält, was es bekam, als sein aktuelles Profil zuletzt aktiviert wurde, bis Sie erneut aktivieren. Diese Lücke ist keine Eigenart, die man umgehen muss; sie ist das Sicherheitsmerkmal. Sie können die Adresse, das Gateway oder eine Route auf dem Profil umschreiben, das Ihre SSH-Sitzung trägt, exakt zurücklesen, was Sie geändert haben, und erst dann durch erneutes Aktivieren committen. Nichts von dem, was Sie eingegeben haben, erreicht die Leitung vor diesem Moment.

Halten Sie beide Ideen zusammen, und der Workflow liest sich einfach. Wählen oder erstellen Sie ein Profil. Ändern Sie seine Eigenschaften, was gespeichert, aber inert ist. Aktivieren Sie es, das ist live. Alles danach ist nur noch eine Frage, welche Eigenschaften und welche Flags.

Wo die Konfiguration liegt, und die ifcfg-Geschichte

Gespeicherte Profile sind Keyfiles: kleine Dateien im INI-Stil unter /etc/NetworkManager/system-connections/, eine pro Profil, jeweils benannt <profile>.nmconnection. Sie können Geheimnisse wie einen Wi-Fi-PSK oder 802.1X-Credentials enthalten, daher weigert sich NetworkManager, eine Datei zu lesen, die nicht root gehört und nicht auf Berechtigung 0600 gesperrt ist. Ein mit nmcli erstelltes Profil bekommt diese Rechte automatisch mit; eine Datei, die Sie von Hand ablegen, braucht chown root:root und chmod 600, sonst ignoriert der Daemon sie.

Wer schon seit ein paar Jahren RHEL einsetzt, erinnert sich an einen anderen Ort: /etc/sysconfig/network-scripts/ifcfg-*. Der Umzug weg von diesen Dateien geschah in Etappen, und welche Etappe Ihr Server erreicht hat, bestimmt, was Sie vorfinden.

• RHEL 8 erklärte den alten network-scripts-Dienst für deprecated. NetworkManager wurde der Standard, und ifup/ifdown wurden so umgeleitet, dass sie ihn aufrufen, aber der Standard auf der Festplatte war weiterhin das alte Format: Neue Profile wurden als ifcfg-*-Dateien geschrieben.
• RHEL 9 drehte diesen Standard um. Neue Profile werden als Keyfiles unter system-connections/ geschrieben. Bestehende ifcfg-*-Dateien werden weiterhin über ein Kompatibilitäts-Plugin gelesen, sodass eine aktualisierte Maschine weiterläuft, aber das Format wurde formell als deprecated markiert, und nmcli connection migrate kam hinzu, um Profile zu konvertieren.
• RHEL 10, veröffentlicht im Mai 2025, brachte die Sache zu Ende. Das ifcfg-Plugin ist verschwunden, NetworkManager ignoriert alles in /etc/sysconfig/network-scripts/, und es gibt keine In-Place-Konvertierung mehr auf der Maschine. Keyfiles sind das einzige Format, das es liest.

Die praktische Konsequenz: Behandeln Sie ab RHEL 9 system-connections/*.nmconnection als Source of Truth. Ein Haken, wenn Sie diese Dateien direkt bearbeiten: NetworkManager beobachtet das Verzeichnis nicht. Führen Sie nach einer manuellen Bearbeitung nmcli con reload aus, um jedes Profil neu einzulesen, oder nmcli con load <path> für eine einzelne Datei, und aktivieren Sie danach. Lassen Sie den Reload aus, arbeitet der Daemon weiterhin mit der zuletzt eingelesenen Kopie.

Eine vollständige statische Konfiguration

Hier ist ein vollständiges statisches Profil für enp1s0: eine IPv4-Adresse und ein Gateway, zwei DNS-Server, eine statische IPv6-Adresse und ein Gateway, sowie autoconnect an, damit es nach einem Neustart zurückkehrt. Ändern Sie die Werte und führen Sie es als einen Befehl aus:

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 ist es, was es statisch macht; das DHCP-Äquivalent ist auto. Adressen verwenden CIDR-Notation. ipv4.dns nimmt eine kommagetrennte Liste. Die IPv6-Hälfte spiegelt die IPv4-Hälfte Eigenschaft für Eigenschaft, sodass ein Dual-Stack-Server ein Befehl ist statt zwei Profile. connection.autoconnect yes ist ohnehin schon der Standard, aber es explizit anzugeben ist eine billige Versicherung gegen ein Profil, das bis zum ersten Neustart funktioniert und danach nicht mehr.

con add erstellt und speichert das Profil. Auf den meisten provisionierten Servern hat das Interface bereits ein aktives Profil (oft ein DHCP-Profil aus der Installation), daher ändert sich auf der Leitung noch nichts. Lesen Sie es zurück, bevor Sie committen:

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

Liest es so zurück, wie Sie es gemeint haben, aktivieren Sie es:

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

Das ist die gefährliche Zeile, und die Stelle, an der Sie langsamer machen sollten. Dieses Profil zu aktivieren deaktiviert, was auch immer Ihre Sitzung getragen hat. Ist das Gateway falsch oder kollidiert die Adresse, bricht SSH ab und kommt nicht zurück, denn das Werkzeug, mit dem Sie es reparieren würden, ist genau das, was Sie gerade kaputt gemacht haben. Zwei Gewohnheiten halten das sicher: Stellen Sie sicher, dass die Werte stimmen, indem Sie sie zuerst zurücklesen, und halten Sie die IPMI oder serielle Konsole des Servers in einem anderen Fenster offen, bevor Sie Enter drücken. NetworkManager macht ein rohes nmcli con up nicht für Sie rückgängig; die Konsole ist Ihr Undo.

Um später eine Eigenschaft zu ändern, ändern Sie sie und aktivieren Sie erneut:

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

Die con mod-Zeile wird gespeichert, bleibt aber inert. Die con up-Zeile ist es, die es auf die Leitung bringt.

Auslesen, was NetworkManager weiß

Vier Befehle beantworten fast jede "was ist hier los"-Frage.

nmcli device status ist das Erste, was Sie auf jedem Server ausführen. Eine Zeile pro Interface: Typ, ob NetworkManager es verwaltet, und welches Profil aktiv ist.

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

nmcli con show listet gespeicherte Profile auf, ob aktiv oder nicht. Fügen Sie einen Namen hinzu, um alle Eigenschaften eines Profils auszugeben; so sehen Sie, was ein Profil tun wird, bevor Sie es aktivieren:

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

Die -f-Flag wählt Felder aus, damit Sie nicht durch zweihundert Zeilen scrollen müssen, und -g (get) gibt einen einzelnen Wert ohne Header aus, genau das, was Sie in einem Skript wollen:

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

Die Ausgabe oben ist illustrativ; UUIDs und die genaue Spaltenbreite unterscheiden sich je nach Version und Host.

nmtui für ein Formular statt Flags

Wenn Sie lieber ein Formular ausfüllen, als sich Eigenschaftsnamen zu merken, ist nmtui das Curses-Frontend für dieselbe Engine. Führen Sie es über SSH oder an der Konsole aus, und Sie erhalten drei Optionen: eine Verbindung bearbeiten, eine Verbindung aktivieren, und den System-Hostnamen setzen. Der Verbindungs-Editor bietet IPv4- und IPv6-Adressierung, DNS und die Felder für Bonds, Bridges und VLANs, sodass ein statisches Setup möglich ist, ohne nmcli überhaupt anzufassen. Steigen Sie direkt ein mit nmtui edit enp1s0 oder nmtui connect.

Die Grenzen sind gut zu kennen. nmtui lässt sich nicht scripten, und es zeigt nicht jede Eigenschaft: Routing-Regeln, Dispatcher-Skripte und die obskureren Einstellungen brauchen weiterhin nmcli oder eine manuelle Keyfile-Bearbeitung. Als geführter Weg zurück, wenn Sie das Netzwerk verloren haben und an einer Konsole sitzen, verdient es seinen Platz.

nmcli Cheat Sheet

Die Befehle, die Sie am häufigsten brauchen, mit static-enp1s0 stellvertretend für Ihren Profilnamen:

Wer standardmäßig NetworkManager nutzt

Welchen Stack Sie bekommen, ist meist eine Folge der installierten Distribution, einer separaten Entscheidung von dieser hier (behandelt in unserem Leitfaden zur Wahl einer Linux-Distribution). Die Aufteilung, wie sie 2026 aussieht:

Die Debian-Server-Zeile bringt Leute zu Fall. Installieren Sie network-manager auf einem Debian-Server, der bereits ifupdown nutzt, übernimmt es die bestehenden Interfaces nicht; alles, was in /etc/network/interfaces deklariert ist, bleibt bei seinem alten Renderer und erscheint in nmcli als unmanaged. Das ist Absicht, und es ist der sichere Standard.

VLANs, Bonds und Bridges

Drei Servermuster gehen über eine einzelne flache Adresse hinaus. Jedes ist ein Profiltyp, und die Syntax ähnelt dem statischen Beispiel.

Ein VLAN legt getaggten Traffic auf ein virtuelles Interface, das über einem physischen liegt. Das fügt VLAN 40 auf enp1s0 mit eigener Adresse hinzu:

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

Das übergeordnete enp1s0 trägt weiterhin ungetaggten Traffic. Der Switch-Port muss ein Trunk sein, der VLAN 40 durchlässt, sonst kommen die getaggten Frames nirgendwo an.

Ein Bond bündelt zwei NICs zu einem logischen Link. LACP (mode 802.3ad) ist die gängige Serverwahl für Durchsatz und 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 wird ausgehandelt, nicht einseitig festgelegt. Der Switch braucht eine passende Link-Aggregation-Gruppe auf diesen zwei Ports, sonst bleibt der Bond down. Setzen Sie die Adressierung auf bond0, nie auf die Member-Ports.

Eine Bridge macht aus dem Host einen virtuellen Switch, was ein KVM-Hypervisor braucht, damit seine Gäste das Netzwerk direkt erreichen. Die Host-IP zieht auf die Bridge um, und die physische NIC wird zu einem Port ohne eigene Adresse:

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

Die Host-Adresse über SSH auf eine Bridge umzuziehen ist dasselbe Aussperrrisiko wie jede Reaktivierung, nur schärfer, weil Sie das Interface umbauen, auf dem die Sitzung reitet. Bauen Sie es von der Konsole aus, oder auf einer zweiten NIC, über die Sie nicht eingeloggt sind. Das ist dieselbe Bridge, die Proxmox als vmbr0 einrichtet; hier bauen Sie sie von Hand.

Troubleshooting

• Ein Device zeigt unmanaged. NetworkManager wurde angewiesen, es zu ignorieren. Suchen Sie in /etc/NetworkManager/NetworkManager.conf und /etc/NetworkManager/conf.d/*.conf nach einer Zeile managed=false oder einem [device-*]-Abschnitt mit managed=0. Unter Debian zeigen in /etc/network/interfaces definierte Interfaces absichtlich als unmanaged. Um ein Device für die Sitzung zurückzugeben: nmcli device set enp1s0 managed yes; damit es dauerhaft bleibt, entfernen Sie die Konfiguration, die es ausgeschlossen hat.
• Eine Änderung wurde nicht angewendet. Fast immer eines von zwei Dingen: Sie haben con mod ausgeführt, aber nie con up, sodass die Änderung gespeichert und inert ist, oder Sie haben eine Keyfile von Hand bearbeitet und nie nmcli con reload ausgeführt, sodass der Daemon noch auf der alten Kopie arbeitet. Keines von beiden schlägt laut fehl. Beides klärt sich in dem Moment, in dem Sie aktivieren.
• Gespeichert und live stimmen nicht überein. ip addr und ip route zeigen, was der Kernel in diesem Moment tut; nmcli -f all con show <name> zeigt, was das Profil beim nächsten Hochfahren tun wird. Stimmt die Adresse auf der Leitung nicht mit dem Profil überein, steht eine Aktivierung aus, das ist kein Bug.
• Nichts davon erklärt es. Lesen Sie das eigene Log des Daemons: journalctl -u NetworkManager -b für diesen Boot, oder -f, um es live in einem Fenster zu verfolgen, während Sie in einem anderen con up ausführen. NetworkManager ist gesprächig darüber, warum eine Aktivierung fehlgeschlagen ist, und der Grund steht meist in den letzten paar Zeilen.

nmstate, die deklarative Schicht

Für große Serverbestände, und für alle, die den Zielzustand lieber beschreiben, als Schritte auszuführen, liefert Red Hat nmstate und dessen Befehl nmstatectl. Sie schreiben das gewünschte Netzwerk als YAML, führen nmstatectl apply aus, und nmstate steuert NetworkManager (sein einziges Backend), um das zu erreichen. Was es auf einem entfernten Server lohnenswert macht, ist der Rollback: Wenden Sie einen Zustand an, der die Konnektivität bricht, und nmstate setzt sich von selbst auf den vorherigen zurück, was ein rohes nmcli con up nicht tut. Es ist auf RHEL 8, 9 und 10 verfügbar, und es ist das, was die RHEL System Role für Networking im Hintergrund nutzt. Für eine einzelne Maschine reicht nmcli. Muss dieselbe Konfiguration identisch und sicher auf fünfzig Servern landen, ist nmstate die dafür gebaute Schicht.

Ubuntu Server nutzt Netplan, nicht NetworkManager

Wenn Sie auch Ubuntu-Server betreiben, gilt dort standardmäßig nichts vom obigen nmcli. Ubuntu Server liefert Netplan, das nach systemd-networkd schreibt, konfiguriert in /etc/netplan/*.yaml, ohne dass NetworkManager im Spiel ist. Ubuntu Desktop nutzt ebenfalls Netplan, aber mit NetworkManager als Renderer, sodass nmcli dort funktioniert. Die Konzepte übertragen sich (deklarierte Konfiguration, ein Aktivierungsschritt, eine Trennung zwischen gespeichert und live), aber das Tool und die Dateien unterscheiden sich. Der Netplan Crash Course ist der Schwesterartikel zu diesem Leitfaden für diese Seite des Serverparks.

Deployment auf Serverside

Ein NetworkManager-Profil ist nur so nützlich wie das Netzwerk, auf das es zeigt. Serverside betreibt sein eigenes Netzwerk (AS55285), sodass ein RHEL-, AlmaLinux- oder Rocky-Server in unter einer Minute provisioniert wird, und die öffentliche IPv4- und IPv6-Adresse, die Sie konfigurieren, steht ab dem ersten Boot hinter permanent aktiver DDoS-Mitigation. Die RHEL Dedicated-Reihe liefert die RHEL-Familie fertig für den nmcli-Workflow oben, und das breitere Dedicated-Angebot deckt den Rest ab.

Verwandte Lektüre: der Vergleich AlmaLinux versus RHEL-Abonnement, wenn Sie eine Lizenz gegen einen kostenlosen Rebuild abwägen, und die Linux-Server-Hardening-Checkliste, um sie auszuführen, sobald das Interface up und erreichbar ist.

Häufig gestellte Fragen

Warum hat meine IP-Änderung einen Neustart nicht überstanden?

Drei übliche Ursachen. Beim Profil ist autoconnect deaktiviert, sodass beim Booten nichts aktiviert wird: setzen Sie connection.autoconnect yes. Sie haben das Profil mit nmcli con mod geändert, aber nie nmcli con up ausgeführt, sodass die Änderung gespeichert, aber nie angewendet wurde. Oder Sie haben die Keyfile von Hand bearbeitet und nie nmcli con reload ausgeführt, sodass NetworkManager weiter die beim Start eingelesene Kopie verwendet hat. Das Profil nach der Änderung zu aktivieren behebt alle drei Fälle.

Sollte ich die .nmconnection-Dateien von Hand bearbeiten oder nmcli verwenden?

Beides funktioniert, und die Keyfile ist in beiden Fällen die Source of Truth. nmcli prüft die übergebenen Werte und lädt das Profil für Sie neu, daher ist es die sicherere Standardwahl. Wenn Sie die Datei direkt bearbeiten, lassen Sie sie root gehören und setzen Sie die Berechtigung auf 600, führen Sie danach nmcli con reload aus, damit der Daemon die Änderung übernimmt. NetworkManager überwacht das Verzeichnis nicht von sich aus.

Wie hindere ich NetworkManager daran, ein Interface zu verwalten?

Für die aktuelle Sitzung führen Sie nmcli device set enp1s0 managed no aus. Damit es Neustarts übersteht, fügen Sie einer Datei unter /etc/NetworkManager/conf.d/ einen [device-*]-Abschnitt mit managed=0 hinzu. Das kommt vor, wenn ein anderes Tool eine bestimmte NIC verwaltet, oder unter Debian, wo in /etc/network/interfaces definierte Interfaces absichtlich unmanaged bleiben.

Habe ich unter RHEL noch ifcfg-Dateien?

Das hängt von der Version ab. RHEL 8 schrieb standardmäßig noch ifcfg-Dateien. RHEL 9 liest bestehende Dateien weiterhin, schreibt neue Profile aber als Keyfiles und markiert das ifcfg-Format als deprecated. RHEL 10 entfernte das ifcfg-Plugin ab Mai 2025 vollständig und ignoriert diese Dateien. Auf RHEL 9 und 10 zählen die Keyfiles unter /etc/NetworkManager/system-connections.

NetworkManager oder systemd-networkd für einen Server?

Bei der RHEL-Familie wird die Entscheidung für Sie getroffen: NetworkManager ist der Standard und der einzige unterstützte Stack, und er handhabt statische Serveradressierung problemlos. Ubuntu Server geht den anderen Weg und nutzt systemd-networkd über Netplan. Beide sind production-grade. Nutzen Sie, was Ihre Distribution mitbringt, statt es zu ersetzen.