  ProxyARP Subnetting HOWTO
  Bob Edwards, <Robert.Edwards@anu.edu.au>
  Aot 1997

  Ce HOWTO explique l'utilisation d'un sous-rseau avec mandataire
  (_p_r_o_x_y) ARP (protocole de rsolution d'adresse), pour rendre visible
  un petit rseau de machines comme si ces machines taient relies
  directement au rseau principal.  (traduction : Michel Billaud, <bil
  laud@labri.u-bordeaux.fr>).
  ______________________________________________________________________

  Table des matires


  1. Introduction

  2. Remerciements

  3. Pourquoi utiliser un sous-rseau avec mandataire ARP ?

  4. Comment marche le mandatement ARP d'un sous-rseau ?

  5. Installation du  mandataire ARP de sous-rseau

  6. Autres alternatives au mandatement ARP de sous-rseau

  7. Autres applications du mandatement ARP de sous-rseau

  8. Copyright



  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn


  Ce HOWTO explique l'utilisation d'un sous-rseau avec mandataire
  (_p_r_o_x_y) ARP (protocole de rsolution d'adresse), pour rendre visible
  un petit rseau de machines (nous l'appellerons _r__s_e_a_u _0 dans la
  suite) comme si ces machines taient relies directement au rseau
  principal (_r__s_e_a_u _1).


  Ceci n'a de sens que si les machines sont relies par Ethernet ou
  autres dispositifs de type _e_t_h_e_r (autrement dit a ne convient pas
  pour SLIP, PPP, CSLIP, etc.)




  22..  RReemmeerrcciieemmeennttss


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

    d'Andrew Tridgell, qui a implment sous Linux les options de sous-
     rseau 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.




  33..  PPoouurrqquuooii uuttiilliisseerr uunn ssoouuss--rrsseeaauu aavveecc mmaannddaattaaiirree AARRPP ??




  Les applications d'un sous-rseau avec mandataire ARP sont assez
  spcifiques.



  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. Aprs 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 ncessaire d'ajouter
  une seconde interface Ethernet  la machine Linux, et d'utiliser alors
  un mcanisme quelconque pour interconnecter les deux rseaux.


  Dans la suite, j'appellerai _r__s_e_a_u _0 le rseau 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 rseau 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 rseau 0, et la
  _m_a_c_h_i_n_e _C est sur le rseau 1.


  Normalement, pour raliser 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
     raliser un pont entre les deux interfaces rseau.
     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 rseau 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 gnrales (_b_r_o_a_d_c_a_s_t_s).
     De plus, un pont charge assez lourdement le processeur.

    ou bien utiliser des sous-rseaux et un routeur pour transmettre
     les paquets entre les rseaux (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 dpendante du protocole, bnficiant du
     fait que le noyau Linux sait grer les paquets IP (Internet
     Protocol), mais demandant du logiciel supplmentaire pour router
     d'autres protocoles (tels qu'AppleTalk). De plus,  ceci ncessite
     d'allouer un nouveau numro de sous-rseau IP, ce qui n'est pas
     toujours possible.

  Dans mon cas, il n'tait pas possible d'obtenir un nouveau numro de
  sous-rseau, alors je voulais une solution qui permette aux machines
  du rseau 0 d'apparatre comme si elles taient sur le rseau 1.
  C'est  cela que sert le mandatement ARP.  D'autres solutions sont
  utilises pour connecter d'autres protocoles (non-IP), comme _n_e_t_a_t_a_l_k
  pour le routage AppleTalk.




  44..  CCoommmmeenntt mmaarrcchhee llee mmaannddaatteemmeenntt AARRPP dd''uunn ssoouuss--rrsseeaauu ??


  En fait, le mandatement ARP sert uniquement  faire passer les paquets
  du rseau 1 vers le rseau 0. Pour faire passer les paquets dans
  l'autre sens, on emploie le routage IP normal.


  Dans mon cas, le rseau 1 possde un masque de sous-rseau  8 bits
  255.255.255.0. Pour le rseau 0, j'ai choisi un masque  4 bits
  (255.255.255.240), qui permet d'avoir 14 noeuds IP sur le rseau 0
  (2^4 = 16, moins deux pour l'adresse de rseau remplie de zros et
  l'adresse de diffusion remplie de uns ). Remarquez que toute taille de
  masque de sous-rseau convient, jusqu' la taille - non comprise - du
  masque de l'autre rseau (dans notre cas : 2, 3, 4, 5, 6 ou 7 bits -
  pour un seul bit utilisez le mandatement ARP normal !).


  Les numros IP (au total 16) du rseau 0 apparaissent comme un sous-
  ensemble du rseau 1. Remarquez qu'il est trs important, dans ce cas,
  de ne pas donner aux machines qui sont connectes directement au
  rseau 1 un numro pris dans cet intervalle.  Dans mon cas, j'ai
  ``rserv'' les numros IP du rseau 1 qui se terminent par 64  79
  pour le rseau 0. Les numros IP qui se terminent par 64 et 79 ne
  peuvent pas tre attribus  des machines : 79 est l'adresse de
  diffusion pour le rseau 0.



  La machine A a deux numros IP, l'un dans la plage d'adresses du
  rseau 0 pour sa vraie carte Ethernet (_e_t_h_0), l'autre dans la plage du
  rseau 1 (mais en dehors de la plage du rseau 0) pour la carte
  Ethernet sans-fil (_e_t_h_1).


  Supposons que la machine C (du rseau 1) veuille envoyer un paquet 
  la machine B (du rseau 0). Comme le numro IP de la machine B laisse
  croire  la machine C que B est sur le mme rseau physique, la
  machine C va utiliser le protocole de rsolution d'adresse ARP pour
  envoyer un message de diffusion sur le rseau 1, demandant  la
  machine qui a le numro IP de B de rpondre avec son adresse
  matrielle (adresse Ethernet ou MAC). La machine B ne verra pas cette
  requte, puisqu'en ralit elle n'est pas sur le rseau 1, mais la
  machine A, qui est sur les deux rseaux, la verra.


  La premire chose magique se produit maintenant, lorsque le code _a_r_p
  du noyau de la machine Linux (configure en mandataire ARP avec sous-
  rseau) dtermine que la requte est arrive sur l'interface du rseau
  1 (_e_t_h_1), et que le numro IP  rsoudre est dans l'intervalle du
  rseau 0.  La machine A envoie alors sa propre adresse matrielle
  (adresse Ethernet)  la machine C dans un paquet de rponse ARP.


  La machine C met alors  jour son cache ARP en y ajoutant une entre
  pour la machine B, mais avec l'adresse matrielle (Ethernet) de la
  machine A (la carte Ethernet sans-fil).  La machine C peut alors
  envoyer le paquet pour B  cette adresse matrielle (Ethernet), et la
  machine A le reoit.


  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 numro de rseau de B. Quoi qu'il en soit, le numro IP de
  B est valide aussi bien pour le rseau 0 (_e_t_h_0) que pour le rseau 1
  (_e_t_h_1).


  C'est alors qu'un autre fait magique se produit : comme le masque de
  sous-rseau du rseau 0 a plus de bits  1 (il est plus spcifique)
  que celui du rseau 1, le code de routage du noyau Linux va associer
  le numro IP de B  l'interface du rseau 0, et ne va pas chercher 
  voir si il correspond  l'interface du rseau 1 (par laquelle le
  paquet est arriv).


  Maintenant la machine A doit trouver la ``vraie'' adresse matrielle
  (Ethernet) de la machine B (en supposant qu'elle ne l'a pas dj dans
  le cache ARP). La machine A utilise une requte ARP, mais cette fois-
  ci le code arp du noyau Linux voit que la requte ne vient pas de
  l'interface du rseau 1 (_e_t_h_1), et donc ne renvoie  pas l'adresse du
  mandataire ARP.  la place, il envoie la requte ARP sur l'interface
  du rseau 0 (_e_t_h_0), o la machine B le verra et rpondra en donnant sa
  propre adresse matrielle (Ethernet). La machine A peut alors envoyer
  le paquet (qui venait de C) vers la machine B.


  La machine B reoit le paquet de C (qui est pass par A) et veut alors
  envoyer une rponse. Cette fois, B remarque que C est sur un sous-
  rseau diffrent (le masque de sous-rseau 255.255.255.240 exclut
  toutes les machines qui ne sont pas dans la plage d'adresses IP du
  rseau 0).  La machine B est configure avec une route par dfaut vers
  l'adresse IP de A sur le rseau 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 rseau 1, et
  envoie le paquet  la machine C par l'interface Ethernet _e_t_h_1.


  Des choses du mme genre (mais moins compliques) se produisent pour
  les paquets mis (ou reus) par la machine A en direction (ou
  provenant) d'autres machines sur l'un ou l'autre des deux rseaux.

  De la mme faon, il est vident que si une autre machine D du rseau
  0 envoie une requte ARP concernant B sur le rseau 0, la machine A
  recevra cette requte sur son interface du rseau 0 (_e_t_h_0) et
  s'abstiendra d'y rpondre, puisqu'elle n'est configure comme
  mandataire que sur son interface du rseau 1 (_e_t_h_1).

  Remarquez aussi que les machines B, C (et D) n'ont de spcial  
  faire, du point de vue IP. Dans mon cas, il y a un mlange de SUN, de
  MAC et de PC sous Windows 95 sur le rseau 0, qui se connectent toutes
  au reste du monde  travers la machine Linux A.


  Pour finir, notez qu'une fois que les adresses matrielles (Ethernet)
  ont t trouves par chacune des machines A, B, C (et D), elles sont
  places dans leur cache ARP, et que les paquets suivants sont
  tranfrs sans surcot d  l'ARP. Normalement, les caches ARP
  suppriment les informations au bout de 5 minutes d'inactivit.



  55..  IInnssttaallllaattiioonn dduu  mmaannddaattaaiirree AARRPP ddee ssoouuss--rrsseeaauu


  J'ai install le mandataire ARP du sous-rseau sur un noyau Linux
  version 2.0.30, mais il parait  que le code fonctionne  avec une
  version 1.2.x.


  La premire chose  noter est que le code ARP est en deux parties :
  une partie dans le noyau, qui envoie et reoit les requtes et les
  rponses ARP et met  jour le cache ARP, etc. ; l'autre partie est
  constitue 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 problme que j'ai eu tait que la commande arp(8) de ma
  distribution Slackware 3.1 tait antique (date de 1994 !) et ne
  communiquait pas correctement du tout avec le code ARP du noyau (``arp
  -a'' donnait un rsultat trange).




  La commande arp(8) de ``net-tools-1.33a'', qui est disponible sur un
  grand nombre de sites, en particulier (d'aprs 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) dcente, il ne me restait plus
  qu' modifier le seul fichier /etc/rc.d/rc.inet1 (pour la Slackware -
  c'est probablement diffrent pour d'autres distributions).  Tout
  d'abord, il nous faut changer l'adresse de diffusion, le numro de
  rseau, et le masque de _e_t_h_0 :


  NETMASK=255.255.255.240 # pour la partie hte sur 4 bits
  NETWORK=x.y.z.64        # notre nouveau rseau
                          #     (remplacez x.y.z par votre rseau)
  BROADCAST=x.y.z.79      # pour moi.



  Il faut ensuite ajouter une ligne pour configurer la seconde interface
  Ethernet (aprs les chargements de modules qui sont ventuellement
  ncessaires 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 dfaut
  pour utiliser celle du rseau 1.


  Arrivs  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 entre statique (``s'') pour
  le rseau ${NETWORK}.  Le ``-D'' dit d'utiliser la mme adresse
  matrielle que l'interface _e_t_h_1 (la seconde interface), ce qui nous
  vite d'avoir  chercher l'adresse matrielle de _e_t_h_1 et de la coder
  directement dans la commande.



  L'option netmask indique qu'il s'agit d'une entre ARP concernant un
  _s_o_u_s_-_r__s_e_a_u, qui est constitu des numros 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 entre ARP, c'est--dire qu'il
  s'agit d'_m_a_n_d_a_t_e_m_e_n_t, et qu'il faudra rpondre au nom de ces numros
  IP.  L'option ``-i eth1'' prcise qu'il ne faudra rpondre qu'aux
  requtes ARP arrivant par l'interface _e_t_h_1.


  Normalement,  ce point, si la machine est redmarre, tous les
  machines du rseau 0 sembleront tre sur le rseau 1.  Vous pouvez
  vrifier que l'entre de mandatement ARP de sous-rseau a t prise en
  compte correctement sur la machine A. Sur ma machine (j'ai chang les
  noms pour protger 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 dernire ligne est l'entre de mandatement pour le sous-rseau. Les
  indicateurs CMP rvlent qu'il s'agit d'une donne statique (entre
  Manuellement) qui doit tre Publie. Elle ne servira qu' rpondre
  qu'aux requtes ARP qui arrivent par _e_t_h_1 et pour lesquelles le numro
  IP, une fois masqu, correspond au numro de rseau (galement
  masqu).  Remarquez que la commande arp(8) a trouv automatiquement
  l'adresse matrielle de _e_t_h_1 et l'a employe comme adresse  utiliser
  ( cause de l'option ``-Ds'').

  De la mme faon il est probablement prudent de vrifier que la table
  de routage a t remplie correctement. Voici la mienne (ici aussi, les
  noms ont t changs pour protger 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 premire entre concerne un sous-ensemble de la
  seconde, mais la table de routage les classe dans l'ordre des masques,
  et donc l'entre _e_t_h_0 sera teste avant celle de _e_t_h_1.



  66..  AAuuttrreess aalltteerrnnaattiivveess aauu mmaannddaatteemmeenntt AARRPP ddee ssoouuss--rrsseeaauu


  Dans la mme situation il y a d'autres possibilits que le mandatement
  ARP de sous-rseau et celles que j'ai dj mentionnes (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 rseau 0 est ``cache'' du reste du monde derrire la machine A.
     Quand les machines du rseau 0 tentent de se connecter 
     l'extrieur  travers la machine A, celle-ci modifie l'adresse
     d'origine et le numro de port des paquets pour qu'ils aient l'air
     d'avoir t envoys par elle-mme, plutt que par la machine cache
     du rseau 0.  C'est une solution lgante, bien qu'elle empche
     toute machine du rseau 1 d'tablir une connexion vers une machine
     du rseau 0, puisque les machines du rseau 0 n'existent pas en
     dehors de celui-ci.

     Ceci amliore efficacement la scurit des machines du rseau 0,
     mais cela signifie aussi que les serveurs du rseau 1 ne peuvent
     pas vrifier l'identit des clients du rseau 0 en se basant sur
     leur numros IP (les serveurs NFS, par exemple, utilisent les noms
     IP pour contrler l'accs aux systmes 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-rseau. C'est tout  fait
     possible, cela signifie simplement qu'il faut crer une entre
     individuelle pour chaque machine du rseau 0, au lieu d'une seule
     entre pour toutes les machines (prsentes et futures) du rseau 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.


  77..  AAuuttrreess aapppplliiccaattiioonnss dduu mmaannddaatteemmeenntt AARRPP ddee ssoouuss--rrsseeaauu




  Je ne connais qu'une autre application du  mandatement ARP de sous-
  rseau, 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-rseaux. 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 dtail).

   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
  rseau utilis est un rseau de classe C, et Andrew avait besoin de le
  dcouper en sous-rseaux pour des raisons de scurit, de contrle du
  trafic et la raison pdagogique mentionne plus haut. Il l'a fait en
  utilisant le mandatement ARP, et a alors dcid qu'une seule entre
  dans le cache ARP pour tout le sous-rseau serait plus rapide et plus
  propre qu'une pour chaque machine du sous-rseau. Et voil.
  Mandatement ARP de sous-rseau !

  Les corrections et les suggestions sont les bienvenues !



  88..  CCooppyyrriigghhtt


  Copyright 1997 par Bob Edwards <Robert.Edwards@anu.edu.au>


  Tlphone : (+61) 2 6249 4090



  Sauf mention contraire, les copyrights des documents ``_L_i_n_u_x _H_O_W_T_O''
  sont dtenus par leurs auteurs respectifs. Ces documents peuvent tre
  reproduits et distribus 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 autorise et
  encourage, cependant l'auteur souhaite en tre averti.  Toutes les
  traductions, les travaux drivs, ou ouvrages incorporant un _L_i_n_u_x
  _H_O_W_T_O doivent tre soumis  cette mme  notice de copyright.
  Autrement dit, vous ne pouvez pas produire un travail driv d'un
  HOWTO en imposant des restrictions supplmentaires  sa diffusion. Des
  drogations  cette rgle peuvent tre accordes sous certaines
  conditions, veuillez contacter le coordinateur des Linux HOWTO 
  l'adresse indique ci-dessous.  En rsum, 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  <greg@sunsie.unc.edu>.
































