Openvpn entre plusieurs vps debian

Support Debian
#1

Bonjour à tous,

j’ai pu voir que certains ont déjà évoqué le sujet mais malheureusement je n’arrive pas du tout à m’y retrouver.
Je souhaite travailler uniquement sur debian wheezy. Je voudrais créer un VPN entre des vps debian, dans le but d’obtenir un réseau virtuel de ce type là:

réseau : 10.8.0.0/24
vps 1 : 10.8.0.1 (openvpn server)
vps 2 : 10.8.0.2 (client)
vps 3 : 10.8.0.3 (client)
…
…

J’ai suivi beaucoup de tuto concernant l’installation d’openvpn côté serveur, mais j’avoue ne pas comprendre la procédure côté client.

côté serveur :
J’ai édité le fichier /etc/openvpn/easy-rsa/vars
J’ai généré les clés et certificats du client, j’ai bien les fichiers (ca.crt client.conf ta.key vpn.crt vpn.key).
J’ai configuré le serveur.conf
j’obtiens bien une interface tun0 en faisant un ifconfig. De plus, le service openvpn est bien lancé.
La séquence “openvpn server.conf” se passe bien puisque j’obtiens un "initialization session completed"
Je pense que ma config est pas trop mal.
j’ai fait le routage avec “sh -c ‘echo 1 > /proc/sys/net/ipv4/ip_forward’”

côté client :
j’ai copié les clés avec rsync du serveur vers le client.

quand je fais un "openvpn --remote @IPSERVER --script-security 2 --dev tun0"
ca me retourne un “read UDPv4 [ECONNREFUSED]: Connection refused (code=111)”

Avez-vous une idée?! Je suis trop mauvais pour continuer tout seul.

Merci d’avance pour votre intérêt!

rick!

#2

Section “Trucs & Astuces” : pour partager une astuce que tu as découvert au sujet de Debian.
Section “Support Debian” : pour demander de l’aide liée à l’utilisation de Debian.

Je déplace ce sujet dans la section SD.

#3

Bonjour,

Il est presque certain que la connexion de ton client openvpn vers le serveur est bloquée par un pare-feu. Que ce soit sur le client ou sur le serveur.

On peut avoir un aperçu des principales règles de filtrage avec la commande iptables --line-numbers -nvx -t filter -L . Remplacer iptables par ip6tables si tu utilises IPv6.

Sous Debian Wheezy,[strike]si l’on utilise pas cette abomination de systemd,[/strike] il suffit de mettre la configuration du client openvpn dans un fichier du genre /etc/openvpn/nom.conf et on peut ensuite démarrer/arrêter le client avec les commandes service openvpn start nom , service openvpn status , service openvpn stop nom ETC. Etant un service, cela se relance aussi tout seul après un redémarrage.

–
AnonymousCoward

#4

Pire encore que de bloquer la connexion, tu ne fais nul mention d’une mise en place de NAT. J’ai récemment suivi un tuto avec succès. Je cherche le lien et reviens le poster.

EDIT : Je n’ai pas retrouvé le fameux sujet, mais voici mes règles iptables (je n’ai laissé que celles qui sont intéressantes pour ton cas) :

[code]# iptables-save

Generated by iptables-save v1.4.21 on Sun May 3 19:14:49 2015

*nat
:PREROUTING ACCEPT [2208137:130623406]
:POSTROUTING ACCEPT [3314:207913]
:OUTPUT ACCEPT [3314:207913]
-A POSTROUTING -s 10.8.0.0/24 -o venet0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 149.91.83.160
COMMIT

Completed on Sun May 3 19:14:49 2015

Generated by iptables-save v1.4.21 on Sun May 3 19:14:49 2015

*filter
:INPUT DROP [676746]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [10845041:3490995008]
-A INPUT -p udp -m state --state NEW -m udp --dport 443 -j ACCEPT #Pas sûr que cette règle soit utile
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT[/code]

Mon VPN écoute sur le port 443, et l’interface venet0 est due au fait que le serveur est virtualisé sur du OpenVZ. Pour voir où ça coince, tu peux aussi tâter tes différentes interfaces réseaux via tcpdump.

#5

Bonjour à tous,
Tout d’abord, je vous remercie beaucoup d’avoir pris le temps d’étudier mon cas.

Concernant le pare feu j’ai mi policy accept partout pour voir si ca bloquait mais je ne sais pas si c’est une bonne idée !

Voici la conf de iptables sur le serveur :
Chain INPUT (policy ACCEPT 1953 packets, 728592 bytes)
num pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT all – * tun0 0.0.0.0/0 0.0.0.0/0
2 0 0 ACCEPT all – tun0 * 0.0.0.0/0 0.0.0.0/0
3 0 0 ACCEPT all – tun0 eth0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 2155 packets, 2960114 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT all – * tun0 0.0.0.0/0 0.0.0.0/0

