Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • État Nouveau
  • Pourcentage achevé
    0%
  • 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

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.

nbanba a commenté le 28.12.2022 10:42

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

Admin

Sur le raspberry depuis le site C, quel est le résultat de la commande suivante ?

ip route get <ip_du_serveur_plex> 

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

cyr06 a commenté le 03.01.2023 16:32

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

cyr06 a commenté le 04.01.2023 07:36

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)

Admin

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.

et plex ne trouve pas son PMS (localement les adresses sont en 192.168.1.XXX)

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 ?

cyr06 a commenté le 06.01.2023 14:29

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…

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

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:

nc 192.168.10.252 32400
quoique remarque depuis un navigateur web ca fonctionne bien…

Derrière le tunnel wireguard ?

cyr06 a commenté le 06.01.2023 15:27

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

nbanba a commenté le 06.01.2023 16:44

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

cyr06 a commenté le 06.01.2023 18:20

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

Admin
tcpdump -nni -vvvtt 'host <ip_du_raspberry> and port 32400' → me donne une erreur "tcpdump -vvvtt : no such device"

il faut spécifier le nom de l'interface après le "-i"

→ 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

"ip route"

Il devrait y avoir un ligne comme suit:

default via <ip_de_la_freebox> dev ...

Est-ce que vous avez modifié le fichier de configuration wireguard ?

cyr06 a commenté le 06.01.2023 18:54

ha mais quand je dis que c'est au dessus de mes compétences ;) donc avec la bonne syntaxe ca donne:

tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
1673030934.819975 IP (tos 0x0, ttl 63, id 10174, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.27.66.40411 > 192.168.10.252.32400: Flags [S], cksum 0xbf0d (correct), seq 3452099077, win 64860, options [mss 1380,sackOK,TS val 3685631091 ecr 0,nop,wscale 7], length 0
1673030934.820043 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.252.32400 > 192.168.27.66.40411: Flags [S.], cksum 0x24cc (correct), seq 1711313558, ack 3452099078, win 65160, options [mss 1460,sackOK,TS val 1116167574 ecr 3685631091,nop,wscale 7], length 0
1673030934.840814 IP (tos 0x0, ttl 63, id 10175, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.27.66.40411 > 192.168.10.252.32400: Flags [.], cksum 0x5011 (correct), seq 1, ack 1, win 507, options [nop,nop,TS val 3685631112 ecr 1116167574], length 0
1673030954.846418 IP (tos 0x0, ttl 64, id 4821, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.252.32400 > 192.168.27.66.40411: Flags [F.], cksum 0x01d3 (correct), seq 1, ack 1, win 510, options [nop,nop,TS val 1116187600 ecr 3685631112], length 0
1673030954.869676 IP (tos 0x0, ttl 63, id 10176, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.27.66.40411 > 192.168.10.252.32400: Flags [.], cksum 0xb398 (correct), seq 1, ack 2, win 507, options [nop,nop,TS val 3685651141 ecr 1116187600], length 0

ip route donne

default via 192.168.10.1 dev enp0s3 proto dhcp src 192.168.10.252 metric 100 
192.168.10.0/24 dev enp0s3 proto kernel scope link src 192.168.10.252 
192.168.10.1 dev enp0s3 proto dhcp scope link src 192.168.10.252 metric 100 

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

Admin

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

 WireGuard.DNS = 8.8.8.8, 1.1.1.1

Est-ce vous pouvez essayer de baisser la MTU de l'interface ?

ip link set dev wg0 mtu 1360
cyr06 a commenté le 06.01.2023 19:11

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

cyr06 a commenté le 06.01.2023 22:21

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 !!

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

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.

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 ;)

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

cyr06 a commenté le 06.01.2023 23:53

via la 4G et la delta A j'obtiens :

Flex:~ # ping6 google.com
PING google.com (2a00:1450:4007:81a::200e): 56 data bytes
ping6: sendto: Network is unreachable

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

nbanba a commenté le 07.01.2023 03:57

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

cyr06 a commenté le 07.01.2023 08:20

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

nbanba a commenté le 07.01.2023 09:39

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

cyr06 a commenté le 07.01.2023 15:50

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

nbanba a commenté le 07.01.2023 16:17

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

cyr06 a commenté le 10.01.2023 08:52

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

cyr06 a commenté le 10.01.2023 09:12

j'ai tenté de faire un fichier gai.conf dans /storage/.config avec ça

         label  ::1/128       0
         label  ::/0          1
         label  2002::/16     2
         label ::/96          3
         label ::ffff:0:0/96  4
         precedence  ::1/128       50
         precedence  ::/0          40
         precedence  2002::/16     30
         precedence ::/96          20
         precedence ::ffff:0:0/96  100

Mais je ne suis pas sûr qu'il soit pris en compte

cyr06 a commenté le 10.01.2023 09:14

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

nbanba a commenté le 10.01.2023 10:02

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…)

vi /etc/gai.conf
<chariot en début de la 1è ligne décommentée>
<CTRL+v>
<descendre avec les flèches jusqu'en bas du fichier>
<SHIFT+i>
#
escape
escape
:w
i
<<put content :   
         label  ::1/128       0
         label  ::/0          1
         label  2002::/16     2
         label ::/96          3
         label ::ffff:0:0/96  4
         precedence  ::1/128       50
         precedence  ::/0          40
         precedence  2002::/16     30
         precedence ::/96          20
         precedence ::ffff:0:0/96  100
end put content>>

escape
:x

___

Après si c est un souci de droit, on peut le savoir facilement (retournez ici l'output des commandes suivantes):

root@librelec # ls -l /etc//gai.conf
root@librelec # ls -lZ /etc/gai.conf
root@librelec # stat /etc/gai.conf
root@librelec # df .
root@librelec # cat /proc/mounts

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 :

ip a | grep inet6

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:

ip -6 route show  

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 :

# disable net ipv6 : 
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

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

nbanba a commenté le 10.01.2023 10:22

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

mount -o remount,rw /

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

Admin

@cyr06

Pour compléter les suggestions de nbanba, vous pouvez désactiver l'IPv6 temporairement:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1

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.

nbanba a commenté le 10.01.2023 10:58

Bonjour

@mmakassikis : C'est wg-quick en dessous ?

Cordialement
nbanba

Admin
C'est wg-quick en dessous ?

Côté libreelec je ne sais pas.

Côté freebox, non.

nbanba a commenté le 10.01.2023 17:25

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:

Trafic proxifiable arrivant du LAN de la DMZ interne: (sens <--)
  @(freebox) <-----> Firewall <----DMZ-ext-v90----> VM(inside freebox delta) <----DMZ-int-v80----> Firewall <---- Local-net-v20,30,...

Trafic routable arrivant du subnet local de la freebox: (sens <--)
  @(freebox) <-----> Firewall <----DMZ-ext-v90----> VM(inside freebox delta) <----FBX-LAN-v100----> Firewall <---- Local-net-v20,30,...

table de routage d'1 namespace

17:30:24 root@14RV-FSRV-01:~# ip netns exec pia-nb bash ip r
default via 10.0.90.250 dev pia-nb90 
10.0.80.0/24 dev pia-nb80 proto kernel scope link src 10.0.80.200 
10.0.90.0/24 dev pia-nb90 proto kernel scope link src 10.0.90.200 
192.168.100.0/24 dev pia-nb100 proto kernel scope link src 192.168.100.200 

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

nbanba a commenté le 12.01.2023 07:59

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

cyr06 a commenté le 16.05.2023 20:11

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…

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche