Auteur Sujet: wireguard souci de débit en externe (Lu 7644 fois)

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:

Code: [Sélectionner]

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:

Code: [Sélectionner]

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

kgersen · « **Réponse #1 le:** 20 avril 2019 à 11:46:24 »

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.

jeremyp3 · « **Réponse #2 le:** 20 avril 2019 à 13:07:49 »

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

kgersen · « **Réponse #3 le:** 20 avril 2019 à 22:39:49 »

"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 ?

jeremyp3 · « **Réponse #4 le:** 20 avril 2019 à 23:13:09 »

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

Code: [Sélectionner]


2019-04-20 22:58:30 (93,4 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]

pour le processeur du serveur, c'est un:

Code: [Sélectionner]

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

kgersen · « **Réponse #5 le:** 20 avril 2019 à 23:21:27 »

Citation de: jeremyp3 le 20 avril 2019 à 23:13:09

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

Code: [Sélectionner]
2019-04-20 22:58:30 (93,4 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
pour le processeur du serveur, c'est un:
Code: [Sélectionner]
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.

jeremyp3 · « **Réponse #6 le:** 20 avril 2019 à 23:24:09 »

j'ai rajouter quelque chose qui peut avoir son importance

jeremyp3 · « **Réponse #7 le:** 08 mai 2019 à 04:07:14 »

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

kgersen · « **Réponse #8 le:** 08 mai 2019 à 12:50:35 »

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.

jeremyp3 · « **Réponse #9 le:** 08 mai 2019 à 19:28:37 »

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:

Code: [Sélectionner]

[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:

Code: [Sélectionner]

[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

kgersen · « **Réponse #10 le:** 08 mai 2019 à 22:06:41 »

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.

jeremyp3 · « **Réponse #11 le:** 08 mai 2019 à 22:20:16 »

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