Voici la conf de iptables sur le client (il n’y a rien mais c’est pour que vous voyez bien!) :
Chain INPUT (policy ACCEPT 146 packets, 25728 bytes)
num pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 159 packets, 169224 bytes)
num pkts bytes target prot opt in out source destination

Concernant le NAT, j’avais effectué cette commande côté serveur :

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.8.0.2/24 -o eth0 -j MASQUERADE

Je suppose que je dois faire un NAT sur le client aussi?

Fichiers de configuration client

j’ai bien mi les fichiers dans /etc/openvpn/

Merci AnonymousCoward & Dunatotatos !

#6

Ne configure rien de particulier sur ton client, openvpn s’occupe de tout. (Sauf problème… Pour info, j’ai des problèmes de routes pas configurées correctement et de resolv.conf qui ne se met pas à jour. Mais c’est une autre histoire)

Normalement, quand tu as configuré ton serveur, openvpn a créé un fichier “client.conf”. Copie ce fichier avec tes clefs et certificats dans /etc/openvpn/[qqch]/ et utilise la commande #openvpn client.conf

Et donne-nous le résultat ^^

#7

Quand je lance le service openvpn avec client.conf
root@vpn-clt:/etc/openvpn# openvpn client.conf
Tue May 5 22:10:06 2015 OpenVPN 2.2.1 arm-linux-gnueabihf [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Dec 1 2014
Tue May 5 22:10:06 2015 WARNING: No server certificate verification method has been enabled. See openvpn.net/howto.html#mitm for more info.
Tue May 5 22:10:06 2015 NOTE: OpenVPN 2.1 requires ‘–script-security 2’ or higher to call user-defined scripts or executables
Tue May 5 22:10:06 2015 Control Channel Authentication: using ‘ta.key’ as a OpenVPN static key file
Tue May 5 22:10:06 2015 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Tue May 5 22:10:06 2015 Incoming Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Tue May 5 22:10:06 2015 LZO compression initialized
Tue May 5 22:10:06 2015 Control Channel MTU parms [ L:1560 D:168 EF:68 EB:0 ET:0 EL:0 ]
Tue May 5 22:10:06 2015 Socket Buffers: R=[87380->131072] S=[16384->131072]
Tue May 5 22:10:06 2015 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Tue May 5 22:10:06 2015 Local Options hash (VER=V4): '2f2c6498’
Tue May 5 22:10:06 2015 Expected Remote Options hash (VER=V4): '9915e4a2’
Tue May 5 22:10:06 2015 Attempting to establish TCP connection with [AF_INET]monserveur:443 [nonblock]
Tue May 5 22:10:07 2015 TCP connection established with [AF_INET]monserveur:443
Tue May 5 22:10:07 2015 TCPv4_CLIENT link local: [undef]
Tue May 5 22:10:07 2015 TCPv4_CLIENT link remote: [AF_INET]monserveur:443
Tue May 5 22:10:07 2015 TLS: Initial packet from [AF_INET]monserveur:443, sid=536372b6 953dc9a7
Tue May 5 22:10:07 2015 VERIFY OK: depth=1, /C=FR/ST=06/L=Nissa/O=FM/OU=changeme/CN … ost.domain
Tue May 5 22:10:07 2015 VERIFY OK: depth=0, /C=FR/ST=06/L=Nissa/O=FM/OU=changeme/CN … ost.domain
Tue May 5 22:10:07 2015 Data Channel Encrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
Tue May 5 22:10:07 2015 Data Channel Encrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Tue May 5 22:10:07 2015 Data Channel Decrypt: Cipher ‘AES-256-CBC’ initialized ith 256 bit key
Tue May 5 22:10:07 2015 Data Channel Decrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Tue May 5 22:10:07 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES2 6-SHA, 1024 bit RSA
Tue May 5 22:10:07 2015 [changeme] Peer Connection Initiated with [AF_INET]monserveur:443
Tue May 5 22:10:10 2015 SENT CONTROL [changeme]: ‘PUSH_REQUEST’ (status=1)
Tue May 5 22:10:10 2015 PUSH: Received control message: 'PUSH_REPLY,redirect-ga eway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220. 20,explicit-exit-notify 3,route 10.8.0.1,topology net30,ping 10,ping-restart 120 ifconfig 10.8.0.6 10.8.0.5’
Tue May 5 22:10:10 2015 OPTIONS IMPORT: timers and/or timeouts modified
Tue May 5 22:10:10 2015 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp
Tue May 5 22:10:10 2015 OPTIONS IMPORT: --ifconfig/up options modified
Tue May 5 22:10:10 2015 OPTIONS IMPORT: route options modified
Tue May 5 22:10:10 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue May 5 22:10:10 2015 ROUTE default_gateway=10.1.38.1
Tue May 5 22:10:10 2015 TUN/TAP device tun0 opened

Mais après c’est “très très long”, au bout de 5 minutes il ne se passe rien, et je ne peux pas ouvrir d’autre session ssh pendant ce temps là (je ne comprends pas) et si je coupe avec ctrl X,
le ping (voir après) s’arrête.

Par contre, j’ai vérifié depuis le serveur (qui a l’ip 10.8.0.1) le ping 10.8.0.6 fonctionne !

Aussi, je suis obligé de faire ça à chaque fois (côté client et serveur) pour que tun/tap fonctionne:

mkdir -p /dev/net
mknod /dev/net/tun c 10 200
chmod 600 /dev/net/tun
cat /dev/net/tun

[edit]

après un long moment d’attente (genre 10/15 minutes) la connexion se coupe toute seule, le ping fonctionne toujours, mais je ne peux plus me connecter à mon client. La seule alternative étant de reboot mon vps…

#8

Bonjour,

Etant donné que la connexion s’établit mais se coupe au bout de quelques minutes, cela nous aiderait si tu pouvais donner ici les fichiers de configuration d’OpenVPN du serveur ET du client.

De même, donner l’affichage complet des commandes iptables --line-numbers -nvx -t filter -L et iptables --line-numbers -nvx -t nat -L .

Quand à çà… OpenVPN en TCP perd énormément en performances dès qu’il y a un minimum de paquets perdus sur la connexion. A passer vite fait en UDP si c’est pour relier deux serveurs entre eux !
Déjà que sur la plupart des VPS il y a des performances pourries sur le chiffrement parce-que l’on a pas accès à une accélération matérielle là-dessus, pas besoin d’en rajouter.

–
AnonymousCoward

#9

Bonjour,

server.conf:

Serveur TCP/443

mode server
proto tcp
port 443
dev tun

Cles et certificats

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 1
key-direction 0
cipher AES-256-CBC

Reseau

server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120

Securite

user nobody
group nogroup
chroot /etc/openvpn/jail
persist-key
persist-tun
comp-lzo

Log

verb 3
mute 20
status openvpn-status.log
log-append /var/log/openvpn.log
push “explicit-exit-notify 3”

client.conf:

Client

client
dev tun
proto tcp-client
remote monserveur 443
resolv-retry infinite
cipher AES-256-CBC
; client-config-dir ccd

Cles

ca ca.crt
cert rick.crt
key rick.key
tls-auth ta.key 1
key-direction 1

Securite

nobind
persist-key
persist-tun
comp-lzo
verb 3

root@vpn-srv:/etc/openvpn# iptables --line-numbers -nvx -t filter -L
Chain INPUT (policy ACCEPT 36993 packets, 3709634 bytes)
num pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 751 57076 ACCEPT all – * tun0 0.0.0.0/0 0.0.0.0/0
2 760 60028 ACCEPT all – tun0 * 0.0.0.0/0 0.0.0.0/0
3 0 0 ACCEPT all – * tun0 0.0.0.0/0 0.0.0.0/0
4 0 0 ACCEPT all – tun0 * 0.0.0.0/0 0.0.0.0/0
5 0 0 ACCEPT all – * tun0 0.0.0.0/0 0.0.0.0/0
6 0 0 ACCEPT all – tun0 * 0.0.0.0/0 0.0.0.0/0
7 0 0 ACCEPT all – tun0 eth0 0.0.0.0/0 0.0.0.0/0
8 0 0 ACCEPT all – tun0 eth0 0.0.0.0/0 0.0.0.0/0
9 0 0 ACCEPT all – tun0 eth0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 47842 packets, 61137365 bytes)
num pkts bytes target prot opt in out source destination
1 1626 136584 ACCEPT all – * tun0 0.0.0.0/0 0.0.0.0/0
2 0 0 ACCEPT all – * tun0 0.0.0.0/0 0.0.0.0/0
3 0 0 ACCEPT all – * tun0 0.0.0.0/0 0.0.0.0/0

