Liaison ipcop à ipcop en ajoutant des routes?

[Franck78]

je ne vous cache pas que je croyait qu'ipcop en été capable.

C'est parceque tu n'as (avais) pas encore saisi que ta demande n'a rien de courant ! Un VPN, ok, ca relie deux (ou plus) sites éloignés. C'est toujours le lien unique entre les sites.
Or tu veux l'utiliser en alternative.
Tu ne couperas pas à une révision approfondie de switch+spanning tree+boucle+bridge soft !

[faycalus]

Salut a tous, me revoilà après quelques jours de repos.

Sur vos conseilles Franck78 j'ai installer ma debian (malgré que je ne soit pas un expert pour la manipuler) et j'ai essayer de suivre le tuto d'Oleksiy Kovyrin sur http://kovyrin.net/2006/04/05/connectin ... -bridging/ mais il y'a plusieurs points qui ne sont pas très claires pour moi
Pour commencer

we need to create tunnel device file for our tunnel:

# cd /dev
# ./MAKEDEV tun
# mkdir misc
# ln -s /dev/net /dev/misc/net

Notice: Last command is needed to make vtun work, because authors build for debian is looking for tunnel device driver at /dev/misc/net/tun.

Cette première étape je ne la vois pas sur d'autres sites comme http://vtun.sourceforge.net ou http://switzernet.com/2/public/100804-vpn-equinix/ que j'ai lu pour essayer de mieux comprendre le mécanisme d’ailleurs sur ce dernier on commence autrement par

# aptitude update
# aptitude install uml-utilities
# aptitude install bridge-utils
# tunctl -u root -t tap0
# ifconfig tap0 0.0.0.0 promisc up
# aptitude install vtun
# modprobe tun

Pour revenir au premier tuto d'Oleksiy Kovyrin la suite c'est d'installer les packages nécessaires

# apt-get install bridge-utils ebtables iptables libssl0.9.6
...

libssl0.9.6 ne fonctionne pas pour moi

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
E: Impossible de trouver le paquet libssl0.9.6
E: Impossible de trouver de paquet correspondant à l'expression rationnelle « libssl0.9.6 »

maintenant la partie config

sur le coté serveur voici mon /etc/vtund.conf

options {
port 5000;
syslog daemon;
# Path to various programs
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/iptables;
ip /sbin/ip;
}

default {
compress no;
encrypt no;
speed 0;
}

bridge01 {
passwd aa;
type ether;
proto udp;
keepalive yes;
compress no;
encrypt no;

up {
ifconfig "%% up";
program "/usr/sbin/brctl addif br0 %%";
};

down {
# Connection is Down
ifconfig "%% down";
};
}

par contre je ne trouve pas le /etc/vtund-start.conf alors es que je doit le créer et mettre la ligne

--server-- 5000

comme mentionné sur le tuto ou aller voir /etc/default/vtun et mettre

RUN_SERVER=yes
SERVER_ARGS="-P 5000"

comme mentionné sur d'autres sites et les exemples /usr/share/doc/vtun/examples

sur le coté client voici le /etc/vtund.conf

options {
# Path to various programs
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/iptables;
}

bridge01 {
pass aa; # Password
type ether; # Ethernet tunnel
up {
# Connection is Up
ifconfig "%% up";
program "brctl addif br0 %%"
};
down {
# Connection is Down
ifconfig "%% down";
};
}

et la aussi meme chose pour le /etc/vtund-start.conf dois-je le créer et mettre la

rembridge 10.173.73.2 -p

sachant que 10.173.73.2 est l'adresse eth1 du coté serveur ou alors simplement mettre sur le /etc/default/vtun

CLIENT0_NAME=bridge01
# CLIENT0_HOST=10.173.73.2

après tous ça on arrive au interfaces /etc/network/interfaces

celui coté serveur

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.10.240
netmask 255.255.255.0
bridge_ports eth0

# The secondary network interface
auto eth1
allow-hotplug eth1
iface eth1 inet static
address 10.173.73.2
netmask 255.255.255.252
gateway 10.173.73.1

et celui coté client

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.10.241
netmask 255.255.255.0
bridge_ports eth0

# The secondary network interface
auto eth1
allow-hotplug eth1
iface eth1 inet static
address 10.173.73.6
netmask 255.255.255.252
gateway 10.173.73.5

