Redirection du trafic en fonction de l'adresse MAC

Support Debian
#1

Bonjour,
J’ai un petit souci réseau…

J’ai deux programmes “concurrents” qui écoutent sur la même interface réseau (physique).
dhcp3-server sur eth1 (192.168.0.1)
chillispot sur tun0 (192.168.182.1)

Je souhaite que toutes les requêtes soient dirigées vers tun0 (ça je sais faire)
SAUF pour une liste d’adresses MAC qui doivent rester sagement sur eth1 (ça je ne sais pas faire…)

Est-ce possible ?

Merci!

ps: J’utilise shorewall, mais si une solution existe avec iptables, je m’arrangerais pour “transposer” dans shorewall.

#2

avec iptables tu as le module MAC -m mac avec l’argument --mac-source

#3

Merci Et je viens de me souvenir que PascalHambourg m’a déjà donné l’info :blush:
Je suis nul…
Merci à toi !

#4

On parle de moi ?
Bon, histoire de ne pas intervenir pour rien, mon grain de sel :

  1. Qu’entends-tu par “concurrents” ? Chillispot est aussi un serveur DHCP ?

  2. eth1 et tun0 sont deux interfaces bien distinctes. Tu veux dire que les paquets de tun0, une fois encapsulés, passent par eth1 ? Un paquet du protocole X encapsulé pour tun0 ne sera pas vu comme du protocole X par eth1 mais comme du protocole d’encapsulation.

  3. Avec iptables on ne redirige pas vers une interface mais vers une adresse. Si tu rediriges un paquet reçu par l’interface A vers l’adresse d’une autre interface B de la même machine, il sera toujours vu comme reçu par l’interface A.

  4. Certains programmes DHCP sont un peu spéciaux : ils communiquent directement avec l’interface réseau et non à travers la pile IP, ce qui a notamment pour effet de court-circuiter les règles iptables. Il n’est donc pas certain qu’une redirection des paquets DHCP par iptables soit efficace, c’est à vérifier.

  5. Le NAT d’iptables ne fonctionne bien qu’avec le trafic bidirectionnel de type unicast, ce qui n’est pas le cas du trafic DHCP du moins dans sa phase initiale (DISCOVERY) qui est en broadcast. Cela peut poser un problème pour les réponses.

Si je peux me permettre, quel est le but ultime du bidule ?

#5

Salut,
Merci d’intervenir, j’ai encore un peu de mal à m’y retrouver…

[quote=“PascalHambourg”]

  1. Qu’entends-tu par “concurrents” ? Chillispot est aussi un serveur DHCP ?[/quote]Oui

[quote=“PascalHambourg”]
2) eth1 et tun0 sont deux interfaces bien distinctes. Tu veux dire que les paquets de tun0, une fois encapsulés, passent par eth1 ? Un paquet du protocole X encapsulé pour tun0 ne sera pas vu comme du protocole X par eth1 mais comme du protocole d’encapsulation.[/quote]Pas tout à fait, la demande entre par tun0, Chillispot donne une IP, une autorisation et autorise l’accès à ppp0 (Internet).[/quote]

[quote=“PascalHambourg”]3) Avec iptables on ne redirige pas vers une interface mais vers une adresse. Si tu rediriges un paquet reçu par l’interface A vers l’adresse d’une autre interface B de la même machine, il sera toujours vu comme reçu par l’interface A.[/quote]Ok. Donc je souhaite rediriger vers les bonnes adresses les demandes…

[quote=“PascalHambourg”]
4) Certains programmes DHCP sont un peu spéciaux : ils communiquent directement avec l’interface réseau et non à travers la pile IP, ce qui a notamment pour effet de court-circuiter les règles iptables. Il n’est donc pas certain qu’une redirection des paquets DHCP par iptables soit efficace, c’est à vérifier.[/quote]Probablement, car c’est aléatoire… une demande dhclient envoie tantôt sur eth1 tantôt sur tun0, c’est ce que je souhaite éviter… Et ceci malgré toutes mes tentatives avec shorewall…

