La Fibre
Télécom => Réseau => 
VPN => Discussion démarrée par: benj le 01 juillet 2024 à 15:59:57
-
Bonjour,
Je solicite votre aide à propos d'un problème que je rencontre lorsque je tente de "proxifier" l'accès à mon serveur WireGuard (hébergé à mon domicile) via un VPS hébergé à Nice.
TLDR : le débit entre mon domicile (Orange ; en France) et mon VPS (en France) est d'environ 300 à 400 Mbits/s symétrique ; lorsque proxifie mon serveur WireGuard via le VPS (redirection 51820/udp vers Livebox 51820/udp) le débit est divisé par 10 et je ne trouve pas d'explication à ce phénomène.
En détails :
J'héberge à mon domicile quelques services (ex : Nextcloud) et je souhaite y accéder depuis l'extérieur. Je pourrai me contenter d'une redirection de port depuis ma Livebox Orange car j'ai un IPv4 full stack, mais pour diverses raisons je souhaiterai plutôt que le point d'entrée se situe sur un VPS. Du coup, je souhaite utiliser un VPS disposant d'une IPv4 comme point d'entrée pour me connecter à mon serveur WireGuard.
La configuration est la suivante : sur le VPS, j'utilise l'utilitaire "socat" pour rediriger le port 51820 (du VPS) vers l'IP publique de ma Livebox (port 51820), qui elle-même est configurée pour rediriger le trafic vers mon serveur WireGuard (VM WG sur le schéma ci-dessous). Problème : dans cette configuration, le débit est d'environ 30Mbits/s, alors que j'ai une connexion fibre 2Gb/600M, et que le serveur dispose d'une connexion 500 Mbits/s symétrique.
Voici ci-dessous une schéma de mon installation réseau :
(https://i.imgur.com/l4KC5a9.jpeg)
- Ma Livebox Orange est le point d'entrée depuis Internet (IP publique 86.X.X.X)
- Le réseau local (LAN) de ma Livebox est le 192.168.10.0/24, sur lequel est connecté mon MacBook (192.168.10.140)
- Sur le LAN, il y a un routeur Mikrotik (CCR2004) derrière lequel se trouve un serveur Proxmox, et plusieurs VMs hébergées dessus (sur le réseau 10.41.0.0/24)
- Le VPS sur l'Internet (IP publique 89.X.X.X)
Afin de tenter d'élucider ce problème, j'ai réalisé quelques tests :
1/ Le premier test consiste à évaluer le débit entre mon LAN et le VPS :
- MacBook --> VPS : débit mesuré d'environ 500 Mbits/s
- Détails du test :
- VPS : iperf -s
- MacBook : iperf3 -c 89.X.X.X
- VPS --> MacBook : débit mesuré d'environ 200 à 400 Mbits/s
- Détails du test :
- VPS : iperf -s
- MacBook : iperf3 -c 89.X.X.X -R
Schéma du test 1 :
(https://i.imgur.com/O9EeMym.jpeg)
2/ Le second test consiste à évaluer le débit entre la "VM iPerf" et le MacBook en profixiant la VM iPerf via le VPS :
- MacBook --> VPS --> VM iPerf : débit mesuré d'environ 400 à 500 Mbits/s
- Détails du test :
- VPS : socat TCP4-LISTEN:5201,fork TCP:86.X.X.X:5201 (VPS forwards TCP-5201 to Livebox ; Livebox forwards TCP-5201 to Mikrotik ; Mikrotik forwards TCP-5201 to iPerf VM)
- MacBook : iperf3 -c 89.X.X.X
- VM iPerf : iperf3 -s
- VM iPerf —> VPS —> MacBook : débit mesuré de 300 à 480 Mbits/s
- Détails du test :
- VPS : socat TCP4-LISTEN:5201,fork TCP:86.X.X.X:5201 (VPS forwards TCP-5201 to Livebox ; Livebox forwards TCP-5201 to Mikrotik ; Mikrotik forwards TCP-5201 to iPerf VM)
- MacBook : iperf3 -c 89.X.X.X -R
- VM iPerf : iperf3 -s
Schéma du test 2 :
(https://i.imgur.com/FE0gcNc.jpeg)
3/ Le troisième test consiste à évaluer le débit entre "VM iPerf" et le MacBook lorsque celui-ci est connecté via WireGuard à WG VM (PAS de profixication via VPS) :
- MacBook via WireGuard Tunnel —> VM iPerf : débit mesuré de 300 à 400 Mbits/s
- Détails du test :
- VM iPerf : iperf3 -s (Livebox forwards UDP-51820 to Mikrotik ; Mikrotik forwards UDP-51820 to WG VM)
- MacBook : iperf3 -c 10.41.0.3 (WG Endpoint : 86.X.X.X:51820)
- VM iPerf —> MacBook via WireGuard Tunnel : débit mesuré de 300 à 400 Mbits/s
- Détails du test :
- VM iPerf : iperf3 -s (Livebox forwards UDP-51820 to Mikrotik ; Mikrotik forwards UDP-51820 to WG VM)
- MacBook : iperf3 -c 10.41.0.3 -R (WG Endpoint : 86.X.X.X:51820)
Schéma du test 3 (en bleu le tunnel WireGuard, en rouge le trafic iPerf) :
(https://i.imgur.com/IwtRZyb.jpeg)
4/ Ce dernier test consiste à évaluer le débit du tunnel WireGuard entre la "VM iPerf" et le MacBook AVEC proxification de "WG VM" via VPS :
- MacBook via WireGuard Tunnel --> VPS —> VM iPerf : 30 à 45 Mbits/s
- Détails du test :
- VPS : socat UDP4-LISTEN:51820,fork UDP:86.X.X.X:51820 (port forwarding 89.X.X.X:51820 to 86.X.X.X:51820)
- MacBook : iperf3 -c 10.41.0.3 (WG Endpoint : 89.X.X.X:51820)
- VM iPerf : iperf3 -s
- VM iPerf —> MacBook via WireGuard Tunnel --> VPS : 30 à 50 Mbits/s
- Détails du test :
- VPS : socat UDP4-LISTEN:51820,fork UDP:86.X.X.X:51820 (port forwarding 89.X.X.X:51820 to 86.X.X.X:51820)
- MacBook : iperf3 -c 10.41.0.3 -R (WG Endpoint : 89.X.X.X:51820)
- VM iPerf : iperf3 -s
Schéma du test 4 (en bleu le tunnel WireGuard, en rouge le trafic iPerf) :
(https://i.imgur.com/FtPpITF.jpeg)
Le problème si situe donc au niveau du test n°4. Si quelqu'un a une ou plusieurs hypothèses sur la manière de régler ce problème que je n'arrive pas à expliquer, je suis à l'écoute de toutes propositions...
J'ai déjà essayé de réduire le MTU du tunnel WireGuard à 1280, et ça n'a rien changé au problème. J'ai aussi essayé d'activer le mode BBR sur le VPS comme indiqué dans ce post (https://lafibre.info/iperf/debit-illogique/), idem. J'ai aussi vérifié que chacune des machines (VPS, Routeurs, VM) ne saturent pas au niveau CPU.
Si quelqu'un ici a une idée, merci !
-
J'ai déjà essayé de réduire le MTU du tunnel WireGuard à 1280, et ça n'a rien changé au problème.
Il faut aussi réduire le MTU sur la machine VM iperf ou clamper le MSS.
-
Il faut aussi réduire le MTU sur la machine VM iperf ou clamper le MSS.
Merci pour cette indication.
Est-il possible d'ajouter une règle générique sur le routeur Mikrotik pour automatiquement clamper le MSS pour toutes les connexions venant du tunnel WG ?
-
Est-il possible d'ajouter une règle générique sur le routeur Mikrotik pour automatiquement clamper le MSS pour toutes les connexions venant du tunnel WG ?
https://help.mikrotik.com/docs/display/ROS/Mangle
Ça devrait donner quelque chose comme ça :
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
-
Merci.
Du coup j'ai concentré mes tests sur une éventuelle fragmentation des packets. Voici les quelques tests réalisés :
1/ Vérifier que le MTU est bien de 1500 octets entre mon MacBook (sur Home Network) et le VPS :
ping -s 1472 -D 89.X.X.X
1480 bytes from 89.X.X.X: icmp_seq=0 ttl=51 time=33.391ms
Du coup, on est bon = 1472 + 8 (header ICMP) + 20 (header IP) = 1500. Une valeur supérieure à 1472 renvoie bien un "Message too long".
2/ Vérifier que le MTU est bien de 1420 octets une fois connecté au tunnel WireGuard entre le MacBook et le VPS :
ping -s 1392 -D 89.X.X.X
1400 bytes from 89.X.X.X: icmp_seq=0 ttl=56 time=118.195ms
Du coup, on est bon = 1392 + 8 (header ICMP) + 20 (header IP) = 1420. Une valeur supérieure à 1392 renvoie bien un "Message too long".
3/ Réaliser le test iPerf depuis MacBook connecté au tunnel WG vers VM iPerf proxifié par VPS (c'est le scénario du test n°4 dans mon post initial) sans la règle MSS sur Mikrotik :
Extrait Wireshark capturé sur MacBook :
10.79.34.4 --> 10.41.0.3 | TCP [SYN] | MSS = 1380
10.41.0.3 --> 10.79.34.4 | TCP [SYN, ACK] | MSS = 8960
Le client WireGuard (MacBook ; 10.79.34.4) envoie donc un MSS = 1380, ce qui est logique (1380 + 20 header TCP + 20 header IP = 1420).
Pour ce qui est de la VM iPerf, elle est configurée avec un MTU = 9000 (le réseau Home Lab supporte les jumbo frames sur un réseau 10G). Du coup, par défaut iPerf renvoie un MSS = 8960, ce qui est logique (8960 + 20 + 20 = 9000).
Dans le capture complète Wireshark, on peut constater que le client envoie bien uniquement des packets de 1420 octets. Donc il ne semble pas y avoir de problème de MTU / Fragmentation à ce niveau.
Le résultat du test iPerf montre un débit de 30Mbits/s.
4/ Réaliser le test iPerf depuis MacBook connecté au tunnel WG vers VM iPerf proxifié par VPS (c'est le scénario du test n°4 dans mon post initial) avec la règle MSS sur Mikrotik :
Extrait Wireshark capturé sur MacBook :
10.79.34.4 --> 10.41.0.3 | TCP [SYN] | MSS = 1380
10.41.0.3 --> 10.79.34.4 | TCP [SYN, ACK] | MSS = 1380
La règle ajoutée sur le Mikrotik :
/ip firewall mangle
add action=change-mss chain=forward dst-address=10.79.34.0/24 new-mss=1380 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1381-65535
Le client WireGuard (MacBook ; 10.79.34.4) envoie toujours un MSS = 1380 ; et le serveur iPerf voit bien son MSS être modifié par le Mikrotik à MSS = 1380.
Le résultat du test iPerf montre toujours un débit de 30Mbits/s. Il ne semble, là encore, ne pas y avoir de problème côté MTU / Fragmentation.
J'ai aussi réalisé deux autres tests similaires aux deux précédents, à la différence près que le processus iPerf (iperf3 -s) était démarré dans le conteneur WireGuard, et non sur le machine hôte. Les captures Wireshark montrent que le MSS renvoyé est cette fois-ci de 1380 (ce qui est logique car le conteneur WG est configuré avec un MTU de 1420). Le débit reste bridé à 30 Mbits/s.
Lien vers les captures complètes Wireshark (https://mega.nz/folder/IBxyyaKJ#I_8BivBF5zn1esijAYPbZg) :
- le dossier "iperf-on-host" contient les 2 tests avec et sans la règle MSS (iperf -s sur la machine VM iPerf)
- le dossier "iperf-in-wg-easy-container" contient les 2 tests avec et sans la règle MSS (iperf -s dans le conteneur docker WG)
Si quelqu'un voit quelque chose d'anormal dans ces captures, je suis à l'écoute...
-
J'ai réalisé d'autres captures (que j'ai ajouté ici (https://mega.nz/folder/IBxyyaKJ#I_8BivBF5zn1esijAYPbZg)) concernant le forwarding des packets UDP depuis le VPS vers la VM WG (le MacBook étant connecté via le tunnel WireGuard ; toujours le scénario du test n°4).
Les fichiers suffixés "vps" sont des captures effectuées sur le VPS (89.X.X.X) ; le fichiers suffixés "vm-wg" sont les captures effectuées sur la VM WG (10.41.X.X).
Il y a deux dossiers :
- connect-wg-easy-profixied-by-socat-vps : c'est une simple connexion / déconnexion au bout de quelques secondes du client VPN "MacBook" ; on constate que tous les packets sont bien retransmis.
- iperf-wg-easy-proxified-by-socat-vps : c'est le test iPerf qui passe dans le tunnel WireGuard ; on constate qu'il y a une différence d'environ 500 packets UDP entre ce que reçoit le VPS du client MacBook, et ce que reçoit WG VM.
Les packets ne semblent pas non plus fragmentés... Une idée ?
Merci.
-
Est-ce qu'il y a une différence en changeant la taille des blocs dans socat ?
-
Est-ce qu'il y a une différence en changeant la taille des blocs dans socat ?
Je n'ai pas testé ; je suppose que l'on parle de l'option "-b" de l'utilitaire ? Par défaut il semble être fixé à 8192 (selon la documentation).
Faudrait-il plutôt le baisser ou l'augmenter ?
EDIT : à noter que j'ai aussi testé la proxification avec Traefik, et j'obtiens les mêmes résultats (~ 30Mb/s), donc ça ne vient probablement pas de socat.
-
Au vu du fait que le sujet n'intéresse pas grand monde ici, deux petites questions subsidiaires :
- Connaissez-vous des forums actifs où ce type de problème est susceptible de trouver intérêt ?
- Connaissez-vous des entreprises / freelances qui accepteraient ce type de mission debogage réseau ?
Merci.
-
Salut,
As-tu essayé une liaison WG entre le VPS et la VM Iperf ?
Que donne l'utilisation de socat avec reuseaddr ? : UDP4-LISTEN:51820,fork,reuseaddr UDP:86.X.X.X:51820
-
As-tu essayé une liaison WG entre le VPS et la VM Iperf ?
Que donne l'utilisation de socat avec reuseaddr ? : UDP4-LISTEN:51820,fork,reuseaddr UDP:86.X.X.X:51820
Bonjour,
Oui la liaison VM iPerf <--> VPS en mode site-2-site WireGuard a bien été testée et ne présente pas de problème de débits.
Je viens de tester l'option reuseaddr, ça ne change rien malheureusement...
Je ne vois vraiment pas d'où ça peut venir.
-
Un problème de routage ou une difficulté supplémentaire liée à UDP certainement.
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.
-
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...
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.
-
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.
-
Merci, je vais tester ça !
Que recommanderiez-vous en lieu et place de socat ?
-
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 à 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é ?
-
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 (https://github.com/wg-easy/) et c'est ce serveur WG qui permet d'accéder aux divers services auto-hébergés.
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...
-
donc du wireguard dans du wireguard ? (ou j'ai pas compris).
Sinon Tailscale c'est simple.
-
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).
Sinon Tailscale c'est simple.
Oui c'est sûr, mais j'aimerai autant ne pas dépendre d'un service tiers.
-
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.
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 )
-
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.
-
Toujours pas trouvé de solutions.
Du coup je réitère ma demande : connaissez-vous des entreprises / freelances qui accepteraient ce type de mission ?
Merci.
-
Toujours pas trouvé de solutions.
Du coup je réitère ma demande : connaissez-vous des entreprises / freelances qui accepteraient ce type de mission ?
Merci.
mission pour faire quoi ? ce n'est pas très clair.
-
mission pour faire quoi ? ce n'est pas très clair.
Une mission rémunérée pour trouver pourquoi le débit est bridé à 30 Mbits/s dans la configuration du test n°4. Après il faudrait aussi que je test avec un pfsense sur un VPS du même hébergeur pour voir si ça change quelque chose, mais j'en doute.