Discussion :

[Leaffy]

Bonjour,

Je cherche actuellement à installer et configurer un serveur VPN, j'ai généré tous les certificats nécessaires à l'application, choisi un mode de chiffrement et modifié les fichiers de configuration. Voici le problème: le service openvpn démarre bien côté serveur, mais l'ennui c'est que côté client il semble y avoir quelques soucis au niveau de TLS que j'aimerais bien pouvoir régler...Je ne vois pas quelle est la source du problème si quelqu'un peut y voir plus clair:

côté serveur:
/etc/openvpn/server.conf

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
;local a.b.c.d
port 443
;proto tcp
proto udp
;dev tap
dev tun
;dev-node MyTap
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/easy-rsa/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
;server-bridge
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 208.67.222.222"
;push "dhcp-option DNS 208.67.220.220"
;client-to-client
;duplicate-cn
keepalive 10 120
;tls-auth ta.key 0 # This file is secret
;cipher BF-CBC        # Blowfish (default)
cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
comp-lzo
;max-clients 100
max-clients 3
;user nobody
;group nogroup
persist-key
persist-tun
status openvpn-status.log
log         openvpn.log
log-append  openvpn.log
verb 9
;mute 20

côté client:
client.ovpn

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
client
;dev tap
dev tun
;dev-node MyTap
;proto tcp
proto udp
remote 178.170.xxx.xxx 443
;remote my-server-2 1194
;remote-random
resolv-retry infinite
nobind
;user nobody
;group nogroup
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
ns-cert-type server
;tls-auth ta.key 1
cipher AES-128-CBC
comp-lzo
verb 9
;mute 20

Le message d'erreur côté serveur est le suivant:
TLS State Error: No TLS state for client [AF_INET]89.2.xxx.xxx:41577, opcode=4

Sinon j'ai une autre question toute bête: dans quel cas est il préférable de passer par tcp pour un vpn?

Merci d'avance

[Etre_Libre]

C'est tout ce qu'il y a dans les logs ?

PS : j'utilise OpenVPN dans Windows, mais la syntaxe est normalement la même.

[Leaffy]

Voici ce que m'indiquent les logs:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Mon Mar 12 22:15:23 2012 us=195842 89.2.xxx.xxx:52450 TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Mon Mar 12 22:15:23 2012 us=195842 89.2.xxx.xxx:52450 TLS Error: TLS object -> incoming plaintext read error
Mon Mar 12 22:15:23 2012 us=195842 89.2.xxx.xxx:52450 TLS Error: TLS handshake failed
Mon Mar 12 22:15:23 2012 us=195842 89.2.xxx.xxx:52450 Fatal TLS error (check_tls_errors_co), restarting
Mon Mar 12 22:15:23 2012 us=195842 89.2.xxx.xxx:52450 SIGUSR1[soft,tls-error] received, client-instance restarting
Mon Mar 12 22:15:23 2012 us=195842 TCP/UDP: Closing socket
Mon Mar 12 22:15:28 2012 us=275842 MULTI: multi_create_instance called
Mon Mar 12 22:15:30 2012 us=327842 TCP/UDP: Closing socket
Mon Mar 12 22:15:35 2012 us=379842 MULTI: multi_create_instance called
Mon Mar 12 22:15:35 2012 us=379842 Re-using SSL/TLS context
Mon Mar 12 22:15:35 2012 us=379842 LZO compression initialized
Mon Mar 12 22:15:35 2012 us=379842 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Mon Mar 12 22:15:35 2012 us=379842 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]

