Forum Linux.général Tunnels OpenVPN - remplacement par solution plus robuste

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
5
16
jan.
2013

Hello,

Pour des besoins personnels, j'ai mis en place un réseau privé virtuel entre ces différents sites :
- mon serveur dédié OVH (172.16.0.0/24, 172.17.0.0/24, 172.18.0.0/24)
- mon réseau local personnel (192.168.1.0/24, 192.168.4.0/24)
- le réseau local de mes parents (192.168.2.0/24)
- le réseau local d'un pote (192.168.24.0/24)

Actuellement, tout fonctionne avec OpenVPN : le serveur est installé sur mon serveur dédié (Kimsufi 16G). Chaque site se connecte donc à ce serveur, qui fait du coup aussi office de routeur.

Techniquement, ça fonctionne, chaque site arrive à joindre un autre site de façon transparente, sans problème. Le problème que j'ai par contre, est que pour un échange de données entre mon réseau local et mon serveur via le VPN est très lent, bien que je possède la fibre optique. Dans les faits, ma connexion réelle est hors VPN 90M DL / 60M UL. Le serveur dédié possède une connexion 100M / 100M. Lorsque je transfère un fichier (via FTP) entre mon serveur dédié et chez moi, les débits ne dépassent pas les 3 Mo/s ce qui équivaut donc à environ 24M. Pendant le transfert j'observe chaque élément pour voir où se situe le problème et aucune des machines ne semblent saturer (je pensais surtout à un CPU fortement utilisé qui freinait l'encapsulation/chiffrement).

Concernant la configuration du lien VPN, je suis en UDP avec un adaptateur TAP. Après avoir essayé les valeurs par défaut, j'ai tenté d'ajouter ces paramètres pour voir si ça améliorait (sur le serveur et sur le client de mon réseau local) :
- tun-mtu 6000
- fragment 0
- mssfix 0

Quelqu'un aurait-il une idée ? Une de mes autres idées serait de remplacer cette partie par un IPSec qui semble un peu plus robuste (puisque à mon avis plus utilisé en entreprise du au fait qu'il soit plus implémenté dans du matériel propriétaire (Cisco par exemple)).

Concernant IPSec, je ne connais pas trop, je sais qu'il possède deux modes : transport et tunnel. Le transport d'après ce que j'ai compris ne sert uniquement à protéger une connexion au sein d'un même réseau (pour protéger un réseau wifi par exemple), tandis que le mode tunnel serait ce dont j'ai besoin.

Si j'ai bien compris, la solution IPSec ne serait pas transparente pour mes clients, puisque chaque client serait relié aux autres (plus de serveur central qui fait tout). Est-ce que ce que j'annonce est correct ou est-ce que j'ai mal compris ?

