Problème de déconnexion de tunnel OpenVPN

Support Debian
#1

Salut à tous les linuxiens,

Après avoir monté un tunnel à l’aide d’OpenVPN entre deux Debian (version 2.6.18-4-686), j’ai constaté des coupures.
Mais avant de vous en dire plus au sujet de ces désagréments, je vais commencer par vous détailler un peu plus la configuration du tout mon petit bazar. :smt003

D’un coté, un serveur OpenVPN ayant accès à Internet.
De l’autre, un client OpenVPN, avec une ribambelle de postes qui doivent avec accès à Internet (disons une 50ène).

La connexion se passe bien le tunnel fonctionne très bien, les interfaces tun sont montées, les postes ont accès à Internet, ect.
Puis soudain! (quelques heures plus tard) PAF! Plus rien ne fonctionne. Les ping ne passent plus, les postes n’ont plus Internet. Pourtant les interfaces tun sont toujours présente, d’un coté comme de l’autre…
Il faut alors relancé le client pour que la connexion revienne.

Voici la configuration du serveur OpenVPN:

====================================================================

#Fichier de configuration de OpenVPN partie SERVEUR

#-----------------------paramètres de connexion---------------------#
port 8000
proto udp
dev tun
server 192.158.151.0 255.255.255.0
ifconfig-pool-persist ipp.txt
max-clients 4

#----------------------Redirection des clients----------------------#
client-config-dir /etc/openvpn/ccd/
route 172.15.0.0 255.255.0.0
client-to-client push “route 172.15.0.0 255.255.0.0”

#----------------------options de persistance-----------------------#
persist-tun
persist-key

#-------------------------compression-------------------------------#
comp-lzo

#------------------------clés & certificats-------------------------#
ca /usr/share/doc/openvpn/examples/easy-rsa/keys/ca.crt
cert /usr/share/doc/openvpn/examples/easy-rsa/keys/serveur.crt
key /usr/share/doc/openvpn/examples/easy-rsa/keys/serveur.key

#--------------------paramètres Diffie-Hellman----------------------#
dh /usr/share/doc/openvpn/examples/easy-rsa/keys/dh1024.pem

#------------------vérification de la connexion---------------------#
keepalive 10 120

#---------------------connexion en cours----------------------------#
status openvpn-status.log

#-----------------------niveau de log-------------------------------#
verb 3

=====================================================================

Et celui du client OpenVPN:

=====================================================================

#Fichier de configuration de OpenVPN partie CLIENT

#-----------------------paramètres de connexion---------------------#
client
proto udp
dev tun
remote 192.158.0.9 8000
resolv-retry 25
pull
nobind

#----------------------options de persistance-----------------------#
persist-tun
persist-key

#-------------------------compression-------------------------------#
comp-lzo

#------------------------clés & certificats-------------------------#
ca /usr/share/doc/openvpn/examples/easy-rsa/keys/client/ca.crt
cert /usr/share/doc/openvpn/examples/easy-rsa/keys/client/client.crt
key /usr/share/doc/openvpn/examples/easy-rsa/keys/client/client.key

#------------------vérification de la connexion---------------------#
ping 20
ping-exit 40

#-----------------------niveau de log-------------------------------#
verb 0

Quelqu’un a t-il une idée sur ce qui cloche?
Personnellement je ne pense pas que ça puisse venir d’OpenVPN, mais j’ai peut-être tort! :stuck_out_tongue:
Je suis bien sur “over” disponible si vous voulez plus d’informations concernant une conf.

Merci d’avance pour voter aide :smt006

#2

Y-a-t-il du traffic en permanence??

#3

Bonsoir,

La seule différence que je vois avec mes fichiers de config, est :

Le -> ping 15 est fait coté serveur.

Peut être ça ?

Sinon, tu utilises les clés offertes par OpenVPN !!! Pas sur que ce soit une bonne idée …

Un petit lien utile pour la création d’un certificat CA et des clés clientes :

http://zepala.free.fr/?q=node/49

#4

Bonjour,

Pour répondre à fran.b, il y a du trafic en permanence.

