Bonjour à tous,
J'ai récemment fait l’acquisition d'un raspberry pi 2 et j'ai donc installé un serveur openvpn sur celui-ci.
Je me connecte à celui-ci grâce à l'application cliente openvpn sur mon mobile android.
Si je configure ma connexion en mode tcp, que ce soit en wifi ou en 3g sur ma connexion freemobile (itinérance ou non) tout fonctionne parfaitement.
Par contre si je configure la connexion en mode udp, cela fonctionne parfaitement en wifi, mais le serveur ne réponds pas quand j'essaye en 3G.
J'ai investigué un peu le problème, à l'aide de l'application du Netalyzr celui-ci m'indique un problème de taille de paquet sur le réseau free/orange :
"The path between your network and our system supports an MTU of at least 1356 bytes, and the path between our system and your network has an MTU of 1444 bytes. The path MTU bottleneck that fails to properly report the ICMP "too big" is between XX.XXX.XXX.XXX and your host. The path between our system and your network does not appear to report properly when the sender needs to fragment traffic."
J'en déduis que la taille des paquets sur le réseau de free en udp est inférieur à la taille standard (1500) et est d'au moins 1356 mais plus petite que 1444.
Il faudrait donc pouvoir paramétrer celle-ci au niveau d'openvpn, il existe apparemment deux options "fragment" et "mssfix" ou encore "link-mtu" mais je n'arrive pas à quelque chose qui fonctionne après avoir lu pas mal de post et de doc sur openvpn et fait pas mal d'essais.
A priori une bonne solution serai d'utiliser "fragment" pour forcer les paquet trop gros a être fragmenter mais cette option n'est pas supporté aujourd'hui par le client android.
Pour mssfix ce n'est pas très clair non plus.
Quelqu'un a t'il réussit à configurer openvpn en mode upd sur une connexion free ? Si oui quelles options configurer ?
Le mode tcp fonctionne très bien mais est quand même moins performant que l'udp.
Merci !
Aworan
# Free
Posté par Axone . Évalué à 2.
J'ai lu ton journal avec intérêt, car il y a des similarités avec un cas que j'ai eu. Je voulais configurer un serveur OpenVPN situé sur une ligne Free ADSL. Je n'ai pas réussi, j'avais l'impression que les paquets n'arrivaient pas sur le serveur. J'avais essayé plusieurs choses, comme changer les ports, etc.
Mais je crois bien que je n'ai pas essayé de changer le protocole ou regarder le MTU. Merci pour cette piste qui mérite d'être explorée.
[^] # Re: Free
Posté par aworan78 . Évalué à 3.
Tout comme toi mon serveur openvpn est connecté sur une ligne free ADSL.
Par contre, mon problème ne se produit que si je me connecte via la connexion 3G freemobile, si je me connecte depuis un réseau wifi lambda je n'ai pas de soucis même en udp.
A partir de quel connexion (wifi ?, 3g ?) as tu essayer de te connecter ?
Pour info, j'ai suivi le tuto suivant : http://open-freax.fr/monter-vpn-openvpn/
C'est un tuto pour rapsberry pi mais ça reste une debian derrière donc valable pour tout système linux.
Peux être as tu simplement oublié d'activer le "packet forwarding for IPv4" ?
[^] # Re: Free
Posté par Axone . Évalué à 2.
J'ai lancé le client depuis une connexion style cable Numéricable (Dartybox pour être précis), et donc le serveur sur une connexion ADSL Free. Le serveur n'a jamais reçu les paquets.
L'inverse a fonctionné immédiatement avec les mêmes réglages OpenVPN. Et c'est pas faute d'avoir vérifier et revérifier la configuration des routeurs/modems et autre choses dans le genre…
Faudra donc que je reteste avec le protocole TCP et avec des réglages de MTU.
# mssfix
Posté par Florent . Évalué à 4.
J'ai presque la même config que toi, j'utilise OpenVPN en UDP sur le réseau Free Mobile depuis mon linux en partage de connexion.
J'ai eu aussi pas mal de problèmes à le faire fonctionner, et j'en suis arrivé à la conclusion que c'est la découverte du MTU qui pose problème et donc OpenVPN envoi des paquets trop gros pour le réseau, qui les DROP tout simplement.
Donc il faut que tu ajoutes "mssfix 1300" à ta conf client, ainsi OpenVPN va indiquer aux connexions TCP dans le tunnel de limiter la taille des paquets pour que les paquets UDP envoyés par OpenVPN ne dépassent pas 1300 bytes.
Ainsi les protocoles TCP devraient fonctionner sans problème.
Pour faire passer de l'UDP dans le tunnel (VOIP…), il faut jouer avec "fragment" mais attention l'option est violente (cf. man openvpn). Je ne l'ai pas mis en place sur ma config, principalement car il faut aussi mettre "fragment" dans la conf serveur aussi et donc je crois que cela s'applique à tous les clients, et que j'utilise pas de protocole UDP dans le tunnel…
J'en profite pour parler du keepalive avec un openvpn en 3G : quand on change d'antenne, l'IP change, comment OpenVPN gère ça ?
Il me semble qu'il "reload" après un timeout lié au keepalive ?
Bref, j'espère que cela t'aide.
"A computer is like air conditioning – it becomes useless when you open Windows", Linus Torvalds
[^] # Re: mssfix
Posté par Kerro . Évalué à 4.
Si tu es en TCP, la connexion est bien entendu coupée. Le client OpenVPN relance alors une nouvelle connexion.
Si tu es en UDP, suivant une option du serveur (je ne sais plus laquelle, je crois que c'est --float, et je crois que c'est par défaut, qui permet aux paquets de provenir de n'importe quelle adresse. De toutes manières ils sont chiffrés/signés) la connexion reste en place sans broncher. Au pire ça coupe, et le client se reconnecte.
[^] # Re: mssfix
Posté par Florent . Évalué à 2.
Merci pour l'explication.
A priori le fonctionnement de --float avec TLS est assez récent, en tout cas c'est une option bien pratique.
"A computer is like air conditioning – it becomes useless when you open Windows", Linus Torvalds
[^] # Re: mssfix
Posté par aworan78 . Évalué à 2. Dernière modification le 03 mars 2015 à 10:50.
Je n'ai pas encore testé car je crois que l'option est mssfix est mal implémentée dans le client android mais je vais tester avec mon pc portable et le mobile en partage de connexion ce soir.
Je te tiens au courant du résultat !
Merci en tout cas !
[^] # Re: mssfix
Posté par aworan78 . Évalué à 3.
Salut,
J'ai testé avec mssfix 1300 au niveau du client et ça fonctionne parfaitement !
Un grand merci à toi !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.