upload sature dans un tunnel openvpn

Samuel a écrit :

Bonjour à tous,

Bonjour,

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

Avec ceci, je n'ai aucun problème.

Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/55155DD0.1030309@systella.fr

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à.
Je vais essayer avec la détection de MTU ce week-end.

Merci bien.
Samuel.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/55157536.2060207@ingescom.com

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

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/551578DF.8010405@systella.fr

Merci pour ton aide,

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.

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).

Je viens de tester, c'est OK à 1500 pour les 2 lignes (ping -s 1473 -M
do XXXXXXXX - plus haute valeur bloquée)

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 donc suivre tes conseils et baisser à 1492 sur les 2 eth de la
passerelle côté wan.

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

Je mets plus bas un log de tcpdump sur l'interface bond, on voit le même
paquet passer plusieurs fois (mais moins depuis que j'ai mis "no-replay"
dans la conf d'openvpn pour la double connexion).
Je n'ai pas encore essayé sans le bond, je vais le faire.

Concernant le routage, c'est la passerelle qui s'en charge en marquant
les paquets :
iptables -t mangle -A PREROUTING -m state --state NEW -m mark --mark 0
-m statistic --mode nth --every 2 --packet 0 -j MARK --set-mark
$sortie_freebox_hd_defaut
iptables -t mangle -A PREROUTING -m state --state NEW -m mark --mark 0
-j MARK --set-mark $sortie_freebox_revolution_defaut

Pour l'UDP d'openvpn, ça dispatche chaque vpn sur chaque ligne ADSL.

Côté serveur :

root@ns5:/etc/openvpn# cat tun0.conf
local 192.9.XXXX
port 1194
proto udp
dev tap2
dev-type tap
secret secret.key
cipher none
keepalive 10 120
txqueuelen 1000
mssfix 1416
fragment 1416
link-mtu 1492
no-replay
nice 10
user nobody
group nogroup
persist-tun
persist-key
status /etc/openvpn/server-bonding-A-status.log
verb 3
mute 20
cd /etc/openvpn

root@ns5:/etc/openvpn# cat tun1.conf
local 192.9.XXXXXXX
port 1195
proto udp
dev tap3
dev-type tap
secret secret.key
cipher none
keepalive 10 120
txqueuelen 1000
mssfix 1416
fragment 1416
link-mtu 1492
no-replay
nice 10
user nobody
group nogroup
persist-tun
persist-key
status /etc/openvpn/server-bonding-B-status.log
verb 5
mute 20
cd /etc/openvpn

root@ns5:/etc/openvpn# cat /etc/network/interfaces
auto bond1
iface bond1 inet static
address 172.27.0.1
netmask 255.255.255.252
bond-slaves none
bond_mode balance-xor

allow-hotplug tap2
iface tap2 inet manual
bond-master bond1
allow-hotplug tap3
iface tap3 inet manual
bond-master bond1

Et sur le client :

root@venus:/etc/openvpn# cat tun0.conf
remote 192.9.XXXXXXXXXX
proto udp
dev tap2
dev-type tap
mode p2p
mssfix 1416
fragment 1416
link-mtu 1492
no-replay
secret secret.key
cipher none
keepalive 10 120
txqueuelen 1000
nice 10
nobind
user nobody
group nogroup
persist-tun
persist-key
status /etc/openvpn/client-bonding-A-status.log
verb 3
mute 20
cd /etc/openvpn

root@venus:/etc/openvpn# cat tun1.conf
remote 192.9.XXXXXXXXX
proto udp
dev tap3
dev-type tap
mode p2p
mssfix 1416
fragment 1416
link-mtu 1492
no-replay
secret secret.key
cipher none
keepalive 10 120
txqueuelen 1000
nice 10
nobind
user nobody
group nogroup
persist-tun
persist-key
status /etc/openvpn/client-bonding-B-status.log
verb 3
mute 20
cd /etc/openvpn

root@venus:/etc/openvpn# cat /etc/network/interfaces
auto bond0
iface bond0 inet static
address 172.27.0.2
netmask 255.255.255.252
bond-slaves none
bond-miimon 300
bond-use-carrier 0
bond_mode balance-xor

allow-hotplug tap2
iface tap2 inet manual
bond-master bond0
allow-hotplug tap3
iface tap3 inet manual
bond-master bond0

Concernant les valeurs MTU sur les bond, après des tests à 1400, j'ai
remis à 1500, puisque si j'ai bien compris c'est l'option mss-fix (ou
link-mtu) qui permet d'adapter le mtu des paquets d'openvpn pour le réseau.

