Modèles de communication

Vous disposez de deux modèles de communication pour vous aider à diagnostiquer le dysfonctionnement d’une machine Linux connectée à un réseau :

le modèle OSI (Open Systems Interconnection),
le modèle TCP/IP (Transmission Control Protocol/Internet Protocol).

1. Rappel du modèle OSI

Avec les architectures SNA d’IBM, DNA de DEC, Appletalk d’Apple pour en citer quelques-unes, comment assurer l’interopérabilité ? D’autant plus que chacune possède ses propres protocoles de communication.

Pour éviter la multiplication des solutions d’interconnexion d’architectures hétérogènes, le modèle de communication OSI a été développé en 1984 par l’ISO (International Standards Organization). Il est constitué de 7 couches :

L’intérêt de créer un modèle est de :

garantir l’interopérabilité entre plusieurs technologies,
réduire la complexité,
uniformiser les interfaces,
permettre une évolution plus aisée,
faciliter la conception du fait de la modularité,
simplifier l’enseignement,
faciliter l’acquisition des connaissances...

Lors d’un diagnostic, vous pouvez vous appuyer sur ce modèle en commençant par la couche physique pour remonter jusqu’à...

Interface physique

1. Détection du matériel et du pilote

Si l’ordinateur n’a pas de communication réseau, vous pouvez commencer à vous poser ces questions :

La carte est-elle bien connectée et alimentée ?
Est-ce que la carte réseau est détectée par le système ?
Le pilote existe-t-il dans le système ? Si oui, est-il chargé ? Sinon, peut-on le charger ?
Si au contraire le pilote n’est pas présent, est-il disponible en téléchargement sur Internet ? Si oui, est-ce un code source à compiler et à installer en tant que module du noyau ? Sinon, il faudrait le développer ou plus simplement ajouter à l’ordinateur une interface de communication compatible avec le système d’exploitation Linux.

Exemple 1

Un ordinateur doté d’une carte réseau Intel ne communique pas. Lorsque vous utilisez ip address dans un terminal, seule l’interface de loopback (lo étant son nom logique) est présente :

[root@system2 ~]# 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN  
group default qlen 1000 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
    inet 127.0.0.1/8 scope host lo 
       valid_lft forever preferred_lft forever 
    inet6 ::1/128 scope host  
       valid_lft forever preferred_lft forever

lshw avec le commutateur -c suivi du mot-clé network liste le matériel de la classe réseau :

[root@system2 ~]# lshw -c network  
*-network UNCLAIMED 
        description: Ethernet controller 
        product: 82540EM Gigabit Ethernet Controller 
        vendor: Intel Corporation 
        physical id: 3 
        bus info: pci@0000:00:03.0 
        version: 02 
        width: 32 bits 
        clock: 66MHz 
        capabilities: pm pcix cap_list 
        configuration: latency=64 mingnt=255 
        resources: memory:f0000000-f001ffff ioport:d010(size=8)

À droite du mot network sur la deuxième...

Interface logique

Si les pilotes périphériques de blocs et de caractères sont montés en tant que fichiers dans le dossier /dev, il n’en est pas de même pour les interfaces réseau. Vous accédez à ces derniers par le biais d’un nom logique tel que enp0s3 ou wlp2s0.

Le gestionnaire de périphérique udev a été intégré dans systemd en 2012. Systemd-udev prend en charge un certain nombre de schémas d’affectation de noms. Le comportement par défaut est d’assigner des noms fixes basés sur le microprogramme, la topologie et les informations sur l’emplacement. Ceci a pour avantage d’offrir des noms complètement automatiques et prévisibles qui resteront fixes même lorsque du matériel est ajouté ou supprimé. Il ne se produit donc pas de ré-énumération. Ainsi, le matériel endommagé peut être remplacé de façon transparente.

L’inconvénient de ce comportement est que les noms sont parfois plus difficiles à lire que les noms traditionnellement utilisés au préalable comme eth0 ou wlan0.

systemd nomme les interfaces en suivant la politique de schéma de dénomination suivante :

