NetworkManager dans la pratique

Voici le cinquième et dernier article dans la série sur la prise en main de NetworkManager sur les serveurs CentOS et Red Hat. Je ne vous apprendrai rien de nouveau dans cet article. J’ai voulu fournir une vue d’ensemble avec une série d’exemples de mon quotidien professionnel. J’en profiterai pour fournir quelques mises en garde sur les points à vérifier.

Je me baserai sur la configuration des trois serveurs suivants.

• nestor.microlinux.lan : le serveur de sauvegardes de mon bureau
• proxy.microlinux.lan : mon routeur local
• alphajet.microlinux.fr : le serveur dédié qui héberge ce blog

Une fois que nous aurons vu en détail ces trois configurations, nous en profiterons pour parler de quelques points importants à vérifier.

Le serveur de sauvegardes

La machine nestor.microlinux.lan – un HP Proliant Microserver – dispose de deux interfaces réseau, mais je n’en utilise qu’une seule.

$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION 
enp2s0  ethernet  connected    LAN        
enp3s0  ethernet  unavailable  --         
lo      loopback  unmanaged    -- 

L’interface enp2s0 est reliée au réseau local.

$ nmcli con show
NAME  UUID                                  TYPE      DEVICE 
LAN   d99a2cf4-8576-3e56-993b-b18073ad169d  ethernet  enp2s0

La configuration de l’interface comporte l’adresse IP et la passerelle, mais pas les informations DNS.

Les informations DNS sont fournies par le fichier /etc/resolv.conf.

# /etc/resolv.conf
search microlinux.lan
nameserver 192.168.2.1

Quant à la configuration de l’interface enp2s0, elle est stockée dans le fichier ifcfg-LAN.

Le routeur local

Le routeur proxy.microlinux.lan – un routerboard PC Engines – est équipé de trois cartes réseau, et j’en utilise deux.

$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION 
enp1s0  ethernet  connected    WAN        
enp2s0  ethernet  connected    LAN        
enp3s0  ethernet  unavailable  --         
lo      loopback  unmanaged    --    

L’interface enp1s0 fait face à la Freebox, alors que l’interface enp2s0 est reliée au switch côté réseau local.

$ nmcli con show
NAME  UUID                                  TYPE      DEVICE 
WAN   b22b118d-6152-3295-a095-1154a6f056cb  ethernet  enp1s0 
LAN   c9489004-f823-42df-8d23-5c4ad1294220  ethernet  enp2s0 

On notera que l’adresse IP de la passerelle est définie côté WAN.

Côté réseau local, on a juste l’adresse IP de la carte.

Les informations DNS sont inscrites dans le fichier /etc/resolv.conf. Elles pointent vers le serveur Dnsmasq qui tourne sur le routeur.

# /etc/resolv.conf
nameserver 127.0.0.1

La configuration des interfaces est stockée dans des fichiers aux noms parlants.

$ ls -1 /etc/sysconfig/network-scripts/ifcfg-?AN
/etc/sysconfig/network-scripts/ifcfg-LAN
/etc/sysconfig/network-scripts/ifcfg-WAN

Le serveur dédié

La machine alphajet.microlinux.fr – un serveur dédié de chez Scaleway – dispose de deux interfaces réseau, mais je n’en utilise qu’une seule.

$ nmcli dev
DEVICE  TYPE      STATE         CONNECTION 
eth0    ethernet  connected     WAN        
eth1    ethernet  disconnected  --         
lo      loopback  unmanaged     --   

L’interface eth0 fournit une ouverture frontale sur Internet.

$ nmcli con show
NAME  UUID                                  TYPE      DEVICE 
WAN   f1f2025e-dbed-3596-b314-371972966e30  ethernet  eth0

Voici la configuration correspondante.

Là aussi, les informations DNS sont inscrites dans le fichier /etc/resolv.conf. Elles pointent vers le serveur BIND qui tourne sur la machine.

# /etc/resolv.conf
nameserver 127.0.0.1

Quant à la configuration de l’interface eth0, elle est stockée dans le fichier ifcfg-WAN.

Discussion et peaufinages

NetworkManager n’est pas exactement un outil simple qui obéit au principe KISS. Son maniement est assez idiosyncratique et parfois même un peu obtus. Quoi qu’il en soit, au bout de quelques jours j’ai fini par prendre le pli grâce à une bonne dose d’obstination.

Quelques remarques en vrac.

• C’est une bonne idée de désactiver les interfaces que l’on n’utilise pas.
• J’aime bien donner des noms parlants du genre WAN ou LAN aux profils de connexion.
• Pour plus de cohérence, ce n’est pas une mauvaise idée de stocker les configurations respectives dans des fichiers ifcfg-WAN ou ifcfg-LAN. Ce n’est pas strictement nécessaire, mais c’est plus parlant que ifcfg-Wired_Connection_3.
• À mon humble avis, c’est une bonne pratique d’inscrire les informations DNS uniquement dans le fichier /etc/resolv.conf et non pas dans la configuration des interfaces. Sur un routeur, c’est même obligatoire, sous peine de se retrouver confronté à toute une série de dysfonctionnements exaspérants.
• Vérifier à deux fois si la configuration manuelle du fichier /etc/resolv.conf ne se fait pas écraser par autre chose. C’est le cas lorsqu’on a oublié de supprimer la configuration DNS individuelle d’une interface.
• Une fois qu’on a basculé vers NetworkManager, on peut éventuellement vérifier si l’on n’a pas des résidus de configuration sur base de network-scripts, du genre une variable GATEWAY oubliée dans un fichier /etc/sysconfig/network.

Nous voilà donc prêts pour travailler sereinement avec les versions plus récentes de CentOS et Red Hat Enterprise Linux.

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.