Paramétrage réseau d’une machine cliente Debian Squeeze en IPv4

Dans cet article, nous allons voir la configuration réseau d'une machine cliente au sein d'un réseau local (en IPv4 uniquement) sur une Debian Squeeze minimaliste (pas d'environnement graphique). On va laisser ici de côté les connexions Wifi et n'envisager que le cas d'une connexion filaire Ethernet.

Pour faire cet article, je me suis largement inspiré de l'excellente documentation Référence Debian, disponible en français sur le site officiel de Debian (qui propose beaucoup de documentations intéressantes). Plus particulièrement, j'ai utilisé cette page.

Configuration IP des interfaces réseau

Pour voir les cartes réseau ainsi que leurs paramètres IP, il suffit de taper en ligne de commandes :

ifconfig

Au démarrage du système, l'activation et la configuration des cartes réseau se fait via le script /etc/init.d/networking qui supporte les arguments stop et start (mais pas restart). En simplifiant au maximum le contenu de ce script, on a ceci :

# Les deux commandes ci-dessous sont globalement équivalentes
/etc/init.d/networking start
ifup -a

# Les deux commandes ci-dessous sont globalement équivalentes
/etc/init.d/networking stop
ifdown -a --exclude=lo

Les commandes ifup et ifdown respectivement activent et désactivent les interfaces qui leurs sont passées en argument, l'option -a signifiant que toutes les interfaces sont concernées par ces commandes (à l'exception de celle précisée par l'option --exclude). En plus d'activer une interface réseau, la commande ifup la configure en allant chercher les paramètres dans le fichier /etc/network/interfaces (ou alors dans celui précisé par l'option --interfaces si celle-ci est spécifiée).

Le fichier de configuration /etc/network/interfaces est donc utilisé par le système au moment du démarrage pour effectuer le paramétrage IP des interfaces. Il est donc important de bien le renseigner. Avant de l'éditer, il faut bien penser à stopper le script /etc/network/interfaces. Une fois le fichier édité correctement, on peut alors lancer le script. Voici un exemple de configuration :

# The loopback interface
auto lo

iface lo inet loopback

# The first network card - this entry was created 
# during the Debian installation
# (network, broadcast and gateway are optional)
auto eth0

iface eth0 inet static
	address 192.168.0.13
	netmask 255.255.255.0
	network 192.168.0.0
	broadcast 192.168.0.255
	gateway 192.168.0.254

auto eth1

iface eth1 inet dhcp

Nous avons des instructions qui commencent avec le mot clé auto et d'autres qui commencent avec le mot clé iface :

  • Les instructions qui commencent avec auto énumèrent les interfaces qui seront activées et configurées au moment de l'appel de la commandes ifup -a (et donc par exemple au moment du démarrage du système).
  • Les instructions qui commencent avec iface précisent le paramétrage de chacune des interfaces. Dans l'exemple ci-dessus, eth0 est en IP statiques tandis que eth1 obtiendra ses paramètres via un serveur DHCP présent sur le réseau.

Il est également possible de modifier les paramètres IP d'une interface à la volée avec la commande ifconfig. Cela peut être utile pour faire des tests. Par exemple :

ifdown eth0 # On désactive eth0
# On la reconfigure avec ifconfig ce qui l'activera du même coup
ifconfig eth0 172.20.0.1 netmask 255.255.0.0 broadcast 172.20.255.255
ifconfig eth0 # pour afficher les nouveaux paramètres

Plutôt que de spécifier des IP statiques, on peut paramétrer eth0 via un serveur DHCP (s'il en existe un sur le réseau) par la commande :

ifdown eth0 # On désactive eth0
dhclient eth0 # On fait appel avec serveur DHCP
ifconfig eth0 # pour afficher les nouveaux paramètres

On peut également modifier la passerelle à l'aide de la commande route :

# On supprime l'ancienne passerelle
route del -net 192.168.0.0/24 gw 192.168.0.254
# et on en met une autre
route add -net 192.168.0.0/24 gw 192.168.0.251
# On affiche le résultat, la ligne commençant "default"
# donne la passerelle par défaut
route

Attention car toutes ces modifications sont temporaires. Après un simple :

/etc/init.d/networking stop
/etc/init.d/networking start

ou bien tout simplement après un redémarrage du système, on se retrouvera alors automatiquement avec les paramètres réseau inscrits dans le fichier /etc/network/interfaces.

Voici un peu de documentation :

man ifconfig
man route
man ifup # concerne aussi ifdown
man interfaces # syntaxe du fichier /etc/network/interfaces
man dhclient

Remarque : apparemment, d'après les documentations qu'on peut trouver sur le site officiel de Debian, les commandes ifconfig et route sont maintenant obsolètes et il faudra préférer la commande ip qui, à elle seule, permet de faire un peu tous les réglages IP possibles sur une interface.

Configuration du résolveur

Un résolveur est un programme qui se situe sur la machine locale et qui interface les applications utilisateur dans la communication avec les serveurs de noms d'hôtes, en général afin d'effectuer la résolution d'un nom d'hôte en une adresse IP. Il y a quatre fichiers qui interviennent dans la configuration du résolveur :

  • le fichier /etc/nsswitch.conf
  • le fichier /etc/hosts
  • le fichier /etc/host.conf
  • le fichier /etc/resolv.conf

Le fichier /etc/nsswitch.conf

Le système NSS (Name Service Switch) permet de définir les fichiers ou services d'annuaires qu'un programme doit interroger pour obtenir des informations. Ces requêtes peuvent concerner la résolution de noms FQDN, mais pas seulement. Cela peut concerner aussi la recherche d'identifiants (nom d'utilisateur et mot de passe) pour l'ouverture de session, la recherche des membres d'un groupe UniX etc. Beaucoup (et de plus en plus) de programmes Linux, dont le résolveur, font appel à NSS (via des appels de fonctions définies dans la bibliothèque standard du langage C). Pour voir la configuration de NSS concernant la résolution de noms d'hôtes, il faut regarder la ligne commençant par hosts dans le fichier /etc/nsswitch.conf :

$ grep -e '^hosts' /etc/nsswitch.conf 
hosts:          files dns

Avec une telle configuration, lors de la résolution d'un nom d'hôte, le résolveur consultera d'abord le fichier /etc/hosts, puis, si le nom n'a toujours pas été résolu, il fera appel à un serveur DNS.

Le fichier /etc/hosts

Le fichier /etc/hosts est donc un petite base locale de noms associés à des adresses IP. Voici un exemple de contenu possible :

# Adresse IP    Nom FQDN                      Alias
127.0.0.1       localhost
127.0.1.1       flpc.reseaulocal.invalid	  flpc monpc
192.168.0.10    serveur1.reseaulocal.invalid  seveur1
192.168.0.11    serveur2.reseaulocal.invalid  

Le fichier /etc/host.conf

Il est en général assez petit. Sur ma Debian Squeeze il contient juste ceci :
multi on

Cela signifie qu'en effectuant une recherche dans /etc/hosts, au lieu de renvoyer la première adresse IP correspondant au nom à résoudre, le résolveur renverra (au programme qui fait appel à ses services) toutes les IP trouvées dans le fichier qui correspondent au nom à résoudre. Avant l'utilisation de NSS, le fichier /etc/host.conf pouvait contenir l'instruction importante suivante :

order hosts, bind

Dans cet exemple, elle signifie que le résolveur doit d'abord consulter le fichier /etc/hosts puis ensuite consulter un serveur DNS. Mais maintenant que le résolveur utilise NSS, cette instruction est purement et simplement ignorée et en fin de compte c'est la ligne commençant par hosts dans le fichier /etc/nsswitch.conf qui compte et seulement elle. Le fichier /etc/host.conf n'est donc plus un fichier de configuration du résolveur d'une importance capitale. Il suffit de se contenter de son contenu par défaut.

Le fichier /etc/resolv.conf

Ce fichier va contenir quant à lui des informations cruciales. Il contiendra les adresses IP des serveurs DNS à contacter. Voici un exemple :

domain reseaulocal.invalid

# Premier DNS contacté
nameserver 212.27.40.240

# Deuxième DNS contacté si le premier n'est pas accessible
nameserver 212.27.40.241 

Avec le mot clé nameserver, on précise les adresses IP des serveurs DNS. L'instruction domain précise la chose suivante. Si le résolveur n'a pu résoudre un nom via le fichier /etc/hosts, alors il fait appel à un serveur DNS :

  • Si le nom est de la forme toto par exemple (c'est-à-dire qu'il n'est a priori pas sous sa forme FQDN), alors le résolveur demande au serveur DNS de résoudre le FQDN toto.reseaulocal.invalid. Si le serveur DNS contacté signale au résolveur que le nom n'existe pas, alors le résolveur fait une nouvelle requête au serveur DNS avec pour FQDN le nom toto « tout court » (c'est-à-dire l'hôte toto qui se trouve dans le domaine racine directement).
  • Si le nom est de la forme toto.truc par exemple (c'est-à-dire qu'il est a priori de la forme FQDN), alors le résolveur demande au serveur DNS de résoudre le FQDN toto.truc. Si le serveur DNS contacté signale au résolveur que le nom n'existe pas, alors le résolveur fait une nouvelle requête au serveur DNS avec pour FQDN le nom toto.truc.reseaulocal.invalid.

Pour s'en rendre compte par des tests, on peut utiliser la commande host :

$ host -v toto.truc # tentative de résolution

Trying "toto.truc"
Received 102 bytes from 212.27.40.240#53 in 38 ms
Trying "toto.truc.reseaulocal.invalid"
Host toto.truc not found: 3(NXDOMAIN)
Received 122 bytes from 212.27.40.240#53 in 38 ms

Il faut bien comprendre qu'à chaque fois que le résolveur fait une requête à un serveur DNS, c'est toujours une requête de la forme : « Cher serveur DNS, connais-tu un hôte dont le nom FQDN est XXX et si oui, quel est son IP ? » Bien sûr, dans l'exemple ci-dessus, la résolution n'aboutit pas mais ce qui nous intéresse ici est l'ordre des tentatives : d'abord toto.truc, puis ensuite toto.truc.reseaulocal.invalid. Attention, la commande host provoque une résolution DNS uniquement et ne passe pas par une consultation du fichier /etc/hosts.

Remarque : dans une Debian Squeeze de base, le résolveur ne possède pas de cache local et toutes modifications des fichiers précédents aura une incidence immédiate.

Maintenant, détaillons un exemple de résolution. Que se passe-t-il si par exemple, avec des fichiers de configuration identiques à ceux présentés plus haut, on tente la commande ci-dessous ?

ping serveur2

Le résolveur va être chargé de résoudre le nom serveur2. Il va donc d'abord consulter le fichier /etc/hosts et ne va rien trouver. En effet, via ce fichier, le résolveur pourrait résoudre serveur2.reseaulocal.invalid mais pas serveur2 « tout court » car dans la ligne en question il n'y a pas d'alias spécifié. Alors le résolveur va contacter le premier serveur DNS (si celui-ci est injoignable, il tentera le second) et lui demander de résoudre le nom FQDN serveur2.reseaulocal.invalid, puis, en cas de réponse négative du DNS, de résoudre le nom FQDN serveur2. Ici les serveurs DNS spécifiés sont ceux du FAI Free et a priori les noms d'hôtes recherchés n'existent pas. Du coup on aura sans doute :

$ ping serveur2

ping: unknown host serveur2

Le paquet resolvconf

Si le paquet resolvconf est installé alors le fichier /etc/resolv.conf devient un lien symbolique dont le contenu est géré automatiquement au moment de l'appel de la commande ifup, à condition que le fichier de configuration /etc/network/interfaces possède des instructions supplémentaires :

auto eth0
iface eth0 inet static
	address 192.168.0.13
	netmask 255.255.255.0
	network 192.168.0.0
	broadcast 192.168.0.255
	gateway 192.168.0.254
    dns-domain reseaulocal.invalid # à ajouter
    dns-nameservers 192.168.0.253  # à ajouter
    
# Ou bien directement via le DHCP si celui-ci est paramétré 
# pour envoyer les informations dns-domain et dns-nameservers
auto eth0
iface eth0 inet dhcp

En fait, le paquet resolvconf est intéressant surtout sur une machine dont l'interface réseau est paramétré en DHCP. Si c'est serveur en IP fixe, il vaut mieux s'en passer et utiliser la configuration via les fichiers comme expliquée avant.

Voici un peu de documentation sur tout ce qui touche au résolveur :

man nsswitch.conf
man hosts
man host.conf
man resolv.conf
man host

Paramétrage du nom de la machine locale

Une machine doit avoir un nom. Sur un réseau, ça semble évident, il faut même un nom FQDN. Mais même une machine connectée à aucun réseau doit avoir un nom propre (pas un nom FQDN, un simple nom, un peu comme un nom NETBIOS) car beaucoup d'applications utilisent ce nom. Par exemple, quand on cherche à ouvrir une session graphique via Gnome, le nom de la machine figure quelque part sur la fenêtre de connexion. Pour connaître le nom actuelle de la machine :

$ hostname 
squeeze # ici la machine s'appelle squeeze

On peut changer à la volée le nom d'une machine avec la commande :

hostname nouveauNom

Si on a un prompt qui affiche le nom de la machine (ce qui est très fréquent), celui-ci ne changera pas immédiatement. Il faudra fermer la session et en ouvrir une autre pour avoir un prompt en accord avec le nouveau nom :

root@squeeze % hostname nouveauNom
root@squeeze % hostname 
nouveauNom # le changement de nom a bien eu lieu
root@squeeze % exit

# Si on ouvre juste après une nouvelle session
# on aura le prompt suivant :
root@nouveauNom %

En revanche, si on redémarre la machine ou si l'on exécute :

/etc/init.d/hostname.sh stop
/etc/init.d/hostname.sh start

Alors la machine retrouvera son nom initial, à savoir celui qui se trouve dans le fichier /etc/hostname. Donc, s'il on souhaite changer le nom de la machine pour de bon, il faut éditer le fichier /etc/hostname, puis stopper et redémarrer le script /etc/init.d/hostname.sh (ou bien redémarrer la machine). Tout cela n'a rien de mystérieux car globalement le démarrage du script /etc/init.d/hostname.sh revient à faire ceci :

# On définit le nom de la machine avec commande hostname 
# en mettant comme argument le contenu de /etc/hostname
hostname $(cat /etc/hostname)

La commande hostname permet aussi d'obtenir le nom FQDN de la machine :

root@squeeze % hostname --fqdn
squeeze.reseaulocal.invalid

Mais attention, le mécanisme est ici très différent de celui sans l'option. Sans l'option, la commande va chercher l'information auprès du noyau Linux (information qui a été inscrite toujours avec cette même commande hostname au moment du démarrage de la machine via le script /etc/init.d/hostname.sh). Avec l'option --fqdn, le résultat affiché en sortie est le fruit de la résolution du nom indiqué par la commande hostname « tout court ». Explications :

# La commande hostname sans option va chercher l'information 
# auprès du noyau. Ici la machine s'appelle squeeze.
root@squeeze % hostname 
squeeze 

# Avec l'option --fqdn, la commande va chercher 
# l'information en cherchant à résoudre le nom squeeze, le nom
# qu'on a obtenu par l'appel de hostname « tout court » juste avant
root@squeeze % hostname --fqdn # Résolution du nom squeeze
squeeze.reseaulocal.invalid

On a déjà vu en détail précédemment comment un nom était résolu. Dans notre exemple, on peut imaginer que le résolveur parvient à résoudre le nom squeeze via un alias se trouvant dans le fichier /etc/hosts et dans ce cas, la commande hostname --fqdn retourne le FQDN qui est associé à cet alias dans le fichier. Si le fichier /etc/hosts n'a pas permis la résolution alors le résolveur va très certainement tenter la résolution via un serveur DNS comme décrit plus haut, c'est-à-dire en proposant au serveur DNS un ou des noms FQDN à la suite. Dès qu'un nom FQDN est résolu par le serveur DNS, la commande retourne alors ce nom FQDN. Mais si aucun des ces noms FQDN n'est résolu, alors on aura un résultat du genre :

$ hostname --fqdn
hostname: Name or service not known

Évidemment, le meilleur moyen de gérer les noms FQDN des machines d'un réseau de manière centralisée est d'administrer un serveur DNS. Mais chez soi, derrière sa FreeBox, nous ne sommes pas administrateur des DNS de chez Free et mettre en place son propre DNS dans son petit réseau local est sans doute un peu exagéré. Dans ce cas, si l'on tient absolument à ce que notre machine ait un nom FQDN pour elle-même, il suffit d'utiliser le fichier /etc/hosts et d'y mettre la ligne :

# Supposons que la machine s'appelle squeeze (autrement dit,
# le résultat de hostname est squeeze).
127.0.1.1   squeeze.reseaulocal.invalid    squeeze

# Si on mettait la ligne :
#127.0.1.1   toto.reseaulocal.invalid    squeeze
# alors hostname donnerait squeeze
# mais hostname --fqdn donnerait toto.reseaulocal.invalid
# Ça serait stupide de faire ainsi bien sûr.

Dans ce cas, la machine à ses yeux aura bien un FQDN qui sera :

$ hostname --fqdn
squeeze.reseaulocal.invalid
# Attention, cela fonctionnera à condition qu'on ait bien paramétré
# le résolveur pour qu'il consulte le fichier /etc/hosts.

En revanche, si on installe une deuxième machine de nom rita derrière sa FreeBox, le FQDN ci-dessus lui sera totalement inconnu puisque l'information se trouve dans le fichier /etc/hosts de la machine squeeze. Pour avoir des noms FQDN uniformément reconnus par les machines squeeze et rita, il faudra que chacune ait un fichier /etc/hosts identique et dûment complété. Mais dans un réseau avec un grand nombre de machines, la synchronisation des fichiers /etc/hosts n'est plus une solution valable et il faut penser à mettre en place un serveur DNS, mais ça c'est une autre histoire...

Voici un peu de documentation :

man hostname
Cette entrée a été publiée dans Réseau, avec comme mot(s)-clef(s) . Vous pouvez la mettre en favoris avec ce permalien.

Les commentaires sont fermés.