root@vpn-srv:/etc/openvpn# iptables --line-numbers -nvx -t nat -L
Chain PREROUTING (policy ACCEPT 1416 packets, 103883 bytes)
num pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 684 packets, 45983 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 1201 packets, 95210 bytes)
num pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 11 packets, 924 bytes)
num pkts bytes target prot opt in out source destination
1 2019 162311 MASQUERADE all – * eth0 0.0.0.0/0 0.0.0.0/0
2 0 0 MASQUERADE all – * eth0 10.8.0.0/24 0.0.0.0/0
3 0 0 MASQUERADE all – * eth0 10.8.0.0/24 0.0.0.0/0
4 0 0 MASQUERADE all – * eth0 0.0.0.0/0 0.0.0.0/0
5 0 0 MASQUERADE all – * eth0 10.8.0.0/24 0.0.0.0/0
6 0 0 MASQUERADE all – * eth0 10.8.0.0/24 0.0.0.0/0
7 0 0 MASQUERADE all – * eth0 0.0.0.0/0 0.0.0.0/0
8 0 0 MASQUERADE all – * eth0 10.8.0.0/24 0.0.0.0/0
9 0 0 MASQUERADE all – * eth0 10.8.0.0/24 0.0.0.0/0

#10

“Etant donné que la connexion s’établit mais se coupe au bout de quelques minutes”

