/usr/share/doc/HOWTO/fr-html/Proxy-ARP-Subnet.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>ProxyARP Subnetting HOWTO</title>
</head>
<body>
<h1>ProxyARP Subnetting HOWTO</h1>
<h2>Bob Edwards,
&lt;<code>Robert.Edwards@anu.edu.au</code>&gt;</h2>
Août 1997
<hr>
<em>Ce HOWTO explique l'utilisation d'un sous-réseau avec
mandataire (</em>proxy) 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,
&lt;<code>billaud@labri.u-bordeaux.fr</code>&gt;).
<hr>
<h2><a name="s1">1. Introduction</a></h2>
<p>Ce HOWTO explique l'utilisation d'un sous-réseau avec mandataire
(<em>proxy</em>) ARP (protocole de résolution d'adresse), pour
rendre visible un petit réseau de machines (nous l'appellerons
<em>réseau 0</em> dans la suite) comme si ces machines étaient
reliées directement au réseau principal (<em>réseau 1</em>).</p>
<p>Ceci n'a de sens que si les machines sont reliées par Ethernet
ou autres dispositifs de type <em>ether</em> (autrement dit ça ne
convient pas pour SLIP, PPP, CSLIP, etc.)</p>
<h2><a name="s2">2. Remerciements</a></h2>
<p>Ni ce document, ni mon implémentation du mandatement ARP,
n'auraient été possibles sans l'aide :</p>
<ul>
<li>d'Andrew Tridgell, qui a implémenté sous Linux les options de
sous-réseau pour <em>arp</em>, et qui m'a aidé personnellement à le
faire marcher ;</li>
<li>du mini-HOWTO <em>Proxy-ARP</em> écrit par Al LongYear ;</li>
<li>du mini-HOWTO <em>Multiple-Ethernet</em> de Don Becker ;</li>
<li>du code source et de la page de manuel de la commande
<code>arp(8)</code>, de Fred N. van Kempen et Bernd Eckenfels.</li>
</ul>
<h2><a name="s3">3. Pourquoi utiliser un sous-réseau avec
mandataire ARP ?</a></h2>
<p>Les applications d'un sous-réseau avec mandataire ARP sont assez
spécifiques.</p>
<p>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 (<em>driver</em>) 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.</p>
<p>Dans la suite, j'appellerai <em>réseau 0</em> le réseau local
Ethernet relié à la machine Linux par une carte Ethernet (clone
NE-2000) sur <em>eth0</em>. Le <em>réseau 1</em> est le réseau
principal connecté par la carte Ethernet sans-fil sur
<em>eth1</em>. La <em>machine A</em> est la machine Linux avec ses
deux interfaces. La <em>machine B</em> est une station quelconque
du réseau 0, et la <em>machine C</em> est sur le réseau 1.</p>
<p>Normalement, pour réaliser l'interconnexion, on pourrait :</p>
<ul>
<li>utiliser le logiciel IP-Bridge (voir le <em>Bridge
mini-HOWTO</em>) 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 (<em>broadcasts</em>). De plus, un pont charge assez
lourdement le processeur.</li>
<li>ou bien utiliser des sous-réseaux et un routeur pour
transmettre les paquets entre les réseaux (voir le
<em>IP-Subnetworking mini-HOWTO</em>). 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.</li>
</ul>
<p>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 <em>netatalk</em> pour le routage AppleTalk.</p>
<h2><a name="s4">4. Comment marche le mandatement ARP d'un
sous-réseau&nbsp;?</a></h2>
<p>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.</p>
<p>Dans mon cas, le réseau 1 possède un masque de sous-réseau à 8
bits <code>255.255.255.0</code>. Pour le réseau 0, j'ai choisi un
masque à 4 bits (<code>255.255.255.240</code>), 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 !).</p>
<p>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.</p>
<p>La machine A a deux numéros IP, l'un dans la plage d'adresses du
réseau 0 pour sa vraie carte Ethernet (<em>eth0</em>), 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 (<em>eth1</em>).</p>
<p>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.</p>
<p>La première chose magique se produit maintenant, lorsque le code
<em>arp</em> 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 (<em>eth1</em>), 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.</p>
<p>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.</p>
<p>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
(<em>eth0</em>) que pour le réseau 1 (<em>eth1</em>).</p>
<p>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é).</p>
<p>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 <code>arp</code> du noyau Linux voit que
la requête ne vient pas de l'interface du réseau 1 (<em>eth1</em>),
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 (<em>eth0</em>),
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.</p>
<p>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 <em>eth1</em>.</p>
<p>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.</p>
<p>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
(<em>eth0</em>) et s'abstiendra d'y répondre, puisqu'elle n'est
configurée comme mandataire que sur son interface du réseau 1
(<em>eth1</em>).</p>
<p>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.</p>
<p>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é.</p>
<h2><a name="s5">5. Installation du mandataire ARP de
sous-réseau</a></h2>
<p>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.</p>
<p>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 <code>arp(8)</code>
qui permet au super-utilisateur de mettre à jour manuellement le
cache ARP, et à tout le monde de le consulter.</p>
<p>Le premier problème que j'ai eu était que la commande
<code>arp(8)</code> 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 (``<code>arp -a</code>'' donnait un résultat
étrange).</p>
<p>La commande <code>arp(8)</code> de
``<code>net-tools-1.33a</code>'', qui est disponible sur un grand
nombre de sites, en particulier (d'après le README qui lui est
joint)
<code>ftp.linux.org.uk:/pub/linux/Networking/PROGRAMS/NetTools/</code>,
fonctionne correctement, et contient de nouvelles pages de manuel
<code>arp(8)</code> qui expliquent les choses bien mieux que les
anciennes.</p>
<p>Une fois muni d'une commande <code>arp(8)</code> décente, il ne
me restait plus qu'à modifier le seul fichier
<code>/etc/rc.d/rc.inet1</code> (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 <em>eth0</em> :</p>
<pre>
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.
</pre>
<p>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) :</p>
<p><code>/sbin/ifconfig eth1</code> <em>nom_sur_le_réseau_1</em>
<code>broadcast</code> <em>x.y.z.255</em> <code>netmask
255.255.255.0</code></p>
<p>Puis nous ajoutons une route pour la nouvelle interface :</p>
<p><code>/sbin/route add -net</code> <em>x.y.z.0</em> <code>netmask
255.255.255.0</code></p>
<p>Et vous aurez sans doute besoin de changer la passerelle par
défaut pour utiliser celle du réseau 1.</p>
<p>Arrivés à ce point, nous pouvons ajouter la ligne pour le
mandatement ARP :</p>
<pre>
/sbin/arp -i eth1 -Ds ${NETWORK} eth1 netmask ${NETMASK} pub
</pre>
<p>Ceci demande à ARP d'ajouter au cache une entrée statique
(``<code>s</code>'') pour le réseau <code>${NETWORK}</code>. Le
``<code>-D''</code> dit d'utiliser la même adresse matérielle que
l'interface <em>eth1</em> (la seconde interface), ce qui nous évite
d'avoir à chercher l'adresse matérielle de <em>eth1</em> et de la
coder directement dans la commande.</p>
<p>L'option <code>netmask</code> indique qu'il s'agit d'une entrée
ARP concernant un <em>sous-réseau</em>, qui est constitué des
numéros IP tels que</p>
<blockquote><code><em>numéro_ip</em> &amp; ${NETMASK} == ${NETWORK}
&amp; ${NETMASK}</code></blockquote>
L'option <code>pub</code> demande de <em>publier</em> cette entrée
ARP, c'est-à-dire qu'il s'agit d'<em>mandatement</em>, et qu'il
faudra répondre au nom de ces numéros IP. L'option ``<code>-i
eth1</code>'' précise qu'il ne faudra répondre qu'aux requêtes ARP
arrivant par l'interface <em>eth1</em>.
<p>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 :</p>
<pre>
#/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
</pre>
<p>Vous pouvez aussi regarder le fichier
<code>/proc/net/arp</code>, par exemple avec
<code>cat(1)</code>.</p>
<p>La dernière ligne est l'entrée de mandatement pour le
sous-réseau. Les indicateurs <code>CMP</code> 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
<em>eth1</em> et pour lesquelles le numéro IP, une fois masqué,
correspond au numéro de réseau (également masqué). Remarquez que la
commande <code>arp(8)</code> a trouvé automatiquement l'adresse
matérielle de <em>eth1</em> et l'a employée comme adresse à
utiliser (à cause de l'option ``<code>-Ds</code>'').</p>
<p>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) :</p>
<pre>
#/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
</pre>
<p>Vous pouvez aussi regarder le contenu du fichier
<code>/proc/net/route</code> (par exemple avec
<code>cat(1)</code>).</p>
<p>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 <em>eth0</em> sera testée avant celle de
<em>eth1</em>.</p>
<h2><a name="s6">6. Autres alternatives au mandatement ARP de
sous-réseau</a></h2>
<p>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) :</p>
<ul>
<li>``<em>Masquerading IP</em>'' (voir le <em>IP-Masquerade
mini-HOWTO</em>), 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.
<p>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).</p>
</li>
<li>Une autre possibilité serait un <em>tunnel IP sur IP</em>, 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.</li>
<li>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.</li>
<li>Il se peut que l'<em>aliasing IP</em> puisse être utilisé ici
(NdT: francheement ça m'étonnerait), mais je n'ai pas du tout
exploré cette voie.</li>
</ul>
<h2><a name="s7">7. Autres applications du mandatement ARP de
sous-réseau</a></h2>
<p>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).</p>
<p>Á 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
!</p>
<p>Les corrections et les suggestions sont les bienvenues !</p>
<h2><a name="s8">8. Copyright</a></h2>
<p>Copyright 1997 par Bob Edwards
&lt;<code>Robert.Edwards@anu.edu.au</code>&gt;</p>
<p>Téléphone : (+61) 2 6249 4090</p>
<p>Sauf mention contraire, les copyrights des documents ``<em>Linux
HOWTO</em>'' 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 <em>Linux HOWTO</em> 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 à
&lt;<code>greg@sunsie.unc.edu</code>&gt;.</p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / Proxy-ARP-Subnet.html