et ça reboucle (du fait que j'ai un retry infinite)

Pour plus d'informations je pourrai vous afficher les logs en mode verbeux si besoin. Donc voilà en gros ce que je comprends c'est que le socket se referme car le handshake de TLS n'a pas fonctionné correctement, la question que je me pose est: est-ce que cela vient de mes certificats ou est-ce dû au fait que SSL est désactivé par défaut sur le serveur dédié que j'utilise pour monter le serveur openvpn. Je ne pense pas que ça soit la deuxième solution mais bon je ne vois pas trop...

[Etre_Libre]

Le "no certificate returned" me laisse penser à un certificat vide...

Tu n'aurais pas un des fichiers certificat à 0 Octet, que ce soit côté serveur ou client ?

[Leaffy]

Visiblement non j'ai regardé de ce côté mais chaque certificat côté client et côté serveur pèse 4ko, y compris les clefs de chiffrement.
Avant de mettre en place le service j'avais également vérifié qu'ils avaient bien du contenu.

Je viens de regarder sur ubuntu-fr.org (http://forum.ubuntu-fr.org/viewtopic.php?id=348933), une personne a le même problème que moi, je vais réessayer de générer les certificats ils ne doivent pas être bons. En tout cas merci pour tes réponses

Je te tiens au courant si j'ai réussi à régler mon problème.

[Etre_Libre]

Et avec l'utilisation des "tls-auth" de chaque côté (il faut générer les ta.key), est-ce mieux ?

[Leaffy]

Ca y' est le serveur vpn est enfin fonctionnel! Effectivement cela venait de mes certificats qui n'étaient pas correctement configurés comme je m'en doutais.

Oui du coup j'ai aussi pensé à rajouter une couche de sécurité supplémentaire via ta méthode 'tls-auth', en ayant crée une clef ta.key supplémentaire générée avec la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

openvpn --genkey --secret ta.key

J'ai regardé les logs et cette fois-ci la connexion s'est bien déroulée, et l'interface tun a enfin été crée.

En revanche je ne comprends pas bien pourquoi je me déconnecte et reconnecte à chaque fois, est-ce normal?

[Etre_Libre]

C'est à dire ?

[Leaffy]

J'ai ça dans les logs:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Wed Mar 14 08:58:55 2012 us=264863 Connection reset, restarting [0]
Wed Mar 14 08:58:55 2012 us=265439 TCP/UDP: Closing socket
Wed Mar 14 08:58:55 2012 us=265574 SIGUSR1[soft,connection-reset] received, process restarting

Le socket s'ouvre et se referme successivement, c'est normal?

[Etre_Libre]

Ah, et c'est régulier ?

Est-ce que la connexion semble stable si tu lances un ping en boucle ?

[Leaffy]

Ce qui m'interpelle c'est le message suivant obtenu sur le serveur (je pense que c'est la cause du problème):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Wed Mar 14 10:08:45 2012 us=469078 client1/212.23.xxx.xxx:2720 MULTI: primary virtual IP for client1/212.23.xxx.xxx:2720: 10.8.0.6
Wed Mar 14 10:08:45 2012 us=877078 client1/212.23.xxx.xxx:2720 Authenticate/Decrypt packet error: cipher final failed
Wed Mar 14 10:08:45 2012 us=877078 client1/212.23.xxx.xxx:2720 Fatal decryption error (process_incoming_link), restarting
Wed Mar 14 10:08:45 2012 us=877078 client1/212.23.xxx.xxx:2720 SIGUSR1[soft,decryption-error] received, client-instance restarting
Wed Mar 14 10:08:45 2012 us=877078 TCP/UDP: Closing socket

Côté client j'ai juste la trace comme quoi le socket se met en pause puis redémarre.

EDIT: c'est bon j'ai changé l'algorithme de chiffrement et je n'ai plus ce problème: désormais j'utilise Blowfish et j'arrive enfin a bien pinger l'adresse tun du serveur

Je ne sais pas pourquoi cela ne fonctionne pas avec l'AES 256...

[Etre_Libre]

Tout a bien été réglé correctement ?

Tous les certificats ont été générés depuis le serveur ?

[Leaffy]

Oui c'est bon, tout fonctionne du coup
Merci pour ton aide!

[Etre_Libre]

Vraiment ? Malgré le message, cela fonctionne ?

[Leaffy]

Non comme je le disais plus haut j'ai dû changer le moyen de chiffrement, sinon cela ne marche pas avec de l'AES 256 sans vraiment que je sache pourquoi...

Du côté du client j'ai pu ainsi débloquer l'interface tun0 avec attribution d'une addresse IP sur le réseau local au serveur.

Ce qui m'embête maintenant c'est ce message obtenu côté serveur, répété en boucle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Wed Mar 14 11:21:28 2012 us=933078 client1/212.xxx.xxx.xxx:44501 MULTI: bad source address from client [10.31.17.167], packet dropped

Du côté du client la connexion semble stable et j'arrive a pinger le serveur sur l'adresse locale de la passerelle en 10.8.0.1.

[Etre_Libre]

Là j'admets que je ne sais pas mieux pour la suite...

De mon côté, lors de tests et de production, le seul chiffrement 256 bits qui fonctionne est le AES-256-CBC (pas les autres).

[Leaffy]

En attendant je continue à chercher de mon côté mais je pense que je ne suis plus très loin de la solution.

Merci pour ta disponibilité

[Leaffy]

Je ressort ce topic pour dire que j'ai pu régler mon problème en utilisant le cryptage par défaut blowfish donc, et pour ce qui est de la connexion, pour bien faire circuler les paquets dans le pipe VPN j'ai rajouté la directive

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

push 'redirect-gateway def1'

sur le client, ca passe nickel du coup, mes paquets empruntent le tunnel comme il le fallait