[quote=“PascalHambourg”]
5) Le NAT d’iptables ne fonctionne bien qu’avec le trafic bidirectionnel de type unicast, ce qui n’est pas le cas du trafic DHCP du moins dans sa phase initiale (DISCOVERY) qui est en broadcast. Cela peut poser un problème pour les réponses.

Si je peux me permettre, quel est le but ultime du bidule ?[/quote]
Je souhaite que les ordinateurs connus de mon ethernet obtiennent leur IP de Dhcp3-serveur sur eth1.
Et que les clients “inconnus” soient dirigés vers tun0 pour authentification.

Le plus simple est peut-être de recenser les clients connus dans dhcp, ne pas autoriser les clients “non connus”. Les autres n’ayant pas de réponse sur eht1 seront automatiquement dirigées sur tun0. non ?

Edit : Non… ça fonctionnera pour les “clients” inconnus, pas pour les connus. Je ne vois pas comment empêcher qu’ils entrent par tun0…

Edit2 : Connection requests from this interface are compared against the contents of shorewall-maclist (5). If this option is specified, the interface must be an ethernet NIC and must be up before Shorewall is started…

Tun0 n’est pas une interface NIC… le filtrage MAC ne peux pas fonctionner…

#6

Bon, je me suis un peu documenté sur le site de ChilliSpot pour comprendre à quoi servait cette interface tun0. Si j’ai bien compris, ChilliSpot intercepte les paquets envoyés par les clients sur l’interface ethernet physique “downlink”, répond lui-même aux requêtes DHCP et ARP, et transmet (ou pas, selon que le client source est authentifié ou pas) les autres paquets sur l’interface tun0 afin qu’ils soient routés par la pile TCP/IP du noyau. Je comprends donc mieux pourquoi tu parlais de “la même interface réseau (physique)”.

Représentation en ASCII “art” pour dhcpif=eth1 et eth0=internet (disclaimer : je ne suis pas un artiste) :

Ainsi, les requêtes DHCP reçues par eth1 ne sont pas transmises à tun0 mais sont interceptées et directement traitées par Chillispot. tun0 ne sert qu’au trafic “internet” des clients.

En un sens, ChilliSpot et dhcp3-server font la même chose sur l’interface ethernet, et il n’est pas étonnant que le résultat soit aléatoire si c’est tantôt l’un et tantôt l’autre qui récupère et traite une requête DHCP.

Je ne peux m’empêcher d’observer que ta configuration ne respecte pas les recommandations de la FAQ de ChilliSpot sur deux points :

[quote][ul][li]The network interface should normally not be configured with an IP address. Take eth1 down by typing /sbin/ifdown eth1.[/li]
[li]No other DHCP server must be running on the network interface (ChilliSpot allocates the IP address).[/li][/ul][/quote]

Seulement un serveur DHCP n’écoute pas sur une adresse particulière mais sur une interface. D’ailleurs les requêtes DHCPDISCOVER sont envoyées à l’adresse de broadcast limité 255.255.255.255. D’autre part d’après mon schéma, iptables, qui fait partie de la pile TCP/IP, n’intervient que sur les paquets de tun0 et pas sur ceux d’eth1. AMA l’approche basée sur iptables est une impasse.

[quote=“lol”]Je souhaite que les ordinateurs connus de mon ethernet obtiennent leur IP de Dhcp3-serveur sur eth1.
Et que les clients “inconnus” soient dirigés vers tun0 pour authentification.[/quote]
Si les ordinateurs “connus” le sont par leur adresse MAC, il semble que ChilliSpot permet de faire une authentification par adresse MAC (cf. options macauth ou macallowed), avec possibilité d’allocation d’une adresse IP fixe par le serveur RADIUS avec l’option statip.

Si tu veux absolument utiliser dhcp3-server, je ne vois guère qu’une solution basée sur le pontage ethernet (bridge) avec filtrage de l’adresse MAC par ebtables.

#7

Bonjour,
Tu ne fais pas les choses à moitié… Merci, je suis impressionné !

[quote=“PascalHambourg”]il n’est pas étonnant que le résultat soit aléatoire si c’est tantôt l’un et tantôt l’autre qui récupère et traite une requête DHCP[/quote]C’est très clair maintenant.

