[Résolu] OpenVPN OpenSSL, tunnel et port 80

[Pang]

Salut,

C'est la mode des VPN.
J'utilise le serveur et le client windows pour réaliser ces VPN. Le résultat n'est pas toujours très bon.

Sur un réseau à priori sain et non encombré, j'ai des pertes de ping entre client et serveur; en moyenne 25 %.
Conséquence : parfois le surf internet par le serveur n'est pas très fluide il y arrive d'avoir des dépassement de délai pour afficher les pages.
(je ne vois vraiment pas pourquoi il y a ces pertes)

De plus, suivant les réseaux par lesquels on se connecte, un proxy empêche la connexion au serveur (le client utilise le port 1723 ET le protocole GRE (47)); Je ne trouve pas (si toutefois c'est possible) le moyen de changer le port du VPN

On me parle d'openVPN et/ou OpenSSL pour la fiabilité de la connectivité ainsi que pour la capacité d'utiliser n'importe quel port... mais j'ai du mal à faire la part des choses entre les deux: qui fait quoi, ai-je vraiment besoin de 'deux couches' de cryptage, etc.

Est-il envisageable de faire un VPN par un tunnel ssl ou est-ce un contre sens ?

Une petite explication ?

@ +

[Greywolf]

La question n'est pas claire...

 

OpenSSL est une bibliothèque d'authentification via un mécanisme de clé privée/publique

OpenVPN est une solution de VPN basée sur SSL (couche applicative=7 modèle OSI), contrairement à du VPN IPSec ou L2TP (respectivement couche 3 et 2)

 

OpenVPN permet de créer un tunnel SSL entre un client et un serveur d'authentification via les binaires délivrés par OpenVPN. Une interface réseau est créée et obtient une adresse IP du serveur VPN distant, ce dernier s'occupant de l'interconnexion et du routage vers d'autres réseaux.

[Pang]

La question n'est pas claire...

C'est normal

 

OpenVPN est une solution de VPN basée sur SSL (couche applicative=7 modèle OSI), contrairement à du VPN IPSec ou L2TP (respectivement couche 3 et 2)

Entendu. Donc la différence entre OpenVPN et VPN windows est essentiellement au niveau du mécanisme de cryptage et d'authentification, exact ?

 

Par là, cela signifie que je n'aurai pas forcement une meilleure connectivité, n'est-ce pas ? Parce qu'actuellement mon problème n'est pas tant la 'force' de cryptage ou d'authentification, mais plutôt la fiabilité et la fluidité du réseau (pour le moment en ppp).

 

Pang pouvait penser que si le serveur/client windows est au VPN ce qu'InternetExplorer est à la navigation WEB, il pouvait être intéressant de trouver une solutin alternative...

Modifié le 7 octobre 2009 par Pang

[Pang]

J'ai installé et paramétré OpenVPN.

Le fonctionnement n'est pas le même qu'avec la solution windows. On ne me demande pas de logon mot de passe, mais l'identification est réalisé avec une clé 2048 bit (je sais pas si c'est mieux).

Le réseau local fonctionne correctement.

 

En revanche lorsque le client fait des requêtes DNS et http par son navigateur web, le serveur reçoit bien les demandes, mais le client reste sourd aux réponses qu'il lui sont pourtant donné; arrive pas à surfer !

 

Par contre, et par l'intermédiaire d'un fichier de configuration, on peut mettre le serveur OpenVPN en écoute sur n'importe quel port, et par le même fichier on peut spécifier au client de passer par un proxy; c'est très bien.

[Greywolf]

les tables de routage sont correctes? i.e. pour atteindre 0.0.0.0/0 on passe par l'interface tun* et le serveur vpn à l'autre bout

 

le serveur est configuré pour faire du routage entre l'interface Tun* et l'interface réseau réelle? si oui, comment (ip_forwarding activé? masquerading ou pas?)

 

tu peux mettre des action de logging de paquets de part et d'autre pour voir où ça coince (wireshark par exemple)

 

à consulter pour info : http://www.supinfo-projects.com/fr/2005/vpn_ssl_openvpn/1/

 

*: à moins que tu ne sois en mode bridgé ?

[Pang]

Merci pour les pistes de recherche. J'utilise wireshark (sur le serveur) ce qui me permet de dire que les requêtes arrivent bien jusqu'à l'interface et repartent vers le client.

 

Je n'ai rien modifié dans la table de routage premièrement parce que je ne sais pas m'en servir et deuxièmement parce que précédemment je n'ai rien eu besoin de paramétrer lorsque j'ai utilisé le serveur VPN de windows.

Je vais déjà essayer en réglant ip forwarding sur le serveur.

 

Voici mon fichier client.ovpn. Ai-je bon ? J'ai un doute sur la dernière ligne :

 

proto tcp-client 
dev tun
ifconfig 192.168.2.2 192.168.2.1
secret key.txt
port 1857
redirect-gateway 
comp-lzo 
verb 3
dhcp-option DNS 212.27.40.240

[Pang]

L'ip forwarding ne change rien du tout à mon affaire; openVPN ne fonctionne pas du tout de la même manière que le VPN windows.

 

J'ai lancé 3 sniffeurs; 1 sur le client, 1 sur l'interface virtuelle du serveur et 1 sur l'interface physique du pc hébergeant le serveur.

 

Le client envoi sa requête (ping dns) qui arrive bien jusqu'à l'interface physique qui lui même la transmet sur l'interface virtuelle mais ça s'arrête ici. Depuis le client, je peux pinger la carte virtuelle ainsi que la carte physique, mais c'est tout (je ne peux pas pinger les autres machines du réseau depuis le client, chose qui est pourtant possible avec le VPN windows)

 

