Mise en place d'OpenVPN

[Bruno]

Bonjour,

J'essaye de mettre en place un VPN entre mes PC-maison-Bruxelles et mes serveurs-datacenter-Roubaix., dans le but d'utiliser le second comme proxy.

J'ai donc installé openvpn sur mon PC XP et sur le serveur Debian.

J'ai suivit la démarche décrite ici : http://www.coagul.org/spip.php?article422

Tout est OK, je lance la connection depuis mon poste XP, et là, c'est le drame :

Sat May 17 01:37:37 2008 OpenVPN 2.0.5 Win32-MinGW [SSL] [LZO] built on Nov  2 2005
Sat May 17 01:37:37 2008 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Sat May 17 01:37:37 2008 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat May 17 01:37:37 2008 LZO compression initialized
Sat May 17 01:37:37 2008 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat May 17 01:37:37 2008 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sat May 17 01:37:37 2008 Local Options hash (VER=V4): '41690919'
Sat May 17 01:37:37 2008 Expected Remote Options hash (VER=V4): '530fdded'
Sat May 17 01:37:37 2008 UDPv4 link local: [undef]
Sat May 17 01:37:37 2008 UDPv4 link remote: 91.121.60.33:1194

En faisant un tail -f sur syslog, je remarque une boucle de tentatives mais aucune erreur apparente, voici ce log : http://brunop.be/public/vpn.txt

Donc là je sèche.. j'ai pensé à un mauvais noyau mais je ne vois rien de tel dans le log.


-----

Publicité

[invite4ad25ccf]

La comme ca, je vois pas. Serait il possible de voir tes fichiers de conf client / serveur ? je dirais que c'est juste une erreur de conf ou certificats mauvais (mais il le signalerais en théorie :s). En tout cas, pas de soucis du coté noyau

Sinon, j'espere que tu as bien regénéré toutes tes clés / certificats RSA / DSA si tu as une debian etch ou plus récent :
http://www.debian.org/security/2008/dsa-1571
http://www.debian.org/security/2008/dsa-1576

[Bruno]

La comme ca, je vois pas. Serait il possible de voir tes fichiers de conf client / serveur ? je dirais que c'est juste une erreur de conf ou certificats mauvais (mais il le signalerais en théorie :s). En tout cas, pas de soucis du coté noyau

Yep, voici les fichiers de conf :

Coté serveur : http://brunop.be/public/server.conf.txt
Coté client : http://brunop.be/public/client.conf.txt

Sinon, j'espere que tu as bien regénéré toutes tes clés / certificats RSA / DSA si tu as une debian etch ou plus récent :

Ne t'inquiète pas, je suis au taquet sur la ML security

[invite4ad25ccf]

De mémoire, sous debian, il faut mettre "dev tun0" et non "dev tun".

Je te conseille aussi de decommenter la ligne ";tls-auth ta.key 0 # This file is secret", en faisant les manip précisées en commentaires

Je regarderais ca plus en détail si ca ne marche pas demain dans l'apres midi

Ne t'inquiète pas, je suis au taquet sur la ML security

Ha oui Enfin je préfère en parler, on sait jamais. Surtout vu la facilité à "casser" les clés (a peine 2h pour me connecter à un de mes serveurs en bruteforce :s)

[A voir en vidéo sur Futura]

[Bruno]

De mémoire, sous debian, il faut mettre "dev tun0" et non "dev tun".

Je te conseille aussi de decommenter la ligne ";tls-auth ta.key 0 # This file is secret", en faisant les manip précisées en commentaires

Je regarderais ca plus en détail si ca ne marche pas demain dans l'apres midi

Changements effectués, toujours la même chose : http://brunop.be/public/vpn2.txt

Ha oui Enfin je préfère en parler, on sait jamais. Surtout vu la facilité à "casser" les clés (a peine 2h pour me connecter à un de mes serveurs en bruteforce :s)

Mouais, quand l'exploit est sorti j'avais déjà mis à jour toutes mes machines..

[invite6754323456711]

Changements effectués, toujours la même chose : http://brunop.be/public/vpn2.txt

Je ne connais pas bien OpenVpn mais ce qui est surprenant c'est que tu obtiennes le même comportement avec des noms de device tun différents.

L'interface tun se crée t'elle correctement ? J'avais adapté un petit utilitaire pour tester les interfaces Tun/Tap

«pour compiler gcc dumptun.c –o dumptun »

#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <net/if.h>
#include <linux/if_tun.h>
#include <sys/ioctl.h>

#define PERROR(x) do { perror(x); exit(1); } while (0)
#define PKTSZ 1600

