Répéteur CPL - Iptables [Résolu]

[meialda]

Bonjour,
je vous expose mon problème ici.
Je travaille sur un répéteur CPL qui doit être capable de répéter le signal sur un seul segment (globalement ça veut dire que le signal rentre et sort par la meme interface on va dire eth0) et router le signal vers un éventuel sous réseau (on va dire que c eth1 qui est du coté de ce réseau).

Le filtrage vers le sous réseau est donc un filtrage classique entre eth0 et eth1... je comprends comment le faire meme si je me suis pas encore penché sur les règles.

Ce qui me fait bizarre, c'est la répétition du signal sur eth0 en fait. En effet, si nous considérons notre réseau de répéteurs dans la meme classe d'@ IPs, tous les répéteurs peuvent communiquer entre eux librement étant donné qu'ils font partie du meme réseau. Cependant, nous voulons assurer la répétition physique du signal (pour gagner en distance) et chaque répéteur aura donc comme route imposée le répéteur qui le suit.

Si vous me suivez toujours, il faut donc que les paquets étant destinés (par exemple) à x.x.0.3 et provenant de x.x.0.1 mais étant obligés de passer par x.x.0.2 (notre répéteur ici) pour des raisons de remise en forme et amplification du signal, rentrent et ressortent par la même interface eth0 du répéteur (x.x.0.2).

Je travaille avec iptables, et je voulais donc connaître la règle qui pourrait correspondre à un tel forwarding en fait.

Voilà, si vous avez compris mon pb et que vous pouvez m'aider je suis preneur
N'hésitez pas à me poser des questions si j'ai mal exposé mon problème :p

Cordialement

P.S : pour ceux qui visualisent mal comment plusieurs répéteurs peuvent être connectés sur une seule interface, il faut bien garder à l'esprit que l'on travaille sur un réseau CPL même si l'arrivée sur le répéteur se fait en ethernet. Tout fonctionne donc comme si le répéteur était directement raccordé au réseau électrique et les autres répéteurs sont connectés ainsi. Ceci entraîne donc que les paquets rentrent et ressortent sur eth0 si ils sont destinés à être répétés.

[Franck78]

Salut,

Ce que je comprend, c'est que tu te fous royalement des couches réseaux (4 ou 7 selon le modèle).

D'abord la longeur:
si il y a une longeur maxi de cable entre les deux cartes réseaux ethernet d'un même 'segment' ou domaine de collision dirons d'autres, répéteur compris, c'est pour que le CSMA/CD fonctionne....
Et oui tout est basé sur le temps de propagation du signal (CS = carrier sense). Distance trop longue, chaque carte pense que la voie est libre, chaque carte emet alors sa trame et et et colision au milieu du segment!
Bilan=ca marche très mal.

Alors oui, achètes un répéteur qui répéte sans se soucier de la couche supérieure ou travaille au bon niveau!

[meialda]

hum tu as pas du comprendre là.. le répéteur je l'achète pas.. je le fais :p
et c pas de mon réseau qu'il s'agit.. le répéteur s'intégrera par la suite dans divers réseaux CPL... aux endroits où il faut

[Franck78]

si si, je comprend bien ton message.

Et j'insiste bien: tu parles de routage à partir du moment ou tu touches aux IP (X.X.01 en est une non ?)
mais tu descends ton pb à la couche liaison.

[meialda]

Tu dis que je descends mon pb à la couche liaison parce que je resonne en interfaces réseau?
Ca c'était pour bien faire comprendre que c'était pas juste une passerelle, mais que ce qui devait rester sur x.x.0.0/24 devait repasser par la meme interface que celle d'entrée. Mais le filtrage se fait bel et bien au niveau IP.
En y réfléchissant je me dis donc qu'il faudrait que je fasse en gros du nat en disant que les paquets qui arrivent avec l'@ de destination sur le réseau 0.x repartent avec l'@ du répéteur par lequel il doit passer ensuite.
C'est pour ça que je demande si quelqu'un sait quelle règle iptable je pourrai utiliser. On sait forcément que le paquet repartira vers x.x.0.3

[meialda]

Bonjour,
bon j'ai résolu mes problèmes de répétition sur la meme interface d'arrivée et de sortie et mon réseau marche ma foi pas trop mal et avec les chemins que je désire emprunter.

Pour ceux qui ont lu le premier post, le but est de répéter le signal, et de pouvoir administrer les sous réseaux se trouvant derrière les répéteurs en accédant à ces répéteurs via une interface web.
Seulement nous avons bien vu que nous voulons emprunter des routes définies (sinon le signal CPL n'aura plus l'intensité nécessaire pour aller vers un point précis). Je me pose donc à présent la question de comment accéder aux divers répéteurs présents sur mon réseau en forçant des routes précises dans le réseau. (en effet les routes que je désire sont bien empruntées mais pour les paquets sortants du réseau.. pas pour l'intérieur du réseau)

Pour avoir une vue un peu plus précise, ces répéteurs appartiennent à un meme sous réseau privé. On peut donc accéder de l'extérieur à la tete de réseau qui sera un serveur ou un répéteur fonctionnant en mode routeur mais comment ensuite, de ce serveur (ou répéteur) accéder aux autres répéteurs en forçant un chemin?

En effet, j'ai fait des tests en considérant trois répéteurs (avec le premier qui sert juste de passerelle vers l'internet et qui ressort donc sur son deuxieme port ethernet vers le réseau de répéteurs).
Si nous avons donc pour le premier répéteur l'@IP 172.16.0.1, pour le deuxieme l'@IP 172.16.0.2 et le troisieme 172.16.0.3 l'idée pourrait etre de réaliser les routes suivantes :

