Liaison ipcop à ipcop en ajoutant des routes?

[Franck78]

alors dans ce cas pourquoi ne pas utiliser un tunnel type IP au lieux d'un tunnel type ETHERNET

je pensais que tu avais saisi que tu n'as qu'un réseau 'local' ou LAN et en plus une boucle créée entre les switch (brXX) à manager !

[faycalus]

oui un seul support physique avec plusieurs sous réseaux lan et je ne savais pas que le tunnel IP sert a relier deux sous réseaux locaux si c'est ce que vous vouliez dire. j'avoue que j'apprend au fur et a mesure

pour l'utilisation d'ebtables j'arrive pas a trouver les bon tutos, la pression et le manque de temps y sont pour beaucoup alors si vous pouviez m'orienter un peut ça m'aiderais beaucoup en ce moment sachant qu'au finale mon bute ( normalement, a moins que ne surviennent d'autres soucis ) est de restreindre le tunnel a permettre la communication uniquement entre le serveur 192.168.10.100/24 d’un coté et l'automate a l’autre bout 192.168.10.203/24 dans l’unique tunnel expérimentale établis actuellement.

et veuillez m’excuser si je pollue un peut cette section du forum qui est normalement dédier a IPCOP.

[Franck78]

http://linuxcommand.org/man_pages/brctl8.html

et spécialement le dernier chapitre, spanning tree !

Il parait évident que la fibre doit être le chemin normal et vsat le moins prioritaire. Et pendant les coupures de fibre (que SPT doit détecter) vsat sera alors le seul possible.

[faycalus]

Oui effectivement Franck78 ceci régleras le problème de la priorité mais ne spécifie pas qui peut emprunter le tunnel vsat parce qu’il ne faut pas que les cameras passe par la vsat vue quelles saturent le lien et ce n’est pas grave si elles ne fonctionnent pas c'est juste un plus, le plus important c'est la communication serveur automates. En plus puisque le raccordement de la fibre est linéaire (en série) comme indiqué dans le petit schéma il est possible que tous le flux derrière la rupture FO va passer par la dernière vsat avant celle-ci
Ex : s’il y’a une rupture entre la chambre 7 et 8 (ce qui est le cas actuellement) il est possible que tous le flux de l’extrémité chambre 14 a la chambre 8 passe par le tunnel vsat installé a la 8 ce qui explique qu’il faut que chaque tunnel communique exclusivement avec l’automate de la chambre ou il est installé et rien d’autre. Si les cameras a partir de cette chambre ne fonctionnent pas c’est pas grave.
Donc le debian a la sale des commandes avec br0 192.168.10.240 ne doit accepter que les requêtes ou la liaison avec le serveur xp 192.168.10.100 et le debian a la chambre n°1 avec br0 192.168.10.241 ne doit accepter que les requêtes ou la liaison avec l’automate 192.168.10.201 ainsi de suite…

[Franck78]

Mais rien n'interdit d'ajouter des règles iptables : interdire tout puis autoriser que les réseaux ip voulus (FORWARD)

Vu la simplicité demandée (ce n'est pas un firewall), quelques lignes iptables suffisent à faire la police !

Leçons par ici:
http://irp.nain-t.net/doku.php

Désolé de ne pas te servir les solutions sur un plateau ! Le jour ou tu devras étendre ou ajuster ton système, tu sauras bien content de savoir pourquoi il marche !

[faycalus]

Désolé de ne pas te servir les solutions sur un plateau ! Le jour ou tu devras étendre ou ajuster ton système, tu sauras bien content de savoir pourquoi il marche !

Bien entendu Franck78 j'adhère complètement au principe et au contraire je m'estime heureux qu'il y es des gents comme vous qui donnent déjà de leurs temps pour en plus partager leur savoir dans le but d'aider c'est pour cela, d’ailleurs, que j'exprime ma gratitude en remerciant chaque personne qui me répond.

Après dans ce lien http://irp.nain-t.net/doku.php très intéressant si j'ai bien compris, en tous cas ce que j'ai parcouru jusqu’ici, on pourrais même se passé du tunnel si on utilise la table NAT en disant a la passerelle debian de la salle des commandes en premier de n'accepter bien sûre que les requêtes venant du serveur 192.168.10.100/24 et que :

- les requêtes vers 192.168.10.201/24, l'automate de la chambre 01, doivent passer par 10.173.73.6/30 qui est eth1 de la passerelle debian à la chambre 01 puis a celle ci de rediriger ces requêtes venant de 192.168.10.240/24 vers 192.168.10.201 sans oublier de dire a cette passerelle de n'accepter et transmettre que les requêtes provenant de l'automate de cette chambre branché sur le même switch 192.168.10.201/24 puis de transmettre les requêtes vers 192.168.10.100/24 a travers 10.173.73.2/30 qui est eth1 de la passerelle debian a la salle des commandes.

- les requêtes vers 192.168.10.202/24, l'automate de la chambre 02, doivent passer par 10.173.73.10/30 qui est eth1 de la passerelle debian à la chambre 02 puis a celle ci de rediriger ces requêtes venant de 192.168.10.240/24 vers 192.168.10.202 sans oublier de dire a cette passerelle de n'accepter et transmettre que les requêtes provenant de l'automate de cette chambre branché sur le même switch 192.168.10.202/24 puis de transmettre les requêtes vers 192.168.10.100/24 a travers 10.173.73.2/30 qui est eth1 de la passerelle debian a la salle des commandes.

Ainsi de suite...

[Franck78]

Ce qu'on a (que j'ai) compris du problème :

Un lignée de switch (mComm) liés par fibre optique.
Un fibre optique peu sure mais qu'on veut utiliser.
A chaque extrémité du réseau fibre, une liaison Vsat

Quand le fibre se coupe, passage par Vsat pour que la comm reste active.
Quand la fibre est réparée, Vsat repasse en backup.

solution => bridge ethernet virtuel entre chaque extrémité; réglage précis du spanning tree

La dessus évolution
1/Chaque switch intermédiaire sur la fibre possède sa liaison Vsat
2/Tout le trafic ne peut pas passer par le Vsat (ou seulement les automates)

=>un nouveau bridge virtuel à partir du debian salle controle vers chaque switch mComm
=>trois quatres lignes IPtables pour policer ça

Tu as l'air de vouloir monter une usine à gaz pour le point 2.

[faycalus]

Ce qu'on a (que j'ai) compris du problème :

