Configurer le réseau avec NetworkManager

Sur un serveur RHEL 9 ou 10, ainsi que sur ses dérivés Rocky Linux et AlmaLinux, la configuration réseau ne passe ni par /etc/network/interfaces ni par Netplan : elle passe par NetworkManager, piloté en ligne de commande avec nmcli. À la fin de cette page, vous saurez créer une connexion en adresse IP statique, la rendre persistante après reboot, monter un bridge ou un bond, et diagnostiquer une interface qui refuse de monter. Le guide vise les administrateurs de niveau intermédiaire qui exploitent des serveurs de la famille Red Hat, et il couvre une compétence directement évaluée à l'examen RHCSA.

Ce que vous allez apprendre

• Identifier quel gestionnaire pilote réellement vos interfaces avant de toucher à quoi que ce soit.
• Créer une connexion Ethernet en DHCP puis en adresse IP statique avec nmcli.
• Vérifier qu'une configuration est bien persistante et survit à un redémarrage.
• Assembler un bridge de virtualisation et un bond de deux liens physiques.
• Diagnostiquer une interface unmanaged, une passerelle absente ou une résolution DNS cassée.

Prérequis et portée

Cette page est une procédure : elle suppose que vous avez déjà un accès sudo sur une machine de la famille Red Hat et que vous savez lire une sortie de systemctl. Les manipulations touchent au réseau de la machine, donc travaillez sur une VM jetable ou gardez un accès console de secours, jamais uniquement une session SSH.

Élément	Valeur
Parcours / bloc	Exploiter, réseau
Niveau	L2 (opérationnel), RHCSA
Portée	Spécifique RHEL (socle commun quand NetworkManager est installé ailleurs)
Version testée	nmcli 1.54.3 sur Rocky Linux 9
Capacité démontrée	Configurer une IP statique persistante et la vérifier après reboot

Glissez pour voir

Compétence RHCSA

L'objectif « configurer la mise en réseau et la résolution de noms de manière statique ou dynamique » de l'examen EX200 se traite entièrement avec nmcli. Le jury évalue la persistance : une adresse posée à la main avec ip addr add disparaît au reboot et ne vaut aucun point. Tout ce qui suit vise donc la connexion NetworkManager, pas l'état volatil de l'interface.

Pourquoi NetworkManager est le standard côté serveur

Beaucoup d'administrateurs associent encore NetworkManager au poste de travail, à cause du petit icône Wi-Fi dans la barre des tâches. C'est une lecture datée : depuis RHEL 8, les anciens scripts ifcfg du paquet network-scripts ont été dépréciés, puis retirés de RHEL 9. Sur une installation minimale de Rocky 9 ou d'AlmaLinux 9, sans aucun environnement graphique, NetworkManager est le seul gestionnaire présent et il démarre par défaut.

Le modèle qu'il impose est utile à comprendre avant de taper la première commande. NetworkManager sépare le périphérique (la carte physique, enp1s0) de la connexion (le profil de configuration, par exemple enp1s0-static). Vous ne configurez jamais une carte : vous créez un profil persistant, et vous l'activez sur une carte. C'est ce découplage qui permet d'avoir plusieurs profils pour une même interface et d'en changer sans réécrire de fichier.

Et sur Debian ou Ubuntu Server ?

NetworkManager y est disponible, mais ce n'est pas le chemin par défaut : Ubuntu Server passe par Netplan, qui délègue à systemd-networkd. Si vous administrez ces machines, le guide Configurer le réseau avec Netplan décrit l'outillage adapté. Les commandes nmcli de cette page restent valables sur Debian ou Ubuntu si NetworkManager y est bien le gestionnaire actif, ce que la section suivante vous apprend à vérifier.

Vérifier quel gestionnaire pilote vos interfaces

Avant toute modification, identifiez qui tient le volant. Deux gestionnaires actifs en même temps se disputent les mêmes cartes et produisent des configurations qui « sautent » sans raison apparente. La commande suivante tranche en une passe :

if systemctl is-active --quiet NetworkManager; then
  echo "NetworkManager gère le réseau"
