ProxyARP Subnetting HOWTO
 Bob Edwards, <[email protected]>
 Ao�t 1997

 Ce HOWTO explique l'utilisation d'un sous-r�seau avec mandataire
 (_p_r_o_x_y) ARP (protocole de r�solution d'adresse), pour rendre visible
 un petit r�seau de machines comme si ces machines �taient reli�es
 directement au r�seau principal.  (traduction : Michel Billaud, <bil�
 [email protected]>).
 ______________________________________________________________________

 Table des mati�res


 1. Introduction

 2. Remerciements

 3. Pourquoi utiliser un sous-r�seau avec mandataire ARP ?

 4. Comment marche le mandatement ARP d'un sous-r�seau ?

 5. Installation du  mandataire ARP de sous-r�seau

 6. Autres alternatives au mandatement ARP de sous-r�seau

 7. Autres applications du mandatement ARP de sous-r�seau

 8. Copyright



 ______________________________________________________________________

 11..  IInnttrroodduuccttiioonn


 Ce HOWTO explique l'utilisation d'un sous-r�seau avec mandataire
 (_p_r_o_x_y) ARP (protocole de r�solution d'adresse), pour rendre visible
 un petit r�seau de machines (nous l'appellerons _r_�_s_e_a_u _0 dans la
 suite) comme si ces machines �taient reli�es directement au r�seau
 principal (_r_�_s_e_a_u _1).


 Ceci n'a de sens que si les machines sont reli�es par Ethernet ou
 autres dispositifs de type _e_t_h_e_r (autrement dit �a ne convient pas
 pour SLIP, PPP, CSLIP, etc.)




 22..  RReemmeerrcciieemmeennttss


 Ni ce document, ni mon impl�mentation du mandatement ARP, n'auraient
 �t� possibles sans l'aide :

 �  d'Andrew Tridgell, qui a impl�ment� sous Linux les options de sous-
    r�seau pour _a_r_p, et qui m'a aid� personnellement � le faire marcher
    ;

 �  du mini-HOWTO _P_r_o_x_y_-_A_R_P �crit par Al LongYear ;

 �  du mini-HOWTO _M_u_l_t_i_p_l_e_-_E_t_h_e_r_n_e_t de Don Becker ;


 �  du code source et de la page de manuel de la commande arp(8), de
    Fred N. van Kempen et Bernd Eckenfels.




 33..  PPoouurrqquuooii uuttiilliisseerr uunn ssoouuss--rr��sseeaauu aavveecc mmaannddaattaaiirree AARRPP ??




 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 (_d_r_i_v_e_r) 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_�_s_e_a_u _0 le r�seau local Ethernet reli� �
 la machine Linux  par une carte Ethernet (clone   NE-2000) sur _e_t_h_0.
 Le _r_�_s_e_a_u _1  est le r�seau principal connect� par la carte Ethernet
 sans-fil sur _e_t_h_1.  La _m_a_c_h_i_n_e _A est la machine Linux avec ses deux
 interfaces. La _m_a_c_h_i_n_e _B est une station quelconque du r�seau 0, et la
 _m_a_c_h_i_n_e _C est sur le r�seau 1.


 Normalement, pour r�aliser l'interconnexion, on pourrait :


 �  utiliser le logiciel IP-Bridge (voir le _B_r_i_d_g_e _m_i_n_i_-_H_O_W_T_O) pour
    r�aliser un pont entre les deux interfaces r�seau.
    Malheureusement, la carte Ethernet sans-fil ne peut pas �tre mise
    en mode ``promiscuous'' (autrement dit elle ne peut pas voir tous
    les paquets circulant sur le r�seau 1).  C'est principalement �
    cause de la faible bande passante de la carte Ethernet sans-fil (2
    Mbits/sec), ce qui implique  que nous ne voulons pas supporter le
    trafic qui n'est pas destin� � une autre machine sans-fil - dans
    notre cas la machine A -, ou les diffusions g�n�rales (_b_r_o_a_d_c_a_s_t_s).
    De plus, un pont charge assez lourdement le processeur.

 �  ou bien utiliser des sous-r�seaux et un routeur pour transmettre
    les paquets entre les r�seaux (voir le _I_P_-_S_u_b_n_e_t_w_o_r_k_i_n_g _m_i_n_i_-
    _H_O_W_T_O).  C'est une solution d�pendante du protocole, b�n�ficiant du
    fait que le noyau Linux sait g�rer les paquets IP (Internet
    Protocol), mais demandant du logiciel suppl�mentaire pour router
    d'autres protocoles (tels qu'AppleTalk). De plus,  ceci n�cessite
    d'allouer un nouveau num�ro de sous-r�seau IP, ce qui n'est pas
    toujours possible.

 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 _n_e_t_a_t_a_l_k
 pour le routage AppleTalk.




 44..  CCoommmmeenntt mmaarrcchhee llee mmaannddaatteemmeenntt AARRPP dd''uunn ssoouuss--rr��sseeaauu ??


 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 (_e_t_h_0), 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 (_e_t_h_1).


 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 _a_r_p
 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 (_e_t_h_1), 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 (_e_t_h_0) que pour le r�seau 1
 (_e_t_h_1).


 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 (_e_t_h_1), 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 (_e_t_h_0), 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 _e_t_h_1.


 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 (_e_t_h_0) et
 s'abstiendra d'y r�pondre, puisqu'elle n'est configur�e comme
 mandataire que sur son interface du r�seau 1 (_e_t_h_1).

 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�.



 55..  IInnssttaallllaattiioonn dduu  mmaannddaattaaiirree AARRPP ddee ssoouuss--rr��sseeaauu


 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 _e_t_h_0 :


 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 _n_o_m___s_u_r___l_e___r_�_s_e_a_u___1 broadcast _x_._y_._z_._2_5_5 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 _e_t_h_1 (la seconde interface), ce qui nous
 �vite d'avoir � chercher l'adresse mat�rielle de _e_t_h_1 et de la coder
 directement dans la commande.



 L'option netmask indique qu'il s'agit d'une entr�e ARP concernant un
 _s_o_u_s_-_r_�_s_e_a_u, qui est constitu� des num�ros IP tels que

      _n_u_m_�_r_o___i_p & ${NETMASK} == ${NETWORK} & ${NETMASK}


 L'option pub demande de _p_u_b_l_i_e_r cette entr�e ARP, c'est-�-dire qu'il
 s'agit d'_m_a_n_d_a_t_e_m_e_n_t, 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 _e_t_h_1.


 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 _e_t_h_1 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 _e_t_h_1 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 _e_t_h_0 sera test�e avant celle de _e_t_h_1.



 66..  AAuuttrreess aalltteerrnnaattiivveess aauu mmaannddaatteemmeenntt AARRPP ddee ssoouuss--rr��sseeaauu


 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) :


 �  ``_M_a_s_q_u_e_r_a_d_i_n_g _I_P'' (voir le _I_P_-_M_a_s_q_u_e_r_a_d_e _m_i_n_i_-_H_O_W_T_O), dans lequel
    le r�seau 0 est ``cach�e'' du reste du monde derri�re la machine A.
    Quand les machines du r�seau 0 tentent de se connecter �
    l'ext�rieur � travers la machine A, celle-ci modifie l'adresse
    d'origine et le num�ro de port des paquets pour qu'ils aient l'air
    d'avoir �t� envoy�s par elle-m�me, plut�t que par la machine cach�e
    du r�seau 0.  C'est une solution �l�gante, bien qu'elle emp�che
    toute machine du r�seau 1 d'�tablir une connexion vers une machine
    du r�seau 0, puisque les machines du r�seau 0 n'existent pas en
    dehors de celui-ci.

    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).

 �  Une autre possibilit� serait un _t_u_n_n_e_l _I_P _s_u_r _I_P, ce qui n'est pas
    support� par toutes les plateformes (comme les Macs et les machines
    sous Windows), et je n'ai donc pas opt� pour cette solution.

 �  Utiliser le mandatement ARP sans sous-r�seau. C'est tout � fait
    possible, cela signifie simplement qu'il faut cr�er une entr�e
    individuelle pour chaque machine du r�seau 0, au lieu d'une seule
    entr�e pour toutes les machines (pr�sentes et futures) du r�seau 0.

 �  Il se peut que l'_a_l_i_a_s_i_n_g _I_P puisse �tre utilis� ici (NdT:
    francheement �a m'�tonnerait), mais je n'ai pas du tout explor�
    cette voie.


 77..  AAuuttrreess aapppplliiccaattiioonnss dduu mmaannddaatteemmeenntt AARRPP ddee ssoouuss--rr��sseeaauu




 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 !



 88..  CCooppyyrriigghhtt


 Copyright 1997 par Bob Edwards <[email protected]>


 T�l�phone : (+61) 2 6249 4090



 Sauf mention contraire, les copyrights des documents ``_L_i_n_u_x _H_O_W_T_O''
 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 _L_i_n_u_x
 _H_O_W_T_O 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]>.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.