Concernant le firewall c'est en accept all dans les 2 sens sur le bond
Et pour les autres ce sont ces règles en général :

# ICMP RELATED FORWARD
iptables -A FORWARD -i $lan -o $fai -p icmp -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -p icmp -m state --state RELATED --icmp-type
destination-unreachable -j ACCEPT
iptables -A FORWARD -p icmp -m state --state RELATED --icmp-type
parameter-problem -j ACCEPT
iptables -A FORWARD -p icmp -m state --state RELATED --icmp-type
source-quench -j ACCEPT
iptables -A FORWARD -p icmp -m state --state RELATED --icmp-type
time-exceeded -j ACCEPT
iptables -A FORWARD -p icmp -m state --state RELATED --icmp-type
fragmentation-needed -j ACCEPT

Concernant le traffic que je constate (2 ou 3 videos youtube en 4K pour
tirer)

Upload sur eth1 : +-1Mb
Upload sur eth2 : +- 1Mb

Upload sur Bond0 : +-1Mb (c'est étrange cette différence d'upload réel
sur les 2 Wan et d'upload dans le Bond )

Voilà pour la littérature.
Merci encore.
Samuel



Logs tcpdump sur le bond :

13:13:20.705589 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
778261, win 21102, options [nop,nop,TS val 23766154 ecr
813980913,nop,nop,sack 3 {795265:796573}{790033:791341}{787417:788725}],
length 0
13:13:20.705850 IP 172.27.0.2.53315 > 173.194.53.53.443: Flags [.], ack
523200, win 24513, options [nop,nop,TS val 23766194 ecr
813981075,nop,nop,sack 3 {536280:541512}{532356:534972}{525816:529740}],
length 0
13:13:20.707081 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
855432:858048, ack 1, win 1654, options [nop,nop,TS val 813981438 ecr
23766188], length 2616
13:13:20.707112 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
779569, win 21102, options [nop,nop,TS val 23766155 ecr
813980913,nop,nop,sack 3 {795265:797881}{790033:791341}{787417:788725}],
length 0
13:13:20.707372 IP 172.27.0.2.54973 > 173.194.53.53.443: Flags [.], ack
435564, win 24549, options [nop,nop,TS val 23766195 ecr
813981080,nop,nop,sack 2 {443412:444720}{436872:439488}], length 0
13:13:20.707583 IP 173.194.53.53.443 > 172.27.0.2.49637: Flags [.], seq
1245217:1246525, ack 0, win 1654, options [nop,nop,TS val 813981433 ecr
23766186], length 1308
13:13:20.708552 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
791341, win 21102, options [nop,nop,TS val 23766158 ecr
813980929,nop,nop,sack 2 {803113:807037}{795265:797881}], length 0
13:13:20.708585 IP 172.27.0.2.54973 > 173.194.53.53.443: Flags [.], ack
439488, win 24531, options [nop,nop,TS val 23766195 ecr
813981084,nop,nop,sack 1 {443412:446028}], length 0
13:13:20.709803 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
858048:860664, ack 1, win 1654, options [nop,nop,TS val 813981438 ecr
23766188], length 2616
13:13:20.709834 IP 172.27.0.2.54973 > 173.194.53.53.443: Flags [.], ack
440796, win 24549, options [nop,nop,TS val 23766195 ecr
813981084,nop,nop,sack 1 {443412:446028}], length 0
13:13:20.709849 IP 172.27.0.2.54973 > 173.194.53.53.443: Flags [.], ack
344004, win 24530, options [nop,nop,TS val 23766159 ecr
813980925,nop,nop,sack 3 {358392:359700}{353160:355776}{350544:351852}],
length 0
13:13:20.710667 IP 173.194.53.53.443 > 172.27.0.2.49637: Flags [.], seq
1246525:1249141, ack 0, win 1654, options [nop,nop,TS val 813981434 ecr
23766187], length 2616
13:13:20.710683 IP 173.194.53.53.443 > 172.27.0.2.49637: Flags [.], seq
1249141:1250449, ack 0, win 1654, options [nop,nop,TS val 813981439 ecr
23766188], length 1308
13:13:20.711258 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
943069, win 21102, options [nop,nop,TS val 23766195 ecr
813981077,nop,nop,sack 3 {956149:957457}{953533:954841}{945685:946993}],
length 0
13:13:20.711511 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
791341, win 21102, options [nop,nop,TS val 23766159 ecr
813980929,nop,nop,sack 3 {809653:810961}{803113:807037}{795265:797881}],
length 0
13:13:20.712459 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
860664:861972, ack 1, win 1654, options [nop,nop,TS val 813981440 ecr
23766188], length 1308
13:13:20.712494 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
861972:863280, ack 1, win 1654, options [nop,nop,TS val 813981442 ecr
23766188], length 1308
13:13:20.712521 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
944377, win 21102, options [nop,nop,TS val 23766196 ecr
813981089,nop,nop,sack 3 {956149:960073}{953533:954841}{945685:946993}],
length 0
13:13:20.712544 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
807037, win 21102, options [nop,nop,TS val 23766162 ecr
813980939,nop,nop,sack 3 {821425:822733}{816193:818809}{812269:814885}],
length 0
13:13:20.713363 IP 173.194.53.53.443 > 172.27.0.2.49637: Flags [.], seq
1250449:1251757, ack 0, win 1654, options [nop,nop,TS val 813981439 ecr
23766188], length 1308
13:13:20.713627 IP 173.194.53.53.443 > 172.27.0.2.49637: Flags [.], seq
1251757:1253065, ack 0, win 1654, options [nop,nop,TS val 813981439 ecr
23766188], length 1308
13:13:20.714207 IP 172.27.0.2.53315 > 173.194.53.53.443: Flags [.], ack
534972, win 24522, options [nop,nop,TS val 23766196 ecr
813981079,nop,nop,sack 3 {546744:548052}{542820:544128}{536280:541512}],
length 0
13:13:20.714480 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
807037, win 21102, options [nop,nop,TS val 23766162 ecr
813980939,nop,nop,sack 3 {821425:824041}{816193:818809}{812269:814885}],
length 0
13:13:20.715144 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
863280:864588, ack 1, win 1654, options [nop,nop,TS val 813981442 ecr
23766188], length 1308
13:13:20.715168 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
864588:865896, ack 1, win 1654, options [nop,nop,TS val 813981443 ecr
23766189], length 1308
13:13:20.715416 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
865896:867204, ack 1, win 1654, options [nop,nop,TS val 813981443 ecr
23766189], length 1308
13:13:20.715444 IP 172.27.0.2.54973 > 173.194.53.53.443: Flags [.], ack
359700, win 24540, options [nop,nop,TS val 23766163 ecr
813980947,nop,nop,sack 1 {362316:364932}], length 0
13:13:20.715952 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
948301, win 21102, options [nop,nop,TS val 23766196 ecr
813981089,nop,nop,sack 2 {956149:960073}{953533:954841}], length 0
13:13:20.720592 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
952225, win 21102, options [nop,nop,TS val 23766197 ecr
813981090,nop,nop,sack 3 {963997:965305}{956149:961381}{953533:954841}],
length 0
13:13:20.720780 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
868512:869820, ack 1, win 1654, options [nop,nop,TS val 813981448 ecr
23766190], length 1308
13:13:20.720792 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
869820:871128, ack 1, win 1654, options [nop,nop,TS val 813981450 ecr
23766190], length 1308
13:13:20.721881 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
954841, win 21102, options [nop,nop,TS val 23766198 ecr
813981092,nop,nop,sack 2 {963997:965305}{956149:961381}], length 0
13:13:20.723378 IP 173.194.53.53.443 > 172.27.0.2.49637: Flags [.], seq
1260913:1263529, ack 0, win 1654, options [nop,nop,TS val 813981453 ecr
23766191], length 2616
13:13:20.723394 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
871128:872436, ack 1, win 1654, options [nop,nop,TS val 813981455 ecr
23766191], length 1308
13:13:20.723629 IP 173.194.53.53.443 > 172.27.0.2.49637: Flags [.], seq
1263529:1264837, ack 0, win 1654, options [nop,nop,TS val 813981453 ecr
23766191], length 1308
13:13:20.723639 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
872436:873744, ack 1, win 1654, options [nop,nop,TS val 813981455 ecr
23766191], length 1308
13:13:20.723893 IP 173.194.53.53.443 > 172.27.0.2.49637: Flags [.], seq
1264837:1266145, ack 0, win 1654, options [nop,nop,TS val 813981453 ecr
23766191], length 1308
13:13:20.723921 IP 172.27.0.2.49637 > 173.194.53.53.443: Flags [.], ack
954841, win 21102, options [nop,nop,TS val 23766198 ecr
813981092,nop,nop,sack 3 {970537:971845}{963997:965305}{956149:961381}],
length 0
13:13:20.725334 IP 172.27.0.2.54973 > 173.194.53.53.443: Flags [.], ack
446028, win 24549, options [nop,nop,TS val 23766199 ecr
813981099,nop,nop,sack 3 {453876:455184}{451260:452568}{447336:448644}],
length 0
13:13:20.726046 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
873744:875052, ack 1, win 1654, options [nop,nop,TS val 813981457 ecr
23766192], length 1308
13:13:20.726807 IP 172.27.0.2.53315 > 173.194.53.53.443: Flags [.], ack
545436, win 24540, options [nop,nop,TS val 23766199 ecr
813981095,nop,nop,sack 3 {551976:554592}{549360:550668}{546744:548052}],
length 0
13:13:20.727363 IP 173.194.53.53.443 > 172.27.0.2.53315: Flags [.], seq
875052:876360, ack 1, win 1654, options [nop,nop,TS val 813981459 ecr
23766192], length 1308^C

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/55159A28.6070500@ingescom.com

Le 27/03/2015 16:35, BERTRAND Joël a écrit :

Samuel a écrit :
[...]

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.

C'est vrai que j'aurais du commencer sans le bond d'abord ...

En effet, quand je vire le bond, les résultats sont meilleurs sur une
ligne :

Download : 11.56 Mbit
Upload : 500 à 550 Kbit

Soit moins de 5 % d'upload, contrairement au bond qui monte à 10 %
d'upload (et sature ma ligne).

Je vais donc chercher du côté du bond.

Merci pour ton aide.

Samuel.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/55166E17.1030703@ingescom.com

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).

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.