vous remarquerez que eth0 est en manuel

iface eth0 inet manual

es exacte?

[jdh]

Le site indiqué est une page de 2006 !
Il est PLUS que probable que certains éléments nécessaires avec Debian en 2006 ne sont plus nécessaires !
Ce doit être le cas de ce "ln" qui semble un 'bricolage'.
De même le paquet libssl0.9.6 doit être un pré-requis du moment : il faut sans doute utiliser libssl0.9.8 pour Lenny ou Squeeze

Je regarderais (pour Squeeze) http://wiki.debian.org/BridgeNetworkConnections
Un lien (pour Lenny) http://www.shakthimaan.com/installs/deb ... setup.html

[faycalus]

voila ce que j'ai eu comme résultats coté serveur

root@SC:~# tail -f /var/log/daemon.log
Mar 31 19:34:15 SC dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Mar 31 19:34:16 SC dhclient: DHCPOFFER from 192.168.10.1
Mar 31 19:34:16 SC dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Mar 31 19:34:16 SC dhclient: DHCPACK from 192.168.10.1
Mar 31 19:34:16 SC dhclient: bound to 192.168.10.36 -- renewal in 1613 seconds.
Mar 31 19:36:06 SC vtund[1174]: Terminated
Mar 31 19:36:07 SC vtund[1543]: VTUN server ver 3.X 09/27/2010 (stand)
Mar 31 19:38:09 SC vtund[1553]: Use SSL-aware challenge/response
Mar 31 19:38:09 SC vtund[1553]: Session bridge01[10.173.73.30:37160] opened
Mar 31 19:38:10 SC vtund[1553]: UDP connection initialized
^C
root@SC:~# traceroute 192.168.10.243
traceroute to 192.168.10.243 (192.168.10.243), 30 hops max, 60 byte packets
1 192.168.10.240 (192.168.10.240) 3002.661 ms !H 3002.662 ms !H 3002.660 ms !H
root@SC:~# ping 192.168.10.243
PING 192.168.10.243 (192.168.10.243) 56(84) bytes of data.
From 192.168.10.240 icmp_seq=9 Destination Host Unreachable
From 192.168.10.240 icmp_seq=10 Destination Host Unreachable
From 192.168.10.240 icmp_seq=11 Destination Host Unreachable
From 192.168.10.240 icmp_seq=12 Destination Host Unreachable
From 192.168.10.240 icmp_seq=13 Destination Host Unreachable
From 192.168.10.240 icmp_seq=14 Destination Host Unreachable
64 bytes from 192.168.10.243: icmp_req=5 ttl=64 time=16113 ms
64 bytes from 192.168.10.243: icmp_req=6 ttl=64 time=15462 ms
64 bytes from 192.168.10.243: icmp_req=8 ttl=64 time=15078 ms
64 bytes from 192.168.10.243: icmp_req=16 ttl=64 time=17736 ms
64 bytes from 192.168.10.243: icmp_req=17 ttl=64 time=16780 ms
64 bytes from 192.168.10.243: icmp_req=18 ttl=64 time=16297 ms
64 bytes from 192.168.10.243: icmp_req=20 ttl=64 time=15363 ms
64 bytes from 192.168.10.243: icmp_req=23 ttl=64 time=13884 ms
64 bytes from 192.168.10.243: icmp_req=24 ttl=64 time=13776 ms
^C
--- 192.168.10.243 ping statistics ---
40 packets transmitted, 9 received, +6 errors, 77% packet loss, time 39244ms
rtt min/avg/max/mdev = 13776.703/15610.560/17736.944/1216.748 ms, pipe 18
root@SC:~# ping 192.168.10.243
PING 192.168.10.243 (192.168.10.243) 56(84) bytes of data.
From 192.168.10.240 icmp_seq=9 Destination Host Unreachable
From 192.168.10.240 icmp_seq=10 Destination Host Unreachable
From 192.168.10.240 icmp_seq=11 Destination Host Unreachable
From 192.168.10.240 icmp_seq=12 Destination Host Unreachable
From 192.168.10.240 icmp_seq=13 Destination Host Unreachable
From 192.168.10.240 icmp_seq=14 Destination Host Unreachable
From 192.168.10.240 icmp_seq=15 Destination Host Unreachable
From 192.168.10.240 icmp_seq=16 Destination Host Unreachable
From 192.168.10.240 icmp_seq=17 Destination Host Unreachable
64 bytes from 192.168.10.243: icmp_req=2 ttl=64 time=17323 ms
From 192.168.10.240 icmp_seq=18 Destination Host Unreachable
From 192.168.10.240 icmp_seq=19 Destination Host Unreachable
From 192.168.10.240 icmp_seq=20 Destination Host Unreachable
From 192.168.10.240 icmp_seq=21 Destination Host Unreachable
From 192.168.10.240 icmp_seq=22 Destination Host Unreachable
From 192.168.10.240 icmp_seq=23 Destination Host Unreachable
From 192.168.10.240 icmp_seq=24 Destination Host Unreachable
From 192.168.10.240 icmp_seq=25 Destination Host Unreachable
From 192.168.10.240 icmp_seq=26 Destination Host Unreachable
64 bytes from 192.168.10.243: icmp_req=27 ttl=64 time=18301 ms
64 bytes from 192.168.10.243: icmp_req=28 ttl=64 time=17544 ms
64 bytes from 192.168.10.243: icmp_req=34 ttl=64 time=17138 ms
64 bytes from 192.168.10.243: icmp_req=35 ttl=64 time=17484 ms
64 bytes from 192.168.10.243: icmp_req=36 ttl=64 time=17040 ms
64 bytes from 192.168.10.243: icmp_req=50 ttl=64 time=18790 ms
64 bytes from 192.168.10.243: icmp_req=51 ttl=64 time=17842 ms
64 bytes from 192.168.10.243: icmp_req=52 ttl=64 time=17427 ms
^C
--- 192.168.10.243 ping statistics ---
72 packets transmitted, 9 received, +18 errors, 87% packet loss, time 71472ms
rtt min/avg/max/mdev = 17040.473/17654.938/18790.169/536.429 ms, pipe 19
root@SC:~# ifconfig
br0 Link encap:Ethernet HWaddr 10:78:d2:e6:70:b8
inet adr:192.168.10.240 Bcast:192.168.10.255 Masque:255.255.255.0
adr inet6: fe80::1278:d2ff:fee6:70b8/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6854 errors:0 dropped:0 overruns:0 frame:0
TX packets:472 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:628634 (613.9 KiB) TX bytes:59078 (57.6 KiB)

