Assurez-vous que votre mtu de liaison pour le tunnel openvpn est défini avec précision afin d'éviter une double fragmentation (une sur l'hôte de 8192 octets à 1500 octets et une sur openvpn de 1500 octets à 1400 octets ou autre). openvpn gère très très mal la définition du mtu de l'interface (il entrave activement les tentatives de définir le mtu correctement).
Vérifiez la latence pour différentes tailles de paquets traversant et contournant le tunnel. Tracez et recherchez les problèmes.
Configurez un NFS de test en dehors du tunnel et effectuez des mesures de performance de cette façon pour isoler si openvpn est le problème ou non.
Essayez différentes versions de NFS, à la fois TCP et UDP.
Essayez d'activer la mise en cache agressive et les E/S asynchrones.
Ce qui suit est une diatribe sur le "blocage actif" d'openvpn concernant le MTU (ajouté par "demande").
Oui. Configurer tun-mtu permet à openvpn de générer WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1413). Je n'utilise pas --mssfix o --fragment .
De plus, définir un MTU statique dans la configuration est stupide et source d'erreurs, il doit être dynamique. Donc, vous utilisez "mtu-disc yes", n'est-ce pas ? Bien sûr, sauf que la valeur qu'il passe dans le script de démarrage est off-by-14 (bien que j'utilise TAP pour le support IPv6, ce qui pourrait mystérieusement le confondre). Je dois donc /sbin/ifconfig $1 mtu $(($2-14)) up pour obtenir la valeur appropriée (appropriée signifiant une valeur qui fera que les paquets du tunnel ne seront pas fragmentés ou abandonnés parce qu'ils sont trop gros).
J'ai du mal à imaginer une circonstance dans laquelle définir le MTU de l'interface à la valeur correcte n'est pas une bonne idée, du moins si vous n'avez pas de fragment set (et vous ne devriez jamais avoir de fragment set, sinon vos péchés de réseau viendront vous hanter). Il devrait également changer dynamiquement le MTU de l'interface s'il obtient plus tard des erreurs de fragment nécessaire dues à des changements de réseau après l'initialisation.
Le MSS n'est absolument pas la bonne couche réseau pour faire ce travail. Si le MTU de l'interface est correctement configuré, la découverte du Path-MTU, le MSS et tout le reste fonctionnent tout simplement. Si ce n'est pas le cas, certaines choses peuvent fonctionner, d'autres non, et les choses qui fonctionnent dépendent du fait que le paquet réel soit envoyé par l'hôte openvpn ou un autre hôte. Oh, et ne me lancez pas sur ce qui peut échouer si le MTU est asymétrique (ce qui n'est pas totalement rare).
Je pense qu'OpenVPN a été écrit par des personnes sans grande expérience des réseaux et des administrateurs système et que leurs mauvais choix ont été codés en dur dans la configuration et les structures de données/API. Ils n'ont vraiment pas fait un très bon travail en matière de configuration et d'intégration de réseaux flexibles et sains (ce n'est qu'un exemple parmi d'autres). Ce qui est triste, c'est qu'il est des centaines de fois meilleur que les autres solutions existantes, ce qui fait de moi un partisan d'OpenVPN. Le VPN de Cisco est un fléau, par exemple.
