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.
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 côté du pont demande l'adresse matérielle d'un hôte se situant de l'autre côté, 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.
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 côté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 :
-
Assigner une adresse à chaque interface, la "gauche" et la "droite"
-
Créer des routes pour que votre machine connaisse quels hôtes résident à gauche et quels hôtes résident à droite
-
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 côté gauche (Left) et de celle du côté droit (Right)
N'oubliez pas également d'activer l'option ip_forwarding ! Quand 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. Dans le passé, certaines versions de route pouvaient correctement deviner le masque ou, au contraire, se tromper 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.