[Résolu] OpenVPN et bridge

Support Debian
#21

D’accord, ça permet de plugger une interface TAP au switch, mais pas une interface TAP “appartenant” à un autre programme comme openvpn. Ça ne fait pas avancer le schmilblick pour connecter openvpn à un switch virtuel.

Si tu penses carrément à remplacer openvpn par VDE, il faut prendre en compte la compatibilité avec les plates-formes clientes. Core a parlé de voisinage réseau et de jeux en LAN, je soupçonne qu’il y a du Windows là-dessous (non, ce n’est pas sale).

Euh, c’est que je n’ai pas de machine en lenny ni en sid. Je sais, wget et dpkg-deb -x sont mes amis, mais j’ai la flemme.

Il me semble avoir vu ça dans la page de manuel de vde_plug. L’inconvénient qu’on reproche souvent aux VPN basés sur SSH, c’est que ça fait du TCP encapsulé dans du TCP, et qu’en cas de pertes de paquets ça met un bazar monstre, chacune des deux couches TCP gérant ses propres temporisations et retransmissions sans savoir ce que fait l’autre.

#22

Re,

Voilà j’ai tout installé comme vous m’aviez dit et ça marche ! Super, j’ai plus qu’à sécuriser un peu tout ça…
Merci pour votre aide, super forum :wink:

Petite question, que pensez vous de la solution ebox pour gérer tout ça ?

#23

Si j’ai bien compris je n’ai même plus besoin du noyau avec le bridge… je peux remettre le dernier compilé sans le bridge ?

#24

Ben je ne connais pas le noyau standard dedibox, mais si l’option “802.1d Ethernet Bridging” est activée dedans (mais d’aprés ce que tu dis, il semble que non), pas de raison que ça gène.
Sinon, je ne connais pas la dédibox, mais qu’est ce qui empêche de compiler un noyau à partir des sources debian standard en prenant comme base la config standard dedibox ?
Il y a des patchs ?
C’est virtualisé ? Quel type de virtualisation ?

#25

Core :
Tu as fait comment, au juste ? Parce qu’on en a dit des choses !

mattotop :
Dedibox n’est pas du virtualisé, c’est de l’architecture i386 un peu spécifique (VIA C7 je crois), donc il y a des patches. Mais il me semble qu’on peut quand même utiliser les noyaux standard Debian ou vanilla.

#26

Re,

Alors j’ai testé ebox et j’ai voulu le désinstaller (vraiment pas top), mon système bootait même plus… Pas grave, je réinstalle tout avec le dernier noyau, je repose ubuntu avec le dernier noyau dedibox et j’installe openVPN via Webmin.
A partir de là j’ai suivi le très bon tuto de mattotop en changeant juste une ligne dans le fichier interfaces comme vous me l’aviez dit:

auto lo br0 iface lo inet loopback iface br0 inet static address 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255 bridge-ports none post-up /etc/openvpn/scripts/ovup && /etc/init.d/openvpn start pre-down /etc/init.d/openvpn stop post-down /etc/openvpn/scripts/ovdown

Tout le reste est resté tel quel et ça marche. Bon pour l’instant j’ai testé qu’avec un seul PC mais ce soir je pousserai un peu plus les tests…
Sinon la dedibox c’est bien du via C7, à la base j’avais essayé de compiler un noyau de dédié OVH, mais ça demarrait même pas (désolé si hérésie). Ceci dit je m’y connais que très peu en linux mais j’apprends avec un grand interêt, c’était donc la première fois que je compilais un noyau… Je pense qu’on doit pouvoir compiler un noyau standard mais ce n’est pas encore de mon niveau surement, de plus je suis passé au dernier de dedibox donc je pense que c’est bon.
Je me connecte au vpn par windows XP ou Vista avec openVPN GUI qui marche très bien et je vais remettre en place Samba pour les partages et je dois trouver un bon tuto pour m’attaquer aux iptables.
Encore merci à vous 2 pour votre aide ! :wink:

#27

Pour info, voila le kernel que j’ai installé si ça peut aider:

[code]~# uname -r
2.6.24.2dedibox-r8-1-c7

~# lspci
00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11)
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01)
[/code]

Croyez-vous que je peux avoir un meilleur ping en mettant le kernel 1000Hz ? Suis à 19ms de chez moi, ce qui est deja bien.

#28

Je crois qu’il y a un soucis en fait, j’ai parlé trop vite, il n’y a pas d’interface tap0 sur le serveur. Pourtant, des clients je me connecte avec les ip du range défini dans openVPN… Mais je ne peux rien pinger de ce réseau à par moi-même. Ca viendrait du noyau donc ?