Les noms comportant les numéros d’index fournis par le microprogramme ou le BIOS sont appliqués si ces informations en provenance du microprogramme ou du BIOS sont applicables et disponibles, sinon le schéma 2 est utilisé comme schéma de secours. Exemple : eno1.

Les noms comportant les numéros d’index de slots de connexion à chaud de PCI Express fournis par le microprogramme ou le BIOS sont appliqués si ces informations en provenance du microprogramme ou du BIOS sont applicables et disponibles, sinon le schéma 3 est utilisé comme schéma de secours. Exemple : ens1.

Les noms comportant un emplacement physique du connecteur de matériel sont applicables si possible, sinon le schéma 5 est utilisé comme schéma de secours dans tous les autres cas. Exemple : enp2s0.

Les noms comportant des adresses MAC d’interfaces ne sont pas utilisés par défaut mais sont à la disposition de l’utilisateur s’il choisit cette possibilité. Exemple :...

Outils d’analyse

1. Problèmes de connexion

Si votre machine Linux n’arrive pas à communiquer sur le réseau, vous disposez de la commande ping. Vous pouvez entendre les intervenants conjuguer le mot ping, par exemple : « avez-vous pingué le serveur ? ».

Syntaxe

ping <option> <adresse_IP

Option utile :

Option	Description
-c	Spécifie le nombre de requêtes ICMP ECHO REQUEST et ECHO REPLY.

Le diagnostic peut s’effectuer à plusieurs niveaux pour vérifier :

la configuration TCP/IP,
l’ajout de la machine au réseau,
la communication locale,
la communication distante.

a. Vérifier la configuration TCP/IP

Si le câble réseau, la carte réseau et le pilote de celle-ci ne sont pas mis en cause, alors utilisez ping sur l’adresse de boucle (127.0.0.1) pour vérifier que le protocole TCP/IP est correctement configuré.

Exemple

[root@system2 ~]# ping 127.0.0.1  
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.  
64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.069 ms  
64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.048 ms  
64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.039 ms  
64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.036 ms  
64 bytes from 127.0.0.1: icmp_req=5 ttl=64 time=0.042 ms  
64 bytes from 127.0.0.1: icmp_req=6 ttl=64 time=0.041 ms  
^C  
--- 127.0.0.1 ping statistics ---  
6 packets transmitted, 6 received, 0% packet loss, time 4997ms  
rtt min/avg/max/mdev = 0.036/0.045/0.069/0.014 ms

La commande ping ne s’arrêtant pas par défaut, il faut l’interrompre avec la combinaison de touches [Ctrl] + C.

b. Vérifier l’ajout au réseau

Pinguez l’adresse IP de l’ordinateur local pour vérifier si l’accès au réseau est correct.

Exemple

Identifiez l’adresse IP de l’interface réseau avec ip address :

[root@system2 ~]# ip addr sh enp0s3 
6: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
pfifo_fast state UP group default qlen 1000 
    link/ether 08:00:27:a4:b6:75 brd ff:ff:ff:ff:ff:ff 
    inet 10.0.2.15/24 brd 10.0.2.255 scope global noprefixroute 
dynamic enp0s3 
       valid_lft 86396sec preferred_lft 86396sec 
    inet6 fe80::a00:27ff:fea4:b675/64...

Exercices

1. Collecter la configuration d’une carte réseau

Deux machines virtuelles sont nécessaires :

la première est une machine Debian 9,
la seconde est une machine CentOS 7.

1. Utilisez la première. Ouvrez une session en tant que root.

2. Identifiez les informations suivantes :

Élément	Valeur	Commande utilisée
Nom de la carte
Nom du constructeur et modèle
Driver de la carte
Duplex
Vitesse de la carte
Adresse MAC
Adresse statique ou dynamique
Adresse IP et masque
Passerelle par défaut
Nom de la machine

2. Renommer l’interface réseau en eth0

1. Utilisez la machine virtuelle CentOS 7.

2. Identifiez le nom de la carte réseau filaire. Puis renommez-la en eth0. Décrivez votre procédure.

Maintenance de la configuration réseau