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�.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:38