#29

A partir du moment où tu utilises un pont (br0, bridge_ports dans le fichier interfaces), tu as besoin d’un noyau avec l’option BRIDGE activée. Je suis très étonné que ça fonctionne avec le noyau Dedibox r8-1 car dans le fichier config-dedibox-r8.txt, l’option BRIDGE est désactivée. Tu es sûr que le pont fonctionne (brctl show ; ifconfig -a) ? L’absence de pont n’empêche peut-être pas openvpn de fonctionner, en revanche deux clients ne pourront pas communiquer sans le pont.

D’après le fichier ChangeLog qui se trouve dans le répertoire ftp://ftp.dedibox.fr/pub/dedibox/kernel/r8/C7-X86-32bits/ il n’y a pas eu de modification des sources officielles contrairement à ce que j’avais écrit. C’est peut-être pour cela que Dedibox ne fournit plus les sources, ce n’est plus nécessaire. Il suffirait donc de récupérer le fichier config dans le même répertoire et les sources de kernel.org, activer l’option BRIDGE et compiler. Par contre il ne faut pas utiliser le noyau Dedibox r8 (2.6.24) qui contient la faille vmsplice, mais le r8-1 (2.6.24.2) ou ultérieur.

Edit : comment ça pas d’interface tap ? Qu’affiche ifconfig -a ou ip addr ?

#30

Tu as totalement raison pascal, le pont ne se fait pas… :confused:

[code]~# brctl show
bridge name bridge id STP enabled interfaces

~# ifconfig -a
eth0 Lien encap:Ethernet HWaddr 00:40:63:E8:60:6C
inet adr:88...* Bcast:88...* Masque:255.255.255.0
adr inet6: 2a01:e0c:1:142:240::fee8:/64 Scope:Global
adr inet6: fe70::240:*:fee8:606c/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:364530 erreurs:0 :0 overruns:0 frame:0
TX packets:224461 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:237239053 (226.2 MB) Octets transmis:39445073 (37.6 MB)
Interruption:18 Adresse de base:0xfc00

lo Lien 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
Packets reçus:363393 erreurs:0 :0 overruns:0 frame:0
TX packets:363393 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:39311567 (37.4 MB) Octets transmis:39311567 (37.4 MB)

sit0 Lien encap:IPv6-dans-IPv4
NOARP MTU:1480 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:0 (0.0 b) Octets transmis:0 (0.0 b)

tap0 Lien encap:Ethernet HWaddr 00:FF:F7:ED:37:75
BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:321 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
Octets reçus:44625 (43.5 KB) Octets transmis:0 (0.0 b)

~# ip addr
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:40:63:e8:60:6c brd ff:ff:ff:ff:ff:ff
inet 88.../24 brd 88... scope global eth0
inet6 2a01:e0c:1:147:240::fee8:606c/64 scope global dynamic
valid_lft 2591999sec preferred_lft 604799sec
inet6 fe80::240::fee8:606c/64 scope link
valid_lft forever preferred_lft forever
3: sit0: mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
4: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 100
link/ether 00:ff:f7:ed:37:75 brd ff:ff:ff:ff:ff:ff
[/code]

Merci pour l’info sur le kernel, ça m’aide bien ! Je vais recompiler tout ça de ce pas :slightly_smiling:

#31

Au moins l’interface tap0 est bien présente. Elle n’a pas d’adresse IP, ce qui est normal puisqu’elle est destinée à être liée au pont. Par contre elle n’est pas activée (pas de flag UP), je suppose que c’est openvpn ou un des scripts qu’il invoque qui est censé l’activer.

PS : il est vain de masquer des bouts de l’adresse IPv6 puisqu’elle est directement dérivée de l’adresse MAC qui elle, n’est pas masquée.

#32

J’ai utilisé le script de mattotop (viewtopic.php?t=4376) à un détail près:

#!/bin/sh openvpn --mktun --dev tap0 brctl addif br0 tap0 ; ifconfig eth0 promisc up ifconfig tap0 promisc up ifconfig br0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255

Ok lol je savais pas :stuck_out_tongue:

#33

Ta dernière modif m’a l’air cohérente. Tu as compilé ton nouveau noyau ?

#34

Je viens juste de finir de le compiler, je l’installe de ce pas et je fais de nouveaux tests pour vous dire ce que ça donne.

#35

Bon alors c’est beaucoup mieux avec le bon noyau:

[code]~# uname -r
2.6.24.2-customdedibox-r8-1-c7

~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.00ff74f1c633 no tap0

