MTU en non-dégroupé

FloBaoti · Chevalier de L'Univers Inscrit le: 06 Nov 2013 Messages: 548

Salut à tous,

Bon c'est une question assez technique, certes, mais peut-être que certains d'entre vous en ont entendu parlé.

Je rencontres des soucis sur une connexion non-dégroupée. En effet, j'utilise plusieurs systèmes de VPN, dont OpenVPN et Tinc, et je constate que les deux ont des problèmes à déterminer le PMTU (Path MTU).
Ce qui revient à un mauvais paramétrage du MTU dans le VPN et donc à des soucis de connexion (pages qui ne se chargent pas, etc...).

En non-dégroupé, le MTU de la connexion est à 1460, certainement dû à l'encapsulation PPP et L2TP.

Je précise que ce problème n'est pas présent lorsque je suis sur une connexion dégroupée (MTU à 1500).

Je rencontre donc ces problèmes de PMTU uniquement sur une connexion non-dégroupée.

Est-ce que ceci évoque quelque chose à quelqu'un ?

Merci par avance Smile

JoePike

Oui

Cela arrive quand il ny a aucune limite max de MTU paramétrée dans le VPN
basiquement l'encryption va rajouter des headers et des trailers à ton paquet et ensuite envoyer le paquet
comme le MTU optimisé max est par exemple de 1500 et que le paquet envoyé est de 1564 ( exemple) le protocole va être obligé de splitter le paquet en 2
Comme c'est une connexion sécurisée , le protocole VPN va être obligé de refuser les paquets modifiés à la réception.

Si t'as un max MTU paramétré dans l'interface tunnel VPN,
le paquet original sera splitté en 2 avant l'encryption.
les 2 paquets seront encryptés , envoyés , reçus et le paquet original reconstitué à l'arrivée sans aucun problème

En fait comme ton problème est différent selon la ligne utilisée c'est uniquement parce que le MTU optimal n'est pas le même dans les 2 cas ( ce qui est tout à fait logique)
Mais il y a 2 cas de figures
1: il n'y a pas de max de paramétré
2: le max qui est paramétré est trop grand ( plus grand que ton max MTU possible)

Edit: au fait j'ai oublié de dire: généralement pour ne pas être emm... avec un VPN on met toujours à 1392 ( ça laisse assez de marge sans trop affecter les perf)

FloBaoti · Chevalier de L'Univers Inscrit le: 06 Nov 2013 Messages: 548

Je comprends effectivement ce qui se passe.

Ce que je comprends moins, c'est que même en jouant sur les paramètres tun-mtu, fragment, mssfix & co pour OpenVPN par exemple, ça ne s'arrange pas. Même en limitant tout à 1300.
En ne mettant rien, il est censé pouvoir déterminer tout seul la MTU max utilisable.
Idem pour Tinc qui sait déterminer tout seul le Path MTU partout, sauf sur une connexion Free non-dégroupée... Il trouve 1518 ! Alors que sur des serveurs hébergés au 4 coins du monde, avec des MTU pour certains inférieures à 1500, il sait le déterminer correctement !

Ce que je comprends encore moins, c'est qu'il y a des postes Mac sur le même réseau que moi, et qu'eux n'ont pas ce problème de MTU sur le même serveur OpenVPN que moi avec les mêmes paramètres.

JoePike

et toi quand tu calcules avec un ping -f tu trouves combien ?
tu utilises quoi comme OS ?

FloBaoti · Chevalier de L'Univers Inscrit le: 06 Nov 2013 Messages: 548

ping -f ça doit être sous Windows non ?

Je suis sous Linux (Ubuntu).

Si je fais un tracepath je trouve 1460 :

JoePike

Euh....
Le ping est universel il me semble et le -f aussi
https://www.linuxcertif.com/man/8/ping/

les valeurs que tu donnes sont celles qui sont paramétrées
je te parle de calculer la valeur optimale
c'est à dire de balancer des paquets de valeurs fixes et d'augmenter jusqu'à ce que ça fragmente et d'ajouter les tailles de headers d'encryption et les 28 octets d'encapsulation TCP/IP