Mieux; l'interface VPN serveur porte l'adresse 192.168.2.1 et le client 192.168.2.2.

Lorsque je démarre le serveur VPN, celui ci se met à envoyer des requêtes SMB vers l'ip 192.168.2.3 (adresse qui n'existe pas sur mon réseau) et l'adresse MAC de destination de 192.168.2.3 est ff:ff:ff:ff:ff:ff. j'en pleurerais tellement je comprends rien.

[Greywolf]

c'est normal le masque VPN pour les clients windows est en /30 (255.255.255.252). 192.168.2.3 correspond à l'adresse de broadcast

 

http://www.nbs-system.com/dossiers/howto-o..._serveur_routed

NOTE IMPORTANTE : point critique de la configuration en mode routé :

 

Le client en mode routé obtient une IP, un réseau, un broadcast et un gateway. Pour que cela fonctionne dans tous les cas, sous Windows, le driver de carte réseau TAP-WIN32 a besoin de travailler avec un sous réseau de 252.

 

Votre machine cliente aura donc par exemple :

IP: 192.168.0.14

NETMASK: 255.255.255.252

GW vers VPN: 192.168.0.13

Réseau: 192.168.0.12

Broadcast: 192.168.0.15

 

Ensuite c'est le daemon serveur OpenVPN qui s'occuper de relier ces masques de sous réseau ensemble si vous avez choisi le mode client-to-client.

 

Ainsi vous ne pouvez pas adresser n'importe comment vos clients, et toutes les IP ne sont pas disponibles. Les couples d'IP (IP du client, IP du serveur pour le client) sont donc limités aux possibilités suivantes (openvpn -show-valid-subnets pour les retrouver) :

 

l'ip_forwarding est activé certes mais y'a-t-il un filtrage en FORWARD ?

 

15. Lancement des connexions & Tests

 

Pour tester votre VPN, lancer la connexion sur un client (sous Windows, un double clique sur l'icône dans la barre de tache suffit). Une fenêtre de log apparaît et couplée avec un tail -f /usr/local/openvpn/log/openvpn.log sur le serveur, rien ne devrait être réellement problématique. Ensuite, quelques pings dans un sens, dans l'autre et entre clients devrait vous confirmer que tout marche correctement.

 

Ben non, ca marche pas !

 

Il existe beaucoup de raison pour lesquelles cette installation pourrait ne pas marcher, je vais en citer et expliquer quelques unes, au cas où la votre serait dans le lot, vous pourrez gagner du temps.

 

Sous Windows 2000 : des problèmes de routages peuvent survenir, il arrive que l'interface VPN ne récupère pas les routes nécessaires. Vous pouvez alors taper la commande suivante dans un shell (cmd.exe) pour vous en assurez : route print

 

Si la route du VPN n'y est pas, faite un : route add [adresse du réseau VPN] MASK 255.255.255.0 [iP du serveur VPN]

 

Firewall sur le serveur : Si vous ne recevez pas les connexions des utilisateurs, il est probable que vous n'ayez pas ouvert (ou forwardé) le port dans votre firewall. Par défaut c'est le 1194 en udp, ce qui donne en iptables :

iptables -I INPUT -s 0.0.0.0/0 -d [iP PUB DU SERVEUR] -p udp -dport 1194 -j ACCEPT

 

Firewalls personnels : Vos client ont peut être des firewalls personnels sur leurs machines. Le SP2 de XP ne devrait pas poser de problèmes dans son réglage par défaut, mais les firewalls personnels doivent au moins être configurés pour accepter les paquets du serveur et éventuellement du réseau VPN si tel est votre désir.

 

Certificats " self signed " : Typiquement vous avez généré des certificats ou le champ CN du client est le même que celui du serveur. Régénérez vos certificats avec des CN (Common Name) différents pour chaque entité du VPN.

 

Paramètres réseau complètement bidon : vous avez probablement mis les clients en " dev tun " et le serveur en " dev tap " ou l'inverse. Mettez dev tun ou dev tap dans le fichier de configuration du client et du serveur.

[Pang]

c'est normal le masque VPN pour les clients windows est en /30 (255.255.255.252). 192.168.2.3 correspond à l'adresse de broadcast

'tain, c'est le genre de truc que si tu le sais pas, ça rend hystérique... enfin, un grand merci Greywolf pour cette information qui me rend plus digne face à ce VPN

 

je vais décortiquer la page du lien que tu me communiques qui me semble bien détaillée et à ma portée.

 

Merci !

[Pang]

piufff, ca y est.

 

Il y avait une erreur dans mon fichier config :

 

serveur :

ifconfig 192.168.2.1 192.168.2.2

client :

ifconfig 192.168.2.1 192.168.2.2

mais avec le client comme ceci :

ifconfig 192.168.2.2 192.168.2.1

ça marche beaucoup mieux

 

l'ip_forwarding est activé certes mais y'a-t-il un filtrage en FORWARD ?

Différence essentielle avec le VPN windows© qui est 'tout automatique', avec Open VPN j'ai dû partager la connexion qui a accès au réseau local :

Là ça fonctionne; accès local et internet.

Il faut un peu jongler parce que lorsque on passe la carte en connexion partagée, elle prend automatiquement l'adresse 192.168.0.1

Me restait à résoudre un petit problème de résolution de nom netbios sur le réseau local, en parti résolu en ajoutant un serveur wins.

 

En toute objectivité, la connectivité est bien supérieure au VPN windows. Le surf internet est aussi rapide que ce que le proxy offre sur le réseau.

C'est parfait.

 

ET hop, un problème résolu > fermeture du ticket

 

Merci Greywolf !