Au cours de cette expérimentation, nous serons amenés à communiquer à travers de nombreux équipements.
Commencez par mettre en place tout ce qui est décrit par ce schéma.

Il ne s'agit que de réutiliser les outils et commandes du précédent sujet.
Prêtez une très grande attention à la désignation des switches, machines, interfaces réseau et à l'attribution des adresses IP.
En effet, la moindre incohérence produirait probablement un comportement inattendu difficile à analyser.

Avant de passer à la suite, il faudra impérativement vérifier la communication (avec ping) au sein de chacun des sous-réseaux :

Pour la première fois, nous venons de configurer des machines (C1A2 et C2A3) participant à des sous-réseaux distincts.
Écoutons (avec tcpdump) le trafic sur les interfaces eth0 de B1, B2 et B3 pendant les opérations suivantes : Une observation attentive des traces de communication doit montrer que : Lorsqu'une machine à plusieurs interfaces décide de communiquer, elle choisit l'adresse IP source du paquet qu'elle émet en fonction de l'interface réseau qu'elle utilise pour atteindre le destinataire.

Plaçons-nous tout d'abord dans le sous-réseau 192.168.10.0/24.
Vous avez déjà dû vérifier que les machines A1, B1 et C1A2 pouvaient s'atteindre mutuellement, mais que se passe-t-il lorsque A1 ou B1 tentent de joindre C1A2 (avec ping) en la désignant par l'adresse IP de son interface eth1 ?
Remarquez que ce cas problématique avait déjà été envisagé à la fin de cette étape du précédent sujet.

Pour comprendre ce que nous constatons, visualisons la table de routage des machines A1, B1 et C1A2. [A1, B1, C1A2]~# ip route ↵ En l'état, chacune contient implicitement une ligne pour chaque interface réseau✍.
A1 et B1 ne peuvent qu'atteindre le sous-réseau 192.168.10.0/24 alors que C1A2 peut atteindre en plus 192.168.20.0/24 grâce à son interface supplémentaire.
Lorsqu'une machine tente de joindre une adresse IP, elle commence par consulter sa table de routage.
Si aucune route (ligne de la table) ne mentionne le sous-réseau incluant l'adresse visée, alors l'échec est immédiat, ce qui explique le comportement constaté plus haut.

Complétons alors explicitement la table de routage de A1 avec une information que nous seuls connaissons pour l'instant : atteindre l'interface eth0 de C1A2 permet de progresser vers le sous-réseau 192.168.20.0/24. [A1]~# ip route add 192.168.20.0/24 via 192.168.10.3 ↵ Contrôlez que la table de routage de A1 affiche bien cette nouvelle information et tentez à nouveau de joindre (avec ping) 192.168.20.1 ; la communication a désormais lieu.
Faites la démarche équivalente sur B1 et vérifiez qu'elle a également le comportement attendu.

Procédez de la même façon pour que :

L'ajout explicite d'une route sur les machines d'un sous-réseau leur permet d'atteindre une adresse IP qui n'en fait pas partie.
Cette route doit désigner l'adresse IP d'une machine directement accessible dans le sous-réseau courant ; celle-ci doit à son tour avoir un moyen d'atteindre le sous-réseau que cette route concerne.

Du point de vue de A1 et B1, ces machines ont désormais toute l'information nécessaire pour atteindre n'importe quelle adresse du sous-réseau 192.168.20.0/24✍.
Tentons alors de leur faire atteindre B2.
Cela se solde à nouveau par un échec mais de nature différente ; l'abandon n'est pas immédiat.

