16. Construire des ponts et des pseudo-ponts avec du Proxy ARP

Les ponts sont des périphériques qui peuvent être installés dans un réseau sans aucune reconfiguration. Un commutateur réseau est basiquement un pont multi-ports. Un pont est souvent un commutateur avec 2 ports. Cependant, Linux supporte très bien plusieurs interfaces dans un pont, le conduisant à fonctionner comme un vrai commutateur.

Les ponts sont souvent déployés quant on est confronté à un réseau défaillant qui a besoin d'être réparé sans aucune modification. Dans la mesure où un pont est un équipement de niveau 2, la couche sous la couche IP, les routeurs et serveurs ne sont pas conscients de son existence. Ceci signifie que vous pouvez bloquer ou modifier certains paquets de manière transparente ou mettre en forme le trafic.

Un autre élément positif est qu'un pont peut souvent être remplacé par un câble croisé ou un hub quand il tombe en panne.

L'aspect négatif est que le mise en place d'un pont peut engendrer beaucoup de confusion, à moins qu'il ne soit très bien configuré. Le pont n'apparaît pas dans les traceroute, mais pourtant des paquets disparaissent sans raison ou sont changés en allant d'un point A à un point B. Vous devriez également vous demander si une organisation qui "ne veut rien changer" fait le bon choix.

Le "pont Linux 2.4" est documenté sur cet page.

16.1 Etat des ponts et iptables

Au moment de Linux 2.4.14, le pont et iptables ne se "voient" pas l'un l'autre sans une aide. Si vous "pontez" les paquets de eth0 à eth1, ils ne "passent" pas par iptables. Ceci signifie que vous ne pouvez pas faire de filtrage, de translation d'adresse (NAT), de dessosage ou quoique ce soit d'autres.

Il y a plusieurs projets continuant de corriger ceci, le meilleur étant celui de l'auteur du code du pont Linux 2.4, Lennert Buytenhek. il nous récemment informé qu'à partir de bridge-nf 0.0.2 (voir l'url ci-dessus), le code est stable et utilisable dans un environnement de production. Il demande maintenant aux responsables du noyau si et comment la mise à jour peut être ajoutée. Rester branché !

Nous comptons que ce problème soit bientôt résolu.

16.2 Pont et mise en forme

Ca marche comme dans les réclames. Soyez sûr du coté attribué à chaque interface. Autrement, il se peut que vous mettiez en forme le trafic sortant au niveau de votre interface interne, ce qui ne marchera pas. Utilisez tcpdump si nécessaire.

16.3 Pseudo-pont avec du Proxy-ARP

Si vous voulez juste implémenter un pseudo-pont, allez jusqu'à la section "Implémentez-le". Cependant, il est sage de lire un peu la façon dont il fonctionne en pratique.

Un pseudo-pont travaille de manière un peu différente. Par défaut, un pont transmet les paquets sans les altérer d'une interface à une autre. Il ne regarde que l'adresse matérielle des paquets pour déterminer où ils doivent aller. Ceci signifie que vous pouvez "pontez" un trafic que Linux ne comprend pas, aussi longtemps qu'il y a une adresse matérielle.

Un "pseudo-pont" travaille différemment et ressemble plus à un routeur caché qu'à un pont. Mais, comme un pont, il a un impact faible sur l'architecture du réseau.

Le fait qu'il ne soit pas un pont présente l'avantage que les paquets traversent réellement le noyau, et peuvent être filtrés, modifiés, redirigés ou reroutés.

Un pont réel peut également réaliser ces tours de force, mais il a besoin d'un code spécial, comme le Ethernet Frame Diverter ou la mise à jour mentionnée au-dessus.

Un autre avantage d'un pseudo-pont est qu'il ne transmet pas les paquets qu'il ne comprend pas, nettoyant ainsi votre réseau de beaucoup de cochonneries. Dans le cas où vous auriez besoin de ces cochonneries (comme les paquets SAP ou Netbeui), utilisez un vrai pont.

ARP & Proxy-ARP

Quand un hôte veut dialoguer avec un autre hôte sur le même segment physique, il envoie un paquet du Protocole de Résolution d'Adresse (ARP) qui, en simplifiant quelque peu, est lu comme ceci : "Qui a 10.0.0.1, le dire à 10.0.0.7". En réponse à ceci, 10.0.0.1 renvoie un petit paquet "ici".

10.0.0.7 envoie alors des paquets à l'adresse matérielle mentionnée dans le paquet "ici". Il met dans un cache cette adresse matérielle pour un temps relativement long et, après l'expiration du cache, repose sa question.

Quand on construit un pseudo-pont, on configure le pont pour qu'il réponde à ces paquets ARP, les hôtes du réseau envoyant alors leurs paquets au pont. Le pont traite alors ces paquets et les envoie à l'interface adaptée.

Donc, en résumé, quand un hôte d'un coté du pont demande l'adresse matérielle d'un hôte se situant de l'autre coté, le pont répond avec un paquet qui dit "transmets le moi".

De cette façon, tout le trafic de données est transmis à la bonne place et il traverse toujours le pont.

Implémentez-le

Les versions anciennes du noyau linux permettait de faire du proxy ARP uniquement à une granularité sous réseaux. Ainsi, pour configurer un pseudo-pont, il fallait spécifier les bonnes routes vers les deux cotés du pont, et également créer les règles proxy-ARP correspondantes. C'était pénible, déjà par la quantité de texte qu'il fallait taper, puis parce qu'il était facile de se tromper et créer des configurations erronées, où le pont répondait à des requêtes pour des réseaux qu'il ne savait pas router.

Avec Linux 2.4 (et peut-être bien le 2.2), cette possibilité a été retirée et a été remplacée par une option dans le répertoire /proc, appelée "proxy-arp". La procédure pour construire un pseudo-pont est maintenant :

1. Assigner une adresse à chaque interface, la "gauche" et la "droite"
2. Créer des routes pour que votre machine connaisse quels hôtes résident à gauche et quels hôtes résident à droite
3. Activer le proxy-ARP sur chaque interface
   echo 1 > /proc/sys/net/ipv4/conf/ethL/proxy_arp
   echo 1 > /proc/sys/net/ipv4/conf/ethR/proxy_arp
   où L et R désignent les numéros de l'interface du coté gauche (Left) et de celle du coté droit (Right)

N'oubliez pas également d'activer l'option ip_forwarding ! Quant on convertit un vrai pont, il se peut que vous trouviez cette option désactivée dans la mesure où il n'y en a pas besoin pour un pont.

Une autre chose que vous devriez considérer lors de la conversion est que vous aurez besoin d'effacer le cache arp des ordinateurs du réseau. Le cache arp peut contenir d'anciennes adresses matérielles du pont qui ne sont plus correctes.

Sur un Cisco, ceci est réalisé en utilisant la commande 'clear arp-cache' et, sous linux, en utilisant 'arp -d ip.adresse'. Vous pouvez aussi attendre l'expiration manuelle du cache, ce qui peut être plutôt long.

Il se peut que vous découvriez également que votre réseau était mal configuré si vous avez/aviez l'habitude de spécifier les routes sans les masques de sous réseau. Certaines versions peuvent avoir deviner correctement de maque ou mal deviner sans pour autant vous le notifier. Quand vous faites du routage chirurgical comme décrit plus haut, il est *vital* que vous vérifiez vos masques de sous-réseau.