elif systemctl is-active --quiet systemd-networkd; then
  echo "systemd-networkd gère le réseau"
elif [ -d /etc/netplan ]; then
  echo "Netplan est probablement utilisé comme frontend"
else
  echo "Aucun gestionnaire de réseau connu n'est actif"
fi

Ce test interroge d'abord les deux démons candidats, puis se rabat sur la présence du répertoire /etc/netplan, indice d'un frontend Netplan. Sur un serveur Rocky 9 fraîchement installé, la sortie attendue est :

NetworkManager gère le réseau

Si c'est bien ce que vous lisez, vous êtes dans le cas nominal de RHEL, Rocky, Alma et Fedora : suivez ce guide tel quel. Si un autre gestionnaire répond, systemd-networkd ou l'ancien ifupdown d'une Debian historique, c'est lui qui pilote vos interfaces, et les commandes nmcli de cette page n'auront aucun effet durable.

Ne désactivez pas un gestionnaire à l'aveugle

Désactiver le gestionnaire qui pilote actuellement vos interfaces coupe le réseau de la machine. Sur un serveur distant, vous perdez la main, et il faut un accès console pour la récupérer.

Avant de basculer d'un gestionnaire à l'autre, préparez la configuration d'arrivée, gardez un accès console (console cloud, IPMI, hyperviseur), et faites la bascule dans une fenêtre planifiée. Sur une machine qui fonctionne, le bon réflexe est d'utiliser le gestionnaire déjà en place, pas de le remplacer.

Comment fonctionne NetworkManager

Un démon, plusieurs clients

Au centre du dispositif tourne un démon système nommé NetworkManager. Il détient l'état du réseau, applique les profils de connexion, réagit aux événements matériels (câble branché, carte détectée) et parle aux services annexes comme le DHCP ou le DNS. Tous les outils que vous utilisez, nmcli, nmtui ou la console web Cockpit, ne configurent rien eux-mêmes : ce sont des clients qui envoient des ordres à ce démon.

Cette communication passe par D-Bus, le bus de messages interprocessus de Linux. C'est ce qui permet à un greffon VPN ou à Cockpit de manipuler vos connexions sans jamais écrire directement dans les fichiers de configuration.

ConnMan et Wicd ne sont pas des clients de NetworkManager

On lit parfois que ConnMan ou Wicd dialogueraient avec NetworkManager via D-Bus. C'est faux : ce sont des gestionnaires réseau concurrents, qui remplacent NetworkManager au lieu de s'y brancher. ConnMan reste utilisé dans l'embarqué et sur certaines distributions légères ; Wicd est un projet abandonné (resté sur Python 2) qu'il ne faut plus déployer. Faire tourner NetworkManager et ConnMan en parallèle sur la même machine crée exactement le conflit décrit plus haut.

Les outils de pilotage, par ordre d'utilité serveur

Sur un serveur, la hiérarchie est claire et elle ne ressemble pas à celle d'un poste de travail. nmcli est l'outil de référence : scriptable, exhaustif, utilisable sur une session SSH, c'est le seul qui compte pour le RHCSA et pour l'automatisation. nmtui est une interface texte qui rend service en console de secours ou quand un collègue moins à l'aise doit corriger une IP dans l'urgence. Les applets graphiques (GNOME, KDE, nm-applet) existent, mais supposent un environnement de bureau : ils n'ont pas leur place sur une installation serveur minimale.

Les services annexes gérés au passage

NetworkManager ne se contente pas de poser des adresses. Il pousse les serveurs DNS obtenus par DHCP ou définis dans le profil vers /etc/resolv.conf, le fichier que les applications consultent pour résoudre les noms, souvent en coordination avec systemd-resolved. Il embarque également des greffons VPN (OpenVPN, WireGuard, IPsec) et sait exposer une interface Wi-Fi en point d'accès, deux fonctions plus marginales sur un serveur en rack.

Installer et activer NetworkManager

