OpenVPN: Comment atténuer les problèmes de MTU de chemin d'accès par client?

Nous avons des dizaines d'appareils intégrés installés chez les clients, tous appelant à la maison à 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 réparer leurs réseaux est limitée, nous avons donc besoin d'OpenVPN pour y faire face. En un mot, ma question est:

Comment puis-je atténuer les MTU à faible chemin de certains clients sur une base par client, c'est-à-dire sans utiliser de paramètres globaux adaptés au pire des cas pour tous les clients

Notez que notre pire cas est assez mauvais: le chemin MTU 576, supprime tous les fragments, ne se fragmente pas, n'honore pas le bit DF. Vous voyez pourquoi je préfère ne pas résoudre ce problème à l'échelle mondiale.

La page de manuel OpenVPN propose un certain nombre d'options liées à MTU, notamment --link-mtu, --tun-mtu, --fragment and --mssfix. Mais ça dit aussi

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

--tun-mtu [...] Il est préférable d'utiliser les options --fragment et / ou --mssfix pour traiter les problèmes de dimensionnement MTU.

J'ai donc commencé à expérimenter --fragmentet j'ai --mssfixvite compris qu'au moins le premier devait être défini non seulement côté client, mais aussi côté serveur . J'ai ensuite examiné la configuration par client côté serveur via --client-config-dirmais il est dit

Les options suivantes sont légales dans un contexte spécifique au client: --push, --push-reset, --iroute, --ifconfig-push et --config.

Aucune mention des options MTU!

Voici donc mes questions les plus spécifiques:

Pourquoi exactement link-mtuet tun-mtudécouragés? Quels sont les problèmes potentiels avec ces options? Notez que je suis assez à l'aise avec le munging d'en-tête IP de bas niveau.
Laquelle des options link-mtu tun-mtu fragment mssfixdoit être mise en miroir côté serveur pour fonctionner?
Dans laquelle des options link-mtu tun-mtu fragment mssfixpeut-on utiliser client-config-dir?
Dans le cas où les quatre options doivent être mises en miroir côté serveur et ne peuvent pas être utilisées à l'intérieur client-config-dir: existe-t-il des alternatives pour lutter contre la MTU à faible chemin par client?

Remarques:

Certaines parties de mes questions ont déjà été posées il y a 5 ans ici , mais elles n'ont pas vraiment été répondues à l'époque, donc 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 moi-même le chemin d'un client-MTU manuellement
Actuellement, nous ne pouvons pas tester beaucoup côté serveur. Mais nous construisons un banc d'essai séparé complet, devrait être prêt bientôt.

Je suis reconnaissant pour tout conseil utile.

ip openvpn mtu ip-fragmentation

— Nils Toedtmann
source

576? Cher gawd. Je n'ai pas vu un MTU aussi bas depuis l'époque des commutateurs. Est-ce que cela passe par une ancienne liaison série?

— Michael Hampton

Pourriez-vous exécuter deux serveurs OpenVPN? Vous pouvez peut-être exécuter les deux serveurs sur la même adresse IP publique et utiliser la redirection de port (ou une politique de routage) pour diriger les clients vers un autre serveur OpenVPN selon qu'ils se trouvent sur un réseau problématique connu ou non (comme déterminé par une liste de clients Adresses IP).

— kasperd

@MichaelHampton, je me demandais aussi. C'est> 600kbit / s et RTT ~ 30ms, ne ressemble pas à une ancienne série pour moi. Étant donné qu'ils ont d'autres paramètres stupides (par exemple, ne répondant pas à DF avec la «fragmentation nécessaire»), je suppose que ce n'est qu'un autre. Nous leur avons dit, mais nous n'avons pas encore entendu.

— Nils Toedtmann

@kasperd idée intéressante. Je pouvais exécuter plusieurs instances de serveur OpenVPN. Devrait avoir peut-être 3 ou 4, pour différentes gammes de MTU. Le NAT par client côté serveur ne fonctionnerait pas (je ne peux pas prédire les adresses IP du client public dynamique), mais je devrais quand même modifier la configuration du client pour les paramètres MTU (correct?), Donc je configurerais simplement les différents ports directement dans le client. - Mais ce serait un cauchemar de maintenance que je préférerais éviter!

— Nils Toedtmann

@NilsToedtmann Quels critères utiliseriez-vous pour détecter les clients concernés? Une autre approche pourrait être d'exécuter un script sur le serveur après la connexion d'un client. Le script peut essayer d'envoyer une requête ping à l'adresse IP du client avec différentes tailles de paquets pour déterminer celles qui fonctionnent et celles qui ne fonctionnent pas. Ensuite, il peut insérer des iptablesrègles pour réduire le MSS sur tous les paquets SYN vers ou depuis cette adresse IP cliente.

— kasperd

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

Depuis la page de manuel openvpn:

--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 personalvpn.org

— Oz123
source

mssfixPeut donc être défini côté client uniquement? Eh bien, c'est au moins quelque chose. Cependant, cela n'aide pas avec les paquets UDP (c'est pourquoi j'étais intéressé par les autres options, mais au moins les recommandations fragmentdoivent également être définies côté serveur)

— Nils Toedtmann

mssfix peut être ajouté sur le serveur ainsi que sur le client. Cependant, la plus petite valeur sera utilisée dans la négociation

— Ahmed

Étant donné le manque de réponses, je poste maintenant une solution qui n'est pas très élégante, mais simple: exécuter une autre instance OpenVPN sur TCP pour les "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 son MSS individuel.

Il s'agit certes de TCP sur TCP, mais cela devrait fonctionner assez bien dans de nombreux scénarios .

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

— Nils Toedtmann
source