Question Comment améliorer la fiabilité OpenVPN sur un lien à latence élevée?


Nous exécutons un VPN OpenVPN sur une liaison satellite BGAN où les temps de ping sont d’environ 3 secondes. Nous l'utilisons dans un tonneau configuration, et nous fonctionnons sous Linux (CentOS). C'est principalement le courrier électronique qui sera envoyé via le lien, mais dès que le courrier contient des pièces jointes volumineuses, le VPN semble caler.

le "Je peux faire un ping à travers le tunnel, mais tout travail réel provoque son verrouillage. Est-ce un problème de MTU?" question dans la FAQ OpenVPN semble décrire mon problème exactement, mais en utilisant mssfix et fragment ne semble toujours pas faire grand chose pour améliorer la situation.

Mon principal test consiste à copier un fichier de 2 Mo sur le VPN avec scp. Il va copier environ 192ko, puis signaler un - en panne - Etat. Si j'attends quelques secondes, la copie reprendra, puis s'arrête après quelques kilo-octets de plus.

Ce blocage se produit que je mette ou non la fragment ou mssfix options dans ma configuration OpenVPN (bien que fragment 1000 semble avoir réduit le décrochage, sans toutefois l’éliminer). L'OpenVPN mtu-test a signalé 1542 comme taille de MTU.

J'ai cherché sur Internet pour plus de conseils sur comment et quand utiliser mssfix et fragment, mais je ne trouve que les pages qui disent la même chose que la FAQ et ne donnent pas de détails sur comment et quand utiliser quels paramètres.

Mes questions sont alors:

  • Quand dois-je utiliser mssfix et fragment?
  • Est-ce que j'utilise mssfix et fragment en combinaison?
  • Si mssfix et fragment sont la solution, quels sont les tun-mtu, link-mtu et mtu-disc paramètres pour?

De plus, j'ai utilisé l'outil iperf pour mesurer la bande passante. Sans le VPN, il mesure en permanence de l'ordre de 210 Kbits / s.

Lors de l'utilisation iperf sur le VPN ($ iperf -c remoteserver -t60 -i5), il commencerait à 10 Kbits / s, puis remonterait progressivement jusqu’à signaler 1,2 Mbits / s, puis il semblerait s’arrêter, où il indique 0 Kbits / s pour un certain nombre d’itérations (je pense que le 1,2 Mbits / s peut être à cause de certains tampons OpenVPN ou autres)

Est iperf le meilleur moyen de mesurer la bande passante?

Toute aide dans cette situation sera grandement appréciée.


11
2017-11-25 14:06


origine


Est-ce que l'openvpn utilise TCP ou UDP en ce moment? - pjc50
Il utilise actuellement UDP - iWerner
Merci pour toutes les réponses, mais j'ai dû m'arrêter temporairement car l'unité BGAN était à court de temps d'antenne. J'espère pouvoir continuer plus tard aujourd'hui. Je devrais mentionner que nous préférerions rester avec UDP, car utiliser TCP doublerait les données envoyées sur le réseau (et donc le coût, pour lequel notre client est déjà très sensible) - iWerner


Réponses:


1542 en tant que MTU? Jamais entendu parler de cela pour un lien WAN. En général, la MTU est la charge utile maximale, la taille du paquet IP moins l'en-tête pour IP (20 octets) et ICMP (8 octets). Cela signifie que MTU = 1500 pour un réseau local Ethernet traditionnel. De plus, la plupart des VPN introduisent une surcharge pour leur encapsulation de paquets. Un MTU VPN typique est 1400.

Dans les réseaux modernes, il est difficile de déterminer quel sera le MTU à un moment donné, car les voies d'entrée et de sortie peuvent être différentes et peuvent également changer en raison du réacheminement automatique du chemin. Pour un réseau de ce type, il peut s'avérer plus efficace de définir une valeur MTU basse sur vos hôtes situés de part et d'autre du lien VPN, tels que 576.

MSS (taille de segment maximale) est MTU moins les en-têtes IP + TCP (40 octets). Cela est généralement négocié par la pile réseau et ne pose généralement pas les mêmes problèmes de négociation que MTU, à moins que MTU ne soit incorrect. (La négociation MTU est généralement altérée par les routeurs ICMP ou Black Hole bloqués).

La première chose à faire est de capturer les paquets réseau et de trier l’affichage en fonction de la taille de la trame (vous devrez peut-être ajouter cette colonne dans Wireshark). Vous devez vérifier que vous n'envoyez pas de cadres surdimensionnés, comme vous le souhaiteriez. Il n’est pas inhabituel que les cartes réseau modernes envoient des trames surdimensionnées si des options telles que Large Send Offload ou Jumbo Frames sont activées. J'ai vu plus de 30 000 octets lorsque ces options sont activées.


5
2017-11-25 14:58



