[email protected]>[email protected]>).
Ce HOWTO explique l'utilisation d'un sous-r�seau avec mandataire (proxy) ARP (protocole de r�solution d'adresse), pour rendre visible un petit r�seau de machines (nous l'appellerons r�seau 0 dans la suite) comme si ces machines �taient reli�es directement au r�seau principal (r�seau 1).
Ceci n'a de sens que si les machines sont reli�es par Ethernet ou autres dispositifs de type ether (autrement dit �a ne convient pas pour SLIP, PPP, CSLIP, etc.)
Ni ce document, ni mon impl�mentation du mandatement ARP, n'auraient �t� possibles sans l'aide :
arp(8), de Fred N. van Kempen et
Bernd Eckenfels.Les applications d'un sous-r�seau avec mandataire ARP sont assez sp�cifiques.
Dans mon cas, j'avais une carte Ethernet sans-fil ISA 8 bits. Je voulais utiliser cette carte pour raccorder un certain nombre de machines. Apr�s avoir �crit un pilote (driver) pour cette carte ISA (c'est le sujet d'un autre document), je pouvais l'utiliser dans une machine Linux. � partir de l�, il �tait seulement n�cessaire d'ajouter une seconde interface Ethernet � la machine Linux, et d'utiliser alors un m�canisme quelconque pour interconnecter les deux r�seaux.
Dans la suite, j'appellerai r�seau 0 le r�seau local Ethernet reli� � la machine Linux par une carte Ethernet (clone NE-2000) sur eth0. Le r�seau 1 est le r�seau principal connect� par la carte Ethernet sans-fil sur eth1. La machine A est la machine Linux avec ses deux interfaces. La machine B est une station quelconque du r�seau 0, et la machine C est sur le r�seau 1.
Normalement, pour r�aliser l'interconnexion, on pourrait :
Dans mon cas, il n'�tait pas possible d'obtenir un nouveau num�ro de sous-r�seau, alors je voulais une solution qui permette aux machines du r�seau 0 d'appara�tre comme si elles �taient sur le r�seau 1. C'est � cela que sert le mandatement ARP. D'autres solutions sont utilis�es pour connecter d'autres protocoles (non-IP), comme netatalk pour le routage AppleTalk.
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�.
J'ai install� le mandataire ARP du sous-r�seau sur un noyau Linux version 2.0.30, mais il parait que le code fonctionne avec une version 1.2.x.
La premi�re chose � noter est que le code ARP est en deux parties :
une partie dans le noyau, qui envoie et re�oit les requ�tes et les r�ponses
ARP et met � jour le cache ARP, etc. ; l'autre partie est constitu�e de
la commande
arp(8) qui permet au super-utilisateur de mettre � jour manuellement
le cache ARP, et � tout le monde de le consulter.
Le premier probl�me que j'ai eu �tait que la commande arp(8) de
ma distribution Slackware 3.1 �tait antique (dat�e de 1994 !) et ne
communiquait pas correctement du tout avec le code ARP du noyau
(``arp -a'' donnait un r�sultat �trange).
La commande arp(8) de ``net-tools-1.33a'', qui est disponible
sur un grand nombre de sites, en particulier (d'apr�s le README qui lui
est joint)
ftp.linux.org.uk:/pub/linux/Networking/PROGRAMS/NetTools/, fonctionne
correctement, et contient de nouvelles pages de manuel arp(8)
qui expliquent
les choses bien mieux que les anciennes.
Une fois muni d'une commande arp(8) d�cente, il ne me restait plus
qu'� modifier le seul fichier /etc/rc.d/rc.inet1 (pour la
Slackware - c'est probablement diff�rent pour d'autres distributions).
Tout d'abord, il nous faut changer l'adresse de diffusion, le num�ro
de r�seau, et le masque de eth0 :
NETMASK=255.255.255.240 # pour la partie h�te sur 4 bits
NETWORK=x.y.z.64 # notre nouveau r�seau
# (remplacez x.y.z par votre r�seau)
BROADCAST=x.y.z.79 # pour moi.
Il faut ensuite ajouter une ligne pour configurer la seconde interface Ethernet (apr�s les chargements de modules qui sont �ventuellement n�cessaires pour lancer le pilote) :
/sbin/ifconfig eth1 nom_sur_le_r�seau_1
broadcast x.y.z.255 netmask 255.255.255.0
Puis nous ajoutons une route pour la nouvelle interface :
/sbin/route add -net
x.y.z.0 netmask 255.255.255.0
Et vous aurez sans doute besoin de changer la passerelle par d�faut pour utiliser celle du r�seau 1.
Arriv�s � ce point, nous pouvons ajouter la ligne pour le mandatement ARP :
/sbin/arp -i eth1 -Ds ${NETWORK} eth1 netmask ${NETMASK} pub
Ceci demande � ARP d'ajouter au cache une entr�e statique (``s'')
pour le r�seau ${NETWORK}.
Le ``-D'' dit d'utiliser la m�me adresse mat�rielle que
l'interface eth1 (la seconde interface), ce qui nous �vite d'avoir
� chercher l'adresse mat�rielle de eth1 et de la coder directement dans
la commande.
L'option netmask indique qu'il s'agit d'une entr�e ARP
concernant un sous-r�seau, qui est constitu� des
num�ros IP tels que
num�ro_ip & ${NETMASK} == ${NETWORK} & ${NETMASK}
pub demande de publier cette entr�e ARP, c'est-�-dire qu'il
s'agit d'mandatement, et qu'il faudra r�pondre au nom de
ces num�ros IP. L'option ``-i eth1'' pr�cise qu'il ne faudra r�pondre
qu'aux requ�tes ARP arrivant par l'interface eth1.
Normalement, � ce point, si la machine est red�marr�e, tous les machines du r�seau 0 sembleront �tre sur le r�seau 1. Vous pouvez v�rifier que l'entr�e de mandatement ARP de sous-r�seau a �t� prise en compte correctement sur la machine A. Sur ma machine (j'ai chang� les noms pour prot�ger les innocents) c'est :
#/sbin/arp -an Address HWtype HWaddress Flags Mask Iface x.y.z.1 ether 00:00:0C:13:6F:17 C * eth1 x.y.z.65 ether 00:40:05:49:77:01 C * eth0 x.y.z.67 ether 08:00:20:0B:79:47 C * eth0 x.y.z.5 ether 00:00:3B:80:18:E5 C * eth1 x.y.z.64 ether 00:40:96:20:CD:D2 CMP 255.255.255.240 eth1
Vous pouvez aussi regarder le fichier /proc/net/arp,
par exemple avec cat(1).
La derni�re ligne est l'entr�e de mandatement pour le sous-r�seau. Les
indicateurs CMP r�v�lent qu'il s'agit d'une donn�e statique
(entr�e Manuellement) qui doit �tre Publi�e. Elle ne servira qu'� r�pondre
qu'aux requ�tes ARP qui arrivent par eth1 et pour lesquelles le num�ro IP,
une fois masqu�, correspond au num�ro de r�seau (�galement masqu�).
Remarquez que la commande arp(8) a trouv� automatiquement l'adresse
mat�rielle de eth1 et l'a employ�e comme adresse � utiliser
(� cause de l'option ``-Ds'').
De la m�me fa�on il est probablement prudent de v�rifier que la table de routage a �t� remplie correctement. Voici la mienne (ici aussi, les noms ont �t� chang�s pour prot�ger les innocents) :
#/bin/netstat -rn Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface x.y.z.64 0.0.0.0 255.255.255.240 U 0 0 71 eth0 x.y.z.0 0.0.0.0 255.255.255.0 U 0 0 389 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 7 lo 0.0.0.0 x.y.z.1 0.0.0.0 UG 1 0 573 eth1
Vous pouvez aussi regarder le contenu du fichier /proc/net/route
(par exemple avec cat(1)).
Remarquez que la premi�re entr�e concerne un sous-ensemble de la seconde, mais la table de routage les classe dans l'ordre des masques, et donc l'entr�e eth0 sera test�e avant celle de eth1.
Dans la m�me situation il y a d'autres possibilit�s que le mandatement ARP de sous-r�seau et celles que j'ai d�j� mentionn�es (utilisation d'un pont et routage direct) :
Ceci am�liore efficacement la s�curit� des machines du r�seau 0, mais cela signifie aussi que les serveurs du r�seau 1 ne peuvent pas v�rifier l'identit� des clients du r�seau 0 en se basant sur leur num�ros IP (les serveurs NFS, par exemple, utilisent les noms IP pour contr�ler l'acc�s aux syst�mes de fichiers).
Je ne connais qu'une autre application du mandatement ARP de sous-r�seau, ici � l'Australian National University (ANU). C'est celle pour laquelle Andrew Tridgell a �crit, � l'origine, les extensions du mandatement ARP pour les sous-r�seaux. Quoiqu'il en soit, Andrew m'informe qu'il y a, de fait, plusieurs autres sites dans le monde qui l'utilisent �galement (je n'ai aucun d�tail).
� l'ANU, l'autre application concerne un laboratoire d'enseignement qui sert � apprendre aux �tudiants comment configurer des machines pour utiliser TCP/IP, y compris pour configurer la passerelle. Le r�seau utilis� est un r�seau de classe C, et Andrew avait besoin de le d�couper en sous-r�seaux pour des raisons de s�curit�, de contr�le du trafic et la raison p�dagogique mentionn�e plus haut. Il l'a fait en utilisant le mandatement ARP, et a alors d�cid� qu'une seule entr�e dans le cache ARP pour tout le sous-r�seau serait plus rapide et plus propre qu'une pour chaque machine du sous-r�seau. Et voil�. Mandatement ARP de sous-r�seau !
Les corrections et les suggestions sont les bienvenues !
Copyright 1997 par Bob Edwards <[email protected]>
T�l�phone : (+61) 2 6249 4090
Sauf mention contraire, les copyrights des documents ``Linux HOWTO''
sont d�tenus
par leurs auteurs respectifs. Ces documents peuvent �tre reproduits
et distribu�s en tout ou partie, sur tout support physique ou �lectronique,
du moment que cette notice de copyright figure sur toutes les
copies. La redistribution commerciale est autoris�e et encourag�e, cependant
l'auteur souhaite en �tre averti. Toutes les traductions, les
travaux d�riv�s, ou ouvrages incorporant un Linux HOWTO doivent �tre
soumis � cette m�me notice de copyright. Autrement dit, vous ne
pouvez pas produire un travail d�riv� d'un HOWTO en imposant des restrictions
suppl�mentaires � sa diffusion. Des d�rogations � cette r�gle peuvent �tre
accord�es sous certaines conditions, veuillez contacter le coordinateur
des Linux HOWTO � l'adresse indiqu�e ci-dessous. En r�sum�, nous souhaitons
promouvoir la diffusion de cette information par autant de canaux que possible,
tout en conservant le copyright sur les HOWTOs, et nous voudrions �tre
avertis de tout projet de redistribution de ces documents. Si vous
avez des questions, veuillez contacter Grek Hankins, coordinateur
des Linux HOWTOs, par courrier �lectronique �
<[email protected]>.