Un lignée de switch (mComm) liés par fibre optique. OK
Un fibre optique peu sure mais qu'on veut utiliser. pas nécessairement
A chaque extrémité du réseau fibre, une liaison Vsat OK

Quand le fibre se coupe, passage par Vsat pour que la comm reste active. OK
Quand la fibre est réparée, Vsat repasse en backup. pas nécessairement

solution => bridge ethernet virtuel entre chaque extrémité; réglage précis du spanning tree

La dessus évolution
1/Chaque switch intermédiaire sur la fibre possède sa liaison Vsat toujours OK
2/Tout le trafic ne peut pas passer par le Vsat (ou seulement les automates) seulement les automates

=>un nouveau bridge virtuel à partir du debian salle controle vers chaque switch mComm pourquoi nouveau?
=>trois quatres lignes IPtables pour policer ça ça coince un peut

Tu as l'air de vouloir monter une usine à gaz pour le point 2.

OK comme j'ai un ultimatum pour Dimanche je vais quand même demander un peut d'aide pour m'orienter

D’après l'architecture netfilter et iptables dans notre cas il faut (je pense, a moins qu'il y es encore d'autres facteurs qui m’échappent) utiliser simplement la table filter, évidement cibler la chaîne INPUT puisqu'on veut interdire l’accès au tunnel a tous sauf au automates et le serveur xp (et mon pc portable 192.168.10.98/24 donc avant tous: iptables -A INPUT -s 192.168.10.98 -j ACCEPT sur tous les debian)