+1 pour la capture de paquets avant de changer quoi que ce soit. même si vous ne trouvez pas un cadre énorme, vous pouvez voir des paquets «normaux» fragmentés quelque part. - Javier
Par défaut, OpenVPN définit le MTU du périphérique tun sur 1500 (ce qui correspond au MTU des périphériques Ethernet de nos machines). Je ne sais toujours pas si la fragmentation des paquets VPN est une bonne ou une mauvaise chose. Les réponses dans ce fil semblent impliquer que c'est mauvais, alors que les autres références que j'ai trouvées sur le web impliquent que c'est bon. - iWerner
@iwerner: avez-vous essayé de déterminer la taille du MTU avec ping? Si ICMP n'est pas désactivé, vous pouvez utiliser les éléments suivants sous Windows: ping -f -l 1372 <adresse IP de destination>. Continuez à réduire le nombre jusqu'à ce qu'il réussisse. Sur linux, ping -s 1372 -M fait <ip de destination>. Pour votre information, la FAQ OpenVPN recommande d’utiliser mssfix 1200, mais cela ne règle pas la cause première. L'utilisation de solutions VPN pour fragmenter peut toujours nuire aux performances. Si vous avez une configuration VPN importante, vous ne pourrez pas utiliser la fragmentation du côté du concentrateur central, mais uniquement du côté du bureau distant. - Greg Askew


Juste par curiosité, avez-vous essayé d'abaisser le MTU de l'interface réseau? Peut-être que la liaison par satellite bousille la fragmentation. En guise de remarque contre-intuitive, vous pouvez essayer openvpn over TCP pour changer. Je sais que cela devrait diminuer les performances, mais si vous n’avez aucun contrôle sur la fragmentation le long de la ligne, cela pourrait vous aider.


2
2017-11-25 14:18



J'allais suggérer le contraire :) - ce cas de latence élevée est celui dans lequel les problèmes de TCP-in-TCP apparaissent et qu'UDP évitera. - pjc50
Je supposais qu'il utilisait le port UDP par défaut pour openvpn, et donc suggéré le contraire ... oui, normalement, je suis d'accord avec vous. Mais bon, nous savons tous que sysadmin est un essai-et-erreur, et généralement "essayer-faire-le-contraire-voir-si-ça-marche" :) - lorenzog
Merci. Nous utilisons UDP en ce moment, et essayer de TCP ne m'est jamais arrivé. (Si j'avais plus de représentant, je vous aurais voté) - iWerner
@ iWerner: merci :) essayez également de réduire progressivement MTU sur l'iface et voyez quand il s'arrête (le cas échéant). - lorenzog


Lorsque vous utilisez TCP, augmentez la taille de la fenêtre de TCP; cela aidera avec le "nombre de paquets en l'air".

Cela fait longtemps que je n'ai pas eu à jouer avec ce genre de choses, mais en voici un lien google trouvé pour moi.

Après avoir relu votre question, je vois que vous exécutez BGAN - Je jetterais un coup d'œil à ce (ou simplement sur Google pour: "BGAN spoofing").

Pour ce qui est de la mesure de la bande passante, j’ai trouvé iperf assez décent tant que vous utilisez des tailles de paquet raisonnables.


2
2017-11-25 15:25



Ceci est intéressant - il est mentionné que l'accélérateur TCP est disponible pour Redhat, alors que les interlocuteurs inmarsat avec lesquels nous nous sommes entretenus ont déclaré qu'il n'était disponible que pour Windows et OS X (c'est d'ailleurs ce que dit le site Web Inmarsat / BGAN). - iWerner
Ils peuvent ne pas l'avoir maintenant; Je vois que la date du document est 07. Si vous poussez assez fort et parlez à assez de gens; vous pourriez trouver quelqu'un avec une ancienne copie de celui-ci. Généralement, lorsque vous appelez, vous bénéficiez d'une assistance de premier niveau. Je vais essayer certains de mes contacts mais aucune garantie. - Eddy
Je suis passé par notre fournisseur de satellite. difficile de trouver quelqu'un qui sait de quoi ils parlent. Je vais continuer d'essayer, en attendant voici quelque chose à essayer: sourceforge.net/projects/pepsal D'après la description du projet, le logiciel Inmarsat fonctionne à peu près comme suit: PEPsal est un proxy TCP transparent d'amélioration des performances multicouche intégré qui scinde la connexion en deux parties, en utilisant les améliorations apportées à Linux TCP lors de l'envoi de données. amélioration des performances dans des liens aux caractéristiques différentes - Eddy


Je pense que vous pourriez aboyer au mauvais arbre. À chaque fois que j'ai des problèmes de MTU, le trafic est arrêté bien avant 192 Ko. Je pense que cela est davantage lié à la fenêtre "paquets de vol", soit à la fenêtre TCP, soit à certains tampons de la liaison montante du satellite.

Effectuez définitivement de longues captures de paquets (à la fois "à l'intérieur" et "à l'extérieur" du VPN) et voyez si vous obtenez tous les avantages. ACKde


2
2017-11-25 18:03