/* echo 1 > /proc/sys/net/ipv4/ip_forward */
void usage()
{
        fprintf(stderr, "Usage: dumptun [-e]\n");
        exit(0);
}


void hexdump(unsigned char *buf, int len)
{
        int p;
        for (p = 0; p < len; p++) {
            printf("%02x ", buf[p]);
            if (p % 16 == 15) printf("\n");
        }
        if (p % 16 != 15) printf("\n");
}


int main(int argc, char *argv[])
{
        struct ifreq ifr;
        int fd, sz, tunmode = IFF_TUN;
        unsigned char buf[PKTSZ];

        if ((argc > 1) && (strcmp("-e", argv[1]) == 0)) tunmode = IFF_TAP;

        if ( (fd = open("/dev/net/tun",O_RDWR)) < 0) PERROR("open");

        memset(&ifr, 0, sizeof(ifr));
        ifr.ifr_flags = tunmode;
        if ( tunmode == IFF_TAP) {
           strncpy(ifr.ifr_name, "tap%d", IFNAMSIZ);
	} else {
           strncpy(ifr.ifr_name, "tun%d", IFNAMSIZ);
	}
        if (ioctl(fd, TUNSETIFF, (void *)&ifr) < 0) PERROR("ioctl");

        printf("Maintenant dumping trafic sur interface %s\n", ifr.ifr_name);

        while (1) {
            sz = read(fd, buf, PKTSZ);
            printf("%s packet. L3 type %#02x%02x :\n",
                   tunmode == IFF_TUN ? "L3" : "L2",
                   buf[2],buf[3]);
            hexdump(buf+4, sz-4);
        }
}


Utilisation TUN :

Installer le module tun
# modprobe tun

Ouvrir le fichier /dev/tun0 pour activer l’interface tun0 
#./dumptun & Maintenant dumping trafic sur interface tun0

Configurer l’IP de l’interface tun0

# ifconfig tun0 192.168.5.1 pointopoint 192.168.5.2
# ping -c 2 192.168.5.2
L3 packet. L3 type 0x800 :
45 00 00 54 00 00 40 00 40 01 af 55 c0 a8 05 01
c0 a8 05 02 08 00 9a 6d dc 21 00 01 db 32 7d 42
36 f7 07 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23
24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33
34 35 36 37
L3 packet. L3 type 0x800 :
45 00 00 54 00 01 40 00 40 01 af 54 c0 a8 05 01
c0 a8 05 02 08 00 bb 6e dc 21 00 02 dc 32 7d 42
14 f5 07 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23
24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33
34 35 36 37

Utilisation TAP :

Installer le module tun
# modprobe tun

Ouvrir le fichier /dev/tap0 pour activer l’interface tap0 
#./dumptun –e & Maintenant dumping trafic sur interface tap0

Configurer l’IP de l’interface tap0

# ifconfig tap0 192.168.5.1
# ping -c 1 192.168.5.2
L2 packet. L3 type 0x806 :
ff ff ff ff ff ff 00 ff 14 10 69 b2 08 06 00 01
08 00 06 04 00 01 00 ff 14 10 69 b2 c0 a8 05 01
00 00 00 00 00 00 c0 a8 05 0
# arp -s 192.168.5.2 01:02:03:04:05:06
# ping -c 1 192.168.5.2
L2 packet. L3 type 0x800 :
01 02 03 04 05 06 00 ff 14 10 69 b2 08 00 45 00
00 54 00 00 40 00 40 01 af 55 c0 a8 05 01 c0 a8
05 02 08 00 ca 2c 7c 21 00 01 34 32 7d 42 07 39
0e 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35
36 37

Patrick

[invite6754323456711]

Je ne connais pas bien OpenVpn mais ce qui est surprenant c'est que tu obtiennes le même comportement avec des noms de device tun différents.

Autant pour moi le client est sur un PC sous XP (On peut donc avoir des comportements mystérieux ).


Patrick

[Bruno]

Towl, des nouvelles ?

[invite4ad25ccf]

Oups, j'avais zappé ce post désolé :s

