Liaison ipcop à ipcop en ajoutant des routes?

[jdh]

Et je pourrais aussi dire qu'INPUT et OUTPUT ne sont peut-être pas les bonnes chaines ...
Il me semble clair que le trafic à contrôler passe par la chaine FORWARD puisqu'il n'est ni destiné à la machine (INPUT) ni ne sort de la machine même (OUTPUT).

[faycalus]

après quelques testes je ne comprend toujours pas le mécanisme a 100%

je prend l'exemple de l'automate 01 avec ip:192.168.10.201 et le serveur 01 br0: 192.168.10.241

- j’ai opter pour la stratégie: ebtables -P FORWARD DROP
puis: ebtables -A FORWARD -p IPv4 --ip-src 192.168.10.201 -j ACCEPT (pour autoriser seulement l'automate à emprunter le tunnel)
mais ça ne fonctionne pas rien ne passe sauf que depuis le serveur debian 01 lui même (br0: 192.168.10.241 eth1: 10.173.73.6/30 gw 10.173.73.5) ça ping et le serveur de la salle des commandes (br0192.168.10.240 eth1: 10.173.73.2/30 gw 10.173.73.1) avec lequel il établis le tunnel mais aussi le serveur xp 192.168.10.100 avec le soft de gestion qui est juste derrière sur le un même switch

- deuxième stratégie: ebtables -P FORWARD ACCEPT
Puis je commence a virer tout le reste un par un
Déjà les cameras ip: ebtables -A FORWARD -p IPv4 --ip-src 192.168.0.0/24 -j DROP (je ne peut pas confirmer que ça marche)
Puis: ebtables -A FORWARD -p IPv4 --ip-src 192.168.10.202 -j DROP (l'automate 02 qui peut remonter par la fibre vers le switch 01 et emprunter le tunnel établie pour le teste)
Pour les autres j'ai débranché la fibre.
Et ça a l'aire de fonctionner

Le problème c'est que je ne maîtrise pas tous ce que pourrais être branché sur les switch et la première méthode semble la plus fiable pour restreindre chaque tunnel à un seul automate et rien de plus

[Franck78]

après quelques testes je ne comprend toujours pas le mécanisme a 100%

normal, c'est loin d'être évident.

potasse tranquillement ce genre de doc

http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html

puis applique

http://ebtables.sourceforge.net/documentation/docs.html

- j’ai opter pour la stratégie: ebtables -P FORWARD DROP

je serais plutôt partisan de ne bloquer que les caméras. Tout le reste qui informe sur l'état du réseau devrait passer, surtout le spanning tree que tu persistes à ignorer !

a suivre simplement :
http://www.linuxjournal.com/article/8172

[faycalus]

merci bien pour les liens Franck78 c'est excellent, mais malheureusement je ne peut pas me permettre le luxe de lire TRANQUILLEMENT car trop pris par le temps en tous cas en ce moment et c'est bien dommage. j'aurais bien aimer apprendre plus maintenant car c'est un excellent cas pratique.

et pas du tous je n'ignore pas le spanning tree je le réserve plutôt pour la fin je procède par étapes quoi, d'abord mettre en place le tunnel puis le filtrage et enfin le spanning tree (pour ne pas m’emmêler les pinceaux a essayer d'en manipuler plusieurs a la fois que je ne maîtrise pas)

je vous donne des nouvelles ce soire et on en reparleras sûrement du spanning tree

[faycalus]

j'ai finalement opter pour la deuxième stratégie: ebtables -P FORWARD ACCEPT et ça fonctionne assez bien pour les automates et la priorité apparemment est pour la vsat, c'est ce que je croyais en tous cas parce qu'au moment ou je met en route le tunnel d’après le ping sur le pc xp ça passe sur ce dernier et l'automate 02 ne répond plus avec ce premier tunnel donc les regles fonctionnent (je rappel que je travaille sur le segment salle contrôle -- chambre 01 -- chambre 02 uniquement).
et soudain les cameras ne fonctionnes plus comme si elles préfèrent impérativement passer par le tunnel, au fait c'est comme si les liaisons fibre sont bypassées. je crois que la en passe a la troisiemme etape le spanning tree mais il va falloir la aussi m'orienté un petit peut

[Franck78]

commence déja par le mettre en route dans la config du bridge virtuel:

brctl stp <bridge> <state>

et aussi dans les "mcomm"