pour 0.1 : dest********gateway********interface
********172.16.0.0*******************eth0
********172.16.0.0***172.16.0.2*******eth0
********192.168.12.0*****************eth1
********default*******192.168.12.249***eth1

eth0 est l'interface vers le réseau de répéteur... eth1 vers internet et 12.249 est le modem adsl on va dire


pour 0.2 : dest********gateway********interface
********172.16.0.0*******************eth0
********172.16.0.0***172.16.0.3*******eth0
********default*******172.16.0.1******eth0

pour 0.3 : dest********gateway********interface
********172.16.0.0*******************eth0
********default*******172.16.0.2******eth0

Voilà, l'idée est donc de forcer des routes à l'intérieur meme du sous réseau.
Mais voilà, on se dit bah c cool ça va marcher.. sauf que non parce que imaginons un ssh de 0.1 à 0.2 avec cette configuration bah on a :

0.1 va voir 0.2 (route dans le sous réseau) qui lui a 0.3 comme passerelle vers le sous réseau au lieu de répondre directement à 0.1, bah il va voir 0.3... et donc 0.3 (s'il n'est pas trop loin en distance et vu ses routes) pourra répondre à 0.1 mais c'est pas garanti d'une part niveau architectural... et d'autre part.. 0.3 n'accepte pas le retour étant donné que le paquet en revient pas physiquement de 0.2.

Voilà, je me demande donc si'il ne faut pas que j'instaure un système qui permet de faire remonter les infos des répéteurs sur leurs sous réseaux au premier répéteur/routeur/serveur afin que la consultation et l'administration se fasse finalement sur la tete de réseau (accessible depuis l'extérieur).. ou alors si il faut que je trouve malgré tout une solution pour imposer les routes dans le réseau de répéteurs.

Si vous avez des questions sur ce que j'ai expliqué.... j'ai essayé de faire de mon mieux mais c pas évident quand on est pas dedans.. j'y répondrai volontiers..

Merci pour votre future aide

[jdh]

Je ne comprends absolument pas l'intéret d'un tel travail mais ... (malgré plus de 10 ans d'expérience dans les réseaux).

Il est possible de définir précisement un routage par la commande "route". Cf man route.

Cependant l'intéret d'un routage est d'être plutôt dynamique. D'où l'existence de plusieurs protocoles définis dans ce but. Les plus connus sont RIP, OSPF, BGP. Historiquement RIP a été le premier, mais son insuffisance (criante) a entrainé l'apparition des 2 autres.

Il faut, pour les comprendre, être capables de comprendre les notions de zones avec le routage interne et externe. C'est très loin d'être évident et simple.

A noter que ce routage dynamique est utilisé sur Internet. Il est donc parfaitement possible qu'un paquet retour de B vers A ne passe pas du tout par le même chemin que le paquet initiale de A vers B. Le protocole TCP permet alors de remettre "dans l'ordre" les paquets malgré une arrivée éventuellement dans le désordre du fait de ces routes différentes.

[meialda]

On est ici dans un réseau CPL (Courant Porteur en Ligne) et il faut bien le garder à l'esprit. La portée du signal sur le courant est de 200m environ (varie en fonction de l'état du réseau électrique).. il faut donc pouvoir etre sur d'atteindre certains points... d'où l'intéret de ce routage.
Et pour définir des routes merci je connais la commande route.. les routes que j'ai spécifié dans le post précédent ont été faites avec :p

Merci

[Franck78]

Je ne comprend pas cette persistence à mélanger la couche réseau et la couche liaison. Quand 'iptables' route quelquechose, c'est une suite d'octet extraite de la couche inférieure. Rien à voir battre que celle-ci lui soit parvenue en CPL, en token ring, ou en ethernet...

Tes cartes réseau CPL recoivent peut-être du 220V mais il en ressort bien une suite 'numérique' de bits. Il n'y a pas de 'régénaration' du signal...

[meialda]

bah hum.. la régénération du signal se fait pas par la carte réseau bien sur..... mais physiquement si le signal ressort d'un point qui est moins éloigné physiquement d'un autre par le CPL, bah le signal sera juste répété.. mais pas au sens d'un EDFA comme une liaison sur fibre par exemple

et je ne vois qu'une seule solution pour que le signal passe par les répéteurs bah c de leur dire d'y passer en se servant du routage IP quoi... sinon ça va jamais passer par là tout seul.. et on va pas dire aux électrons de suivre tel ou tel chemin si?

[Franck78]

Pour un cablage ethernet, le commité 802.3 à fixé un certains nombre de règles physiques pour que cela marche (forme du signal, niveau, distance,...).