~# ip addr
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:40:63:e8:60:6c brd ff:ff:ff:ff:ff:ff
inet 88.../24 brd 88..*.255 scope global eth0
inet6 2a01:e0b:1:147:240:63ff:fee8:606c/64 scope global dynamic
valid_lft 2591999sec preferred_lft 604799sec
inet6 fe80::240:63ff:fee8:606c/64 scope link
valid_lft forever preferred_lft forever
3: sit0: mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
4: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
link/ether 00:ff:74:f1:c6:33 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br0
inet6 fe80::b879:dbff:febc:43a2/64 scope link
valid_lft forever preferred_lft forever
5: tap0: <BROADCAST,MULTICAST,PROMISC,UP,10000> mtu 1500 qdisc noqueue qlen 100
link/ether 00:ff:74:f1:c6:33 brd ff:ff:ff:ff:ff:ff
inet6 fe80::2ff:74ff:fef1:c633/64 scope link
valid_lft forever preferred_lft forever

~# ifconfig -a
br0 Lien encap:Ethernet HWaddr 00:FF:74:F1:C6:33
inet adr:192.168.1.1 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::b879:dbff:febc:43a2/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:0 (0.0 b) Octets transmis:468 (468.0 b)

eth0 Lien encap:Ethernet HWaddr 00:40:63:E8:60:6C
inet adr:88...* Bcast:88...255 Masque:255.255.255.0
adr inet6: 2a01:e0b:1:147:240:63ff:fee8:606c/64 Scope:Global
adr inet6: fe80::240:63ff:fee8:606c/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:11609 erreurs:0 :0 overruns:0 frame:0
TX packets:12248 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:3069836 (2.9 MB) Octets transmis:2228990 (2.1 MB)
Interruption:18 Adresse de base:0xfc00

lo Lien 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
Packets reçus:21312 erreurs:0 :0 overruns:0 frame:0
TX packets:21312 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:2265344 (2.1 MB) Octets transmis:2265344 (2.1 MB)

sit0 Lien encap:IPv6-dans-IPv4
NOARP MTU:1480 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:0 (0.0 b) Octets transmis:0 (0.0 b)

tap0 Lien encap:Ethernet HWaddr 00:FF:74:F1:C6:33
adr inet6: fe80::2ff:74ff:fef1:c633/64 Scope:Lien
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:5 errors:0 dropped:1 overruns:0 carrier:0
collisions:0 lg file transmission:100
Octets reçus:0 (0.0 b) Octets transmis:378 (378.0 b)
[/code]

Je n’arrive pas encore à me connecter, j’ai un “connection reset by peer (code:10054)” du client pour l’instant, je cherche un peu…

#36

Alors, j’avais bloqué la lecture à tout le répertoire contenant les keys, ce qui faisait coincer… Je peux maintenant me connecter à partir des clients mais toujours pas de ping entre eux ni avec l’ip locale du serveur. Pourtant le pont a l’air activé cette fois. Je continue les recherches…

#37

J’ai activé ces règles dans iptables:

iptables -I INPUT -p udp --dport 1194 -j ACCEPT iptables -I INPUT -i tap0 -j ACCEPT iptables -I FORWARD -i tap0 -j ACCEPT iptables -I FORWARD -o tap0 -j ACCEPT iptables -I OUTPUT -o tap0 -j ACCEPT iptables -I INPUT -i br0 -j ACCEPT iptables -I FORWARD -i br0 -j ACCEPT iptables -I OUTPUT -o br0 -j ACCEPT

Après ceci je peux, du serveur pinger tous les clients ou des clients pinger le serveur mais les clients ne ping pas entre eux… J’avoue que j’ai un peu de mal avec iptables, j’ai dû oublier un truc. Il n’y a pas de nat à config pour le bridge pourtant si je ne m’abuse.

#38

Mais si tu lève (temporairement) complètement ton parefeu, ça marche mieux ?

#39

Quand j’enlève mon pare feu ça marche plus du tout, je reviens au même point qu’avant d’avoir rajouté les 5 règles mises plus haut…
Je viens d’installer Samba et maintenant mes PC apparaissent tous dans le voisinage réseau windows, cool ! Mais ce qui est bizarre c’est que je ne peux toujours pas pinger les clients entre eux, alors que le serveur WINS de Samba les trouve…
Pour Samba, si j’écoute sur 192.168.1.1 ça passe pas, donc j’ai mis toutes les interfaces pour l’instant.

#40

[quote=“Core”]Quand j’enlève mon pare feu ça marche plus du tout, je reviens au même point qu’avant d’avoir rajouté les 5 règles mises plus haut… [/quote]Ça, c’est pas possible ! Tu dois oublier de remettre tes policies à ACCEPT ? Comment tu fais pour baisser ton pf ?