Sur une installation standard de RHEL, Rocky ou Alma, NetworkManager est déjà présent et actif : cette section ne vous concerne que sur un système minimaliste, une image de conteneur ou une distribution où il faut l'ajouter. Commencez toujours par vérifier avant d'installer quoi que ce soit :

systemctl status NetworkManager

Une ligne Active: active (running) signifie que le service tourne déjà : passez directement à la configuration. Si la commande répond Unit NetworkManager.service could not be found, installez le paquet.

RHEL/Rocky/Alma

sudo dnf install NetworkManager

Debian/Ubuntu

sudo apt update
sudo apt install network-manager

openSUSE

sudo zypper install NetworkManager

Le nom du paquet change d'une famille à l'autre (NetworkManager avec les majuscules côté Red Hat, network-manager côté Debian), mais le nom de l'unité systemd reste NetworkManager partout. Activez-la pour qu'elle démarre au boot, puis lancez-la :

sudo systemctl enable --now NetworkManager

L'option --now combine le enable (démarrage automatique au boot) et le start (démarrage immédiat). Vérifiez ensuite les deux dimensions, l'activation au démarrage et l'état courant :

systemctl is-enabled NetworkManager
systemctl is-active NetworkManager

Les deux commandes doivent répondre respectivement enabled et active. Un enabled sans active signale un démon qui plantera au prochain reboot : inspectez journalctl -u NetworkManager avant d'aller plus loin.

Configurer une connexion avec nmcli

Toute la suite repose sur trois sous-commandes qu'il faut distinguer : nmcli device parle des cartes physiques, nmcli connection parle des profils persistants, et nmcli general parle de l'état global. La confusion entre device et connection est la première source d'erreur chez les débutants.

Dresser l'état des lieux

Avant de créer un profil, regardez ce que le démon voit :

nmcli device status

Sur un serveur Rocky 9 avec une seule carte, la sortie ressemble à ceci :

DEVICE  TYPE      STATE      CONNECTION
enp1s0  ethernet  connected  enp1s0
lo      loopback  unmanaged  --

La colonne STATE est celle qui compte. Un connected indique une carte pilotée et active ; un disconnected une carte reconnue mais sans profil actif ; un unmanaged une carte que NetworkManager a délibérément laissée de côté, souvent parce qu'un autre gestionnaire la revendique. L'interface de loopback lo apparaît en unmanaged sur les versions antérieures à NetworkManager 1.42 : c'est normal et sans conséquence.

Créer une connexion en DHCP

Le cas le plus simple laisse un serveur DHCP attribuer l'adresse. Créez le profil, puis activez-le :

sudo nmcli connection add type ethernet ifname enp1s0 con-name enp1s0-dhcp autoconnect yes
sudo nmcli connection up enp1s0-dhcp

Chaque mot-clé porte un rôle précis : type ethernet fixe la nature du lien, ifname enp1s0 désigne la carte cible, con-name enp1s0-dhcp nomme le profil (ce nom est ce que vous manipulerez ensuite), et autoconnect yes demande son activation automatique au démarrage. Sans propriété IPv4 explicite, NetworkManager retient ipv4.method auto, c'est-à-dire le DHCP.

Vérifiez que l'adresse a bien été obtenue :

nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway connection show enp1s0-dhcp
ip addr show enp1s0

Créer une connexion en adresse IP statique

C'est le cas de référence sur un serveur, et celui que l'examen RHCSA attend. Deux commandes suffisent, la première pose l'adresse et la passerelle, la seconde ajoute les résolveurs :

sudo nmcli connection add type ethernet ifname enp1s0 con-name enp1s0-static \
  ip4 192.168.1.50/24 gw4 192.168.1.1
sudo nmcli connection modify enp1s0-static ipv4.dns "192.168.1.10 192.168.1.11"
sudo nmcli connection up enp1s0-static

Le raccourci ip4 mérite une explication, car il fait une chose de plus que ce qu'il annonce : renseigner ip4 bascule automatiquement ipv4.method sur manual. Vous n'avez donc pas besoin d'ajouter ipv4.method manual à la main, contrairement à ce qu'on lit souvent. Les deux serveurs DNS sont passés dans une seule chaîne entre guillemets, séparés par une espace.

