[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upload sature dans un tunnel openvpn



Samuel a écrit :
Le 27/03/2015 14:40, BERTRAND Joël a écrit :
Samuel a écrit :
Sur une VM Wheezy à la maison, j'ai monté 2 tunnels (2 lignes adsl) vers
un serveur OVH
Ils sont montés de manière classique et à priori optimisé : connexion en
UDP et pas de chiffrement (cypher none) et en interface tap (car bonding
dessus)

Quand je fais un gros téléchargement (disons une video youtube) par les
lignes adsl, je download à 13Mbit avec un upload (d'après zabbix) très
léger : peut-être 200 à 500 kb

Quand je route les IP google (208.xxxx , 173.xxxx etc ...) au travers du
bonding des tap, je constate une baisse à moins de 10Mbit sur chaque
ligne ...; et je constate que mon upload et complètement saturé (1 Mbit)
sur chaque ligne au travers des tunnels vpn.

Les tests sont faits quand il n'y a pas d'autre charge sur le réseau
interne ou externe.

Question : Avez-vous aussi remarqué un upload énorme lors de gros
téléchargements via openvpn ?

    Oui, parce que par défaut l'interface tap est avec une MTU de
1500, ce qui est un peu gros pour faire passer la chose sur un PPPoE
ou PPPoA. Tu devrais utiliser la détection de MTU max pour optimiser
la taille de paquets. Si tu demande à OpenVPN de passer des paquets
standard, ils vont être fragmentés et l'upload va en prendre un coup.

    Sur mes serveurs, en TCP, j'ai forcé une MTU de 1492 et openvpn
monte un tap0 avec une MTU de 1416. En UDP, la MTU passe à 1418
(au-delà, le paquet fragmente) avec les paramètres suivants :

port 1194
fragment 1416
mssfix 1416
proto udp
link-mtu 1492
dev tap1

Je viens de tester rapidement, y compris en mettant des valeurs plus
basses sur les tap, mais ça ne change rien.
J'ai aussi essayé de baisser la MTU de l'interface bond0, mais rien de
mieux.
Quand aux interfaces adsl il s'agit de 2 freebox en bridge, donc à
priori une MTU à 1500 sur la passerelle Linux, mais je vais quand même
vérifier aussi ce point là.

Attention, ce n'est pas parce que la Freebox a une interface en MTU1500 côté LAN que la MTU côté WAN est de 1500. Il y a de l'encapsulation. Le seul moyen est de tester avec un ping -s (un ICMP ne fragmente pas). Si le protocole ethernet est correctement configuré (c'est-à-dire en laissant l'ICMP faire son boulot et en ne bloquant pas le ping), la MTU est négociée ou à défaut le paquet est scindé en plusieurs morceaux (sauf si flag DF pour don't fragment).

En règle générale, toujours mettre une MTU à 1492 pour un modem ADSL/VDSL, surtout s'il y a de l'IPv6 parce que je n'ai pas encore rencontré une pile IPv6 de modem même professionnel qui était capable d'être réellement transparente au MTU (1500 côté LAN, 1492 côté WAN non annoncé et paf, le trou de MTU).

Je vais essayer avec la détection de MTU ce week-end.

Il faudrait aussi que tu analyses le trafic sortant (sont-ce des ACK UDP pour le VPN ?). En virant le bond, qu'est-ce que cela donne ? Parce que j'ai un peu de mal à voir comment on fait du bonding en niveau 3 (ce qu'imposent les freeboxes qui ont chacune une adresse IP publique différente). Cela met peut-être un certain bazar dans les ACK d'openvpn.

	JKB


Reply to: