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

kgersen · « **Réponse #12 le:** 08 mai 2019 à 22:34:16 »

Citation de: jeremyp3 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 ?

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.

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

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

jeremyp3 · « **Réponse #14 le:** 09 mai 2019 à 03:33:16 »

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:

Code: [Sélectionner]

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:~#

kgersen · « **Réponse #15 le:** 10 mai 2019 à 15:48:17 »

oui c'est clairement pas un probleme de cpu.

voici un probleme de cpu avec wireguard qui plafonne a 200Mbps sur un ER-X:

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 :

Code: [Sélectionner]

sudo sysctl net.core.rmem_max
sudo sysctl net.core.rmem_default

pour mettre le max:

Code: [Sélectionner]

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.

jeremyp3 · « **Réponse #16 le:** 10 mai 2019 à 17:53:38 »

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.

kgersen · « **Réponse #17 le:** 10 mai 2019 à 19:35:15 »

Citation de: jeremyp3 le 09 mai 2019 à 03:33:16

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.

Citation de: jeremyp3 le 10 mai 2019 à 17:53:38

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.

jeremyp3 · « **Réponse #18 le:** 10 mai 2019 à 22:31:21 »

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

kgersen · « **Réponse #19 le:** 10 mai 2019 à 23:41:15 »

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 ?

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

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

kgersen · « **Réponse #21 le:** 11 mai 2019 à 00:22:26 »

t'as quelle latence entre ton serveur wg et Bouygues et Online ? (mtr ou ping)

jeremyp3 · « **Réponse #22 le:** 11 mai 2019 à 00:29:30 »

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

kgersen · « **Réponse #23 le:** 11 mai 2019 à 00:56:48 »

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)