eth0 Link encap:Ethernet HWaddr 10:78:d2:e6:70:b8
adr inet6: fe80::1278:d2ff:fee6:70b8/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:68002 errors:0 dropped:0 overruns:0 frame:0
TX packets:3547 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:63821812 (60.8 MiB) TX bytes:547952 (535.1 KiB)
Interruption:25 Adresse de base:0x6000

eth1 Link encap:Ethernet HWaddr 00:e0:4c:12:ed:64
inet adr:10.173.73.2 Bcast:10.173.73.3 Masque:255.255.255.252
adr inet6: fe80::2e0:4cff:fe12:ed64/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2918 errors:0 dropped:0 overruns:0 frame:0
TX packets:4006 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:514852 (502.7 KiB) TX bytes:1120456 (1.0 MiB)
Interruption:21 Adresse de base:0xe800

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:27 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:2952 (2.8 KiB) TX bytes:2952 (2.8 KiB)

tap0 Link encap:Ethernet HWaddr 76:21:09:22:63:69
adr inet6: fe80::7421:9ff:fe22:6369/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2758 errors:0 dropped:0 overruns:0 frame:0
TX packets:3803 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:378900 (370.0 KiB) TX bytes:937475 (915.5 KiB)
root@SC:~# traceroute 192.168.10.243
traceroute to 192.168.10.243 (192.168.10.243), 30 hops max, 60 byte packets
1 192.168.10.240 (192.168.10.240) 3002.609 ms !H 3002.610 ms !H 3002.609 ms !H

un trace route de l’automate 192.168.10.203 derrière le debian client 192.168.10.243

root@SC:~# traceroute 192.168.10.203
traceroute to 192.168.10.203 (192.168.10.203), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

sur le serveur client CR03 192.168.10.243