[quote=“PascalHambourg”]Je ne peux m’empêcher d’observer que ta configuration ne respecte pas les recommandations de la FAQ de ChilliSpot sur deux points :[quote]
* The network interface should normally not be configured with an IP address. Take eth1 down by typing /sbin/ifdown eth1.
* No other DHCP server must be running on the network interface (ChilliSpot allocates the IP address).[/quote][/quote]Je n’avais lu dans aucun des tutos que je devais désactiver l’interface réseau. Je suis passé à coté :blush:
Je savais que le DHCP devait être éteint… Mais j’espérais…

[quote]iptables, qui fait partie de la pile TCP/IP, n’intervient que sur les paquets de tun0 et pas sur ceux d’eth1[/quote]Donc impossible de réaliser ce que je souhaite…

[quote=“PascalHambourg”]Si les ordinateurs “connus” le sont par leur adresse MAC, il semble que ChilliSpot permet de faire une authentification par adresse MAC (cf. options macauth ou macallowed), avec possibilité d’allocation d’une adresse IP fixe par le serveur RADIUS avec l’option statip.[/quote]Oui, mais… tout le monde sera sur le même réseau, et mon serveur n’aura plus d’IP puisqu’il faut enlever l’IP de l’interface sur laquelle écoute Chillispot ? non ?

[quote=“PascalHambourg”]Si tu veux absolument utiliser dhcp3-server, je ne vois guère qu’une solution basée sur le pontage ethernet (bridge) avec filtrage de l’adresse MAC par ebtables.[/quote]Oui…

Et si… Je rajoute une carte réseau uniquement pour dhcp3-serveur (J’ai deux cartes ethernet libres dans le serveur…), je règle mon problème ?
eth1 pour Chillispot, sans adresse ip (celles de Chillispot 192.168.182.0/24)
eth2 pour mon réseau “privé” 192.168.0.0/24
J’ai encore un problème… eth1 et eth2 sont toutes les deux à l’écoute sur le même réseau physique… Il est possible d’empêcher certaines machines de faire leur demande sur une interface ? Cette fois-ci s’il s’agit d’une interface ça ne pose pas de problème ?

Merci beaucoup pour le temps passé sur mes questions, et pour tes réponses précises !

#8

Ce n’est pas très grave dans la mesure où ChilliSpot va forcément la réactiver. Le point important était AMA surtout l’absence d’adresse IP et de sous-réseau sur l’interface physique, car celle-ci ne doit pas être vue par la pile TCP/IP du noyau qui ne doit voir que tun0.

Tout le monde est déjà sur le même réseau physique de toute façon, qu’il y ai plusieurs préfixes IP dessus ne change pas grand chose. Quant à l’adresse IP du serveur, c’est celle de tun0 qui compte.

Si eth1 et eth2 sont connectées au même réseau physique, ça ne change rien au problème de fond qui est que tu veux faire cohabiter un réseau “normal” et un réseau de type hotspot sur le même réseau physique. Je ne te demande pas pourquoi, je suppose que tu as tes raisons.

Tu peux configurer dhcp3-server pour ne répondre qu’aux requêtes DHCP provenant d’adresses MAC connues, mais en revanche je n’ai pas l’impression que ChilliSpot sache ignorer les paquets provenant d’adresses MAC spécifiques. Pour y parvenir, on doit pouvoir créer un pont contenant eth1, utiliser l’interface pont dans ChilliSpot et faire du filtrage d’adresse MAC sur le pont avec ebtables. On peut peut-être se passer d’une interface physique supplémentaire grâce à une interface virtuelle pontée ou en utilisant la fonction “brouting” d’ebtables.

#9

Merci,
Je ne vais pas m’embarquer dans des choses aussi compliquées, je ne maîtrise pas… Je vais donc mettre tout le monde sur le dhcp de chillispot ! Mais je vais le forcer à être sur 192.168.0.0/24; je n’ai pas envie de reparamétrer tous les services du serveur :wink:
Je me garde 50 IP pour mon réseau Perso, le reste pour le réseau public.

