La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: jeremyp3 le 19 avril 2019 à 23:29:00
-
Bonjour à tous,
comme le titre l'indique, je pense rencontrer un souci qui n'en est peut être pas un avec wireguard.
voici les paramètres de base: chez moi, connexion orange ftth 1000/300 mbps. chez ma mère, connexion sosh 300 mbps symétrique.
depuis chez ma mère PC en ethernet, je connecte mon wireguard à la connexion de chez moi.
si je télécharge depuis le vpn un fichier sur mon lighttpd local, j'ai le débit max de mon upload, entre 32 et 34 MO/s.
par contre, depuis le vpn toujours, si je télécharge un fichier sur ping.online.net ou ipv4.testdebit.info, le débit ne monte pas plus haut que 15 à 17 MO/s. On dirait que pour gérer le download et l'upload en même temps vers mon vpn, la fibre a du mal a tout gérer ...
je précise qu'il y a une faible latence entre les deux FTTH, environ 3 ms en moyenne.
propriété des machines:
serveur:
debian stretch
noyau: Linux routeurlinux 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux
ma machine:
debian testing
noyau: Linux jerem-debian 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux
du coup, mes questions:
- est-ce que ce comportement est normal ?
- est-ce qu'il y aurait moyen d'améliorer ça ?
merci,
Jerem
-
Je n'ai pas bien compris ton histoire de 'télécharge un fichier sur ping.online.net ou ipv4.testdebit.info' ...
Sinon comme tout vpn, wireguard est tres lié a la puissance cpu des extrémités. regarde sous htop (ou top) la charge cpu pendant un transfert.
-
bonjour,
arf, je pensais que c'était simple pourtant.
ben la grande différence c'est que quand je télécharge un fichier sur le serveur du vpn j'utilise que le sens montant de ma liaison fibre alors que si je télécharge un fichier externe sur ping.online.net ou ipv4.testdebit.info avec ma machine cliente, j'utilise les deux sens en même temps vu que je télécharge via ma connnexion fibre et que je suis connecté au vpn, et que ma ftth est la route par défaut.
c'est plus clair ainsi ? :)
Jerem
-
"télécharge sur" = "télécharge depuis" dans ton language ?
cas 1 , vitesse max de A (= 300, upload box2 vers le Net):
pc(client wg) <-- box 1 <-- fibre <-- internet <-- fibre <-A- box2 <-- serveur wg <-- serveur lighttpd <-- fichier
cas 2 , vitesse pas max:
pc(client wg) <-- box 1 <-- fibre <-- internet <-- fibre <-A- box2 <-- serveur wg <-- box2 <-B- fibre <-- internet <--fichier chez Online
(j'ai dupliqué box2 expres pour voir le chemin mais bien sur y'en a qu'une :))
A = upload box 2 = 300
B = download box 2 = 1000
y'a pas de raison qu'une box ne supporte pas 300 down +300 up en meme temps (plus ce n'est pas dit par contre).
c'est probablement le serveur wg qui n'arrive pas a suivre ?
-
re,
le schéma est bon a une chose près. chez moi il y a pas de box. la fibre est directement connecté sur le serveur, ou se trouve lighttpd et wg.
Directement sur le serveur si je fais un ping.online.net/1000Mo.dat
2019-04-20 22:58:30 (93,4 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
pour le processeur du serveur, c'est un:
model name : Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz
du coup ça me confirme que les 15 à 17MO/s quand je télécharge un fichier en externe ne sont pas normal ...
petite information à laquelle je viens de penser et qui peut avoir son importance:
entre l'ONT et le serveur, il y a un netgear GS105Ev2 qui collecte toutes mes connexion (une ftth et 2 DSL) pour les redistribuer dans des vlans. je viens de penser à ça, alors si ça peut être un facteur limitant à mon problème, je signale.
merci pour votre aide :)
Jerem
-
re,
le schéma est bon a une chose près. chez moi il y a pas de box. la fibre est directement connecté sur le serveur, ou se trouve lighttpd et wg.
Directement sur le serveur si je fais un ping.online.net/1000Mo.dat
2019-04-20 22:58:30 (93,4 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
pour le processeur du serveur, c'est un:
model name : Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz
du coup ça me confirme que les 15 à 17MO/s quand je télécharge un fichier en externe ne sont pas normal ...
ça me laisse perplexe cette affaire.
si quelqu'un a une idée où regarder je suis preneur. je vais continuer de faire des tests ...
Jerem
deja met un iperf3 de chaque coté de ton tunnel wg et vérifie qu'il tourne bien a 300M dans chaque sens puis les 2 sens en temps (avec 2 fenetres ou un seul test avec l'option --bidir si tes iperf3 sont tres récents).
A priori tu n'a tester a 300M que dans un sens.
puis check le mtu aussi.
-
j'ai rajouter quelque chose qui peut avoir son importance
-
Bonjour,
me revoilà avec mon problème, qui ne concerne pas que wg en fait. j'ai testé avec un openvpn sans chiffrement, et j'obtiens les mêmes résultats.
ma dernière constatations est que plus la latence augmentes, moins le débit monte... quand je parle de latence, c'est moins de 30MS.
un iperf donne bien 300 mbps dans chaque sens quand je fais l'iperf sur mon serveur ou sur le pc.
donc si je résume:
téléchargement depuis mon pc connecté en wg sur mon serveur directement 300 mbps.
téléchargement depuis mon serveur sur le pc conecté en wg derrière la livebox toujours: 300 mbps.
le souci est quand depuis le pc, je tente de télécharger depuis la connexion internet du serveur, qui est en 1000/300 mbps, la ça merdoit.
Y a-t-il des choses a vérifier, taille de buffer ou autres joyeuseté sur le serveur, parce que je pense (peut être à tord) que c'est lui le coupable.
le serveur tourne sur une debian stretch mis à jour depuis jessie.
merci si vous avez n'importe quelle idée :D
-
ipv4 ou ipv6?
si ipv4 c'est peut-être un souci de fragmentation qui fait qu'un équipement intermédiaire n'arrive pas a suivre (le serveur par exemple).verifier que la MTU coté client est bien réglée.
-
re,
j'ai le souci en ipv4 et en ipv6.
j'ai testé toutes les MTU possible...
du coup je sèche ...
en ipv6, j'utilise du fd en adressage donc du nat, et j'ai le même problème.
mes confs de wireguard sont assez classiques
par exemple:
[Interface]
address = 192.168.80.1/24
address = fd42:42:42::1/64
Table = off
mtu = 1420
#SaveConfig = true
ListenPort = 4000
PrivateKey = xxxxx
[Peer]
PublicKey = 1wFfrpMHxxxxxxxxxxxxxlqyA=
AllowedIPs = 192.168.80.6/32,fd42:42:42::2/128
client:
[Interface]
Address = 192.168.80.6/24,fd42:42:42::2/64
mtu = 1420
PrivateKey = xxxxxxxxxxx
#ListenPort = 51820
[Peer]
PublicKey = cq2GSAE7jhwxxxxxxxxxxwz51g=
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = ftth.domain.net:4000
PersistentKeepalive = 15
du simple quoi :)
je précise que j'ai pas testé avec un autre port pour le moment
-
c'est probablement le NAT alors ... (ca nécessite un cpu costaud ou de l'optimisation).
check le cpu de l'equipement qui fait le NAT.
-
re,
si le nat était le souci, j'aurais le même souci quand je suis chez moi et que je suis en nat derrière cette machine, non ?
si on ne trouve pas d'ou viens le souci, je vais faire une réinstall propre, ça ne va pas traîner.
j'ai fais le test avec une sc de chez online, et j'ai pas le souci, pourtant elle a un processeur moins bon que le miens sur le serveur a la maison ...
c'est à devenir dingue cette histoire
jerem
-
re,
si le nat était le souci, j'aurais le même souci quand je suis chez moi et que je suis en nat derrière cette machine, non ?
non car peut-etre le cpu est suffisant pour wg ou nat mais pas pour wg + nat (double boulot à faire).
regarder le cpu (htop, top ou autre) pendant un transfert est la 1ere étape d'un diagnostic.
-
re,
de ce que je peux voir, le cpu semble etre a 6% pendant un transfrère.
une préférence de logiciel / options pour voir ça bien ?
pour rappel j'utilise un logiciel d'assistance, alors c'est pas pratique de voir des choses qui bouge tout le temps. du coup je vais vous envoyer une capture
avez vous une préférences entre top, htop, avec les options qui vont bien ?
merci.
Jerem
edit: voilà une capture voir si ça marche comme vous voulez
-
re,
bon j'avance tranquillement.
si je mets un wg sur mon serveur online, et que je le fais sortir par mon serveur a la maison, je sature mon upload sur ping.online.net. donc le nat, ne semble pas être un souci.
par contre, sur ipv4.bouygues.testdebit.info ou encore ipv4.rbx.proof.ovh.net, la ça ne dépasse pas 20MO/s
c'est super bizarre ce problème là. je suspecte une mauvaise configuration quelque part, mais je vois pas où ...
pour finir, les 3 mtr des destinations que je tests:
root@sd-xxxxx:~# mtr -zwrc10 ipv4.bouygues.testdebit.info
Start: Thu May 9 03:25:33 2019
HOST: sd-xxxxx Loss% Snt Last Avg Best Wrst StDev
1. AS??? 10.5.5.10 0.0% 10 16.4 16.3 16.2 16.4 0.0
2. AS??? 80.10.232.109 0.0% 10 17.7 17.4 16.9 17.8 0.0
3. AS??? ae113-0.ncbay102.Bayonne.francetelecom.net 0.0% 10 17.9 18.6 17.9 19.0 0.0
4. AS??? ae45-0.nrpoi102.Poitiers.francetelecom.net 0.0% 10 26.0 26.4 25.8 27.8 0.3
5. AS??? ae45-0.nridf102.Aubervilliers.francetelecom.net 0.0% 10 33.1 33.1 32.8 33.3 0.0
6. AS??? ae41-0.noidf002.Aubervilliers.francetelecom.net 0.0% 10 33.2 32.8 31.6 39.9 2.5
7. AS5410 la105.rpt01-ix2.net.bbox.fr 0.0% 10 31.4 32.0 31.4 32.5 0.0
8. AS5410 be12.cbr01-ntr.net.bbox.fr 0.0% 10 39.6 39.9 38.9 40.8 0.3
9. AS5410 la20.bsr01-ntr.net.bbox.fr 0.0% 10 37.7 38.2 37.7 38.6 0.0
10. AS5410 89.89.101.141 0.0% 10 38.6 38.6 38.3 38.8 0.0
11. AS5410 89.84.1.222 0.0% 10 38.3 38.4 37.9 39.1 0.0
root@sd-xxxxx:~# mtr -zwrc10 ping.online.net
Start: Thu May 9 03:26:48 2019
HOST: sd-xxxxx Loss% Snt Last Avg Best Wrst StDev
1. AS??? 10.5.5.10 0.0% 10 16.4 16.2 15.9 16.4 0.0
2. AS??? 80.10.232.109 0.0% 10 17.5 17.4 17.2 17.7 0.0
3. AS??? ae113-0.ncbay102.Bayonne.francetelecom.net 0.0% 10 18.2 18.6 18.2 18.9 0.0
4. AS??? ae45-0.nrpoi102.Poitiers.francetelecom.net 0.0% 10 26.2 26.4 26.2 27.0 0.0
5. AS??? ae45-0.nridf102.Aubervilliers.francetelecom.net 0.0% 10 33.4 34.0 32.9 38.9 1.9
6. AS??? ae41-0.noidf002.Aubervilliers.francetelecom.net 0.0% 10 31.8 32.6 31.5 40.7 2.8
7. AS??? 193.253.13.202 0.0% 10 31.7 31.8 31.5 32.1 0.0
8. AS??? online.dc3-2.rt.hopus.net 0.0% 10 32.5 32.5 32.3 32.7 0.0
9. AS12876 45x-s44-2-a9k2.dc3.poneytelecom.eu 0.0% 10 32.3 33.1 32.3 37.7 1.5
10. AS12876 ping.online.net 0.0% 10 32.3 32.1 32.0 32.3 0.0
root@sd-xxxx:~# mtr -zwrc10 ipv4.rbx.proof.ovh.net
Start: Thu May 9 03:28:10 2019
HOST: sd-xxxxxx Loss% Snt Last Avg Best Wrst StDev
1. AS??? 10.5.5.10 0.0% 10 16.5 16.4 16.2 16.5 0.0
2. AS??? 80.10.232.109 0.0% 10 17.5 17.5 17.2 17.7 0.0
3. AS??? ae113-0.ncbay102.Bayonne.francetelecom.net 0.0% 10 18.7 18.8 18.6 19.0 0.0
4. AS??? ae45-0.nrpoi102.Poitiers.francetelecom.net 0.0% 10 26.2 27.4 26.2 37.8 3.6
5. AS??? ae45-0.nridf102.Aubervilliers.francetelecom.net 0.0% 10 33.3 33.2 32.8 33.3 0.0
6. AS??? ae41-0.noidf002.Aubervilliers.francetelecom.net 0.0% 10 33.1 35.2 31.2 58.0 8.3
7. AS16276 be100-101.gsw-1-a9.fr.eu 0.0% 10 32.6 32.4 32.2 32.7 0.0
8. AS16276 be102.rbx-g2-nc5.fr.eu 0.0% 10 36.5 37.8 36.1 42.0 1.8
9. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12. AS16276 proof.ovh.net 0.0% 10 35.5 35.3 35.0 35.5 0.0
root@sd-xxxxxx:~#
-
oui c'est clairement pas un probleme de cpu.
voici un probleme de cpu avec wireguard qui plafonne a 200Mbps sur un ER-X:
(https://i.imgur.com/hmmfl7X.png)
pour ton souci il semblerai que ce soit un probleme avec tcp et de la latence. Regarde si tu peux augmenter/changer les tampons UDP de ton serveur et client:
pour les afficher :
sudo sysctl net.core.rmem_max
sudo sysctl net.core.rmem_default
pour mettre le max:
sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.rmem_default=26214400
Ca peut être une piste. Sinon une capture permettrait d'en savoir plus.
-
bonjour,
j'ai testé l'application des deux paramètres sur client et serveur, et testé un wget direct. aucun changement.
dans le doute j'ai redémarrer wg des deux côté, aucun changement non plus.
sur quelle interface souhaites tu la capture ? l'interface public, ou l'interface wg ?
et des paramètres spéciaux pour pas que la capture soit trop volumineuse ?
merci.
-
si je mets un wg sur mon serveur online, et que je le fais sortir par mon serveur a la maison, je sature mon upload sur ping.online.net. donc le nat, ne semble pas être un souci.
par contre, sur ipv4.bouygues.testdebit.info ou encore ipv4.rbx.proof.ovh.net, la ça ne dépasse pas 20MO/s
tu ne test qu'avec curl ou wget ? le mieux reste iperf3 quand meme, avec l'option -P4 par exemple. ca permet de voir tout de suite si c'est un souci de latence avec tcp ou pas.
sur quelle interface souhaites tu la capture ? l'interface public, ou l'interface wg ?
et des paramètres spéciaux pour pas que la capture soit trop volumineuse ?
idéalement les 2 (public et wg), pendant 5 secondes à partir du début. mais surtout le wg.
Tu peux compresser les captures et/ou ne capturer que le debut de chaque paquet (l'option -s100 de tcpdump par exemple, ne prend que les 100 premiers octets).
(attention a ne pas leak des clefs ou donnés dans les captures).
je recommande de tester avec iperf3 avant de se lancer dans des captures.
-
re,
voilà les iperfs:
online:
https://hastebin.milkywan.fr/fotipuvefa.cs
bouygues:
https://hastebin.milkywan.fr/cuviwoqibe.cs
même en iperf on voit bien la différence de débit.
Jerem
-
pas mal de 'retr' (retransmission) donc paquets qui se perdent = saturation quelque part ou un lien défectueux.
tu peux faire les meme iperf hors tunnel, depuis le serveur lui meme ?
-
re,
iperf depuis le serveur:
bouygues:
https://hastebin.milkywan.fr/parakocufa.cs
online:
https://hastebin.milkywan.fr/xemiginuke.cs
je crois que ça sent de plus en plus le sapin cette affaire ....
Jerem
-
t'as quelle latence entre ton serveur wg et Bouygues et Online ? (mtr ou ping)
-
re,
--- ping.online.net ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19027ms
rtt min/avg/max/mdev = 15.091/15.777/16.194/0.246 ms
--- ipv4.bouygues.testdebit.info ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19023ms
rtt min/avg/max/mdev = 21.668/22.133/22.268/0.197 ms
pour les 15ms, c'est le mini pour remonté a paris depuis Pau. donc ceux-la il sont incompressibles
-
recap des mesures:
online : 270 Mbps via le tunnel , 900+ Mbps du serveur wg, latence 15ms
bouygues : 150 Mbps via le tunnel , 900+ Mbps du serveur wg, latence 22ms
+7 ms de latence = 120 Mbps en moins dans le tunnel ...
faudrait test avec d'autres serveurs plus loin et plus proche pour voir si c'est cohérent.
essai avec ping-90ms.online.net ? (avec -P4 puis -P8)
-
re,
en effet, c'est pas bon du tout, ça ne dépasse pas 60 mbps avec le serveur 90ms.online.net
depuis le tunel:
p4:
https://hastebin.milkywan.fr/asapiyojif.cs
p8:
https://hastebin.milkywan.fr/amacafetup.cs
directement sur le serveur:
p4:
https://hastebin.milkywan.fr/fojakovoli.cs
p8:
https://hastebin.milkywan.fr/cacizoqame.cs
Jerem