Pour les clés offertes par OpenVPN, ne t’inquiète pas NooP le réseau est déjà bien sécurisé. Je sais qu’un administrateur réseaux se doit d’être paranoïaque, mais là en l’occurence aucuns risques :smt002

Pour le ping 15, l’option keepalive le remplace!
Merci pour votre aide, et si vous avez d’autres idées, lachez vous :mrgreen:

#5

Bonjour,

Tu peux toujours augmenter la verbosité :

[code]# Verbosity level.

0 – quiet except for fatal errors.

1 – mostly quiet, but display non-fatal network errors.

3 – medium output, good for normal operation.

9 – verbose, good for troubleshooting

verb 3[/code]

Et regarder les logs. Tu auras plus d’informations sur ce qui se passe réellement.

#6

Bonne idée, pendant mes tests ils étaient tout deux à 3 mais réduit à 0 pour le client pour le déploiement (raisons pratiques).
Et dire que je n’y avais même pas pensé! :open_mouth:
Merci de m’ouvrir les yeux NooP :astonished:

#7

Bon j’ai testé cette nuit en changeant les paramètres suivant:

Serveur:
tun-mtu 1500
fragment 1300
mssfix

Client:
tun-mtu 1500
fragment 1300
mssfix
persist-remote-ip

J’ai réglé la fragmentation des paquets udp à 1300 pour une plus grande fiabilité de réseau.
Le persist-remote-ip sert a garder la dernière IP de connexion ainsi que le port.
Suppression des ping et ping-restart puisque le serveur “push” le keepalive.

Apparemment ça fonctionne, mais j’ai l’impression que les certificats sont revérifiés toutes les heures. Il y a eu plusieurs déconnexions pendant la nuit mais le keepalive à fait son travail.
Cependant il n’y avait que quelques personnes de brancher dessus. Je vais augmenter le nombre au fur et à mesure et je vous tiens au courant de l’évolution des choses.

#8

Deux questions: Y-a-t-il une passerelle entre le serveur VPN et l’extérieur? et as tu essayé en tcp?

#9

Il y a bien une passerelle entre le serveur OpenVPN et Internet.
Je n’ai pas essayé en TCP car (reprends moi si je me trompe :wink: ) d’après ce que je sais c’est beaucoup plus lent.
Or les personnes doivent pouvoir bénéficier d’Internet sans ce problème de lenteur.

Pour le moment la connexion n’a toujours pas coupé, tout fonctionne parfaitement bien.

#10

Je pensais à ça car j’ai remarqué que les connexions udp avait une durée de vie très courte dans netfilter. Mais ça doit surtout jouer du coté client, du coté serveur, il y a une redirection statique donc permanente. Sinon, il ne faut pas exagérer la perte du au passage en tcp même si elle est indéniable.

#11

J’exagère un peu c’est vrai mais étant donné le contexte (que je n’ai pas précisé par ailleurs), le moindre gain est très appréciable car le client et le serveur sont reliés par plusieurs liens radio. Donc la connexion n’est pas comparable avec du filaire pour ce qui est du débit et des possibilités de pertes!

#12

Tu veux dire qu’il y a pas mal de pertes?? Dans ce cas, une connexion tcp devrait régulariser considérablement les choses et peut être même améliorer le débit… (Sur ce point, il faudrait que Pascal (Hambourg) ou Matt viennent confirmer car je dis peut être une anerie mais je ne crois pas, UDP est très bien pour une connexion solide mais ça se dégrade très vite (attente longue de paquets) si la connexion est pourrie).

#13

Non, la connexion est bonne mais elle a beaucoup plus de chance de subir des perturbations qu’une ligne filaire.
L’avantage ici, c’est de pouvoir contrôler la taille des paquets UDP. En effet, plus ils sont plus petits, mois il y aura de pertes de données si la ligne est perturbée.
Quoi que, je crois que ce n’est pas spécifique pour l’UDP, puisque c’est une unité de transfert…
Merci pour cet avis constructif fran.b, je vais approfondir la question. :smt002

Pour infos, la connexion a tenu toute la nuit.