… Je vais éclairer ta lanterne :
J’ai un réseau hétéroclite…
Un routeur/Proxy/Pare-feu (mon serveur) connecté à Internet.
Le serveur est relié à un LAN qui distribue le réseau à la zone n°1 en filaire (privé) + 1 point WiFi (public)
La zone N°2 est reliée à la Zone n°1 par une BLR (1 km de distance) > C’est ce goulet là que je ne peux pas modifier
Dans le zone n°2 un Lan (privé) + 1 point wifi (public)

Donc difficile de séparer physiquement les deux réseaux… A moins de me payer une deuxième BLR, mais crois moi ce n’est pas cadeau ici à Madagascar…

Encore merci pour tes explications.
Je vais essayer de ne pas reposer les mêmes questions après-demain :wink:

#10

Ne serait-il pas possible de séparer logiquement les réseaux public et privé tout en mutualisant les liaisons physiques avec des techniques de type VPN ou VLAN ?

#11

J’ai bien pensé au VPN oui, mais… je ne sais pas comment faire. Vu “de loin” ça n’a pas l’air évident à mettre en place…
VLAN, je ne sais pas comment ça fonctionne… Je viens de lire une page Wiki sur le vlan ça a l’air séduisant !
Toi qui a des facilités pour ce genre d’explication, tu peux me faire un petit topo si ce n’est abuser (même tout petit) ?

Quelle serait la meilleure solution d’après toi ? (sachant qu’il y a quelques machines sous un OS “dont-il-ne-faut-pas-dire-le-nom”)

Ce sera la prochaine étape…

#12

Bien
j’ai lu la doc livrée avec vlan… Installer vlan est carrément simple…
L’interface eth0 est démarrée sans adresse IP.

Nous créons ensuite autant (presque) d’interfaces virtuelles que nous le souhaitons… (vlan1, vlan2…)
configurées comme ceci dans /etc/network/interfaces

# VLAN 1 iface vlan1 inet static address 192.168.0.8 netmask 255.255.255.192 network 192.168.0.0 broadcast 192.168.0.63 mtu 1500 vlan_raw_device eth0
/etc/init.d/networking restart… et le tour est joué.

C’est ipatbles (avec shorewall en plus chez moi) qui fait tout le boulot ensuite, c’est ça ?

Mais ça c’est pour du vlan niveau 3…
J’ai lu qu’il était possible de faire du vlan niveau 2… Difficile à mettre en place ?

Ok… RTFM :laughing:

Encore merci PascalHambourg pour tes infos, j’ai beaucoup appris aujourd’hui !
Apéro dans une demi heure… :wink:

#13

Le VLAN, c’est du niveau 2. Cela consiste à faire passer plusieurs réseaux ethernet isolés les uns des autres sur une même liaison physique en insérant dans l’en-tête des trames ethernet une étiquette (tag) qui identifie le réseau logique auquel elles appartiennent. Tu voulais peut-être dire du VLAN logiciel ? Les VLAN sont principalement mis en place sur des switches compatibles VLAN pour économiser des liens, mais on peut aussi le faire sur des serveurs ou des routeurs pour économiser des interfaces. Sur les stations, c’est plus rare.

Pour passer deux VLAN dans la liaison BLR, il faudrait par exemple deux switches compatibles VLAN ayant au moins trois ports. Sur chaque switch de chaque côté de la BLR on définirait deux VLAN, par exemple VLAN1 et VLAN2 avec les tags 1 et 2 :

  • un port non taggé dans VLAN 1 connecté au réseau privé
  • un port non taggé dans VLAN 2 connecté au réseau public
  • un port taggé dans VLAN1 et VLAN2 connecté à la liaison BLR

Si on n’a pas de switch compatible VLAN, pour un volume de trafic modeste on peut se débrouiller avec des machines à trois interfaces ethernet tournant sous Linux en combinant VLAN et pontage, par exemple :

  • eth0 sert de port taggé dans VLAN1 et VLAN2 -> on crée les interfaces VLAN eth0.1 et eth0.2
  • eth1 sert de port non taggé dans VLAN 1 -> on crée un pont br1 entre eth1 et eth0.1
  • eth2 sert de port non taggé dans VLAN 2 -> on créé un pont br2 entre eth2 et eth0.2

