Comment puis-je améliorer la fiabilité d'OpenVPN sur une liaison à latence élevée?


11

Nous utilisons un VPN OpenVPN sur une liaison satellite BGAN où les temps de ping sont d'environ 3 secondes. Nous l'utilisons dans une configuration tun , 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 se bloquer.

Le message "Je peux exécuter une commande ping dans le tunnel, mais tout travail réel le bloque. Est-ce un problème MTU?" question dans la FAQ OpenVPN semble décrire mon problème exactement, mais l'utilisation mssfixet fragmentne semble toujours pas faire grand-chose pour améliorer la situation.

Mon test principal consiste à copier un fichier de 2 Mo sur le VPN avec scp . Il copiera environ 192 Ko, puis signalera un état - bloqué - . Si j'attends quelques secondes, la copie recommencera, puis s'arrêtera à nouveau après quelques kilo-octets.

Ce blocage se produit que j'aie ou non défini les options fragmentou mssfixdans ma configuration OpenVPN (bien que le réglage fragment 1000ait semblé réduire le blocage, mais pas l'éliminer). L'OpenVPN a mtu-testindiqué 1542 comme taille MTU.

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

Mes questions sont alors:

  • Quand dois-je utiliser mssfixet fragment?
  • Dois-je utiliser mssfixet fragmenten combinaison?
  • Si mssfixet fragmentsont la solution, ce sont les tun-mtu, link-mtuet les mtu-discparamètres pour?

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

Lorsque vous utilisez iperf sur le VPN ( $ iperf -c remoteserver -t60 -i5), il démarre à 10 Kbits / s, puis monte régulièrement jusqu'à ce qu'il signale 1,2 Mbit / s, puis il semble se bloquer, où il signale 0 kbits / s pour un certain nombre d'itérations (I pense que le 1.2Mbits / sec peut être à cause d'une mise en mémoire tampon OpenVPN ou ainsi de suite)

Iperf est-il le meilleur moyen de mesurer la bande passante?

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


L'openvpn utilise-t-il TCP ou UDP pour le 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 a manqué de temps d'antenne. J'espère pouvoir continuer plus tard dans la journée. Je dois mentionner que nous préférerions rester avec UDP, car l'utilisation de 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:


5

1542 comme MTU? Jamais entendu parler de cela pour une liaison WAN. Habituellement, MTU est la charge utile maximale, la taille de paquet IP moins l'en-tête pour IP (20 octets) et ICMP (8 octets). Cela signifie MTU = 1500 pour un LAN 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 conclure quel MTU sera à tout moment, car les chemins d'entrée et de sortie peuvent être différents, et ils peuvent également changer en raison du réacheminement automatique des chemins. Pour un réseau comme celui-ci, il peut être plus efficace de définir le MTU bas sur vos hôtes qui se trouvent de chaque côté de la liaison VPN, comme 576.

MSS (taille de segment maximale) est MTU moins les en-têtes IP + TCP (40 octets). Ceci est généralement négocié par la pile réseau et n'a généralement pas les mêmes problèmes de négociation que MTU, sauf si MTU est erroné. (La négociation MTU est généralement entravée par des routeurs ICMP bloqués ou des trous noirs).

La première chose que je ferais est de faire une capture de paquets réseau du côté de l'envoi et de trier l'affichage par taille de trame (vous devrez peut-être ajouter cette colonne dans Wireshark). Vous devez vérifier que vous n'envoyez pas de cadres surdimensionnés, ce que vous attendez d'eux. Il n'est pas rare que des 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 trames d'octets lorsque ces options sont activées.


+1 pour la capture de paquets avant de changer quoi que ce soit. même si vous ne trouvez pas de trame énorme, vous pourriez voir des paquets «normaux» fragmentés quelque part.
Javier