La connexion vpn entre les deux serveurs fonctionne toujours, mais je ne peux plus accéder à mon serveur “client” en ssh une fois que la connexion vpn est faite!

Merci encore!

#11

Mes suggestions en bleu :

[quote=“ricko55”]server.conf:

Serveur UDP/1194

mode server
proto udp
port 1194
dev tun

Cles et certificats

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 1
key-direction 0
cipher AES-256-CBC

Reseau

server 10.8.0.0 255.255.255.0
#push “redirect-gateway def1 bypass-dhcp”
#push “dhcp-option DNS 208.67.222.222”
#push "dhcp-option DNS 208.67.220.220"
keepalive 10 120

Securite

user nobody
group nogroup
chroot /etc/openvpn/jail
persist-key
persist-tun
comp-lzo

Log

verb 3
mute 20
status openvpn-status.log
log-append /var/log/openvpn.log
push “explicit-exit-notify 3”

[/quote]
Explications :

push “redirect-gateway def1 bypass-dhcp” demande au client OpenVPN d’utiliser l’IP VPN du serveur comme étant la route par défaut.
C’est adapté si tu est dans une configuration “roadwarrior” ou si tu veux accéder au web malgré le pare-feu de ta fac/ton boulot/ton hôtel. Ce n’est pas adapté pour un lien entre deux serveurs : Le client veut juste pouvoir causer avec le serveur VPN au travers du VPN mais pas avec l’ensemble de l’internet au travers du VPN.
De même, je pense qu’il n’y a aucun intérêt à demander au client de changer sa configuration DNS. A priori, pour la communication entre les deux VPS, il n’y a même pas besoin de DNS (puisque l’on ne souhaite surfer au travers du VPN).

Note bien que les connexions au travers du VPN seront forcément initiées par le client VPN puisque le serveur VPN aura une IP connue et fixe, 10.8.0.1, alors que les clients VPN se retrouveront avec une IP prise au hasard entre 10.8.0.2 et 10.8.0.254 .

Quant au NAT/masquerade, il n’y en a pas du tout besoin si les clients VPN ne sortent pas sur Internet au travers du VPN. Si ton serveur hébergeait des machines virtuelles, tu pourrais en avoir besoin mais comme ton serveur est déjà une VM, ce sera un peu contre-productif.
Tu pourras donc vider complètement la chaîne POSTROUTING de la table nat avec la commande iptables -t nat -F POSTROUTING .

Et une fois que tu seras à l’aise avec la partie VPN, ne tardes pas trop à remettre un filtrage sur les connexions entrantes et sortantes de ton serveur.

–
AnonymousCoward

#12

Enfin, cela fonctionne :slightly_smiling:

j’ai modifié le serveur.conf comme tu me l’as dis, du coup j’ai changé aussi le client.conf.
voilà donc les fichiers de configurations qui fonctionnent (pour ceux qui rencontreraient le même problème)

serveur.conf:

Serveur UDP/1194

mode server
proto udp
port 1194
dev tun

Cles et certificats

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 1
key-direction 0
cipher AES-256-CBC

Reseau

server 10.8.0.0 255.255.255.0
#push “redirect-gateway def1 bypass-dhcp”
#push “dhcp-option DNS 208.67.222.222”
#push "dhcp-option DNS 208.67.220.220"
keepalive 10 120

Securite

user nobody
group nogroup
chroot /etc/openvpn/jail
persist-key
persist-tun
comp-lzo

Log

verb 3
mute 20
status openvpn-status.log
log-append /var/log/openvpn.log
push “explicit-exit-notify 3”

client.conf:

Client

client
dev tun
proto udp
remote IPSERVEUR 1194
resolv-retry infinite
cipher AES-256-CBC
; client-config-dir ccd

Cles

ca ca.crt
cert rick.crt
key rick.key
tls-auth ta.key 1
key-direction 1

Securite

nobind
persist-key
persist-tun
comp-lzo
verb 3

Merci beaucoup de votre aide :slightly_smiling:

Ricko !