root@CR03bis:~# tail -f /var/log/daemon.log
Mar 29 19:03:05 CR03bis vtund[1357]: Exit
Mar 31 18:42:09 CR03bis vtund[1840]: VTun client ver 3.X 09/27/2010 started
Mar 31 18:42:09 CR03bis vtund[1840]: Connecting to 10.173.73.2
Mar 31 18:42:12 CR03bis vtund[1840]: Use SSL-aware challenge/response
Mar 31 18:42:13 CR03bis vtund[1840]: Remote Server sends <UeK>#012.
Mar 31 18:42:13 CR03bis vtund[1840]: Session bridge01[10.173.73.2] opened
Mar 31 18:42:13 CR03bis vtund[1840]: UDP connection initialized

[jdh]

Si on suit le premier lien, le schéma est

lan gauche -> (eth0) BRIDGE G (eth1) <----> (eth1) BRIDGE D (eth0) <- lan droit

Il faut tester la situation "en laboratoire" : avec juste un câble croisé entre les 2 machines (BRIDGE G) et (BRIDGE D).
(Donc avec une config statique d'adresses ip des interfaces eth1.)

Puis on teste en plaçant 2 machines de chaque côté.
(De facto, il faut 4 machines : les 2 bridges et 2 pc de tests).

Quand les tests sont concluants,
on modifie la config des 2 interfaces eth1 pour qu'elles soit adaptées à la liaison VSAT, et on reteste "en situation".


=> Cela manque de description :
- quelle Debian est installé ?
- quel adressage ? quelle config avec VSAT ?
=> Cela semble imparfaitement préparé :
- discordance config "serveur" / "client" -> bridgeG / bridgeD + TOUT doit être coordonné !


J'insiste sur la nécessité de tester en laboratoire AVANT de faire autre chose ...
Plus vous aurez pris de temps à "représenter les choses", à tester en labo, plus vous gagnez de temps !

Le lien 3 ( http://switzernet.com/2/public/100804-vpn-equinix/ ) me parait plus "pointu" et plus à jour ...
Les config "type ether; proto udp;" sont primordiales : ne pas transformer en "proto tcp" qui diminuerait sensiblement les performances !

[faycalus]

Merci a toi aussi jdh pour ton intéret et ton aide.

Le teste en labo c'est exactement ce que j'ai réaliser hier chez moi ( ça ressemble beaucoup a un labo ) le teste est un succès et du premier coup, ça marche nickel. et le plus intéressant ça ma aider a comprendre d'ou venais le problème.

au fait, en réalisant le teste, par accident, je remarque que le vtun est un sacré tunel a quatre vois car les deux pc de tests dans les deux bouts du tunel n'étais pas dans le même sous réseaux que les deux eth0 ou plutot br0 des deux debian bridges ( configurés en 192.168.10.240/24 et 192.168.10.241/24 ) les deux pc de teste en réalité sont un pc win xp en 192.168.1.233/24 et une dreambox en 192.168.1.23/24 gw 192.168.1.1 qui est le modem routeur branché de l'autre coté avec le pc win xp sur un switch, j'ai activer le tunnel vtun après avoir relier les deux debian par les eth1 avec un câble croisé la je m'apprête a changer les adresse du pc win xp et la dreambox pour les mettre sur le 192.168.10.0/24 pour effectuer un ping teste croyant qu'il fallait qu'ils soient sur le même sous réseaux que les interfaces br0 pour que cela fonctionne et la ….. je vois redémarrer ma télé c'est ma dreambox qui reprend du service ce qui implique qu’elle arrive a rejoindre le modem routeur qui est a l'autre bout je fait des teste de ping histoire d'être sure que je ne rêve pas ( il se faisait tard quand même ) mais tous fonctionne correctement tous le monde arrive a joindre tous le monde. la je change les adresses comme prévu histoire de confirmer et être sûre donc je met tous le monde sur 192.168.10.0/24 la aussi tous fonctionne.

bref, tous cela pour dire que ce petit accident ma aider a comprendre qu'elle étais le problème. et bien dans mon cas pratique la fibre transporté aussi un flux de cameras de surveillance ip branchées sur les mêmes switches mais configurées avec le dvr sur le sous réseau 192.168.0.0/24 dans presque toutes les chambres le problème c'est qu'au moment ou le tunnel est établi ce flux ip vidéo l'emprunte pour rejoindre le dvr et donc sature la liaison vsat qui est de juste 128/128 Kbps en dédier pour les 14 sites ( juste de quoi faire fonctionner les commandes transmises au automates et recevoir les lectures ).

Voila mon problème maintenant est de pouvoir isoler les sous réseaux qui cohabitent sur les switches HARTING McON 1000 ( 192.168.10.0/24 et 192.168.0.0/24 ) ou interdire au 192.168.0.0/24 de passer par le tunnel sur les debian ou que chaque bridge debian ne communique qu'avec l'automate qui lui est destiné et qui est sur le même switch

en ce qui concerne les descriptions:

- le Debian je vient juste de télécharger la dernière version dispo 6.0.4 squeeze avec une installation minimale

- l'adressage et la config je vous envoi ça demain

[jdh]

Un bridge fonctionne au niveau ethernet !
Donc ce qui arrive d'un côté passe de l'autre, quelque soit l'adressage !
Mais rien n'interdit d'ajouter des règles iptables : interdire tout puis autoriser que les réseaux ip voulus (FORWARD)

Les fichiers vtun.conf me semblaient "désaccordés" ?

[Franck78]

iptables, ebtables, ok pour faire la police.
Mais faut pas oublier que ca ne marcheras pas.

La CAM a pris le chemin de campagne à 128 alors que l'autoroute à fibre était dispo.
Le flic a jeté le paquet, la cam ne le saura jamais.

C'est les réglages spaning tree drans les 'br0' qu'il faut faire avant....

[faycalus]

Les fichiers vtun.conf me semblaient "désaccordés" ?

effectivement erreur de copier coller ci-dessous les bons
coté serveur:

options {
port 5000; # Listen on this port.

# Syslog facility
syslog daemon;

# Path to various programs
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/iptables;
ip /sbin/ip;
}

default {
compress yes;
encrypt no;
speed 0;
}

bridge01 {
passwd aa;
type ether;
proto udp;
keepalive yes;
compress yes;
encrypt no;

up {
# Connection is Up
ifconfig "%% up";
program "brctl addif br0 %%";
};

down {
# Connection is Down
ifconfig "%% down";
};
}

coté client:

options {
# Path to various programs
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/iptables;
#ip /sbin/ip;
}

bridge01 {
passwd aa;
type ether;
proto udp;
keepalive yes;
compress yes;
encrypt no;

up {
ifconfig "%% up";
program "brctl addif br0 %%"
};

down {
# Connection is Down
ifconfig "%% down";
};
}

j'en profite d’ailleurs pour vous demander si vous avez une idée de la façon dont on peut rajouter plusieurs clients ( clients debian vtun ) pour créer plusieurs tunnels avec le même serveur? et s'il y'avais une limite? les machines sont des intel duel core a 3.00 Ghz, 2 Go de RAM et 250 Go de disque.

Un bridge fonctionne au niveau ethernet !
Donc ce qui arrive d'un côté passe de l'autre, quelque soit l'adressage !
Mais rien n'interdit d'ajouter des règles iptables : interdire tout puis autoriser que les réseaux ip voulus (FORWARD)

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

iptables, ebtables, ok pour faire la police.
Mais faut pas oublier que ca ne marcheras pas.

La CAM a pris le chemin de campagne à 128 alors que l'autoroute à fibre était dispo.
Le flic a jeté le paquet, la cam ne le saura jamais.

C'est les réglages spaning tree drans les 'br0' qu'il faut faire avant....

il vas falloir m'aider u peut plus les gars sur les iptables et spanning tree.

[jdh]

Les réponses me semblent se trouver sur le lien 2 ( http://vtun.sourceforge.net/ )
- il est possible de créer plusieurs tunnels (cf FAQ et cf Setup),
- il est possible de créer un tunnel ip plutôt que ethernet (cf Setup) : à tester en labo au préalable !

Les options de compression et d'encryptage sont à regarder : encryptage puisque passage au travers d'Internet, compression puisque lien "lent" et machines puissantes.

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

Le spanning tree est une mesure qui permet d'éviter (de s'adapter ?) les "chemins" multiples cf bridge_stp.