1
Par défaut, OpenVPN définit le MTU du périphérique tun sur 1500 (ce qui est le même que le MTU sur les 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 qu'il est mauvais, tandis que les autres références que j'ai trouvées sur le Web impliquent qu'il est bon.
iWerner

2
@iwerner: avez-vous essayé de déterminer la taille du MTU avec ping? Si ICMP n'est pas désactivé quelque part, vous pouvez utiliser ce qui suit sur Windows: ping -f -l 1372 <destination ip>. Continuez à réduire le nombre jusqu'à ce qu'il réussisse. Sous linux, ping -s 1372 -M fait <destination ip>. Pour info, la FAQ OpenVPN recommande d'utiliser mssfix 1200, mais cela ne résout pas la cause première. L'utilisation de solutions VPN pour fragmenter a toujours le potentiel de réduire les performances. Si vous avez une grande configuration VPN, vous ne pourrez pas utiliser la fragmentation du côté du concentrateur central, uniquement du côté du bureau distant.
Greg Askew

2

Par simple curiosité, avez-vous essayé de réduire le MTU de l'interface réseau? Peut-être que la liaison satellite gâche mal la fragmentation. À titre de contre-intuitif, vous voudrez peut-être essayer openvpn sur TCP pour un changement. 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.


J'allais suggérer le contraire :) - ce cas de latence élevée est celui où les problèmes TCP-in-TCP apparaissent et UDP évitera cela.
pjc50

Je supposais qu'il utilisait le port UDP par défaut pour openvpn, et j'ai donc suggéré le contraire .. oui, normalement je serais d'accord avec vous. Mais bon, nous savons tous que sysadmin est un essai et une erreur, et généralement «essaye de faire le contraire-voir-si-ça-marche» :)
lorenzog

Merci. Nous utilisons UDP pour le moment, et essayer TCP ne m'est jamais venu à l'esprit. (Si j'avais plus de représentants, j'aurais voté pour vous)
iWerner

@iWerner: merci :) aussi, essayez de réduire progressivement MTU sur l'iface, et voyez quand il s'arrête (si c'est le cas).
lorenzog

2

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

Cela fait un moment que je n'ai pas dû jouer avec ce genre de choses, mais voici un lien que Google a trouvé pour moi.

Après avoir relu votre question, je vois que vous utilisez BGAN - j'aurais un bon aperçu de cela (ou simplement google pour: "BGAN spoofing").

En ce qui concerne la mesure de la bande passante, j'ai trouvé iperf assez décent tant que vous utilisez des tailles de paquets raisonnables.


C'est intéressant - Il mentionne que l'accélérateur TCP est disponible pour Redhat, tandis que les personnes inmarsat à qui nous avons parlé ont dit qu'il n'était disponible que pour Windows et OS X (et c'est en effet ce que dit le site Inmarsat / BGAN)
iWerner

Ils ne l'ont peut-être pas maintenant; Je vois que la date du document est 07. Si vous poussez assez fort et parlez à suffisamment de gens; vous pourriez trouver quelqu'un avec une ancienne copie de celui-ci. Généralement, lorsque vous téléphonez, vous bénéficiez d'une assistance de niveau un. J'essaierai certains de mes contacts mais aucune garantie.
Eddy

J'ai obtenu la course de notre fournisseur de satellites; difficile de trouver quelqu'un qui sait de quoi il parle. Je vais continuer d'essayer, en attendant, voici quelque chose à essayer: sourceforge.net/projects/pepsal D'après la description du projet, il fait à peu près ce que fait le logiciel Inmarsat: PEPsal est un TCP intégré, multicouche et transparent Performance Enhancing Proxy qui divise la connexion en deux parties, en utilisant les améliorations Linux TCP lors de l'envoi de données et en améliorant largement les performances des liens avec des caractéristiques différentes
Eddy

2

Je pense que vous aboyez sur le mauvais arbre. Chaque fois que j'ai eu de mauvais problèmes MTU, le trafic s'est arrêté bien avant 192 Ko. Je pense que c'est plus lié à certains dans la fenêtre "en vol des paquets", soit la fenêtre TCP, ou peut-être certains tampons dans la liaison montante satellite elle-même.

Sans aucun doute faire quelques captures de paquets à long ( à la fois « l' intérieur » et « extérieur » du VPN) et voir si vous obtenez tous les ACK« s

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.