Ensuite donc a ce stade sur tous les debian:iptables -P INPUT DROP
Plus rien ne passe sauf mon pc portable 192.168.10.98/24

Dans notre cas pratique au niveau de la salle contrôle
Le serveur xp en 192.168.10.100/24 est en INPUT par rapport à eth0 (ou plutôt par rapport a br0 en 192.168.10.240/24) de notre passerelle debian et la vsat locale 10.173.73.1/30 est en INPUT par rapport à eth1 10.173.73.2/30
donc:
iptables -A INPUT -s 192.168.10.100 -i br0 -j ACCEPT
iptables -A INPUT -s 10.173.73.1 -i eth1 -j ACCEPT

et de l'autre coté (à la chambre 03 par exemple)
l'automate 192.168.10.203/24 est en INPUT par rapport à eth0 (ou plutôt par rapport a br0 en 192.168.10.243/24) de notre passerelle debian et la vsat locale 10.173.73.13/30 est en INPUT par rapport à eth1 10.173.73.14/30
donc:
iptables -A INPUT -s 192.168.10.203 -i br0 -j ACCEPT
iptables -A INPUT -s 10.173.73.13 -i eth1 -j ACCEPT

Mais es qu’on peut dire que le serveur xp 192.168.10.100/24 et la vsat 10.173.73.1/30 de la salle de contrôle sont en INPUT par rapport à eth1 du debian à la chambre 03?
et peut-on dire aussi que l’automate 192.168.10.203/24 et la vsat 10.173.73.13/30 de la chambre 03 sont en INPUT par rapport à eth1 du debian à la salle de contrôle ?

Et les interfaces internes br0 et eth1 de chaque coté? (192.168.10.240/24 et 10.173.73.2/30 du coté salle de contrôle et 192.168.10.243/24 et 10.173.73.30 du coté de la chambre 03) ?

Sans oublier eth0 tap0?

En dernier es qu’on peut exclure toute la plage 10.173.73.0/30 du drope par rapport a eth1 sur chaque debian ? c.a.d : iptables -A INPUT -s 10.173.73.0/30 -eth1 -j ACCEPT

[Franck78]

Code : Tout sélectionner

iptables -A INPUT -s 192.168.10.203 -i br0 -j ACCEPT
iptables -A INPUT -s 10.173.73.13 -i eth1 -j ACCEPT


Je n'ai pas vraiment étudié iptables avec un switch virtuel. Je ne sais pas trop comment ca interagit.

Cependant,
tu veux jeter ce qui vient de eth0 et va ressort sur tap0, pour quelques IP source ou destination.

C'est dans du FORWARD pour commencer (INPUT c'est de/vers la machine hôte)

ca ressemblera dans à

iptbales -P FORWARD ACCEPT
iptables -F FORWARD
iptables -A FORWARD -i eth0 -o tap0 -d 10.0.0.0/8 -j LOG --limit rate 10/minute "Dropping camera stream"
iptables -A FORWARD -i eth0 -o tap0 -d 10.0.0.0/8 -j DROP


Je rappelle que ce n'est pas un firewall, donc pas la peine de discuter sur le "policy accept"...
--limit rate 10/minute (pendant les tests, après 1/hour suffit)
-d 10.0.0.0/8 à adapter bien sur
ou source aussi
-s 10.0.0.0/8
ou les deux conditions !

[faycalus]

après plusieurs testes avec les chaînes INPUT et FORWARD j'ai l'impression que les règles n'ont plus d'effet après établissement du tunnel, le temps que j'ai est insuffisant pour l'instant pour que je creuse plus loin mais après plusieurs recherches sur des dizaines de liens je pense que ebtables est plus approprier dans le cas des bridges http://ebtables.sourceforge.net/misc/ebtables-man.html j'ai pas trouver grand chose en Français j'aimerais bien des liens si vous en avez mais pour l'instant je me contente de ça.

Le filtrage dans un bridge est plutôt réalisé par ebtables au lieu d'iptables. cf http://ebtables.sourceforge.net/

il faut dire que notre ami jdh nous a bien prévenus