Merci d'avance pour vos réponses.

  • # UDP ?

    Posté par  (site web personnel) . Évalué à 2.

    Je ne sais pas comment marche OpenVPN, mais il me semble que l'UDP sur du WAN peut etre une mauvaise idee :

    • des paquets perdus dans tous les sens (tu contrôles beaucoup moins bien que sur du LAN)
    • de la fragmentation de folie (surtout si tu mets ton MTU a 6000)

    Des francophones de chez Gentoo se sont déjà pose la question. Je commencerais a voir de ce cote la si j’étais toi.

    • [^] # Re: UDP ?

      Posté par  . Évalué à 3.

      Je reste dubitatif, il n'y a aucun raison d'avoir un controle d'integrité à ce niveau, et à mon avis, rien ne peut le justifier. Donc pour moi le VPN c'est en UDP sauf exceptions (comme passer un pare-feu à la con qui ne laisse passer que tcp {80,443}).

      Par contre, as-tu une raison précise de faire du VPN au niveau de la couche transport (couche 2), et non au niveau de la couche réseau (couche 3). Tu peux en avoir, comme faire un VPN dual-stack IP-legacy et IP-v6, mais ça rajoute de l'overhead supplémentaire. À ta place je testerai d'abort avec tun au lieu de tap.

      • [^] # Re: UDP ?

        Posté par  (site web personnel) . Évalué à 1.

        Tout à fait, le contrôle d'intégrité est fait par les connexions à l'intérieur du tunnel, du coup, le faire deux fois n'est pas nécessaire.

        Par contre, comme je le disais dans une autre réponse, je me suis trompé en expliquant mon problème, puisque OVH bride les connexions UDP, j'étais déjà passé en TCP

      • [^] # Re: UDP ?

        Posté par  (site web personnel) . Évalué à 1.

        J'avoue que je n'ai jamais vraiment compris quand est-ce qu'il fallait utiliser tun ou tap. Dans mon cas, avec un serveur central + 3 clients, est-ce que c'est toujours possible de faire du tun ? Concernant l'architecture finale, qu'est ce qui change ?

        • [^] # Re: UDP ?

          Posté par  . Évalué à 1.

          La question que je pose est la suivante : Veux tu faire passer autre chose que de l'IPv4 (genre IPv6) dans ton tunnel ?

          Si la réponse est

          • non : tu as le choix entre tap et tun sachant qu'il y a plus d'overhead avec tap, donc tun est préferable ;
          • oui : tu dois choisir tap.

          • [^] # Re: UDP ?

            Posté par  (site web personnel) . Évalué à 1.

            Donc, dans mon cas, pour le moment, tun (je pense que si je passe tout en ipv6, je ne m'embêterai pas avec du VPN, mais du firewall).

            Je vais voir dans la doc openvpn si la transition est aussi simple que ça, de mémoire, le tun est uniquement en point à point, du coup ça impliquerait (d'après ce que je me souviens) à une instance par client.

            En espérant me tromper.. :p

            • [^] # Re: UDP ?

              Posté par  . Évalué à 2.

              du coup ça impliquerait (d'après ce que je me souviens) à une instance par client

              Faudra que j'en parle à mon instance openvpn.

              Serieusement, ça marche très bien avec une instance sur le serveur et n clients, avec n>1.

              • [^] # Re: UDP ?

                Posté par  (site web personnel) . Évalué à 1.

                Ok, je le précisais, c'était d'après mes souvenirs, j'espérais me tromper, apparemment, heureusement c'était le cas.

                Par contre, en regardant rapidement sur le net, à priori, c'est moins évident pour du routage entre plusieurs réseaux.

                Est-ce qu'il sera toujours possible de router tous les réseaux entre eux avec du tun ? Si on regarde mon premier post, on peut noter que des sites possèdent plusieurs réseaux qui doivent tous être routés entre eux. Qu'est ce que ça change côté architecture ? Pour le moment, des routes sont poussées à chaque client VPN qui indique comment joindre chaque réseau :
                - le tunnel openvpn fourni un réseau 172.16.0.0/24, chaque client a donc une IP sur ce réseau
                - pour chaque client (via ccd) j'indique comment joindre les réseaux qu'il ne connait pas : pour le réseau 192.168.1.0/24 tu passes par 172.16.0.2, pour le réseau 192.168.24.0/24 tu passes par 172.16.0.3, etc…

                En passant par tun, ce système peut-il encore fonctionner ?

                • [^] # Re: UDP ?

                  Posté par  . Évalué à 1.

                  En passant par tun, ce système peut-il encore fonctionner ?

                  Tout à fait. Et niveau config, ne connaissant pas ta config exacte, les modifications à apporter me semblent mineure (même si au final ça change le niveau auquel est fait le tunnel, donc des modifications importantes).

                  • [^] # Re: UDP ?

                    Posté par  . Évalué à 2.

                    Et niveau config, ne connaissant pas ta config exacte, les modifications à apporter me semblent mineure

                    ca change l'interface sur laquelle est créée le VPN
                    /dev/tap0 devient /dev/tun0

                    il faut alors adapter les regles du parefeu et le forwarding entre les interfaces.
                    mais ca peut se scripter :

                    root@machine : ~ # iptables-save >lefichier
root@machine : ~ # sed -i 's/tap0/tun0/g' lefichier
root@machine : ~ # iptables-restore <lefichier

                    • [^] # Re: UDP ?

                      Posté par  (site web personnel) . Évalué à 0.

                      Ouep, ça les changements d'interface je m'en doutais un peu xD

                      Hm, je vais faire le test entre 2 VM :
                      - transfert d'un fichier aléatoire de 700M en utilisant leur réseau classique
                      - transfert d'un fichier aléatoire de 700M en utilisant une liaison OpenVPN tap (2 tests : tcp et udp)
                      - transfert d'un fichier aléatoire de 700M en utilisant une liaison OpenVPN tun (2 tests : tcp et udp)

                      Si j'ai encore la motivation, j'essaierai de faire un test avec IPSec

                      J'ai déjà fait le premier test, j'obtiens un débit de 19 Mo/s environ, ça servira de base de départ

                      Je posterai les résultats si ça vous intéresse

                      • [^] # Re: UDP ?

                        Posté par  . Évalué à 2.

                        Les conditions de ton protocole experimental me semblent trop otimistes.

                        En vrac :

                        • Débit tellement important que ça risque de rendre le chiffrement limitant en vitesse, pas forcement représentatif du cas réel
                        • Pas de pertes de paquets
                        • Ping très faible, donc la latence introduite en faisant passer sur du TCP ne va pas être représentative

                        Bref, pour moi, avec ce protocole de mesure, tu va obtenir des différences qui seront faibles, mais en plus pas significative des différences observés lors d'un déploiement réel.

                        • [^] # Re: UDP ?

                          Posté par  (site web personnel) . Évalué à 0.

                          C'est possible oui. Déjà dans un premier temps, j'ai limité la bande passante du transfert à 100M, puisque avec SCP sinon, c'était mes VM qui limitaient à cause du CPU.

                          Je vais quand même cette série de tests histoire de voir si quelque chose est déjà mis en évidence. Ensuite concernant le test réel, je pourrai voir quel outil je peux utiliser pour "perturber" la connexion. Je sais qu'un outil existant pour ajouter de la latence et simuler des pertes de paquets.

                          Sinon, entre chez moi et mon serveur dédié, je viens de regarder, j'ai environ 5-6 ms de latence pour le ping, ce qui me semble tout à fait raisonnable.

                          Pour résumer, une première série de tests en "conditions optimale" mais avec un débit similaire (100M) afin de voir si des éléments de configuration ont un impact. Dans un second temps, la même série de test mais avec un outil qui perturbe la liaison.

                          Je ne sais pas si au final ça amènera une solution, mais bon qui ne tente rien a rien :D

  • # Étape par étape

    Posté par  . Évalué à 2.

    Question con, mais tu as testé le débit chez toi <> ovh sans le vpn ?

    • [^] # Re: Étape par étape

      Posté par  . Évalué à 2.

      je crois pouvoir affirmer qu'il la fait

      Dans les faits, ma connexion réelle est hors VPN 90M DL / 60M UL

      • [^] # Re: Étape par étape

        Posté par  (site web personnel) . Évalué à 1.

        Tout à fait, en dehors du VPN, j'atteins environ les 9-10 Mo/s en SCP

        • [^] # Re: Étape par étape

          Posté par  . Évalué à 2.

          ca pourrait meme aller plus vite en pur FTP
          car SCP passe par SSH qui encrypte aussi le flux…

          • [^] # Re: Étape par étape

            Posté par  (site web personnel) . Évalué à 2.

            Ouép je sais bien, c'est pour ça que je disais que même en SCP j'atteignais des débits corrects.

            Pour info, j'ai tenté y a quelques jours de désactiver l'encryption OpenVPN afin de voir si ça arrangeait les choses, ce qui n'est malheureusement pas le cas… ^

  • # UDP bridé

    Posté par  . Évalué à 3.

    L'UDP est bridé en débit chez OVH.
    Passe ton VPN en TCP et tout ira bien. On perds un poil en perf théoriquement, mais ça ne se voit pas à la mesure.
    Utilisé pendant des années sur plus de 60 sites sans jamais aucun soucis.

    • [^] # Re: UDP bridé

      Posté par  (site web personnel) . Évalué à 1.

      Salut, j'ai écrit l'article un peu vite tout à l'heure… En fait, je m'étais déjà rendu compte du bridage UDP et mon VPN est donc bien dores et déjà en TCP… Désolé pour l'information erronée… !

    • [^] # Re: UDPbridé

      Posté par  (site web personnel) . Évalué à 3.

      L'UDP est bridé en débit chez OVH.

      Pourquoi ?

      • [^] # Re: UDPbridé

        Posté par  . Évalué à 2.

        Leur ligne chaude ne sait pas dire pourqoi.
        Donc je ne sais pas.

  • # tcp-queue-limit

    Posté par  (site web personnel) . Évalué à 1.

    Yop,

    J'ai un peu avancé sur le problème. Il se trouve qu'en passant le verbose a 4, je voyais que des paquets étaient jetés par OpenVPN. J'ai donc augmenté la valeur du paramètre tcp-queue-limit (de 64 à 256).

    Maintenant, les paquets sont jetés au niveau de l'interface tap. Je suis donc en train de voir si je peux pas augmenter la valeur à ce niveau également.

    Le débit est passé de 2Mo/s à 6Mo/s pour l'instant… (même débit en FTP et SCP)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.