Bonjour à tous,
J’ai un problème avec ma VM DEBIAN (KVM) sur hôte Debian PROXMOX.
Lorsque j’installe OPENVPN sur ma VM, l’interface Tun ne monte pas dans mes cartes réseaux.
Auriez-vous une astuce ou une solution à mon problème?
Merci d’avance pour votre aide.
Titi_rugby
Que disent les logs, visiblement la connexion échoue.
Bonjour,
Les logs disent que l’interface Tun0 n’existe pas.
Effectivement elle n’apparait pas dans les interfaces.
Cdt
Je soupçonne que François demandait une copie des logs afin de faire son diagnostic, plutôt que ton interprétation de ceux-ci.
D’une manière plus générale, ça pourrait aider si tes descriptions étaient un peu plus concrètes et étoffées.
bonjour à tous,
J’avais 2 problèmes,
Le premier : j’avais le port 443 déjà en écoute par openSSH 
Le second : mon fichier de conf n’était pas bon. 
Tout est Ok maintenant.
Merci encore pour votre aide.
Titi_rugby
Salut tout le monde, me revoilà avec mes problèmes openvpn.
Lorsque je suis connecté, je ne vois pas les autres machines du réseau alors que j’ai fait un ip_forward.
orsque je fait un ipconfig du poste client, je n’ai pas de passerelle sur la carte TUN/TAP.
Help.
Mercid 'avance.
Titi_rugby
On ne peut rien faire si tu ne donnes pas un minimum de renseignements:
Fichiers de configuration serveur et client, existence ou non de parefeu, route -n sur le serveur et le client.
Effectivement, mais je donnerai ça ce soir car en faisant une modif à distance ce matin, j’ai tout cassé et je n’ai plus accès à rien!!!lol
A ce soir donc.
Titi_rugby
Qu’entends-tu exactement par “voir” ?
ipconfig est une commande Windows, le client est sous Windows ?
Le serveur peut “pousser” des routes sur le client avec l’option push.
Lorsque je suis connecté sur mon serveur VPN, je ne vois pas les machines de mon réseau qui sont après. Impossible de les pinguer et encore moins prendre la main dessus.*
Effectivement, j’accède à mon VPN depuis un poste XP (on m’oblige lol). je fait bien un push route de mon lan sur lequel se trouve mon serveur VPN.
Titi_rugby
Tu l’as déjà dit, ça n’apporte rien et ça n’explique pas ce que tu entends par “voir”. Ça a un rapport avec l’affichage dans le voisinage réseau de Windows ou c’est autre chose ?
La route est-elle bien affichée par “route print” sur le client ?
Le serveur VPN est-il la passerelle par défaut des machines du LAN ?
Sinon, les machines du LAN ont-elle une route vers le sous-réseau du client openvpn avec le serveur comme passerelle ? Ou bien la passerelle par défaut du LAN a-t-elle une telle route ?
Sinon, le serveur openvpn fait-il du SNAT/MASQUERADE sur son interface LAN pour le trafic en provenance du client ?
Et bien sûr, pas de filtrage intempestif qui pourrait bloquer le trafic ?
Au vu de ce que tu viens d’écrire, je pense que mon problème vient d’une route mal configurée concernant ma passerelle.
Je ne pourrai rien voir avant ce soir car en modifiant un fichier ce matin, je n’ai plus la main sur le serveur.
Titi_rugby
Un oubli classique est l’absence de route de retour. Généralement on met en place les routes qui vont bien sur chaque noeud pour que A puisse envoyer un paquet juqu’à B, mais on oublie parfois les routes pour que B puisse répondre à A.
je pense que mon problème vient effectivement de la.
Je mets 2 copies d’écrans de mes connexions depuis mon client XP.
UNe est une copie d’un IPCONFIG qui indique le manque de passerelle et l’autre le route print.
titi_rugby
L’absence de passerelle par défaut sur l’interface openvpn n’est pas un problème. On voit bien une route pour 192.168.1.0/255.255.255.0 qui correspond au LAN du serveur openvpn, je suppose. Donc je pense que la configuration IP du client est bonne. Il faut vérifier que le serveur est bien configuré en routeur IP (/proc/sys/net/ipv4/ip_forward=1), et la connectivité dans le sens LAN -> client. Pour cela il faut répondre aux questions que j’ai posées. Un outil de capture de paquets comme tcpdump sur le serveur pourrait permettre de vérifier si les paquets arrivent et repartent sur ses interfaces openvpn (tun/tap) et LAN (eth).
Je rajoute la copie d’écran sur le serveur de la commande route -n
Titi_rugby
C’est bon mais il n’y avait pas de raison que la table de routage soit mauvaise sur le serveur, après tout lui il sait où est tout le monde.
Par contre je vois une passerelle par défaut 192.168.1.1, je suppose que les autres machines du LAN utilisent aussi cette adresse comme passerelle par défaut (qui n’est donc pas le serveur VPN). Dans ce cas il faut que ce routeur, ou les machines du LAN, aient une route vers 10.8.8.0/255.255.255.0 via 192.168.1.x (l’adresse LAN du serveur VPN).
Note : puisque ce sont des affichages en mode texte, une copie du texte serait plus économique et pratique (possibilité de copier/coller) qu’une copie d’écran graphique.
/proc/sys/net/ipv4/ip_forward=1)
C’est bien à 1 sur mon serveur.
En ce qui concerne TCPDUMP, je ne connais pas. Pourrais-tu me dire la commande pour laquelle tu souhaites avoir un résultat.
Titi_rugby
Tu as raison, c’est mou routeur qui fait office de passerelle pour l’intégralité du réseau.
Je vais regarder comme faire pour rajouter une route sur mon routeur.
Je ne pourrai pas contre pas faire la modif avant ce soir sur mon routeur. Je te tiendrai au jus.
Merci pour ton aide.
Titi_rugby
En attendant tu peux tester en faisant du masquerading en sortie du serveur openvpn, c’est laid mais cela évite de devoir définir une route de retour :