Il en est forcément de même pour le CPL. Sinon il n'y aura aucune comptatibilité entre différentes implementations constructeur, chacun chercherait une solution comme toi, etc...

Tu as commencé par chercher ce qui définit les règles physiques du CPL. Par exemple on sait, (décidé), qu'un signal CPL ne doit pas franchir la limite d'un compteur EDF.
-valables avec les anciens car le bobinage bloque la HF. Une chance.
-et avec les nouveaux compteurs électronique, pas sur, car ayant explosé l'un d'eux, je n'ai pas vu de self.

Tu n'as rien à réinventer, sauf si tu bosses chez schlumberger et à les reins assez solide pour imposer une nouvelle 'normes'! Cherches les spécs existantes et fais avec.

Bye

[jdh]

Un bon site de référence sur le CPL : http://www.cpl-france.org/.

Je comprends que le signal (superposé sur le signal alternatif 50hz) subit une atténuation rapide en moins de 200m. De plus ce signal n'est pas arreté par le compteur electrique. Ceci pour évoquer ce que j'ignorais sur cette techno.

AMHA cette techno est destiné à un usage non-professionnel (où la sécurité n'est pas essentielle) limité à la maison. Je note que certains FAI (Neuf par exemple) se mettent à proposer des kits CPL à prix abordables.


Le cas que tu décris est soit un travail universitaire soit en milieu professionnel, ce que tu ne précises pas.
L'intéret me parait assez limité et très technique. Certains fournisseurs ont d'ailleurs travaillé sur le sujet : Oxane par exemple : http://www.01net.com/article/240885.html

AMHA je n'utiliserais pas ce type de techno en entreprise du fait des faibles performances et du manque flagrant de sécurité. La fibre optique ou le câblage catégorie 5 (FTP ou SFTP) me paraissent des technos suffisamment éprouvées, peu onéreuses (plus ou moins) et évolutives. Seule des solutions comme celle d'Oxane me paraissent professionnelles mais à 200€ le point (en 14Mb), c'est vite vu !

Il faudrait s'intéresser aux "bridges" et non aux "routeurs" pour comprendre les mécanismes en jeu. Je note que tu ne t'intéresses pas à proxy-Arp qui me parait essentiel. Comme Franck, il me semble qu'il ne faut pas mélanger les couches de protocoles : regarder le routage ip est assez restrictif (et de niveau trop supérieur) par rapport à du bridge à l'aide de MAC adresses.

Même si le travail de cette société (oxane) semble très pro, je ne suis pas sur que le marché cible soit très étendu.

[Franck78]

grâce au protocole de répétition et de routage automatisé (PLRP, Powerline Routed Protocol ), qui, si besoin, répète ou reroute le signal en fonction de sa qualité.

PLRP: proprio ou non? L'article datant de deux ans, il y surement du changement depuis...

[jdh]

PLRP est propriétaire cf le site d'Oxane.

Je recommande le site de la société Oxane qui donne pas mal d'infos sur son activité.

Je ne suis pas persuadé de la réalité du marché visé mais, comme il s'agit de vendéens, ce sont des gens les pieds sur terre. (J'ai été formé en Vendée !)

On voit bien que le marché de la fourniture d'accès à Internet dans les hotels (ou les campings) existe. Mais il me semble déjà couvert par des solutions Wifi très facile à mettre en oeuvre. Même si ces solutions sont peu sécuritaires. De tous temps en informatique, on a vu (hélas) que les solutions les meilleures ne sont pas celles qui se développent le mieux : exemple Token-Ring contre Ethernet, Windows contre Novell, Windows contre Linux, ...

Bonne chance à Oxane. Ils savent faire ce que veux faire meialda.

[meialda]

Oxance plutot que oxane il me semble...

De plus, les répéteurs sont placés au niveau des fausses coupures du réseau électrique... L'intéret est par exemple d'amener l'adsl à des zones ne l'ayant pas encore en outdoor par le réseau électrique... intéret indoor plutot limité.

Je crois que l'on se comprend pas très bien et que vous ne saississez de ttes façons pas l'intéret du projet et donc donnez des solutions autres comme cabler (alors que c'est justement ce qui coute cher). Moi je vous dit que mon réseau est tel qu'il est.. que je dois passer par ces répéteurs.. qui n'ont qu'une seule interface ethernet pour simplifier la compréhension.. et que si j'impose pas une route au niveau IP.. bah ça y passera pas hein... alors bon.. si vous avez une idée ok.. sinon si on en était au point de cabler en fibre ou RJ45 bah on se poserait pas la question du CPL hein.... non?

Le réseau marche donc bien quand un client de l'intérieur veut accéder un point hors du réseau de répéteur (bon sauts et donc couverture assurée) mais j'ai un problème d'accès interne à mes répéteurs... si vous avez une idée ok.. sinon me proposez pas un cabalge à deux balles.. ce n'est pas une option

Edit : v peut etre regarder Spanning tree pour les routes à l'intérieur du réseau.. comme ça ça assurera les sauts et y aura pas de boucles mais on controlera pas grand chose masi au moins ce sera automatique)