Samuel.




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/5517ED85.10403@ingescom.com

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

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/55191D1D.4000301@systella.fr

Le 30/03/2015 11:53, BERTRAND Joël a écrit :

Samuel a écrit :

[...]

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.

En fait, le bonding ne servait qu'à router les IP youtube/google pour
tester les débits depuis OVH. Mais c'était plus pour comprendre le
fonctionnement, car un seul tunnel (voire 2 tunnels en Load Balancing
avec ipmark) suffit largement pour résoudre les problèmes free/youtube à
certaines heures.

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.

Certains forums conseillaient de jouer avec la valeur de tcp_replay,
mais cela n'a rien donné. J'ai aussi rééquilibré la latence entre les 2
lignes avec tc, mais pas mieux.
Après comme je l'ai dit, il n'y avait pas d'impératif de réussite.
C'était surtout intéressant ...

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.

Tu as raison, je vais rester avec mon Load balancing ipmark (+ match
recent pour https et dns) qui convient parfaitement pour un réseau
domestique.
Quand à Free, je préfère ne rien demander depuis le jour où un
technicien m'a engueulé parce que j'envoyais 3 ping toutes les 5 mn vers
numericable pour detecter le up/down de mes lignes.
Mais comme je suis éligible chez la fibre d'orange, je crois que je vais
migrer une ligne en fibre.

Merci encore pour tes conseils très avisés.

Samuel.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/551A54E5.4080002@ingescom.com