Auteur Sujet: WireGuard & Proxy UDP : débit bridé étrange / inexpliqué (Lu 842 fois)

benj · « **Réponse #12 le:** **Hier** à 17:23:29 »

Citation de: ppn_sd le Hier à 17:17:24

Un problème de routage ou une difficulté supplémentaire liée à UDP certainement.

Oui il y a visiblement un problème, mais je n'arrive pas à déterminer où il se trouve...

Citation de: ppn_sd le Hier à 17:17:24

Un tunnel classique VPS <=>VM et un WG pour la mobilité entre PC <=> VPS ne suffirait pas ?

J'avoue ne pas être très séduit par le forward/proxy UDP/SOCAT. Mais j'ai peut-être tort.

Dans les faits je pourrai me contenter d'exposer un DDNS et me connecter directement sur l'IP de ma Livebox, mais le but ici était me connecter sur le VPS pour ensuite retransmettre les paquets vers ma Livebox.

Là j'en suis simplement au stade où je souhaite juste comprendre le pourquoi du comment. Parce que, pour moi, c'est énigmatique.

kgersen · « **Réponse #13 le:** **Hier** à 21:49:46 »

socat avec 8192 par défaut ca ne doit pas etre performant non ? il faut l'évaluer en direct pour voir son impact.

j'ai fait quelques tests en local (avec 127.0.0.1 donc). iperf3 qui envoi a 20Gbps

en direct: recu 20Gbps
via un socat sans -b: 70% de perte (4.5 Gbps environ)
via un socat -b 65536: 45% de perte (9 Gbps environ)
en montant plus la valeur -b je ne gagne pas plus de débit.

reproduction du test:
ouvrir 4 terminux sur une machine Linux:
terminal 1: iperf3 -s
terminal 2 (reverse proxy udp): socat UDP4-LISTEN:51820,fork, UDP:127.0.0.1:5201
termlnal 3 (reverse proxy tcp) : socat TCP4-LISTEN:51820,fork, TCP:127.0.0.1:5201

(il faut 2 proxy car iperf3 en udp a besoin d'un session initiale en tcp).

dans le terminal 4 on fait les test avec iperf3
en direct: iperf3 -u -c 127.0.0.1 -b 20g (donne le débit de référence, a voir dans terminal 1 coté serveur donc).
via le rp: iperf3 -u -c 127.0.0.1 -b 20g -p 51820

dans le terminal 2 on peut rajouter -b 65536 pour tester l'impact. eventuellement ajuster pour trouver la valeur opti.

apres socat c'est pas le top pour faire cela.

benj · « **Réponse #14 le:** **Hier** à 21:53:40 »

Merci, je vais tester ça !

Que recommanderiez-vous en lieu et place de socat ?

kgersen · « **Réponse #15 le:** **Hier** à 21:58:09 »

Citation de: benj le Hier à 21:53:40

Merci, je vais tester ça !

Que recommanderiez-vous en lieu et place de socat ?

je ne sais pas , ce n'est pas un cas d'usage fréquent hormis a mettre un vrai firewall et faire un port forwarding. donc un pfsense par exemple (meme pas sur que ca soit aussi performant. il faut eventuellement de l'accelaration matérielle voir un truc utilisant ebpf)

apres je n'ai pas tout lu donc c'est peut etre un https://fr.wikipedia.org/wiki/Probl%C3%A8me_XY

c'est quoi le but principal ? y'a IPv6 de nos jours donc peut-etre pas besoin de toute cette complexité ?

benj · « **Réponse #16 le:** **Hier** à 22:03:39 »

Citation de: kgersen le Hier à 21:58:09

c'est quoi le but principal ? y'a IPv6 de nos jours donc peut-etre pas besoin de toute cette complexité ?

L'objectif c'est d'utiliser le VPS comme point d'entrée pour ne pas dépendre de l'IPv4 de l'ISP (car de plus en plus il y a du CGNAT), et il se peut qu'un jour, un simple port forwarding ne soit alors plus possible.

Du coup, le plan initial était le suivant :
- Créer un premier tunnel WG entre le VPS et le routeur Mikrotik
- Ajouter un entrée de proxification UDP dans Traefik sur le VPS pour rediriger VPS:51820/udp vers "VM WG":51820/udp

Sur VM WG est installé wg-easy et c'est ce serveur WG qui permet d'accéder aux divers services auto-hébergés.

Citation de: kgersen le Hier à 21:58:09

y'a IPv6 de nos jours donc peut-etre pas besoin de toute cette complexité ?

C'est vrai. C'est peut être la solution la plus simple. Il faut que j'y mette. Mais j'aimerai tout de même comprendre ce qui bride le débit dans la configuration actuelle...

kgersen · « **Réponse #17 le:** **Hier** à 22:41:43 »

donc du wireguard dans du wireguard ? (ou j'ai pas compris).

Sinon Tailscale c'est simple.

benj · « **Réponse #18 le:** **Hier** à 22:43:38 »

Citation de: kgersen le Hier à 22:41:43

donc du wireguard dans du wireguard ? (ou j'ai pas compris).

Oui c'est bien ça, il y un tunnel dans un tunnel (oui je sais, c'est pas top).

Citation de: kgersen le Hier à 22:41:43

Sinon Tailscale c'est simple.

Oui c'est sûr, mais j'aimerai autant ne pas dépendre d'un service tiers.

kgersen · « **Réponse #19 le:** **Hier** à 22:48:01 »

Citation de: benj le Hier à 22:43:38

Oui c'est bien ça, il y un tunnel dans un tunnel (oui je sais, c'est pas top).

en général tunnel dans un tunnel on évite car ca tue souvent les performances de tcp dans le tunnel intérieur.

Citation de: benj le Hier à 22:43:38

Oui c'est sûr, mais j'aimerai autant ne pas dépendre d'un service tiers.

y'a headscale la version self hosted de Tailscale. ( https://github.com/juanfont/headscale )

benj · « **Réponse #20 le:** **Hier** à 22:57:31 »

Citation de: kgersen le Hier à 22:48:01

y'a headscale la version self hosted de Tailscale. ( https://github.com/juanfont/headscale )

Headscale j'avais vu en effet. Après on dépend toujours de Tailscale pour les clients iOS / macOS de Tailscale. Mais oui, c'est une solution envisageable si je n'arrive pas à faire autrement.