Server Debian + openvpn, probleme de routage?

Support Debian
#1

Bonjour,
afin que vous puissiez comprendre mon problème voici un récapitulatif de l’existant.
Vous trouverez sur l’image ci-dessous le réseau personnel que je me suis affairé à mettre en place afin d’expérimenter plusieurs solutions

img156.imageshack.us/i/schmareseaux.jpg/

Je dispose donc d’un serveur debian (2.6.26-2-686-bigmem)avec vmware server 2.0
Voici les paramètres de mes cartes réseaux:

img696.imageshack.us/i/ifconfig.jpg/

J’ai pour le moment 2 VM. Les VM sont bridgé sur ETH1 et communique bien avec les postes physique du réseaux 192.168.252.0/24 (ping/accés web/serveur de fichier/etc…)
Afin de tester la solution que propose openvpn j’ai donc installer le nécessaire à sa mise en place sur ma debian server. Openvpn me génère une interface TUN0 qui communique au travers du tunnel. J’ai crée un jeu de certificat que je dispose sur un poste client interne au réseau 192.168.252.0/24 (toujours en local).
Je lance l’utilitaire OPENVPN UI et mon VPN fonctionne bien en local. Les certificats sont donc OK
Je prend ensuite ce même poste que je place dans un réseau externe et je relance ma connexion VPN (en changeant mon fichier de conf client pour cette fois faire une connexion sur le domaine dyndns).
La connexion à réussi.

Mon problème maintenant est que au travers de se tunnel (interne et externe) je ne peux discuter avec aucun autres postes (sur le poste client dans /démarrer/exécuter --> \[ip_server_fichier] ou encore un simple ping ne passe sur aucune machines autres que la debian) mise à part mon serveur debian (test sur l’interface web de vmware etc… = ok).
Le réseau virtuel a par défaut une adresse en 10.8.0.0 et openvpn gère son propre DHCP sur ce réseau virtuel.

Voici ma table de routage sur mon serveur debian

img190.imageshack.us/i/routendf.jpg/

faut-il que j’effectue un bridge entre TUN0 et ETH1 ? cela ne pose pas des problèmes de sécurité? Faut-il que je fasse un route add -net 192.168.252.0 255.255.255.0 gw 10.8.0.1? oui mais sur quel interface? et comment le préciser dans mon “route add” ? faut-il que je change la plage ip de mon VPN pour qu’elle corresponde directement avec celle de mon réseau et effectuer un bridge entre les deux interfaces (TUN0 & ETH1)? Cela posera surement des problèmes de sécurité à nouveaux ? etc…?
Je suis un peu perdu et j’aimerai éviter de tout démolir a coup de “route del” ou autres du coup les quelques tests que j’ai effectué d’ajout se sont révélé non concluant
Maintenant il s’agit peut-être d’un autre problème que celui de la table de routage à dire vrai je suis un peu rester focalisé dessus sachant que je découvre ce genre de solution

Par avance merci

#2

Notes sur la forme :

  1. Les images jpg, c’est bien pour les dessins. Par contre pour le texte et les sorties de commandes en console, il est beaucoup plus pratique et économique de faire des copier-coller de texte.
  2. Utiliser route avec l’option -n pour éviter la résolution inverse des adresses qui rend l’affichage moins lisible.

Notes sur le fond :

  1. eth0 et eth1 ont des adresses dans le même sous-réseau IP alors qu’eth0 n’est pas connectée. Mauvaise idée. Si la machine choisit d’essayer d’atteindre le sous-réseau par eth0, ça ne va pas bien marcher.
  2. La table de routage contient plusieurs routes par défaut sur plusieurs interfaces différentes (eth0, eth1, vmnet8). Toutes ne sont manifestement pas correctes (celle sur eth0 qui n’est pas connectée et celle sur l’interface virtuelle vmnet8). Or la machine en choisit une seule, pas au hasard mais presque car elles sont de même priorité (metric), et si ce n’est pas la bonne, elle ne va pas réessayer les autres. A éviter donc. En règle générale, une machine a une seule route par défaut active.

Non, ce n’est pas nécessaire. De toute façon ce n’est pas possible, tun0 n’est pas une interface de type ethernet et n’est donc pas pontable. Cela aurait été possible avec un tunnel en mode TAP (émulation ethernet) au lieu de TUN (liaison routée point à point).

Pour que le client openvpn et le LAN puissent communiquer à travers le serveur openvpn, il faut plusieurs conditions :

  1. Le serveur doit être configuré en routeur IP (sysctl net.ipv4.ip_forward=1).
  2. Le client doit avoir une route vers les sous-réseau du LAN 192.168.252.0/24 via son interface tun openvpn. Cette route peut être “poussée” par le serveur, cf. l’option “push” d’openvpn.
  3. Les machines du LAN doivent avoir une route vers le sous-réseau openvpn 10.8.0.0/24 avec comme passerelle le serveur 192.168.252.253. Ou bien le routeur par défaut du LAN doit avoir une telle route, mais ça ne marche pas toujours, ça dépend des routeurs.
#3

Bonjour,

et merci pour la réponse.

Par rapport à mon eth0 elle est down maintenant donc plus de soucis
Au niveau de ma table de routage j’ai effectuer un route del sur les routes provenant de eth0.

C’est vrai que j’aurai du mettre mon server.conf afin de pas vous faire perdre de temps :confused:

port 443
proto tcp
dev tun
ca ca.crt
cert novavpn.crt
key novavpn.key # This file should be kept secret
dh dh1024.pem
tls-auth ta.key 0
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.252.0 255.255.255.0"
client-to-client
keepalive 10 120
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
verb 1

J’ai bien un push qui est en place et mon forwarding est bien effectué.

Mettant peut-être mal exprimé (car je suis dans le noir en ce moment :p) je vais reformulé le problème:

je me connecte a mon server Debian via un VPN. Je souhaiterais avoir accès a mon LAN en passant par le tunnel.
Voila le début de solution que j’ai trouvé et que j’essaie de comprendre / tester en ce moment
secure-computing.net/wiki/in … PN/Routing

(d’ou la presence de mon NOVASVR002 /etc/openvpn/ccd contenant un iroute 10.8.0.0 255.255.255.0).
Je vous tiens au courant de l’évolution de mon problème

#4

Dans ce cas il reste à vérifier si la route vers le sous-réseau du VPN est bien présente dans la table de routage des machines du LAN devant communiquer avec le VPN. Et éventuellement l’absence de filtrage par iptables ou autre qui bloquerait les paquets.

Cet URL avec des points de suspension au milieu est incorrect.