La vérification ne consiste pas à faire un ping, mais à relire le profil enregistré, car c'est lui qui sera rejoué au reboot :

nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns,connection.autoconnect \
  connection show enp1s0-static

La sortie attendue, obtenue sur Rocky 9, confirme les quatre paramètres :

ipv4.method:                            manual
ipv4.addresses:                         192.168.1.50/24
ipv4.gateway:                           192.168.1.1
ipv4.dns:                               192.168.1.10,192.168.1.11
connection.autoconnect:                 yes

Le connection.autoconnect: yes est la ligne la plus importante de ce guide : c'est elle, et elle seule, qui garantit que la configuration revient après un redémarrage.

Confirmer la persistance après reboot

Un profil correct sur le papier peut ne jamais remonter. Le seul test qui fait foi est le redémarrage réel de la machine, à faire sur une VM jetable et jamais sur un serveur distant sans accès console :

sudo reboot

Une fois la machine revenue, contrôlez que la connexion s'est réactivée d'elle-même et que l'adresse est bien posée :

nmcli connection show --active
ip addr show enp1s0
ip route

La connexion enp1s0-static doit apparaître dans les connexions actives, l'adresse 192.168.1.50/24 sur la carte, et une route par défaut via 192.168.1.1 dans la table de routage. Si l'un des trois manque, la section Dépannage plus bas vous donne la piste correspondante.

Modifier une connexion existante

Vous corrigerez plus souvent un profil que vous n'en créerez. nmcli connection modify écrit dans la configuration, mais n'applique rien à chaud : la modification ne prend effet qu'après réactivation du profil.

sudo nmcli connection modify enp1s0-static ipv4.addresses 192.168.1.51/24
sudo nmcli connection up enp1s0-static

Cet oubli du connection up est le grand classique du dépannage : la sortie de nmcli connection show affiche la nouvelle valeur, ip addr affiche encore l'ancienne, et l'administrateur croit à un bug. Il n'y en a pas, la configuration et l'état courant sont simplement deux choses distinctes.

Monter un bridge pour la virtualisation

Un bridge est un commutateur logiciel : il permet à des machines virtuelles (KVM, Incus, conteneurs) de se présenter directement sur le réseau physique. La construction se fait en trois temps, le pont, le port, puis l'adressage :

sudo nmcli connection add type bridge ifname br0 con-name br0
sudo nmcli connection add type ethernet ifname enp2s0 con-name br0-port1 controller br0
sudo nmcli connection modify br0 ipv4.method manual \
  ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "192.168.1.10"
sudo nmcli connection up br0

Le mot-clé controller rattache la carte physique au pont. Il remplace l'ancien master, encore accepté comme alias historique par nmcli 1.54 mais absent de l'aide en ligne : sur RHEL 9 et 10, écrivez controller. Notez aussi que l'adresse IP est portée par le bridge, jamais par la carte physique qui lui est rattachée.

Vérifiez que le port est bien rattaché et que le pont porte l'adresse :

nmcli -f connection.controller,connection.port-type connection show br0-port1
ip addr show br0

Agréger deux liens avec un bond

Un bond agrège plusieurs cartes en une seule interface logique, pour la tolérance de panne ou pour le débit. Le mode active-backup est le plus sûr et ne demande rien au commutateur en face :

sudo nmcli connection add type bond ifname bond0 con-name bond0 mode active-backup
sudo nmcli connection add type ethernet ifname enp2s0 con-name bond0-port1 controller bond0
sudo nmcli connection add type ethernet ifname enp3s0 con-name bond0-port2 controller bond0
sudo nmcli connection modify bond0 ipv4.method manual \
  ipv4.addresses 192.168.1.60/24 ipv4.gateway 192.168.1.1 ipv4.dns "192.168.1.10"
sudo nmcli connection up bond0

En active-backup, une seule carte transporte le trafic et la seconde prend le relais si le lien tombe. Les autres modes (802.3ad pour du LACP, balance-rr) exigent une configuration côté commutateur et sortent du cadre de cette page.