ping -f -l 1400 www.free.fr

FloBaoti · Chevalier de L'Univers Inscrit le: 06 Nov 2013 Messages: 548

Non les paramètres sont différents selon l'OS.

Genre ton -l est -s sur Linux.

Ton -f doit être pour ne pas fragmenter ? Donc c'est "-M do" sous Linux.

Sinon je ne vois pas en quoi le "mode inondation" peut être utile ici Smile

Les tests que j'ai fait sont sans VPN, connecté direct sur la Freebox.

Et donc en MTU 1500. Donc aucune valeur paramétré nulle part... lorsque ping indique mtu=1460 il a du le déterminer vu que je n'ai indiqué ça nulle part...

JoePike

Yep désolé je viens de vérifier, les paramètres de la commande ping sont différents entre les OS et j'ai confondu avec un autre OS
PDT_Aliboronz_37

Le 1460 est à l'évidence déterminé proprement puisque tu fragmentes au dessus de 1432 avec le header TCP/IP ça fait bien 1432+28=1460 ( encore faut il essayer sur plusieurs serveurs mais bon ... )
Comme pour l'instant tu n'encryptes ni n'encapsules pas ... so far so good.. pas de header supplémentaire.
Mais je suppose que ce test a eu lieu sur une ligne dégroupée non ?

Il faudrait donc déjà savoir à combien ça fragmente sur du non dégroupé ...
Donc refaire le même test en non dégroupé .. enfin c'est une suggestion

et ensuite on regarde avec VPN ( je ne sais pas si ça va faire bon ménage ICMP/VPN encryption toussa) mais ça ne coutera rien d'essayer

melleray · Esprit de L'Univers Inscrit le: 20 Mar 2007 Messages: 317

JoePike

Merci pour l'explication de cette taille de MTU ( je n'étais pas du tout au courant et je n'ai pas compris tous les sigles) , mais je ne vois pas ( ou plutot ne comprend pas) le rapport avec le problème.
Que ce MTU soit a 1000 1500 ou 1460 est normal , un MTU ça se calcule et s'ajuste en fonction ( on met des MTU de 5 ou 6 digits sur certains mainframe parce qu'on balance des paquets monstrueux )
Le problème ici est que ou bien le calcul se fait mal, ou bien il y a un paramètre qui gène.
Mon opinion est que le paquet est splitté en 2 après encryption et donc refusé par le protocole VPN à la réception.
Après tout les macs ne marcheraient pas mieux que le Linux si c'était dû aux protocoles de collecte surtout qu'en réglant à 1300 le max dans le VPN ça ne marche toujours pas
Mais je n'ai peut être pas tout saisi .

Very Happy

FloBaoti · Chevalier de L'Univers Inscrit le: 06 Nov 2013 Messages: 548

Mes tests ont bien été faits depuis une ligne NON-dégroupée.
Sinon en dégroupée, c'est 1500 partout, aucun problème.

Donc effectivement j'ai du mal à saisir aussi... mais c'est vraiment très embarassant... Sad

On dirait qu'un des équipements sur le chemin "fait croire" que les paquets de 1500 sont possibles, alors que ce n'est pas le cas en réalité... étrange.

FloBaoti · Chevalier de L'Univers Inscrit le: 06 Nov 2013 Messages: 548

Je me permet de relancer ce sujet, car je n'ai toujours pas trouvé de solution à mon problème.
Est-ce que quelqu'un a déjà fait fonctionner un tunnel VPN en redirect-gateway sur une ligne Free non-dégroupée.

En fait, en touchant un peu les paramètres, au mieux j'arrive à faire fonctionner le tunnel par intermittence (de temps en temps, une page Google ne se charge pas, mais 2 minutes après ça passe). Le problème semble apparaitre principalement pour les services Google. On dirait que de temps en temps un serveur envoit un paquet avec le flag DF et que par conséquent, ça ne passe plus...

J'aurais la solution de limiter la taille maximale d'un paquet échangé entre le serveur et les clients, mais ça vaudrait dire changer la config du serveur, et donc changer toutes les configs de tous les clients, alors que certains n'ont aucun soucis...