web-dev-qa-db-fra.com

OpenVPN: Comment atténuer les problèmes de PATH MTU sur une base par client?

Nous avons des dizaines d'appareils intégrés installés chez les clients, tous appelant à notre service OpenVPN. Cela fonctionne bien en général, mais quelques-uns de nos clients ont de graves problèmes de MTU. Notre influence sur les clients pour corriger leurs réseaux est limitée, nous avons donc besoin OpenVPN pour y faire face. En bref, ma question est la suivante:

Comment puis-je atténuer la mauvaise liaison MTUS de certains clients sur une base par client, c'est-à-dire sans utiliser des paramètres globaux accumulant le pire des cas pour tous les clients

Notez que notre pire cas que c'est plutôt mauvais: chemin MTU 576, goutte tous les fragments, ne fragment pas lui-même, n'honore pas DF-Bit. Vous voyez pourquoi je préférerais ne pas résoudre ce problème à l'échelle mondiale.

Le OpenVPN Manpage offre un certain nombre d'options liées à la MTU, notamment --link-mtu, --tun-mtu, --fragment and --mssfix. Mais cela dit aussi

--Link-MTU [...] Il est préférable de ne pas définir ce paramètre à moins que vous sachiez ce que vous faites.

--Tun-MTU [...] Il est préférable d'utiliser les options --fragment et/ou --MSSFix pour gérer les problèmes de dimensionnement du MTU.

J'ai donc commencé à expérimenter avec --fragment et --mssfix Mais il fallait bientôt comprendre que au moins le premier doit être défini non seulement côté client, mais également côté serveur . J'ai ensuite examiné la configuration par client côté serveur via --client-config-dir mais ça dit

Les options suivantes sont légales dans un contexte spécifique au client: --PUSH, --PUSH-RESET, --IRORE, --IFCONFIG-PUSH et --CONFIG.

Aucune mention des options MTU!

Voici donc mes questions plus spécifiques:

  • Pourquoi exactement link-mtu et tun-mtu découragé? Quels sont les problèmes potentiels avec ces options? Notez que je suis assez à l'aise avec une en-tête IP de bas niveau.
  • Laquelle des options link-mtu tun-mtu fragment mssfix doit être reflétable sur le côté serveur afin de travailler?
  • Laquelle des options link-mtu tun-mtu fragment mssfix peut être utilisé dans client-config-dir?
  • Au cas où les quatre options doivent être mirées côté serveur, et ne peuvent pas être utilisées à l'intérieur client-config-dir: Y a-t-il des alternatives à lutter contre la mauvaise voie MTU par client?

Remarques:

  • Certaines parties de mes questions ont déjà été posées il y a 5 ans ici , mais ils n'ont pas vraiment été répondu à ce moment-là, alors j'ose les dupliquer.
  • Le serveur OpenVPN est actuellement 2.2.1 sur Ubuntu 12.04. Nous préparons une mise à niveau vers 2.3.2 sur Ubuntu 14.04
  • Les clients OpenVPN sont 2.2.1 sur Debian 7.6
  • Je suis heureux de déterminer le chemin du client moi-même manuellement
  • Actuellement, nous ne pouvons pas tester beaucoup de serveur. Mais nous construisons un lit de test séparé complet, devrait être prêt bientôt prêt.

Je suis reconnaissant pour tout conseiller utile.

ipopenvpnmtuip-fragmentation
18
Nils Toedtmann

J'ai résolu le problème du côté du client en ajoutant l'option mssfix 1300 au fichier de configuration.

De la page OpenVPN Man:

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

L'idée originale de ma solution est venue de personnalvpn.org

6
Oz123

Compte tenu du manque de réponses, je pose maintenant une solution qui n'est pas très élégante, mais simple: exécutez une autre instance OpenVPN sur TCP pour "mauvais clients"

proto tcp

et abaisser le TCP MSS sur le client, par exemple.

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

Un avantage de cette solution est que chaque client peut définir ses SMS individuels.

C'est certes TCP-Over-TCP, mais cela devrait fonctionner assez bien dans de nombreux scénarios .

Notez que je suis toujours des solutions très intéressées qui ne nécessitent pas proto tcp, et je vais les marquer comme une réponse valide si elles remplissent plus ou moins mes exigences décrites.

2
Nils Toedtmann