En fait, le mandatement ARP sert uniquement à faire passer les paquets
du réseau 1 vers le réseau 0. Pour faire passer les paquets dans
l'autre sens, on emploie le routage IP normal.
Dans mon cas, le réseau 1 possède un masque de sous-réseau à 8 bits
255.255.255.0. Pour le réseau 0, j'ai choisi un masque à
4 bits (255.255.255.240), qui permet d'avoir 14 noeuds IP
sur le réseau 0 (2^4 = 16, moins deux pour l'adresse de réseau remplie de zéros
et l'adresse de diffusion remplie de uns ). Remarquez que toute taille
de masque de sous-réseau convient, jusqu'à la taille - non comprise -
du masque de l'autre réseau (dans notre cas : 2, 3, 4, 5, 6 ou 7 bits -
pour un seul bit utilisez le mandatement ARP normal !).
Les numéros IP (au total 16) du réseau 0 apparaissent comme un sous-ensemble
du réseau 1. Remarquez qu'il est très important, dans ce cas, de ne pas
donner aux machines qui sont connectées directement au réseau 1 un numéro
pris dans cet intervalle. Dans mon cas, j'ai ``réservé'' les numéros IP
du réseau 1 qui se terminent par 64 à 79 pour le réseau 0. Les numéros IP qui
se terminent par 64 et 79 ne peuvent pas être attribués à des machines :
79 est l'adresse de diffusion pour le réseau 0.
La machine A a deux numéros IP, l'un dans la plage d'adresses du
réseau 0 pour sa vraie carte Ethernet (eth0), l'autre dans la
plage du réseau 1 (mais en dehors de la plage du réseau 0) pour la
carte Ethernet sans-fil (eth1).
Supposons que la machine C (du réseau 1) veuille envoyer
un paquet à la machine B (du réseau 0). Comme le numéro IP de la
machine B laisse croire à la machine C que B est sur le même réseau
physique, la machine C va utiliser le protocole de résolution
d'adresse ARP pour envoyer un message de diffusion sur le réseau 1,
demandant à la machine qui a le numéro IP de B de répondre avec son
adresse matérielle (adresse Ethernet ou MAC). La machine B ne verra
pas cette requête, puisqu'en réalité elle n'est pas sur le réseau 1,
mais la machine A, qui est sur les deux réseaux, la verra.
La première chose magique se produit maintenant, lorsque le
code arp du noyau de la machine Linux (configurée
en mandataire ARP avec sous-réseau) détermine que la
requête
est arrivée sur l'interface du réseau 1 (eth1), et que
le numéro IP à résoudre est dans l'intervalle du réseau 0.
La machine A envoie alors sa propre adresse matérielle (adresse
Ethernet) à la machine C dans un paquet de réponse ARP.
La machine C met alors à jour son cache ARP en y ajoutant une entrée pour
la machine B, mais avec l'adresse matérielle (Ethernet) de la machine
A (la carte Ethernet sans-fil). La machine C peut alors
envoyer le paquet pour B à cette adresse matérielle (Ethernet), et la
machine A le reçoit.
La machine A remarque que l'adresse de destination IP n'est pas la
sienne, mais celle de B. Le code de routage du noyau Linux de la
machine A essaie alors de faire suivre ce paquet vers la machine B en
cherchant dans ses tables de routage pour savoir quelle interface
contient le numéro de réseau de B. Quoi qu'il en soit, le numéro IP de
B est valide aussi bien pour le réseau 0 (eth0) que pour le réseau 1
(eth1).
C'est alors qu'un autre fait magique se produit : comme le masque de sous-réseau
du réseau 0 a plus de bits à 1 (il est plus spécifique) que celui du
réseau 1, le code de routage du noyau Linux va associer le
numéro IP de B à l'interface du réseau 0, et ne va pas chercher
à voir si il correspond à l'interface du réseau 1 (par laquelle le
paquet est arrivé).
Maintenant la machine A doit trouver la ``vraie'' adresse matérielle
(Ethernet) de la machine B (en supposant qu'elle ne l'a pas déjà dans
le cache ARP). La machine A utilise une requête ARP, mais cette fois-ci le
code arp du noyau Linux voit que la requête ne vient pas de
l'interface du réseau 1 (eth1), et donc ne renvoie pas
l'adresse du mandataire ARP. À la place, il envoie la requête ARP
sur l'interface du réseau 0 (eth0), où la machine B le verra et répondra
en donnant sa propre adresse matérielle (Ethernet). La machine A peut
alors envoyer le paquet (qui venait de C) vers la machine B.
La machine B reçoit le paquet de C (qui est passé par A) et veut alors
envoyer une réponse. Cette fois, B remarque que C est sur un
sous-réseau différent (le masque de sous-réseau 255.255.255.240 exclut
toutes les machines qui ne sont pas dans la plage d'adresses IP du
réseau 0). La machine B est configurée avec une route par défaut
vers l'adresse IP de A sur le réseau 0, et envoie le paquet à la machine A.
Cette fois-ci, le code de routage du noyau Linux de A trouve que
l'adresse IP de la destination (machine C) est sur le réseau 1, et
envoie le paquet à la machine C par l'interface Ethernet eth1.
Des choses du même genre (mais moins compliquées) se produisent pour
les paquets émis (ou reçus) par la machine A en direction (ou
provenant) d'autres machines sur l'un ou l'autre des deux réseaux.
De la même façon, il est évident que si une autre machine D du
réseau 0 envoie une requête ARP concernant B sur le réseau 0, la
machine
A recevra cette requête sur son interface du réseau 0 (eth0) et
s'abstiendra d'y répondre, puisqu'elle n'est configurée comme mandataire
que sur son interface du réseau 1 (eth1).
Remarquez aussi que les machines B, C (et D) n'ont de spécial à faire,
du point de vue IP. Dans mon cas, il y a un mélange de SUN, de MAC et de
PC sous Windows 95 sur le réseau 0, qui se connectent toutes au reste du monde
à travers la machine Linux A.
Pour finir, notez qu'une fois que les adresses matérielles (Ethernet)
ont été trouvées par chacune des machines A, B, C (et D), elles sont
placées dans leur cache ARP, et que les paquets suivants sont tranférés
sans surcoût dû à l'ARP. Normalement, les caches ARP suppriment les informations
au bout de 5 minutes d'inactivité.
|