Il faut néanmoins s’assurer que la liaison BLR permet l’utilisation de VLAN. Pour cela il suffit qu’elle traite les trames VLAN comme n’importe quel autre type de trame ethernet.

Ça me gonfle prodigieusement cette mode de ne pas oser/vouloir écrire ou de déformer le nom de Microsoft Windows. Ce n'est pas sale ! Je lis et j'écris dans ce forum depuis mon poste sous Windows, ça change quelque chose ? [color=#FF0000][size=200]ECRIT AVEC MICROSOFT WINDOWS[/size][/color] Alors, ça pique les yeux ? J'ai bien envie de le mettre dans ma signature...
#14

[quote=“PascalHambourg”]

Ça me gonfle prodigieusement cette mode de ne pas oser/vouloir écrire ou de déformer le nom de Microsoft Windows. Ce n’est pas sale ! Je lis et j’écris dans ce forum depuis mon poste sous Windows, ça change quelque chose ?
[size=200]ECRIT AVEC MICROSOFT WINDOWS[/size]
Alors, ça pique les yeux ? J’ai bien envie de le mettre dans ma signature…
[/quote]
Non, mais là quand même c’est un peu gros… ça pique un peu :wink: J’ai du mal à me concentrer sur les vlans…
Tu peux signer Bill Gates, moi je m’en fou… mais je préfère PascalHambourg, plus marrant.

Bon les Vlan c’est un peu plus compliqué que je ne le pensais. Je pense que mes BLR supportent, elles sont récentes (Cisco), je vais regarder dans les pages d’administration (j’ai un peu galéré pour mettre ça en route, je vais être prudent.

Salut Bill,
merci !

#15

Fallait pas le recopier si ça pique, parce que maintenant tu le vois deux fois et ça pique deux fois plus. Je ne parlais pas de signer Bill Gates mais de mettre en signature quelque chose du genre “ce message a été écrit avec Microsoft Windows”.

Les VLAN ne sont pas si compliqués à mettre en place, du moins sous Linux. Avec du Cisco en revanche… vu la toute petite expérience que j’ai pu avoir de la doc d’IOS, je t’assure de tout mon soutien moral. Au mieux il n’y a rien à modifier si le bidule transmet bêtement les trames VLAN sans y mettre son nez. C’est quand les équipements se croient trop intelligents qu’on a des ennuis.

#16

[quote=“PascalHambourg”]Fallait pas le recopier si ça pique, parce que maintenant tu le vois deux fois et ça pique deux fois plus. Je ne parlais pas de signer Bill Gates mais de mettre en signature quelque chose du genre “ce message a été écrit avec Microsoft Windows”.[/quote]Microsoft ? Je me suis bêtement plié aux us et coutumes que j’ai vu sur le forum… J’ai plus travailler avec des logiciels microsoft qu’avec des logiciels libres, alors… Mais je fait des progrès…

Je fais un essai, si les BLR “résistent” je n’insiste pas, j’ai déjà pas mal galéré à configurer la liaison (Elles ont été livrées nues… Personne pour m’aider à installer… C’est moi qui suis monté sur le toit poser les antennes, et c’est moi qui me suis coltiné les réglages… Avec un mode d’emploi style “man”…).

Je ne suis pas dans une zone urbaine à risque… Je me contenterais d’une sécurité “raisonnable” !

Merci de tes conseils et merci de m’avoir consacrer de ton temps !

#17

Le risque, avec un équipement réseau trop “intelligent”, c’est qu’il se dise “tiens, une trame VLAN… mais je n’ai pas de configuration pour ça, je ne sais pas quoi en faire donc je la jette”.

Pour tester la transparence aux VLAN, voici un moyen simple. Tu prends deux machines sous GNU/Linux de part et d’autre de la BLR, tu leur crées une interface VLAN avec le même identificateur de VLAN, tu leur configures des adresses dans un sous-réseau IP non utilisé et tu envoies du trafic de l’une à l’autre ; d’abord des trucs simples (ping) puis du gros TCP bien lourd pour vérifier la stabilité. Attention à ce que les jeux de règles iptables ne bloquent pas le trafic des interfaces VLAN.

vconfig add eth0 1
ifconfig eth0.1 192.168.44.x