.Shad.

@PiwiLAbruti Mon pfSense en amont s'occupe déjà de tout le filtrage IPv6, donc n'arrive au NAS que le trafic que j'autorise (requêtes ICMP et clients seedbox), donc jamais remarqué de blocage. Cela dit je peux faire le test, je supprime le filtrage de pfSense, je rajoute une règle qui bannit l'espace publique 2000::/3 après mes règles d'autorisation sur mon préfixe personnel, et vérifier sur un temps donné. Je vais essayer de regarder ça cette semaine. Ce sera assez facile à vérifier avec la seedbox.

Ouais ça me semblait logique désolé, c'était à remplacer par le port que tu as affecté. 😛 Pour l'IPv6, je vois plusieurs points qui peuvent te poser problème. Est-ce que ton NAS dispose d'une IPv6 routable ? c'est déjà un préalable pour communiquer avec l'extérieur, une IP routable commencera probablement par "2a" de ton côté. Si c'est le cas, tu peux vérifier que la connectivité est fonctionnelle en faisant un : ping -6 ipv6.google.com Maintenant au niveau du pare-feu, si le but est d'accéder à ton NAS via l'extérieur en IPv6, sans utiliser de NAT, il faut autoriser le protocole ICMP, car autant ton NAS ne sera pas pingable de l'extérieur en IPv4 (ça s'arrête généralement à la box qui les refuse par défaut assez souvent), autant en IPv6 c'est problématique l'ICMP fait partie intégrante de l'établissement d'une connexion entre deux périphériques (en IPv6, ce ne sont pas les routeurs intermédiaires qui font le travail de fragmentation des paquets, mais les périphériques aux extrêmités, la MTU minimale est calculée par ces derniers et assure qu'on peut aller du point A au point Z). Moi j'ai donc une règle en entête qui autorise toutes les requêtes ICMP de toutes les sources (cela comprend IPv6 et IPv4, on ne peut pas les dissocier dans DSM, c'est dommage). Localement, un périphérique peut communiquer via son IP publique avec un autre périphérique sans passer par l'extérieur, car les IPv6 ont une notion de portée que n'ont pas les IPv4. Donc il faut aussi autoriser le préfixe de ton pool d'IPv6 alloué par ton FAI, par exemple moi j'ai autorisé 3 réseaux différents, avec un même préfixe en /56 (fourni par le FAI), mon pare-feu crée ensuite des pools /64 depuis ce /56, et j'autorise ceux qui m'intéressent dans le NAS : Personnellement, je n'ai eu aucun problème à accéder à mon NAS en utilisant le blocage GeoIP en IPv6, visiblement ils importent également les adresses IPv6. Avec tous ces points, tu devrais pouvoir accéder à ton NAS en IPv6 sans problème depuis l'extérieur. Sous réserve de ce que la box permet comme configuration au niveau du pare-feu IPv6 (mais j'ai ouïe dire que la Freebox est relativement configurable par rapport aux box concurrentes).

Ca ce n'est pas normal, voilà ce que j'ai chez moi : On voit bien que l'application est disponible pour les deux protocoles. Pour moi la longueur d'établissement de la connexion vient du fait que ton périphérique essaie de se connecter en IPv6. Mais il n'obtient qu'un timeout, et fait donc un fallback sur de l'IPv4. La question est : comment parvient-il à résoudre si le nom d'hôte utilisé n'amène que vers de l'IPv6 ? Possible qu'il essaie de passer par l'extérieur, si ta zone DNS publique a un enregistrement wildcard. Est-ce que tu as une zone DNS locale ou bien tu te sers de la zone publique et du loopback pour rester dans la boucle locale ?

J'ai subodoré un problème avec l'IPv6 car j'ai un problème quasi similaire avec une application musicale, Mopidy. Mais avec Drive jamais eu de souci. Pour le coup ça ne devrait pas être lié au port de synchro 6690, car quand on essaie de se connecter à Drive via l'application, on n'emploie pas ce port, on utilise le port de l'interface web, 5000 si pas de port personnalisé. J'imagine qu'avec un proxy inversé tu as défini un port personnalisé pour cette application. Tu peux quand même vérifier que Drive est bien exposé pour les adresses IPv6 via : netstat -tunlp | grep PORT_INTERFACE_WEB_DRIVE Est-ce que le problème se produit autant en accès local qu'à distance ? ou seulement à distance ?

Essaie de désactiver l'IPv6 sur ton routeur si c'est activé et réessaie. D'autant plus si tu utilises un proxy inversé. Pour voir si le problème vient de là.

Essaie de changer manuellement les DNS dans Panneau de configuration -> Réseau -> Configurer manuellement les DNS, et tu mets en primaire par exemple 9.9.9.9 et en second 1.0.0.1. Ensuite tu réessaies.

Bienvenue parmi nous ! 🙂

@bebert73 Est-ce que tu utilises les variables HOSTFS pour translater dans le conteneur les dossiers système du NAS ? Car pour le coup ce n'est pas sensé fonctionner sans ça, et même l'utilisation de la RAM n'est pas forcément une preuve irréfutable. Mais si le measurement "net", qui correspond aux données pollées par le plugin inputs.net de Telegraf, donne toutes les interfaces de ton NAS et pas celle du conteneur, alors oui c'est indéniable ça fonctionne. Par exemple, chez moi j'ai Telegraf en host, par facilité, si regarde les interfaces de "net" j'ai celles du NAS : En bridge, j'aurais peut-être l0 et eth0, c'est tout.

Je ne pense pas qu'on soit nombreux à avoir de tels besoins, donc l'expérience pourra difficilement aider. Je pense que tu aurais des retours plus pertinents sur les forums ubiquity. Ce qui peut consommer pas mal de ressources avec le contrôleur c'est la récolte des données et le tracé des graphes. Voir si on peut éventuellement désactiver cette option. A vrai dire à ta place je testerais sur un Rpi 4 avec 4 ou 8 Go de RAM dans un premier temps si tu as ça sous la main.

La question c'est que veux-tu faire exactement. Je t'invite à créer un sujet dédié pour en discuter.

Bienvenue !

Bienvenue parmi nous !

Bienvenue ! Oublie Ipkg et regarde ce que permet Docker.

Beaucoup moins, InfluxDB embarque tout un panel de visualisations mais reste moins complet, quand j'ai testé il y a quelques mois, que Grafana. Après tu peux construire ton tableau sur InfluxDB et copier/coller la requête FluxQL sur Grafana. @bebert73 Je ne vois aucune raison que ton Telegraf supervise le NAS si tu ne passes pas par SNMP et que tu es en bridge. Un moyen simple est de vérifier si les interfaces remontées par le input.net sont exactement les mêmes que celles pollées par l'agent SNMP. Si oui, je ne me l'explique pas.

Salut et bienvenue !

Normalement si c'est une vitesse que tu veux il te faut plotter la différentielle de la valeur TxBytes sur un temps donné, 1s généralement.

A quand Johnny Knoxville et Bam Margera ? Bienvenue parmi nous !

Bienvenue ! Toujours courageux de se lancer dans ce genre d'aventures, mais entre les tutos et les réponses qu'on peut t'apporter, tu devrais rapidement y voir plus clair. 😉

Bienvenue parmi nous !

Salut @bebert73 ce que tu as fait avec Telegraf ne fonctionne que si tu l'a mis en network host, car les inputs CPU, mem, networks, etc... ne supervisent que la machine en cours d'utilisation. Si c'est en bridge, ce sont donc les données du conteneur Telegraf et pas le NAS. En host ça marchera. Mais l'activation de SNMP permet de récupérer bien d'autres données comme la version du système, la présence d'une mise à jour, les caractéristiques d'un onduleur, etc... Pour les droits pour Telegraf, je referai l'opération de zéro dans les semaines qui viennent pour voir si je n'ai pas un défaut de configuration quelque part.

Je ne pense pas car ce sera plus une refonte qu'une mise à jour, il y aurait trop à consigner.

Début de mise à jour du tutoriel.

Ca fait partie des applications qu'il est quand même plus pratique d'exposer. Il y a tout un tas d'options de sécurité intégrées à Bitwarden pour ne pas avoir à faire ça. Bitwarden exige en effet une utilisation via un port sécurisé. Il te suffit d'utiliser le proxy inversé du NAS. Tu rediriges le port 443 dans ta box vers le NAS, port à ouvrir dans le NAS aussi (par exemple pour la France uniquement). Côté certificat, tu peux utiliser les nom de domaine fourni par Synology et créer un certificat wildcard (à la demande du création, tu précises dans les domaines alias le domaine *.xxx.synology.me, "xxx" étant ton sous-domaine unique. En créant un wildcard, aucun port à ouvrir, car la validation se fait au niveau des serveurs DNS de Synology. Une fois le certificat créé, il suffira de créer une entrée de proxy inversé pour Bitwarden, qui s'exposera sur tel ou tel port en HTTP suivant la version que tu as utilisées (officielle ou Vaultwarden). Non pas viable. Un certificat wildcard comme cité plus haut se renouvelle tout seul, tu peux complètement l'oublier et ça fonctionnera, le tout gratuitement. Tu devrais jeter un œil au tutoriel du proxy inversé si tu ne sais pas de quoi il retourne exactement :

DS-101 c'est plus un ancêtre, c'est une antiquité. 🤣 Bienvenue !

Bienvenue parmi nous !