les gens
 
 
Je ne sais pas si vous avez suivi mes prises de chou avec le bridging d'interface, mais j'ai une autre idée... Y a t'il un moyen (peu importe lekel) de spécifier un routage de paquets en fonction de l'@ IP source ?
 
Un exemple:  
 
- Configurer le nux pour que les paquets provenant d'une ip X soient routés vers l'IP Y automatiquement et sans changer les entetes IP (donc notamment l'adresse source).
 
En temps normal on route les paquets suivant l'adresse du réseau de destination, par suivant l'adresse IP source du paquet... d'où ma question
 
Est-ce possible ? Quelqu'un a t'il une idée svp ? merci d'avance...
 
 
PS: ne me répondez pas iptables, ça fonctionne pas

t'as bien fait d'éditer, parce que je dis iptables (pourquoi ça marche pas ?)

Je me doutais bien qu'on me répondrais iptables
 
Ben en fait je ne souhaite pas que le paquet IP soit modifié, notamment l'adresse ip source ou destination doit rester la même...
 
Or, avec iptables, je ne peux pas faire de NAT de cette façon... J'ai du essayer 500 lignes de commande, pas une ne marche (sisi j'ai bien activé le forwarding IP, tu as vu j'anticipe les questions )  
 
Tu vois mon souci ?

heu ... en principe, ça devrait marcher avec iptables ...

Ben donne la commande alors, je te dirai pourquoi ça marche pas...
 
Je veux que tout le traffic qui arrive sur l'interface ppp0 avec IP 60.0.0.1/30 soit redirigé automatiquement et sans modification du paquet vers l'interface toPC1 (tunnel GRE) avec IP 60.0.0.6/30
 

ps : c'est du traffic multicast

euh la table mangle fait pas ce que tu veux ?

Ben la table mangle permet de modifier les paquets mais pa de les rediriger/forwarder/router... je m'en sers par exemple pour incrémenter le TTL des paquets multicast pour qu'ils traversent mon pont

Je viens de regarder et apparemment, ça doit se gérer avec du policy routing... Notamment du iproute2 de bourrin, j'espère trouver rapidement

tu peux pas "tagger" les paquets et les "récupérer" avec ip route après ?

http://lartc.org/howto/lartc.netfilter.html

Moui  ... je viens de jeter un oeil aussi ...
 
http://lartc.org/howto/lartc.rpdb.html
 
A priori, il faut :

• créer une nouvelle "table de routage"
• ajouter une/des règles qui disent quelles sont les adresses sources "impactées" par cette table de routage
• ajouter la passerelle/le routeur (le "next hop" quoi) par défaut pour cette "table de routage"
• penser à "flusher" le "cache de routage"

Yop, c'est fort gentil à toi tout ça, j'ai trouvé un truc qui explique exactement ce que je veux : utilisation de telle gateway suivant l'IP source...
 
Seul léger problème, j'ai tout fait comme expliqué ( ce qui correspond à ce que tu me dis ci-dessus) et le résultat est très simple : ca marche toujours pas
 
Comment c'est la loooooooooooooooose merci qd même

Je rappelle que j'ai ce type de réseau avec trois pc's reliés entre eux.
 
 
     PC1 ----------------------  PC2  ------------------ PC3            
IP: 60.0.0.6/30          IP: 60.0.0.5/30           IP: 60.0.0.2/29  
Dev: toLAC               Dev : toPC1               Dev : ppp0
                                      et
                                 IP: 60.0.0.1/30
                                 Dev: ppp0
 
 
Je tente donc du policy routing sur le PC2 qui doit faire le forwarding des flux (ces config concernent le sens PC1 vers PC3 en passant par PC2) :
 
> ip rule add from 60.0.0.6 table 20
> ip route add default via 60.0.0.1 dev ppp0 table 20
> ip route flush cache
 
Ca ne fonctionne pas... Suis pas sûr de ma commande de routage associée à la table 20, vous en pensez quoi ?

Allez euhhhh siouplé
 
Personne n'a déjà utilisé ce type de commandes ?

Cé quoi les symptomes du problème exactement ?

Merci de t'intéresser
 
ben le symptome est simple :  
 
sur le PC2 mon paquet émis par PC1 arrive bien sur l'interface toPC1, mais il ne ressort pas par l'interface ppp0 en direction du PC3.
 
Pourtant j'ai configuré le routage comme explicité ci-dessus. J'ai aussi vider les caches de routage, activer le forwarding IP... je sais plu trop quoi faire
 
Comme règle pour la table 20, j'ai également ajouté "tous les paquets qui viennent de toPC1" : ip rule add dev toPC1 table 20
 
Même avec les deux règles de match (IP et device), aucun paquet est routé comme je veux

Essaies ça pour voir :
 

• echo 20 ma_table >> /etc/iproute2/rt_tables
• ip rule add from 60.0.0.6 table ma_table
• ip route add default via 60.0.0.1 dev ppp0 table ma_table
• ip route flush cache

 
Penses à bien nettoyer tes tables de routage des essais précédents, avant de lancer ces manips ...

T'as bien fait gaffe à ce que ta machine PC2 ne filtre pas (firewall) ce que tu souhaites router ?

avec un proxy arp, non ?

Zzozo and co
 
Ben j'ai mis exactement tes commande Zzozo, mais ca ne marche po et c'était d'ailleurs les mêmes que moi hormis le renommage de table
 
Suis sur un pc rebooté nickel de base, avec les paquetages et options du noyau activées comme il faut, j'ai activé le forwarding IP, j'ai arreté iptables...
 
Ben ça marche toujours pas, même quand j'essaie de matcher pour tous les paquets et non seulement ceux avec ma bonne ip source...
 
Y aurait il des paramétrages oubliés par mes soins ? Une ruse de siouxee ?

Re
 
 
Quand je fais un ip rule, j'obtiens ça :
0:     from all     lookup local
32765: from 0.0.0.0 lookup 1
32766: from all     lookup main
32767: from all     lookup 253
 
On voit bien que le premier élément est l'interface locale. Dois je en déduire que tout paquet destiné à ce PC est en fait gérer par le système avant de "rentrer" dans ma ligne de la table de routage ??? Genre ça matcherais avant que ma règle se fasse ?
 
parce que là j'ai une config minimale, ya plus rien hormis forwarding IP, une regle et une ligne de routage... Ben un ping n'est pas relayé par exemple, mon PC y réponds au lieu de transférer le ping comme le suggère ma règle...

ya bien plu que mes smiles qui dansent, j'en ai plein le bip de ce truc :bounce:

Euh je (re)débarque un peu mais en quoi le bridging de niveau 2 ne fonctionnerait pas sur ça ?

c'est tout ce que t'as après avoir ajouté une nouvelle règle avec ip rule add ?     ... je me demande s'il te manque pas un truc dans ton noyau ...  

notamment, aurais tu ces lignes là dans ton .config ? :
 

 
Sisi, j'ai bien ces lignes dans ma config noyau, je les ai activées il y a quelques jours... D'ailleurs si j'avais pas cette config là, je n'aurais même pas pu tenter les commandes je pense... Là les commandes passent c'est simplement que le résultat est pas là
 
Donc pour info, les trois tables de base sur une RH9:
 
0:     from all     lookup local  
32766: from all     lookup main  
32767: from all     lookup 253  
 
Un exemple de ligne bonus chez moi, suite à l'une des commandes ip rule
32765: from 0.0.0.0 lookup 1  
 
 
-------
 
En fait, je pense avoir trouvé une solution hier, puisque je réussissais à forwarder les paquets ICMP. Je pense que maintenant j'ai juste mon probleme de TTL à régler.  
 
Pour le forward des paquets hier, j'ai en fait bidouillé la table de routage locale qui matchait avant le reroutage : :
 
# Effacement des entrées ajoutées par le kernel dans la table "local"
ip route del 60.0.0.5 table local
ip route del 60.0.0.1 table local
# Ajout des nouvelles entrées pour donner le comportement à suivre sur les interfaces ppp0 et toPC1
ip route add 60.0.0.5 via 60.0.0.2 table local
ip route add 60.0.0.1 via 60.0.0.6 table local
 
Je n'avais pas besoin de nouvelle règle... (par ip rule)
 
 
Maintenant, j'ai le souci du multicast à régler... je ne peux re définir de la même façon le comportement à adopter lors de la réception des différents messages multicast. Mais je dois le mettre en dehors de la table locale, dans une table séparée pour chaque sens du flux, tout en rajoutant 2 règles cette fois-ci afin de distinguer le sens du flux... Enfin ça c'est mon avis et c'est ce que je vais tester là titsuite  
 
Si quelqu'un a des idées...

J'ai toujours du mal à comprendre le but initial de la manip...
 
Tu as un PC source (PC1) qui diffuse de l'UDP multicast et tu veux qui ça arrive au PC cible (PC3) via ton PC2 en utilisant la connexion ppp ?

 
Je n'ai pas voulu donner toute la manip qui est bien compliquée, je pensais que c'était clair tout de même...
 
J'ai trois PC's clients, un LAc, un LNS et une Source Multicast.  
 
- Entre le LAC et le LNS j'ai trois sessions PPP dans un tunnel L2TP: ppp0, ppp1, ppp2
- Entre le LAC et les PC's client, j'ai trois tunnels GRE : toPC1, toPC2, toPC3 sur LAC et toLAC sur chaqun des clients.
 
Le trafic multicast qui vient de la source et arrive au LNS puis au LAC, je veux le forwarder aux différents clients suivant l'interface ppp concernée.
 
Ceci implique que je configure le LAC en pont transparent et qu'aucune modification des paquets ne soit réalisée.  
 
-> J'ai "grugé" les masques de sous réseau histoire de faire croire au LNS que les pc's clients sont à 1hop IP (malgré le LAC intermédiaire).
-> Je dois réussir à faire cette sorte de bridging d'interface sans modification des paquets, ces interfaces étant virtuelles (GRE d'un côté, PPP de l'autre). C'est cette phase que je n'arrive pas à mettre en place correctement. Je ne peux pas faire de NAT car ça modifie les paquets, le trafic multicast et son TTL à 1 me galère pas mal, j'ai rencontré d'autres problèmes encore.
 
 
Au final, je ne parviens pas à faire du policy routing tout con parce que le nux chope les paquets en local avant de faire le routage. J'ai donc bidouillé la table de routage en locale en effaçant les entrées des interfaces concernées. J'ai ajouté des règles ip rule pour distinguer les deux sens de flux multicast qui disent en gros "tous les paquets qui arrivent sur ppp0, je leur applique la table de routage X". Et dans cette table de routage, je définis une passerelle qui correspond à l'interface ppp du LNS dans un sens et interface GRE sur le PC Client dans l'autre sens.
 
Ca marche pour des ping, ça me forwarde ce que je veux ou je veux. Mais ca ne marche pas pour du multicast, le LAC ne relaie rien... Le probleme vient soit du champs TTL à 1 qui fait jeter le pmaquet par le LAC, soit mon routage appliqué à des IP multicast qui ne fonctionne pas.  
 
je ne sais pas si c'est clair, en tout cas c'est galère à expliquer comme ça

OK, c'est un peu plus clair comme ça.
 
Tu as pensé à faire du routage multicast pour ton affaire ?

Yop, c'est ce que je fais sur le LNS avec un démon mrouted modifié.
 
Mais sur le LAC je ne peux pas le mettre en place de la même façon, je t'en expliquerai pas les raisons par contre, j'ai pas vraiment le droit à vrai dire

En fait, mon problème actuel n'est plu de faire du routage en fonction de l'adresse IP source, puisque ça j'y parviens. Mais mon problème est de le faire en multicast et de savoir pourquoi ça ne fonctionne pas alors qu'en flux classique je n'ai pas de souci

 
Les protocoles de routage unicast et multicast sont différents. Tu utilises des adresses de classe D pour ta diffusion ?

Ptet que je t'ai mal compris, mais je n'utilise pas de protocole de routage autre que ceux implémentés dans le Kernel. je fais juste du paramétrage de routes en "policy routing" c'est à dire que je distingue des tables différentes suivant l'interface de réception des paquets tout en ayant anihilé le routage "local" par défaut.
 
Tu me parles de diffusion mais j'ai pas tout capté, tu parles de la diffusion de quel flux et provenant de quelle machine ? De toute façon je n'ai rien d'autre à faire que forwarder les paquets au niveau de mon LAC, ces paquets sont générés correctement avec des IP Multicast valides si c'est ta question
 
Merci pour ton temps accordé en tout cas

De rien, c'est interessant même si c'est dur de ce comprendre sans schéma clair.
 
Quand je te parle de diffusion, c'est que les flux multicast sont "diffusé" au travers du réseau, donc n'importe quelle machine écoutant le flux peut le prendre.
Au niveau du routage (dynamique je l'admets), les protocoles à utiliser sont différents selon si tu traites des flux unicast (utilisation d'OSPF par exemple) ou multicast (pim, ...).
 
Enfin je dis ptet des conneries si j'ai pas bien pigé le rôle de ton architecture.
 
Faudrait approfondir le bridging sur une interface ppp, voir si ya pas moyen de contourner cette limitation.

 
Retour des fêtes, probleme toujours présent...
 
Zebib, merci pour tes précisions, en fait je n'utilise ni OSPF ni PIM, j'ai fait expres de les désactiver même, je t'explique pourquoi. Je me suis dit que le kernel devait gérer différement les flux multicast et unicast sachant que mon routage fonctionne pour des pings classiques par exemple mais pas pour relayer des messages multicast pourtant destiné à tout le monde et donc aussi à ma machine qui forwarde.  
 
Cette machine reçoit bien le paquet multicast, mais elle relaie riene t là est mon probleme. je me suis dit que le kernel devait refiler la gestion du paquet à Pim ou OSPF au lieu d'utiliser la même table de routage que pour de l'unicast. En désactivant tous les démons comme mrouted et en n'activant ni OSPF ni PIM (bidouilles certes, mais ma machine est dédiée à mon expérience) lors de la compilation de sources, celà ne fonctionne pas non plu.
 
En fait, j'ai regardé les sources de route.c du kernel sous Nux, elles montrent bien que les paquets unicast et multicast sont gérés différemment. C'est pour celà que mes paquets multicast ne sont pas soumis à mes règles de routage (de policy routing basé sur interface d'entrée).
 
A part modifier les sources du noyau, celle de Linus et Alan, je vois pas d'autre solution là tout de suite, mais ca m'enchante moyen de tout détruire à coup de vieille prog C dès début Janvier
 
Suis sur qu'il doit y avoir un moyen de pas aller jusque là, genre de bridger des interfaces virtuelles oui, ou de faire un équivalent... M'en sort pas de ce truc et c'est un peu fatiguant en fait, mon chef va finir par s'impatienter

un probleme pour Taz    

je reviens là dessus justement, j'ai déouvert les sources d'un routeur linksys basé sur linux et dedans il y a un mode bridge entre des interfaces "ADSL" et "LAN" comme ils les appellent.
 
L'interface ADSL peut être en ppp, donc c'est que c'est possible de bridger tout ça, par contre est-ce un patch ? A priori oui en cherchant un peu sur le net mais je ne suis pas sur à 100% de cette affirmation.
 
Bonne continuation

Merci Zebib pour l'information, vrai que j'aurais du regarder dans le linksys, c'est dans un WRT54G ou du même style ?
 
Mis à part ça, le truc, c'est que je pense qu'ils utilisent un noyau modifié, ce qu'il me faudrait donc faire moi même dans le code C. J'ai un peu peur d'avoir des effets de bord non souhaité tant mon expé prend en compte de variables réseau différentes... Puis j'ai aussi le problème que j'utilise pas une interface Ethernet mais plutot une interface logique GRE aussi de l'autre côté. Suis pas sûr que le bridging du Linksys transposé à mon Linux à moi serait une solution forcément réalisable facilement...
 
Sinon, j'ai aussi la possibilité de modifier le fichier de routage Linux "route.c" et d'assimiler - en bidouillant - le trafic multicast à du trafic unicast. Le policy routing qui lui serait appliqué serait donc correct. Mais de la même façon je crains des effets de bord, j'avais plutot envie d'utiliser des package ou des solutions de patch rapide du kernel me permettant de faire cette manip proprement. J'avais cru trouver en ebtable mon bonheur, erreur
 
Sinon, j'ai aussi une autre solution, c'est de partir d'une vraie souche L2TP et d'y implémenter les fonctionnalités dont j'ai besoin pour mon LAC.
 
J'ai mis un peu ça de côté pour l'instant mais va falloir que je m'y replonge, donc si certains ont déjà bidouillé une sorte de bridging d'interfaces logiques sous nux, je suis toujours preneur. C'était ma solution favorisée avant de tenter du policy routing, l'idéal serait de pouvoir mettre une règle automatique de bridging au niveau des interfaces, en gros de me faire un pont automatique avec simplement des règles sur les interfaces d'entrée et de sortie...