A priori, c'est une de tes interfaces tun qui ne monte pas d'un coté ou de l'autre. J'ai quasiment le meme fichier de conf que toi sur le serveur (j'ai un dev tun0 sous OpenBSD), et le meme pour mon client WinXP.
Donc reste la possibilité des drivers non chargés (modprobe tun sous Debian), je sais pas quoi sous Windows.

[Bruno]

Oups, j'avais zappé ce post désolé :s

A priori, c'est une de tes interfaces tun qui ne monte pas d'un coté ou de l'autre. J'ai quasiment le meme fichier de conf que toi sur le serveur (j'ai un dev tun0 sous OpenBSD), et le meme pour mon client WinXP.
Donc reste la possibilité des drivers non chargés (modprobe tun sous Debian), je sais pas quoi sous Windows.

fo:/etc/squid# modprobe tun0
FATAL: Could not load /lib/modules/2.6.24.5-grsec-xxxx-grs-ipv4-32/modules.dep: No such file or directory


:-/

[invite4ad25ccf]

Il faut faire modprobe tun (driver tun qui permet de créer les interfaces tunX)

[Bruno]

Idem :

fo:/etc/squid# modprobe tun0
FATAL: Could not load /lib/modules/2.6.24.5-grsec-xxxx-grs-ipv4-32/modules.dep: No such file or directory
fo:/etc/squid# modprobe tun
FATAL: Could not load /lib/modules/2.6.24.5-grsec-xxxx-grs-ipv4-32/modules.dep: No such file or directory

fo:/etc/squid# ifconfig | grep tun
tun0      Lien encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

[invite4ad25ccf]

Ca veut dire que tu as le driver compilé direct dans le noyau puisque l'interface est montée (ifconfig le confirme). Donc pas besoin de modprobe.

Reste à vérifier du coté de Windows, et la par contre, je sais pas trop comment faire :s

[Bruno]

Reste à vérifier du coté de Windows, et la par contre, je sais pas trop comment faire :s

En laissant tourner un peu :

Sun May 18 23:15:04 2008 OpenVPN 2.0.5 Win32-MinGW [SSL] [LZO] built on Nov 2 2005
Sun May 18 23:15:04 2008 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Sun May 18 23:15:04 2008 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sun May 18 23:15:04 2008 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Sun May 18 23:15:04 2008 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 18 23:15:04 2008 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 18 23:15:04 2008 LZO compression initialized
Sun May 18 23:15:04 2008 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun May 18 23:15:04 2008 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sun May 18 23:15:04 2008 Local Options hash (VER=V4): '504e774e'
Sun May 18 23:15:04 2008 Expected Remote Options hash (VER=V4): '14168603'
Sun May 18 23:15:04 2008 UDPv4 link local: [undef]
Sun May 18 23:15:04 2008 UDPv4 link remote: 91.121.60.33:1194
Sun May 18 23:16:04 2008 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun May 18 23:16:04 2008 TLS Error: TLS handshake failed
Sun May 18 23:16:04 2008 TCP/UDP: Closing socket
Sun May 18 23:16:04 2008 SIGUSR1[soft,tls-error] received, process restarting
Sun May 18 23:16:04 2008 Restart pause, 2 second(s)

[invite4ad25ccf]

Ah, alors c'est un probleme de certificats / clés. Ou alors de filtrage un peu trop bourrin d'un coté ou de l'autre, mais ca m'etonnerais.
. As tu générés correctement les certificats et les clés ? Au pire essaye de regénerer tout ca pour voir ce que cela donne.

[Bruno]

Ah, alors c'est un probleme de certificats / clés. Ou alors de filtrage un peu trop bourrin d'un coté ou de l'autre, mais ca m'etonnerais.
. As tu générés correctement les certificats et les clés ? Au pire essaye de regénerer tout ca pour voir ce que cela donne.

Je vais essayer.

Sinon c'est normal ça ?

r10013:~# telnet 91.121.60.33 1194
Trying 91.121.60.33...
telnet: Unable to connect to remote host: Connection refused

[invite4ad25ccf]

yep, telnet c'est du TCP, et ta conf openvpn est UDP.
Pour tester, essaye avec netcat : "nc -l -p 1194 -u" pour simuler le serveur, "nc -u <IP> 1194" pour simuler le client

[Bruno]

yep, telnet c'est du TCP, et ta conf openvpn est UDP.
Pour tester, essaye avec netcat : "nc -l -p 1194 -u" pour simuler le serveur, "nc -u <IP> 1194" pour simuler le client

r10013:~# nc -u 91.121.60.33 1194

et rien ne vient...

Après avoir régénéré les certificats, toujours la même chose. En mode ultra verbeux, il lui envoie des requêtes en boucle puis finis avec un :


Mon May 19 00:28:49 2008 UDPv4 link remote: 91.121.60.33:1194
Mon May 19 00:29:49 2008 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon May 19 00:29:49 2008 TLS Error: TLS handshake failed
Mon May 19 00:29:49 2008 TCP/UDP: Closing socket
Mon May 19 00:29:49 2008 SIGUSR1[soft,tls-error] received, process restarting

EDIT : j'ai passé les deux en TCP et tout est OK. Problème résolu.