Écoutez l'interface eth0 de C1A2 pendant que A1 (ou B1) tente de joindre B2 : nous percevons, comme prévu, des paquets IP provenant de A1 et destinés à B2.
Reprenez la même expérience en écoutant cette fois-ci sur l'interface eth1 de C1A2 : aucun paquet n'est réémis !
En effet, par défaut, un système d'exploitation qui reçoit un paquet IP qui ne lui est pas destiné se contente de l'ignorer.
Grâce à cette commande [C1A2]~# echo 1 >/proc/sys/net/ipv4/ip_forward ↵ nous autorisons le système d'exploitation de C1A2 à retransmettre les paquets IP qu'il reçoit mais qui ne lui sont pas destinés.
C'est à dire que la machine C1A2, au lieu d'ignorer le paquet IP reçu, va elle-même consulter sa table de routage pour chercher à atteindre le destinataire de ce paquet.
Reprenez encore la même expérience ; cette fois-ci la communication fonctionne et nous voyons bien les paquets IP concernant A1 et B2 circuler dans les deux sens sur les interfaces eth0 et eth1 de C1A2.
Un routeur est donc une machine équipée de plusieurs interfaces réseau et qui accepte de retransmettre vers leur destination les paquets IP qui ne la concernent pas directement.

Après avoir fait une intervention similaire sur C2A3 afin qu'il soit lui aussi un routeur, vérifiez le bon fonctionnement des communications bidirectionnelles suivantes : En l'état, chaque machine présente dans un sous-réseau a également accès aux machines des sous-réseaux immédiatement voisins.
Mais que se passe-t-il lorsque nous cherchons à faire interagir A1 ou B1 avec B3 ?
Le contrôle de l'état des tables de routage de ces trois machines nous indique que cet échec immédiat est lié au fait qu'il n'existe pour l'instant aucune information de routage sur A1 ou B1 indiquant comment atteindre le sous-réseau de B3 (et réciproquement).
Ceci sera envisagé juste après.