La vérification passe par le pseudo-fichier exposé par le noyau, qui indique la carte active et l'état de chaque membre :

cat /proc/net/bonding/bond0

Se connecter à un réseau Wi-Fi

Le Wi-Fi reste anecdotique en salle machine, mais il rend service sur un laboratoire ou un mini-serveur. nmcli crée le profil et l'active en une seule commande :

nmcli device wifi list
sudo nmcli device wifi connect "MonSSID" password "motdepassewifi"

Le profil créé est persistant comme les autres. Attention toutefois : le mot de passe passé en argument atterrit dans l'historique du shell. Préférez nmtui, ou purgez la ligne concernée, si la machine est partagée.

Où NetworkManager stocke ses connexions

Chaque profil créé avec nmcli est écrit dans un fichier keyfile sous /etc/NetworkManager/system-connections/, le répertoire où vit la configuration réseau persistante de la machine. C'est ce répertoire qu'il faut sauvegarder avant une migration, et c'est lui que le démon relit au démarrage.

ls -l /etc/NetworkManager/system-connections/

La sortie réelle sur Rocky 9 montre le point de sécurité important, les permissions 0600 :

-rw------- 1 root root 233 Jul 12 07:37 enp1s0-static.nmconnection

Seul root peut lire ces fichiers, ce qui est indispensable puisqu'ils contiennent les secrets (clés Wi-Fi, identifiants VPN, mots de passe 802.1X) en clair. Le contenu est un simple format INI, ici celui du profil statique créé plus haut :

[connection]
id=enp1s0-static
uuid=955bae20-d352-4e2b-b36c-0226e5763708
type=ethernet
interface-name=enp1s0

[ipv4]
address1=192.168.1.50/24
gateway=192.168.1.1
method=manual

[ipv6]
addr-gen-mode=default
method=auto

Éditer ces fichiers à la main reste possible, mais ce n'est pas le chemin recommandé : le démon garde sa propre vision en mémoire et vous risquez de travailler dans le vide. Si vous y touchez malgré tout, par exemple pour déployer une configuration standardisée par Ansible, forcez la relecture :

sudo nmcli connection reload
nmcli connection show

Le fichier global /etc/NetworkManager/NetworkManager.conf reste le lieu des réglages de comportement du démon, notamment le choix du gestionnaire DNS :

[main]
dns=systemd-resolved

Ce réglage indique à NetworkManager de déléguer la résolution à systemd-resolved au lieu d'écrire lui-même /etc/resolv.conf. Toute modification de ce fichier demande un sudo systemctl reload NetworkManager pour être prise en compte.

Sécurité et points de vigilance

Le réseau est le premier vecteur d'exposition d'un serveur, et NetworkManager en est la porte d'entrée. Trois réflexes limitent les dégâts.

Protégez d'abord les secrets : les fichiers .nmconnection sont en 0600 par défaut, ne les recopiez jamais dans un dépôt Git et ne les ouvrez pas en lecture au groupe. Ensuite, gardez toujours un chemin de repli avant de modifier la connexion qui porte votre session SSH : une console hyperviseur, une console cloud ou un accès IPMI. Une adresse mal saisie sur connection up vous éjecte instantanément, et aucune commande ne vous ramènera.

Enfin, souvenez-vous que NetworkManager ne filtre rien : il pose des adresses et des routes, pas des règles de pare-feu. Sur RHEL, Rocky et Alma, le filtrage reste le travail de firewalld, à configurer séparément. Une interface correctement adressée est une interface joignable, y compris par ce que vous ne voulez pas voir arriver.

En cas de fausse manœuvre, le rollback est immédiat tant que l'ancien profil existe encore : réactivez-le et supprimez le fautif.

sudo nmcli connection up enp1s0-dhcp
sudo nmcli connection delete enp1s0-static

Dépannage

Les pannes réseau sous NetworkManager se ramènent presque toujours à une poignée de symptômes. Le tableau suivant donne le diagnostic et la correction associés ; suivez toujours le même ordre d'investigation, du plus concret au plus abstrait : périphérique, puis connexion, puis journal, puis configuration.

