- État Nouveau
- Pourcentage achevé
- Type Anomalie
- Catégorie Services locaux → Serveur VPN
- Assignée à Personne
- Système d'exploitation Freebox Server V7 (Delta)
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 4.7.3
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par cyr06 - 27/12/2022
FS#37540 - vpn wireguard & libreelec / plex
Bonjour
j’utilise, sur un site A disposant d’une Freebox delta, une VM avec Plex Media Serveur.
Sur ce même site A j’utilise P2F sur le player devialet et cela fonctionne très bien.
Sur un autre site B, disposant d’une fibre bouygues, j’utilise un Raspberry avec libreelec 10.0.3 avec kodi 19.4 et l’extension plex. le tout avec un tunnel wireguard pour aller sur le site A. Cela fonctionne très bien.
Sur un 3eme site C, je faisais la même chose que le B mais via un partage de connexion 4G, cela marchait pas trop mal, au débit près. Je suis donc passé sur une box delta S. Mais le même Raspberry avec le même kodi et la même extension plex dit alors que mon serveur PMS est introuvable. Si je rebascule en 4G il le trouve !!
Je ne comprends pas mais il doit y avoir un problème lié au fait que le tunnel entre 2 freebox delta est un peu particulier et empêche plex de trouver le serveur.
Avez vous une explication et une correction possible ?
Pour être complet, sur le site C, je peux utiliser plex sur mon téléphone avec l’appli ou via le navigateur.
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Bonjour
Ça sent le souci de gateway ou de routage retour…
L'aspect mobile de la connexion 4G est également à prendre en compte, il y a fort à parier que le device fournissant la 4G ait une IP privée et fonctionne au niveau du VPN comme un client dans une topologie HUB & SPOKE et non comme un des sites dans une topologie SITE TO SITE (comme le ferait à priori la DeltaS)
Merci de préciser :
- le plan d'adressage de chacun des sites
- les IP de chacun des devices sur chacun des sites
- la table de routage de chacun des devices sur chacun des sites
- qui est la gateway de qui
- un micro schéma (fait avec des "/-_>|\…" aiderai)
Avec ces informations, on comprendra mieux votre problématique (quand on n'a pas sois même monté la solution)
Merci
Cordialement
nbanba
Sur le raspberry depuis le site C, quel est le résultat de la commande suivante ?
Je suspecte que le même sous réseau est utilisé pour le LAN sur les sites A et C, et le raspberry essaie de joindre le serveur plex dans le réseau local plutôt que via le tunnel wireguard.
L'agrégation 4g pose aussi des pbms de routage
Merci de vos retours (malheureusement je n'ai pas eu les notifs email c'est pourquoi je tarde un peu)
Sur le site A je suis en 192.168.10.XXX mon PMS est en VM 192.168.10.252
Sur le site C je suis en 192.168.83.XXX mon kodi a pour adresse 192.168.83.252
quand je passe par wireguard je prends une adresse 192.168.27.XX
Je n'utilise pas de routage en plus
je ne peux plus faire la commande demandée ce soir mais j'essaierai demain depuis un site D qui a la même config que le C.
En tout cas, sur le site B (qui est avec fibre Bouygues 192.168.1.XXX) ça fonctionne très bien
J'espère être assez clair dans mes explications
Encore merci de votre intérêt
donc depuis une connexion 4G la commande ip route get <ip_du_serveur_plex> donne
192.168.10.252 dev wg0 src 192.168.27.66
et plex trouve bien son PMS (localement les adresses sont en 192.168.51.XXX)
et depuis la box delta donne
192.168.10.252 dev wg0 src 192.168.27.66
et plex ne trouve pas son PMS (localement les adresses sont en 192.168.1.XXX)
D'accord, donc le traffic passe bien par le tunnel WireGuard dans les deux cas, et il ne semble pas y avoir de conflits sur l'espace d'adressage.
Est-ce plex remonte un message d'erreur plus explicite ?
Est-ce que le serveur plex est censé répondre au ping (et si oui, avez-vous testé le ping) ?
Est-ce que depuis le raspberry vous arrivez à pinger la box distante ?
je n'ai pas de message plus explicite malheureusement de la part de plex, du moins je ne sais pas le trouver s'il y en a un.
Le serveur plex et la box distante répondent bien au ping de la part du Raspberry dans les 2 cas (delta ou 4g)
Question naïve : pour accéder au PMS, il faut spécifier un port (32400 en base) est ce que ce ne pourrait pas être le problème ? quoique remarque depuis un navigateur web ca fonctionne bien…
Le VPN en soit ne bloque pas l'un ou l'autre port. Du moment que le firewall côté PMS (s'il y en a) authorise le port c'est bon. S'il y a un firewall, pensez à vérifier qu'il n'y a pas de règles spécifique à l'IP source.
Si netcat est installé sur votre raspberry, vous pouvez tester l'établissement d'une connexion TCP:
Derrière le tunnel wireguard ?
intéressant, alors :
nc 192.168.10.252 32400 ne répond rien (sauf un punt! lorsque je fais un ctrl X)
là où nc 192.168.10.252 80 ou 8080 me redonne le prompt immédiatement (d'ailleurs j'ai l'impression que n'importe quelle valeur me redonne le prompt)
après je ne connais pas ce que dois faire cette fonction :)
(le ping marche toujours bien)
je n'ai pas de firewall outre celui de ma freebox delta qui héberge mon PMS.
Derrière le tunnel wireguard ? → oui derrière le tunnel
Bonjour
Désolé, pas reçu de notif des échanges…
Sur 192.168.10.252 pouvez vous faire un :
tcpdump -nni -vvvtt 'host <ip_du_raspberry> and port 32400'
Puis vous refaite le
nc -v 192.168.10.252 32400 depuis le rapsberry
ou nc -vz 192.168.10.252 32400 (scan mode si supporté par votre version de netcat)
Et vous regardez si les paquets arrivent sur 192.168.10.252
Si oui, recommencez en faisant juste:
tcpdump -nni -vvvtt 'host <ip_du_raspberry>'
vous verrez les paquets de réponse repartir (si ils repartent)
et la regardez les entêtes (ou postez ici les traces pour analyse) pour avoir la destination et vous verrez si ça répond bien à la source ou à la bonne gateway qui connait le chemin du subnet de la source dans sa table de routage
Si ça ne répond pas, il faut trouver l'équipement qui bloque le flux.
Avez vous du NAT par endroit sur la route ? (sur le site source ou sur le site de destination)?
Et vérifiez sur 192.168.10.252 que la freebox locale de ce réseau est bien la gateway de 192.168.10.252
Car soit il y a un équipement qui bloque le port 32400 depuis le site source ou il y a la deltaS, soit dans certains cas, les équipements se trouvent et arrivent à communiquer en L2 grace aux requêtes de broadcast (arp) mais quand il y a du routage, ces équipements ne parlent pas à la bonne gateway ou la gateway ne connait pas le remote subnet donc le flux retour ne passe pas
Et à tout hasard, sur le raspberry, pourriez vous faire en root :
iptables -vnL
nft list ruleset
et comme wireguard utilise en général la table de routabe numéro 51820
ip r s t all
Et question au cas ou : Y a t'il un firewall entre le rapsberry et la DeltaS locale ? un routeur ?
PS: sur le serveur PLEX, il serait bien de jouer également les commandes
iptables -vnL
nft list ruleset
et
ip r s t all
Dernier point, avez vous une IP failover pour la DeltaS ?
avec 100% des ports pour la connexion de la deltaS ?
Je ne vois pas trop pourquoi ça serait en cause, mais le fait que ça fonctionne depuis Bouygues et en 4G et pas depuis la DeltaS est surprenant.
Le fait que votre nc sur le port 32400 bloque montre que le port soit n'est pas ouvert (je veux dire bloqué quelque part par qq chose) soit que la réponse de la machine PMS est faite à une mauvaise gateway
Une différence majeur entre la DeltaS et les 2 autres connexions c'est que de base, si vous ne demandez pas d'IP failover disposant de 100% des ports, Free vous livre la connexion avec 1 IP pour 4 abonnés proches, chacun ayant 25% des ports de NAT vers sa connexion.
Sur du réseau privé interne à Wireguard, je ne vois pas trop pourquoi ça aurait un impact (sauf si vous avez du source nat sur le réseau wireguard du site ayant la deltaS), mais si dans le tunnel wireguard le rapsberry se présente au serveur PMS avec l'IP publique de la DeltaS au lieu de l'IP privée du rapsberry sur le subnet wireguard local du site de la deltaS, et que le port 32400 n'est pas dans la plage de port attribuée à la connexion de la DeltaS il est possible qu'un "helper" sur la box (deltaS) shoot les flux qui sont hors de la plage de port assignée à la connexion.
Bref, juste par design à votre place je vérifierai ce point et par principe, je demanderai une ip failover (c'est gratuit) histoire d'avoir une "vraie" connexion internet avec notamment l'accès aux ports standard utilisés sur internet (ports inférieur à 1024, genre https, ssh, ike, etc…)
Cordialement
nbanba
Bonsoir
merci pour cette réponse exhaustive, te ça me rassure je ne suis pas le seul à ne plus recevoir les notifications. (si jamais Thibault nous lit;)
Alors clairement tout cela dépasse mes compétences réseaux. J'ai tout de même essayé du mieux que je pouvais.
tcpdump -nni -vvvtt 'host <ip_du_raspberry> and port 32400' → me donne une erreur "tcpdump -vvvtt : no such device"
nc -vz 192.168.10.252 32400 → me donne "open"
Et vérifiez sur 192.168.10.252 que la freebox locale de ce réseau est bien la gateway de 192.168.10.252
→ j'ai un doute sur ce point car j'ai fait une VM sur la delta en attribuant une IP fixe mais je n'ai jamais rien spécifié d'autre
je ne vois pas la Gateway quand je fais un "if-config -a" je ne sais pas si c'est normal
Les diverses commandes donnent
FlexP:~ # iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
FlexP:~ # nft list ruleset
-sh: nft: not found
FlexP:~ # ip r s t all
default dev wg0 scope link
1.1.1.1 dev wg0 scope link
1.1.1.1 via 192.168.1.8 dev eth0 8.8.8.8 dev wg0 scope link
8.8.8.8 via 192.168.1.8 dev eth0 82.64.xxx.xxx via 192.168.1.8 dev eth0
192.168.1.0/24 dev eth0 scope link src 192.168.1.200
192.168.1.8 dev eth0 scope link
les lignes en gras ne sont pas présentes lorsque je passe en 4G je ne sais pas si c'est significatif.
je n'ai pas de firewall entre les 2 sauf celui de la freebox natif "ipv6"
ip failover est-ce pareil qu'une IP full stack (ça j'ai) ?
encore merci
je vais essayer de faire une VM plex sur une autre delta pour voir si dans l'autre sens le problème est identique. On ne sait jamais :)
Bien à vous
il faut spécifier le nom de l'interface après le "-i"
"ip route"
Il devrait y avoir un ligne comme suit:
Est-ce que vous avez modifié le fichier de configuration wireguard ?
ha mais quand je dis que c'est au dessus de mes compétences ;) donc avec la bonne syntaxe ca donne:
ip route donne
Concernant le fichier de conf wireguard de l'ai récupéré de ma delta et "importé" sur libreelec en suivant le tutoriel (j'ai recopié les valeurs sans trop réfléchir)
https://wiki.libreelec.tv/configuration/wireguard
La capture tcpdump montre que la communication se fait bien entre la raspberry et la vm en passant par wireguard. Est-ce que la capture a été faite lors d'un test avec netcat, ou bien le client plex ?
La ligne suivante explique pourquoi il y a des routes spécifiques pour 8.8.8.8 et 1.1.1.1
Est-ce vous pouvez essayer de baisser la MTU de l'interface ?
la capture a été faite avec netcat
j'ai fait la commande ip link set dev wg0 mtu 1360 sur le Raspberry, malheureusement ce soir je ne peux pas constater si il y a du mieux car je n'ai plus accès a l'interface de kodi (juste en ssh)
je vais essayer de voir si dans l'autre sens le problème se reproduit et à ce moment je pourrai voir si la commande améliore
encore merci de votre support
OK solution :
donc j'ai remonté à distance un PMS sur une delta ; celle du site C (honnêtement les VM freebox c'est dément comment ca marche bien)
Depuis le site A, avec une delta, connexion via wireguard → nickel
Sauf que, la différence entre A et C, est que sur A j'avais activé le firewall de la freebox IPV6 et pas sur le C ; si je l'active sur C même souci → pas de PMS trouvé
Donc on peut raisonnablement dire que le firewall ipv6 de la delta est à l'origine du problème. Je ne sais pas si c'est un truc à corriger mais le fait est que je vais le désactiver ;)
Ce qui m'interroge c'est que c'est lorsque le flux vient d'une Delta que ça pose problème et pas d'une 4G ou d'un autre opérateur fibre. Les cordonniers les plus mal chaussés ?
Encore merci de vos aides et bon we !!
Est-ce que depuis la connexion 4G, vous pouvez aller sur un site comme test-ipv6.com ?
Ou alors faire un "ping6 google.com" depuis la raspberry.
Le tunnel wireguard de la freebox aujourd'hui ne supporte pas le trafic IPv6, donc si cela fonctionne en IPv6 c'est que le tunnel n'est pas utilisé.
Je ne sais pas comment plex fait sa découverte serveur mais il est possible qu'un serveur tiers soit impliqué. Dans ce cas, le PMS est enregistré avec l'ipv4 de la box, et l'ipv6 de la VM. Côté client, la raspberry a de la connectivité IPv4 et IPv6 lorsqu'elle est connectée à la delta donc elle essaie de se connecter en IPv6. Et ça ne marche pas à cause du firewall.
Si le partage de connexion ne fournit pas d'IPv6, la raspberry passe en v4 et donc le trafic est routé par le tunnel.
A confirmer bien entendu :)
via la 4G et la delta A j'obtiens :
et ceci que j'ai activé ou non le firewall ipv6 de la delta C
je ne sais pas si ça infirme ou confirme votre hypothèse
bon we
Bonjour
2 truc à tester pour confirmer:
Sur la connexion 4g, pouvez vous activer l APN ipv6 et refaire 1 test (il faudra reboot le raspberry pour qu’il reinitialise complètement le reseau)?
Autre point a tester avec le "firewall ipv6 coché" et la connexion deltaS:
Dans le raspberry, editez le fichiers:
/etc/gai.conf
Et modifiez la conf pour qu’il contienne:
precedence ::1/128 50
precedence ::/0 40
precedence 2002::/16 30
precedence ::/96 20
precedence ::ffff:0:0/96 100
(Attention par défaut la dernière ligne a pour valeur 10, pas 100)
Le raspberry ne devrait plus utiliser l ipv6 en premier (quand dispo) mais la precedence ira a l ipv4 par défaut.
Cordialement
nbanba
Bonjour
j'ai réessayé ce matin et ce matin je n'arrive pas à reproduire le problème (et donc à valider vos solutions)
Hier soir, quand j'ai monté un PMS à distance, j'ai utilisé un seul user wireguard. J'étais donc connecté avec le même user et la même adresse avec mon ordi sur lequel je bricolais mes VM et avec le Raspberry.
C'est ça qui expliquait les dysfonctionnements sur cette config (peut être couplé au firewall de la delta sauf si j'ai biaisé le truc en voulant trop y croire :)
aujourd'hui avec 2 users ça fonctionne bien
je m'y perds un peu.
Il faut que je réessaie avec ma config initiale mais je ne vais pas y avoir accès ce we. Je tenterai de le faire en début de semaine.
N'est donc pas à exclure que, dans ma config initiale, mon PMS n'est pas assez à jour ou un peu défaillant.
Navré d'avoir cru trouvé la solution :)
Bonjour
Merci pour le retour.
Mais il faudrait dans tous les cas (pour vous) laisser activer le firewall ipv6 car vous n utilisez pas de vrai firewall entre la box et les equipment.
Si vous decochez la case firewall ipv6, ça revient a mettre tous vos equipment directement accessible sur internet avec 1 ipv6 public…
Extremely dangerous!
Suite à une plainte a l ANSSI et plusieurs tickets ici, j ai réussi au bout de plusieurs années à obtenir la création de cette case (quand Free a supprimer l option de desactivation complete de l ipv6 sur les freebox en 2019 je crois), ce n est pas pour que les utilisateurs la decoche, en tout cas ceux qui n ont pas de vrai firewall entre la box et leur réseau local
Et pour pouvoir décocher cette case, mais utiliser les ipv6 de la box de manière securisée comme des ipv4 rfc1918 derrière 1 routeur nat, j ai du m acheter 1 cluster de firewall professionel permettant la gestion complete de l ipv6 pour la modique somme 11000 euros (vous lisez bien, c est le prix d une voiture… il n y pas de zero en trop)
Après plusieurs semaines de configuration et de tests de ce cluster de firewall de gamme professionnelle j ai enfin pu decocher serainement la case firewall ipv6 de la freebox (et c est mon métier, si vous acheter ce job a une société spécialisée, il y en a pour le même prix que le cluster de fortigate ayant des ports 10g sfp+…)
Bref, tout ça pour dire:
Vous ne maitrisez pas le WAN ni l ipv6 et ses conséquence sur 1 sur un réseau domestique et vous n avez pas des budgets d enterprise pour acheter et maintenir des equipments de gamme professionnelle (il faut 1 local techniques, de la clim, des onduleurs, beaucoup d electricity 24h/24 et … des compétences pro …)
Donc vous laissez la case firewall ipv6 coché
Dans le cas contraire, vous configurer vos equipments professionnelle comme next-hop ipv6 pour les subnets publiques ipv6 associés a votre box (1 bloc /60 don't vous avez la main sur le premier/61) dans le menu de configuration ipv6 de la box et vous gérer ces subnets avec vos firewall pro.
Bref, c est ma recommandation.
D autre part, toutes les commandes fournis plus haut dans ce ticket fonctionne en dual stack v4 /v6 il suffit de rajouter un 6 a la command
ip r s t all ⇒ ip6 r s t all
tcpdump ⇒ tcpdump6
… Donc vous pouvez refaire l analyse en 100% ipv6 et poster ici pour examen des traces.
Cordialement
nbanba
Bonjour
Donc vous laissez la case firewall ipv6 coché → Merci pour ce rappel clair et sans appel
Je le remets illico et ferai des tests semaine prochaine avec.
Très bon we
Cyril
Bonjour
C est dans tous les cas ma recommandation.
Si l IPv6 est réelement en cause dans votre problématique, les tests et configuration du raspberry de
décrites dans mon post de 5h57 devraient régler le souci
(Surtout la modification de la precedence ipv4 / ipv6 dans le gai.conf "Get Address Info" du rapsberry)
Cordialement
Bon week-end
nbanba
Bonjour
malheureusement je n'arrive pas à modifier gai.conf
le système Libreelec donne pourtant l'accès root nativement
je ne peux pas faire de chmod non plus dessus
flute
j'ai tenté de faire un fichier gai.conf dans /storage/.config avec ça
Mais je ne suis pas sûr qu'il soit pris en compte
en tout cas clairement ce n'est pas le firewall IPV6 :) navré pour cette fausse piste.
je ne sais pas si je peux éditer mon commentaire ou j'avais crié victoire trop vite
Bonjour
le fichier à modifier est dans /etc, par exemple avec vi ou vim ou nano :
perso j'ai une préférence pour vi (après 25 ans d'unix…)
___
Après si c est un souci de droit, on peut le savoir facilement (retournez ici l'output des commandes suivantes):
Mais pour valider si le souci vient de l'IPv6, pourriez vous SVP faire le test suivant :
Sur la ligne 4G, dans les propriétés de la connexion GSM pourriez vous activer l'APN IPv6 voir si vous avez l'option l'APN IPv4+6
Puis vous rebootez le rapsberry et vous faites :
Et vous vérifiez sur votre rapsberry après reboot que vous avez bien une IPv6 soit publique sur 2000::/3 ou une IPv6 locale sur la classe fc00::/7 (pas sur la classe fe80::/10 qui est le link-local, vous en aurez de toute manière une sur ce subnet si l'IPv6 n'est pas désactivée dans le kernel)
Remarque à la lecture de vos anciens postes: Quand en 2023 on dispose du paquet 'iproute2' sur une machine, on n'utilise plus que lui pour tout la stack IP (ip address, ip route, ip link, ip neigh, ip rule, ip netns …) et on oubli les outils antédiluviens comme ifconfig
Le paquet iproute2 permet vraiment de tout faire, même du Policy Based Routing, du BGP, de l'allocation fine de bande passante, de la balance de charge, du tunnelling…
un bon résumé ici: https://paulgorman.org/technical/linux-iproute2-cheatsheet.html
Remarque2 : toutes les commandes iproute2 commençant par 'ip' supportent l'IPv6 en ajoutant l'option '-6'
ex:
En reprenant les échanges plus haut et en refaisant les mêmes tests en ajoutant l'option '-6' à toutes les commandes, cela permettrait de voir si le souci vient de là.
PS: si vous n'y arrivez pas avec le gai.conf, on essayera de blacklist le module IPv6 du kernel en créant un fichier dans /etc/sysctl.d/00-no_ipv6.conf avec dedans :
Mais bon c est un peu le dernier recours car en 2023 pour moi, on doit pouvoir gérer le dual-stack IPv4/IPv6 en jouant sur la precedence des paquets en fonction des destinations plutôt que de prendre un buldozer pour écraser 1 mouche et de désactiver complètement IPv6 (ce qui peut nécessiter de reconfigurer certains daemon du rapsberry qui chercheront un link local et une loopback en IPv6 (::1) lors de leur démarrage)
Cordialement
nbanba
Bonjour
Désolé pour le 'repost'.
Je ne connais pas librelec, mais visiblement le root filesystem est un FS de type squashfs compressé ⇒ monté en read only
Il faudrait modifier l'image à froid en modifiant cette partition depuis un autre système
vous pouvez toujours essayer
mais pas certain que ca fonctionne, ou plutôt ça ne fonctionnera très certainement pas
Si on souhaite tuner l'install de librelec, il va falloir mettre les mains dans le cambouis pour reconstruire l'image librelec (avec la bonne config dans le /etc) ou réussir à jouer avec losetup pour faire prendre ne compte des fichiers externes au système
regarder ici semble une bonne idée https://elinux.org/Squash_FS_Howto
Dans les 2 cas, un niveau "correcte" sous Linux est demandé si on ne veut pas tout casser
Cordialement
nbanba
@cyr06
Pour compléter les suggestions de nbanba, vous pouvez désactiver l'IPv6 temporairement:
La modification est perdue au reboot.
Est-ce que confirmez qu'il n'y a pas de config wireguard partagées ?
Pour éviter des surprises, chaque profil wireguard doit être utilisé sur un appareil.
Si la même configuration est utilisée en même temps sur deux appareils différents, il n'y a pas d'erreurs mais cela ne fonctionne pas.
Bonjour
@mmakassikis : C'est wg-quick en dessous ?
Cordialement
nbanba
Côté libreelec je ne sais pas.
Côté freebox, non.
Bonjour
@mmakassikis : Merci du retour.
Désolé, je profite de l'échange pour essayer de trouver une solution sur un autre point:
Est il possible de mettre la route par défaut de la freebox dans le tunnel wireguard et ainsi de faire sortir tout le trafic par un VPN ?
Aujourd'hui je n'utilise pas le WG de la freebox car je n'ai pas réussi à mettre la route par défaut de la box dans le tunnel
Voici ce que j'ai du "bricoler" pour faire sortir le trafic du LAN par un VPN WG sans installer de client sur tous les devices qui vont générer des sessions sur le réseau:
J'utilise une solution commerciale que j'ai déployée en en mode multi-head VPN connecté à plusieurs endroits du monde en parallèle, chaque connexion tourne dans une VM de la delta dans un namespace indépendant (ip netns / ip -n).
Puis pour envoyer le traffic dans les tunnels WG, chaque namespace de la VM de la delta à 3 IPs:
1 en DMZ externe vlan 90 en 10.0.90.xxx ,
1 en DMZ interne vlan 80en 10.0.80.xxx (pour exposer au LAN un SQUID, 1 SOCKS et 1 relais DNS)
1 sur le subnet local de la box vlan 100 en 192.168.100.xxx (routable avec macvlan) pour le policy based routing et pour que chaque namespace agisse comme un routeur
La route par default de chaque namespace passe par la DMZ externe qui à pour gateway un firewall centralisant tout le trafic avant de l'envoyer sur internet (au travers de la freebox), puis avec du Policy Based Routing, je fais sortir telle ou telle session par tel ou tel namespace mais ça c'est parce que j'en ai pop 12 et que c'est possible avec mon script, et que je me suis amusé avec le PBR, mais la sortie VPN sans PBR vers 1 seule destination me suffirait (route par defaut de la freebox dans le tunnel WG par exemple)
petit schéma:
table de routage d'1 namespace
Tout est dev en bash (je ne suis pas dev), si vous voulez voir le dépot est publique : https://github.com/nbanb/pia-wg-netns
C'est la seule solution que j'ai trouvé pour pouvoir faire sortir toutes les machine du lan (vlan 20, 30, 40,.. 115) par le tunnel wireguard sans exécuter de client wireguard sur chaque machine générant des sessions (je ne peux pas vraiment installer WG sur mon frigo ou ma TV connecté…)
Le flux fait donc une boucle par la freebox avant de repasser dans le firewall puis de sortir sur internet par cette même freebox. C'est moche, je vous l'accorde mais je n'ai pas trouvé d'autre solution.
Dernier souci, les capacités AES du snapdragon de la Delta sont complétement bridées par KVM.
En utilisant un cipher moderne et ultra fast (chacha20poly1305), et en mettant les 3 vCPU disponibles dans une VM qui à 8G de ram, avec 3 sessions routés j'ai à peu près 700Mb/s de trafic cumulé (UP ou DOWN) et la température du SoC de la box monte à plus de 94° …
D'ou ma question aujourd'hui… j'aimerai utiliser les capacités natives et non virtualisées Snapdragon de la delta pour executer wireguard et j'aimerai pouvoir router tout le trafic du réseau local dans le tunnel WG
En vous remerciant d'avance
Cordialement
nbanba
Bonjour
@mmakassikis:
Désolé, je n'aurais pas du poser ma question ici. Je vous envoi un mail.
@cyr06 Je n'ai pas trouver le moyen d’éditer / supprimer mon dernier poste qui ne traite pas de votre problématique. Je ne sais pas si vous avez le moyen de la faire en temps qu'auteur du ticket. Merci
Cordialement
nbanba
Bonjour
je reviens sur ce problème auquel je n'ai toujours pas trouvé de solution,
Personne n'a eu d'idée complémentaire ?
pour mémoire j'en suis resté à la désactivation temporaire de l'IPV6
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
mais rien de mieux
entre temps j'ai mis à jour mon PMS sur une version récente de ubuntu (sur la VM) mais ça ne change rien à l'histoire.
Serveur indisponible…