OpenVPN et samba sur le même serveur => transferts lents

Bonjour à tous,

Je m’occupe de la configuration du réseau de mon entreprise et je suis confronté à un problème que je n’arrive pas à résoudre malgré la lecture de nombreux tutoriaux.

Voici le problème :
Nous avons un petit réseau local / partage de connexion Internet gérés par une Livebox (routeur/DHCP, IP locale 10.10.10.1).
Afin de partager nos documents, j’ai mis en place un serveur samba sur un PC, sous Debian 4.0 (Linux 2.6.17-2-686). Jusqu’ici, pas de problème.
Après, certains employés ayant besoin d’accéder à leur documents depuis l’extérieur, j’ai mis en place un VPN.
Après pas mal d’arrachage de cheveux, j’ai réussi à le faire fonctionner.

Mais depuis que le VPN est en place, les transfert en réseau local sont lents (300 à 500 ko/s) au lieu des 7-8 Mo / s lorsque le VPN est coupé. Cela pose problème car certains utilisateurs comme les graphistes manipulent des gros fichiers (jusqu’à quelques Go).

Voici un récap du réseau :

Voici la configuration de openVPN :

[code]local 10.10.10.100
mode server
tls-server
port 1194
proto udp
dev tap0

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
dh /etc/openvpn/keys/dh1024.pem

ifconfig-pool-persist ipp.txt
server-bridge 10.10.10.100 255.255.255.0 10.10.10.101 10.10.10.150
[/code]
Script de lancement du pont

[code]#!/bin/bash

Create global variables

Define Bridge Interface

br=“br0”

Define list of TAP interfaces to be bridged,

for example tap=“tap0 tap1 tap2”.

tap=“tap0”

Define physical ethernet interface to be bridged

with TAP interface(s) above.

eth="eth0"
eth_ip="10.10.10.100"
eth_netmask="255.255.255.0"
eth_broadcast="10.10.10.255"
gw="10.10.10.1"
start_bridge () {
#################################

Set up Ethernet bridge on Linux

Requires: bridge-utils

#################################
for t in $tap; do
openvpn --mktun --dev $t
done
for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
brctl addif $br $t
done
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast up
route add default gw $gw $br
}
stop_bridge () {
####################################

Tear Down Ethernet bridge on Linux

####################################
ifconfig $br down
brctl delbr $br
for t in $tap; do
openvpn --rmtun --dev $t
done
ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast up
route add default gw $gw $eth
}
case “$1” in
start)
echo -n "Starting Bridge"
start_bridge
;;
stop)
echo -n "Stopping Bridge"
stop_bridge
;;
restart)
stop_bridge
sleep 2
start_bridge
;;
*)
echo “Usage: $0 {start|stop|restart}” >&2
exit 1
;;
esac
[/code]

Merci d’avance de votre aide !

J’ai avancé sur mon problème. En fait je pense que c’est une histoire de routage. Voilà ma table de route :

Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 10.10.10.0 * 255.255.255.0 U 0 0 0 br0 default 10.10.10.1 0.0.0.0 UG 0 0 0 br0
Je me dit qu’il faudrait que pour les vraies IP locales l’interface soit eth0 au lieu de br0. Donc séparer les IP en 10.10.10.* en 2 plages.
Est-il possible de faire quelque chose comme 10.10.10.1->127 : eth0 et 10.10.10.128->254 br0 ?

Merci.

une fois intègrée à ton bridge, eth0 n’existe plus vraiment (même si tu peux éventuellement t’amuser à faire un routage fin, avec le match iptables physdev et en marquant les paquets suivant leurs provenances), donc tu ne peux pas vraiment distinguer en terme de routes les paquets qui vont sur le lan de ceux qui passent sur le vpn, sauf à faire des acrobaties avec iptables.
Ton idée de séparer le réseau des clients vpn des clients lan n’est pas bête, mais tu ferais mieux de fonctionner alors en mode routé, et d’abandonner le mode bridge.

Cette discussion m’interesse donc je vais tenté de dire deux trois conneries un peu :smt001

la seule fois ou je me suis fais un VPN c’était en utilisant le mode routé, le problème c’est évidemment que pas moyen de faire partager le reste du réseau (coté serveur) avec les clients extérieurs. Je pensais jusqu’alors que ce n’était pas possible à moins d’utiliser le mode bridge, mais en fait ça à l’air possible non ?

On a donc sur le serveur une eth0 et une tun0 virtuelle pour openVPN avec par exemple ceci :
eth0 : 10.10.10.0/24
tun0 : 192.168.1.0/24

Le client qui se connecte en VPN sur le serveur aura donc une IP en 192.168.1.0/24 mais ne pourra pas voir les stations du 10.10.10.0/24.

Ce problème semble pouvoir se régler assez facilement en faisant ceci :

  • Autoriser l’ip forwarding avec une certaine commande

Voir peut être aussi bidouiller de la chaine forward dans iptables (?..)

  • Rajouter une route sur les clients 10.10.10.0/24 de ta boite

Comme ça ils sauront que pour discuter sur le VPN faut passer par le serveur et pas par leur GW par défaut

source --> http://www.coagul.org/article.php3?id_article=422

Le mode routé a juste un ou deux défauts: le processeur travaille plus au routage, et l’absence de retransmission des paquets de la couche réseau ne parmet pas au machines windows de se “voir” naturellement dans le voisinage et de se désigner par leur nom sans configurer ça dans le dns (même si on peut accèder à leurs partages en les attaquant par l’ip, et si on peut “proxyfier” les noms en obligeant tous les clients à utiliser un même serveur wins).

Merci pour vos réponses. :slightly_smiling:

Le but de ce VPN est principalement du partage de fichier avec des clients sous Windows. Après avoir lu les différences entre le mode bridge et le mode routé, j’avais cru comprendre que le mode routé n’était pas bien adapté à du partage de fichier Windows, parce que ce dernier utilise des broadcasts qui ne passent pas en mode routé.

Mais d’après ce que mattotop dit, ça n’est pas si problématique que ça et il a y des solutions pour que ça ne fasse pas trop de différence pour les clients. Pour la partie ‘“proxyfier” les noms en obligeant tous les clients à utiliser un même serveur wins’ ça reste encore un peu mystérieux pour moi, mais je vais me renseigner.

Bon ben me reste plus qu’à tout reconfigurer en mode routé :mrgreen:

merci encore.