Symptôme	Cause probable	Correction
L'interface apparaît unmanaged	Un autre gestionnaire (systemd-networkd, Netplan) revendique la carte, ou elle est exclue dans NetworkManager.conf	Identifier le gestionnaire actif (section plus haut), puis choisir lequel garder
nmcli connection show affiche la bonne IP, ip addr l'ancienne	Profil modifié mais jamais réactivé	sudo nmcli connection up <profil>
La configuration disparaît au reboot	connection.autoconnect à no, ou adresse posée avec ip addr add (volatile)	sudo nmcli connection modify <profil> connection.autoconnect yes
Connexion active mais aucun nom ne se résout	Résolveurs DNS absents du profil	sudo nmcli connection modify <profil> ipv4.dns "192.168.1.10" puis réactiver
Ping par IP fonctionne, rien d'autre ne sort	Passerelle par défaut absente	Vérifier ip route, corriger avec ipv4.gateway
Le bond ou le bridge reste sans porteuse	Ports créés sans controller, ou profils de ports jamais activés	Contrôler nmcli -f connection.controller connection show <port>

Glissez pour voir

Quand le tableau ne suffit pas, le journal du démon contient toujours la raison exacte du refus, échec DHCP, clé Wi-Fi rejetée, carte absente :

sudo journalctl -u NetworkManager -b --no-pager | tail -50

L'option -b limite au boot courant, ce qui évite de remonter des erreurs déjà résolues. Pour observer une panne en direct, laissez tourner sudo journalctl -u NetworkManager -f dans un terminal pendant que vous rejouez la commande fautive dans un autre.

Trois commandes complètent enfin le diagnostic de base et méritent d'être dans vos doigts : nmcli general status pour l'état global de la connectivité, ip route pour la route par défaut, et resolvectl status (ou un simple cat /etc/resolv.conf) pour les résolveurs effectivement utilisés.

Mettre en pratique

La différence entre un profil persistant et une adresse volatile ne se comprend vraiment qu'après un redémarrage. Le lab vous fait poser une IPv4 statique avec nmcli, contrôler connection.autoconnect, puis prouver au reboot que l'adresse, la passerelle et le DNS reviennent seuls.

Lab pratique

Configurer une IPv4 statique persistante avec NetworkManager

$ dsoxlab run l4-network-static-persist

Environnement : VM·Durée : ~25 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l4-network-static-persist
dsoxlab check l4-network-static-persist

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• NetworkManager est le gestionnaire réseau standard des serveurs RHEL 9 et 10, ainsi que de Rocky et Alma : les scripts ifcfg de network-scripts ont été retirés, il n'y a pas d'alternative par défaut.
• Distinguez le périphérique (nmcli device, la carte) de la connexion (nmcli connection, le profil persistant) : vous configurez toujours un profil, jamais une carte.
• Une adresse posée avec ip addr add est volatile ; seule une connexion NetworkManager avec connection.autoconnect yes survit au reboot. C'est le point noté au RHCSA.
• Le raccourci ip4 de nmcli connection add bascule déjà ipv4.method sur manual : inutile de le préciser en plus.
• nmcli connection modify n'applique rien à chaud. Tant que vous n'avez pas fait nmcli connection up, l'état courant reste l'ancien.
• Sur RHEL 9 et 10, rattachez les ports d'un bond ou d'un bridge avec controller : master n'est plus qu'un alias historique.
• Les profils vivent dans /etc/NetworkManager/system-connections/ en permissions 0600 et contiennent les secrets en clair : sauvegardez ce répertoire, ne le versionnez jamais.
• Ne désactivez jamais le gestionnaire actif à distance sans accès console de secours : vous couperiez le réseau de la machine et perdriez la main.

Articles qui pourraient vous intéresser

• Configurer le réseau sous Linux efficacement
• Configurer le réseau avec Netplan
• Gérer les interfaces réseau avec la commande ip
• Diagnostiquer un problème réseau sous Linux

×

📖 Voir la documentation →