Reprenez maintenant un des six exemples précédents pour communiquer à travers un routeur.
Écoutez (avec tcpdump) l'interface eth0 du routeur dans un terminal et son interface eth1 dans un second terminal✍.
Observez alors très attentivement les adresses MAC et IP, sources et destinations des paquets qui parviennent au routeur et qui sont ensuite retransmis (dans les deux directions).
Vous devriez constater que : En résumé, les paquets IP conservent leurs adresses IP tout au long de leur trajet alors que les trames qui les contiennent nécessitent l'indication d'adresses MAC spécifiques à chaque sous-réseau.
C'est ce qui fait l'intérêt de la désignation d'une machine par une adresse IP ; celle-ci reste valable quels que soient les détails des moyens d'interconnexion pour la joindre (routage, remplacement d'une carte réseau...)

Pour confirmer cela, vous pouvez également effacer les entrées des tables ARP des deux machines qui communiquent et celle du routeur, puis relancer l'expérience en écoutant toujours les interfaces du routeur.
Vous devriez constater qu'aucune requête ARP n'est tentée entre les interlocuteurs extrêmes ; elles ne concernent que les échanges entre un interlocuteur et le routeur qu'il emprunte.

Cherchons maintenant à faire en sorte que n'importe quelle machine de notre réseau puisse joindre n'importe quelle autre.
Nous avons constaté juste avant qu'il n'était pas encore possible de faire interagir A1 ou B1 avec B3.
La solution logique consiste à procéder comme précédemment pour : En effet, quand un routeur décide de retransmettre un paquet IP reçu, il consulte sa table de routage comme s'il avait lui même produit initialement ce paquet.
C'est ce procédé qui permet aux paquets IP de traverser, pas à pas, une succession de routeurs pour atteindre l'adresse IP visée.
Vérifiez que la communication est dorénavant possible entre les deux extrémités du réseau, grâce au relais par les deux routeurs intermédiaires.

Si cette solution fonctionne, elle n'est toutefois pas très confortable à utiliser.
Dans le cadre de notre expérimentation nous utilisons très peu de machines mais en pratique il pourrait y en avoir beaucoup plus dans chacun des sous-réseaux (voir les pointillés du schéma).
Et il pourrait également y avoir bien plus de sous-réseaux et donc bien plus de routeurs pour les interconnecter.
L'Internet représente justement le gigantesque ensemble de tous les réseaux interconnectés.
Il deviendrait alors très difficile de préciser sur chaque machine quelles sont les routes à emprunter pour atteindre telle destination ou telle autre.

Dans les situations courantes, le réseau de chaque site (une entreprise, une université...) pris isolément est organisé de manière hiérarchique sous la forme d'un arbre : Puisque l'organisation est arborescente, il suffit à chaque poste terminal (qui ne soit pas un routeur) de s'adresser systématiquement au routeur qui le rapproche de “l'extérieur” lorsqu'il doit sortir de son sous-réseau courant.
Il n'y a donc qu'une route à ajouter explicitement sur chaque poste terminal : il s'agit de la route par défaut 0.0.0.0/0. Cette route par défaut est envisagée en tout dernier lieu, lorsque aucune autre plus spécifique ne correspond à l'adresse IP de destination.
Dans ces conditions, seuls les routeurs ont besoin de connaître très précisément les routes très spécifiques aux sous-réseaux du site ; la configuration des postes terminaux (beaucoup plus nombreux normalement) s'en trouve largement simplifiée.

Pour expérimenter cette solution, supposons que la machine C2A3 soit également reliée à “l'extérieur” par une liaison non matérialisée ici✍.
Commençons par retirer une à une toutes les routes que nous avions ajoutées explicitement pour atteindre les sous-réseaux éloignés. [A1, B1, C1A2, B2]~# ip route del 192.168.30.0/24 ↵ [A1, B1, B3]~# ip route del 192.168.20.0/24 ↵ [B2, C2A3, B3]~# ip route del 192.168.10.0/24 ↵ Puis, sur chaque machine ajoutons la route par défaut (vers “l'extérieur”).
[A1, B1]~# ip route add default via 192.168.10.3 ↵ [C1A2, B2]~# ip route add default via 192.168.20.3 ↵ [B3]~# ip route add default via 192.168.30.1 ↵ Normalement, C2A3 devrait aussi avoir une route par défaut vers le fournisseur d'accès mais nous n'avons pas matérialisé cette liaison.

Vérifiez que, en l'état, B2 (ou C1A2) peuvent interagir sans problème avec B3 : Cependant, la même expérience entre B1 (ou A1) et B2 (ou C2A3) échoue car B2 (ou C2A3) ne sait pas comment atteindre le sous-réseau 192.168.10.0/24 ; au contraire, les routes par défaut ont tendance à diriger les paquets IP vers “l'extérieur”.
Pour pallier ce défaut, il suffit d'intervenir sur un routeur afin d'expliciter l'architecture interne de notre réseau, comme nous l'avions déjà fait à cette étape. [C2A3]~# ip route add 192.168.10.0/24 via 192.168.20.1 ↵ En effet, alors que toutes les routes par défaut ont tendance à faire “sortir” les paquets IP, il faut indiquer explicitement qu'il est nécessaire de “rentrer” par C1A2/eth1 pour atteindre notre sous-réseau 192.168.10.0/24.
Remarquez que cette intervention n'a lieu que sur C2A3 ; il n'est pas nécessaire de la répliquer sur les postes terminaux.
Vérifiez que, grâce à cette nouvelle route explicite, la communication entre B1 (ou A1) et B2 est redevenue possible.

En regardant attentivement le schéma, nous remarquons qu'un paquet IP issu de B2 et destiné à B1 (ou A1) emprunte la route par défaut de B2 par C2A3 puis la route explicite de C2A3 par C1A2.
Néanmoins, il serait bien plus pertinent pour B2 d'atteindre C1A2 sans passer juste avant par C2A3.
À ce propos, notre toute dernière utilisation de ping a dû indiquer, par un affichage furtif, qu'une redirection avait eu lieu.
Il s'agit d'un message ICMP-redirect émis par le routeur C2A3 à l'intention de B2 pour lui signifier qu'il peut désormais atteindre son destinataire par une route plus directe (que ce routeur connaît).
Cette information est mémorisée (temporairement) par B2 et vient en quelque sorte en complément de la table de routage.
Pour s'en rendre compte, nous pouvons interroger les décisions de routage de B2. [B2]~# ip route get 192.168.30.2 ↵ [B2]~# ip route get 192.168.10.2 ↵ Dans le premier cas, la route par défaut est choisie ; dans le second, il est indiqué qu'une redirection par une autre route sera préférée.

Pour mettre en évidence l'établissement de ce fonctionnement, commençons par forcer l'oubli des informations de redirection sur B2 [B2]~# ip route flush cached ↵ et contrôlons le fait que la route par défaut sera à nouveau considérée pour atteindre B1. [B2]~# ip route get 192.168.10.2 ↵ Écoutons l'interface eth0 de C2A3 [C2A3]~# tcpdump -eni eth0 ↵ pendant que B2 cherche à joindre B1. [B2]~# ping -c2 192.168.10.2 ↵ Vous devriez constater que le tout premier paquet IP (ICMP-echo-request) est bien reçu puis retransmis par C2A3 mais qu'un message ICMP-redirect est également émis vers B2.
Dès lors, B2 ne sollicite plus du tout C2A3 pour communiquer avec B1 mais s'adresse directement à C1A2 comme suggéré par le message ICMP-redirect que vient de lui adresser C2A3

Voici ce que nous pouvons retenir de cette étape :

Lors de la mise au point de l'architecture d'un réseau, il est nécessaire d'utiliser des outils de diagnostic.
Nous avons déjà eu recours à l'outil ping pour tester la connectivité entre deux machines et l'outil tcpdump afin de visualiser les trames qui circulent.
Dans le but d'aller un peu plus loin dans cette démarche, l'outil traceroute et l'option -R de l'outil ping permettent de relever les adresses IP des routeurs qu'il faut traverser pour atteindre une machine.

Essayez l'outil traceroute en visant B3 depuis B1. [B1]~# traceroute -In 192.168.30.2 ↵ Il reporte une trace dans laquelle apparaissent les adresses IP d'entrée des machines rencontrées ; ici C1A2/eth0 puis C2A3/eth0 et enfin B3. À titre d'entraînement, vous pouvez écouter attentivement les interfaces des routeurs pour constater la stratégie de fonctionnement de traceroute.

De la même façon, l'option -R de l'outil ping [B1]~# ping -R -c1 192.168.30.2 ↵ reporte une séquence d'adresses IP, mais cette fois-ci il s'agit des adresses de sortie des machines rencontrées.
L'enregistrement relève tout d'abord les adresses de sortie sur le trajet du message ICMP-echo-request.
Cette liste d'adresses est ensuite reprise à l'émission du message ICMP-echo-reply puis à nouveau complétée sur son trajet.
L'outil ping affiche donc les adresses IP ainsi récupérées au long d'un aller-retour complet.

Dans le cadre de cette expérimentation, notre réseau est très petit et ping -R suffit à découvrir complètement les routeurs traversés (nous voyons leurs adresses des deux côtés).
Seulement, le nombre d'adresses qu'il est possible d'enregistrer est limité à neuf car ce procédé repose sur l'utilisation d'une partie optionnelle (de capacité limitée) des en-têtes des paquets IP.
S'il y avait plus de deux routeurs entre les deux machines concernées par l'échange, il manquerait des informations sur le trajet de retour (mais ce serait probablement suffisant pour l'aller).
C'est la raison pour laquelle il est très courant d'utiliser à la fois : et de fusionner les informations obtenues pour décrire complètement les adresses IP de part et d'autre des routeurs traversés.
À titre d'entraînement, vous pouvez, depuis n'importe quelle poste terminal, tenter de relever la cartographie complète du réseau.