Re: upload sature dans un tunnel openvpn

[BERTRAND Joël <joel.bertrand@systella.fr>]

Samuel a écrit :
> Le 27/03/2015 16:35, BERTRAND Joël a écrit :
> > 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.
> > > > > [...]
> >     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.
>
> Je n'ai pas trouvé beaucoup de doc, ni de solution, mais cela a l'air
> lié au problème de packet reordering du mode balance-rr du bonding.
> Avec un seul tunnel, ou même en changeant pour l'option balance-xor le
> problème disparait. (upload divisé par 2)
> Le problème avec balance-xor c'est que c'est plus lié à une connexion,
> ce qui fait qu'on ne bénéficie du bonding que sur plusieurs
> téléchargements.
> Je vais chercher pour comprendre si le problème du packet reordering est
> plus lié à la latence adsl ou comme tu le soulignais un problème de ack
> ( ce qui semblait être le cas au vu des captures tcpdump) vis à vis du
> routage (mais là je crois que ça va dépasser mes compétences).

	Tes observations me semblent assez cohérentes et je ne vois pas trop ce 
qui pourrait forcer OpenVPN à accepter des ACK UDP en provenance d'une 
autre adresse IP. Ton bounding est de niveau 3 et je ne comprends même 
pas que ça se passe bien avec les autres services UDP, mais peut-être 
n'en utilises-tu pas.

> J'ai joué avec les options no-replay et replay-window d'openvpn qui ont
> supprimé certains logs d'erreur liés à l'ordre des paquets, mais ça ne
> corrige pas l'overhead.
>
> Merci encore.
> Je ferai un retour si je trouve.

	Je ne vois pas de solution triviale à ton problème en UDP (sauf à 
demander gentiment à Free une connexion directe de niveau 2). Je 
m'orienterais plutôt vers un load balancing par application. Dans le cas 
où tu voudrais quand même agréger les deux liens en VPN, il y aurait 
peut-être moyen de faire quelque chose avec deux openvpn en niveau 2 (un 
par freebox) et du bounding sur les deux interface tap de part et d'autre.

	Attention, je n'ai pas testé et ne sais pas comment OpenVPN se comportera.

	Cordialement,

	JKB