hello,
je possède une connexion fibre à la maison, et j'ai un tunnel VPN entre mon domicile et un serveur que je loue chez OVH.
Le tunnel VPN est configuré de telle manière :
- openvpn 2.2.2 (sur CentOS 6.3, des deux côtés)
- tap sur udp
- compression LZO
- pas de configuration spécifique pour le chiffrement de la connexion, donc blowfish je crois, par défaut
- l'authentification est effectuée par certificats et clé TLS
Côté matos, le serveur VPN (chez OVH) est un Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz avec 16 Go de RAM et le client est un AMD Turion(tm) II Neo N40L Dual-Core Processor avec 8 Go de RAM (ce sont à mon avis les caractéristiques les plus significatives pour ce genre de besoin).
Ma connexion fibre est une connexion 100M en DL et 50M en UL. J'ai un graphique actualisé qui révèle qu'en fait les débits réels sont plutôt 95M / 62M (cf http://www.grenouille.com/graph/index.php?zone=394183&type=download&day=2012-10-12&month=2012-10-01).
J'ai donc décidé de faire un iperf entre mon serveur local et mon serveur OVH. Dans le sens OVH -> chez moi à travers le VPN : 0.0-10.0 sec 115 MBytes 11.5 MBytes/sec
cette métrique est très bonne, je n'ai presque pas de perte en passant par le VPN
J'ai quand même voulu tester le retour, et c'est là que les problèmes ont commencé : 0.0-10.1 sec 17.9 MBytes 1.77 MBytes/sec
Même si ce débit est honorable, c'est quand même environ 5 fois moins de ce qui est techniquement possible…
Par acquis de conscience, j'ai effectué le même test sans passer par le VPN, et là, j'ai bien le bon débit :0.0-10.0 sec 63.4 MBytes 6.32 MBytes/sec
Côté CPU, le serveur OVH ne dépasse pas les 10% sur le process OpenVPN, côté proliant (chez moi), le processus monte à 50% lorsque je fais le test de download (ovh vers chez moi) et 20% quand je fais la voie de retour…
Quelqu'un a déjà eu ce genre de problème ?
# MTU?
Posté par lay . Évalué à 6. Dernière modification le 12 octobre 2012 à 17:18.
Bonjour,
Pour avoir un début de piste, essayes de regarder avec tcpdump sur le tunnel pour voir si la connexion TCP à travers le VPN a bonne allure et n'a pas de fragmentation.
Si il y a de la fragmentation, regardes du coté des réglages mtu, fragment ou mssfix dans le manuel d'openvpn, un mauvais réglage peut entrainer des problèmes du genre :)
# TunTap
Posté par maxix . Évalué à 1.
Et en tun, tu a le même problème?
# UDP
Posté par Kerro . Évalué à 2. Dernière modification le 13 octobre 2012 à 14:52.
OVH limite sévèrement le débit UDP. Si quelqu'un sait pourquoi, je suis intéressé.
Passe en TCP et tu seras plein pot.
C'est moins top, mais ça fonctionne très bien. J'ai fait tourner plus de 60 tunnels simultanés pendant des années de cette manière (60 x ADSL --> OVH) sans jamais avoir un seul pépin.
Demande éventuellement à leur ligne chaude, ils t'indiqueront peut-être quelques ports UDP non filtrés.
[^] # Re: UDP
Posté par Thomas Bétrancourt (site web personnel) . Évalué à 0.
On a eu la même idée, et effectivement, je suis passé en TCP ce weekend, et c'est un peu mieux.
Dommage de la part d'OVH
[^] # Re: UDP
Posté par Kerro . Évalué à 2. Dernière modification le 14 octobre 2012 à 20:29.
Un peu mieux, donc tu n'as pas le débit plein pot ?
Ha, je n'avais pas fait attention : tu utilises TAP. Donc un pont. Donc tu as peut-être du débit non désiré qui passe. tcpdump t'en dira plus. Ou htop (je ne sais plus si on voit l'UDP avec htop).
[^] # Re: UDP
Posté par Thomas Bétrancourt (site web personnel) . Évalué à 0.
Si si c'est mieux, disons que j'ai un débit de 6-7 Mo/s, donc à peu de choses près mon débit réel hors VPN.
J'avais tenté de faire des tests avec iperf en UDP mais bon, le comportement d'iperf est très différent en UDP, car il faut définir une bande passante max et tout, je trouve ça moins clair.
Quoiqu'il en soit, avec une connexion TAP en TCP c'est mieux (résolu).
Me reste juste à régler mes problèmes NFS et j'suis bon ^
Merci pour l'info, même si on a eu l'idée en même temps, mais au moins ça confirme mes investigations… :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.