.Shad.

Tu peux te contenter de le renommer. Oui

Non pas besoin de redémarrer le NAS, tu peux faire : ip link delete mac0 Sinon attention, je pense que tu l'avais remarqué, mais ovs_eth0 c'est le nom de ton interface principale seulement si tu utilises Virtual Machine Manager.

T'as tout compris. Mais du coup si ton NAS utilise comme DNS l'IP du conteneur Pi-Hole, il ne pourra pas faire de résolution DNS car le serveur sera injoignable. Une solution est de créer l'interface virtuelle, afin d'établir un chemin entre le conteneur et le NAS. Une autre est de faire en sorte que la passerelle passe par un autre port RJ45, si tu en as plusieurs sur ton NAS. La dernière est de configurer manuellement le DNS du NAS pour une IP qu'il peut atteindre (un serveur DNS local autre, le routeur/la box, des DNS publiques, etc...).

On se fera un Teamviewer plutôt, je te dirai quand je peux.

Pas de souci. Ce serait bien que tu désactives le forward sinon on ne pourra pas trouver le problème.

A priori DSM est donc bien exposé sur le serveur VPN (0.0.0.0 signifie toutes les interfaces du NAS). Quoiqu'il en soit, lorsque tu tapes https://ndd.fr:5001 ou https://ns.ndd.fr:5001, en étant connecté au serveur VPN sur le PC ou le Mac autrement qu'en local (je ne parle pas d'une tablette ou d'un GSM dans un premier temps), tu as un avertissement de sécurité ?

Simple, sûrement. Fastidieux, encore plus. Rapide, sûrement pas. 😛

Oui SLAAC c'est le stateless. 😉

On peut vérifier que ton interface émet ou non sur l'IP du serveur VPN, tu te connectes en SSH et tu tapes : netstat -tunlp | grep 5001

Fais F12 sur Chrome et regarde la console, soit ça mouline soit tu as un message d'erreur, ça ne peut pas être autrement.

Aléatoire dans le sens où tu ne la contrôles pas, elle est basée sur la MAC. Et ca c'est valable pour l'IPv6 "vraie" uniquement, pour les temporaires tu n'as aucun contrôle. Une distribution Linux classique (même sur Rpi) fait l'affaire. Mais c'est pas forcément évident à mettre en place. Et la fiabilité d'un Rpi est toute relative. Pour ma part j'utilise aussi SLAAC, la séparation périphériques sécurisés et moins sécurisés je la fais au niveau du réseau même (pas le même VLAN). La réservation DHCP en IPv6 ? Ca veut dire que tu as un serveur DHCPv6 pour lequel tu détermines quel préfixe en /64 ou plus que tu utilises, et que tu as défini une plage DHCP pour tes périphériques ? https://www.networkacademy.io/ccna/ipv6/stateful-dhcpv6 pour des infos sur stateful et stateless en IPv6.

Bienvenue parmi nous.

J'avais testé sur la beta je n'avais pas réussi à aller au bout de la sauvegarde, il faudra que je réessaie.

Si tu n'autorises que des IPv4, normalement ton ordinateur devrait faire un fallback vers IPv4. Il continuera d'utiliser IPv6 pour le reste. Si ça ne fonctionne pas, c'est sûrement ton architecture IPv4 et IPv6 qui fait encore des siennes. Je pense que tu devrais revoir tout ça, car ça t'a déjà amené à des comportements inattendus. @Mic13710 @MilesTEG1 IPv6 ne pose pas de problème outre mesure, simplement si on limite localement l'accès à des périphériques, il ne faut plus faire du stateless mais du stateful, donc avoir un serveur DHCPv6. Plus de génération aléatoire des IP, et donc contrôle total des IPv6 sur le réseau.

Tu obtiens quoi comme erreur ?

@Mic13710 En fait généralement le souci en créant le dossier via File Station, c'est que ça utilise un umask bien défini (chez moi c'est 0022, donc pas de droit écriture pour other). Vu que l'utilisateur d'ID 472 sur le NAS ne fait évidemment pas partie du range d'id disponibles gérés par les ACL de DSM pour utilisateur et groupe (1025+ pour les utilisateurs), 472 ne peut pas écrire dans ce dossier. Donc le mieux est généralement de chmod ce dossier pour péter les ACL de DSM et se servir de ses permissions UNIX, en temps normal bypassées. C'est un problème qu'on ne retrouve pas sur les images Linuxserver, car ils utilisent un système astucieux de mappage d'utilisateur entre le conteneur et l'hôte. Si Grafana faisait pareil, en gros tu pourrais via une variable (P)UID et (P)GID préciser à quel utilisateur du NAS correspond l'utilisateur 472 du conteneur. Dans le conteneur tu verrais les volumes montés comme appartenant à 472/root. Et sur le NAS tu verrais l'utilisateur et le groupe précisés dont les id seraient stipulées dans les variables définies ci-avant. Ca règle donc tous les problèmes de droit et permet de ne pas s'affranchir des ACL de DSM. Dans le cas de Grafana on s'en fiche un peu car le contenu des fichiers dans le dossier data n'est pas vraiment confidentiel. Donc même si en pétant les ACL un utilisateur du NAS pouvait y avoir accès, il n'en ferait rien. Je vais sûrement modifier le tutoriel pour utiliser la méthode du chmod plutôt que changer l'utilisateur exécutant le programme.

Oui. Non, aucune raison que ce soit problématique pour le NAS. Non pour les points 1 et 2, pourquoi faire ça ? Ne t'occupe pas de la résolution des conteneurs en bridge ou host, Docker a son propre résolveur DNS qui se base sur les réglages de l'hôte. Donc à moins de vouloir fonctionner différemment, tu n'as rien à faire de ce côté-là. Le Rpi va recevoir l'ordre de s'utiliser comme serveur DNS, donc il va interroger son propre port 53, sur lequel tu as normalement translaté le port 53 d'Adguard (sinon il ne serait pas accessible au reste du réseau vu qu'il est en bridge). Ce qui va le renvoyer vers le NAS. Oui, voir message de @Jeff777. Soit tu configures l'onglet Résolution dans les paramètres généraux de DNS Server. Soit à l'intérieur de la zone locale, pour ne l'appliquer qu'à cette zone. C'est surtout valable si tu crées d'autres zones (publiques, locales avec un autre NDD, VPN, etc...).

A partir du moment où tu utilises SWAG, je te conseillerais de créer un réseau bridge personnalisé comprenant SWAG et les applications qui peuvent être "reverse proxi-ées", exemple : Et dans net-proxy, qui est mon réseau où je mets toutes les applications sensées être accessibles par proxy inversé : SWAG devant communiquer avec redis également, il est aussi dans un deuxième réseau "net-db" qui contient swag et redis (j'utilise MariaDB du NAS). Pour ton problème, je t'avoue qu'à distance comme ça c'est un peu compliqué. Je pense que le problème est ailleurs. Il faudrait qu'on puisse se faire un Teamviewer.

Depuis quel périphérique le ping ? le NAS ?

En fait le point 8 dit de démarrer (start) le service car il n'est pas préexistant. Dans ton cas il faut remplacer start par restart. 😉

Tu dois redémarrer le service. systemctl restart media-moi-ds119j.mount Si tu fais daemon-reload, tu prends juste en compte les modifications dans les fichiers service, mount, etc... mais ça ne les relance pas. C'est peut-être tout simplement ça ton problème. 😉 Aucune idée, mais si non nécessaire alors il faut s'en passer. Laisser SMB2 et large MTU en protocole minimum et SMB3 en maximum. Je ne sais plus. 😄

A priori comme DSM 6, les services sont arrêtés et les volumes de données (/volumeX) sont démontés donc aucun risque d'endommager tes données.

Change le protocole SMB maximum pour SMB3. Et reteste (en laissant par vers=3.0 dans un premier temps). Une bonne raison d'autoriser le protocole SMB1 ? Du matériel non compatible avec des versions plus récentes ?

@rodo37 Possibilité d'ajouter cette section dans la liste des applications C2 ? 🙂

@Swagme Concernant ta configuration access control d'Authelia, pour moi elle est ok, hormis 2 remarques : Je ne vois pas pourquoi tu mets ton IP publique fixe dans le réseau internal L'ordre a son importance, je vois que as trié dans le sens bypass -> two_factor, je te conseillerais de trier plutôt par network. Donc dans ton cas d'abord ce qui prend origine dans le réseau "internal" puis le reste, avec en seconde règle de tri la règle appliquée actuellement. On est d'accord que tu souhaites utiliser un accès 2FA que tu sois en interne ou en externe ? car c'est ce qu'implique ta configuration actuelle. Je n'ai pas trouvé ce fichier. Il se situe où ? Est-ce que Adguard serait en mode host sur ton NAS ? Si tu pouvais mettre une impression d'écran de ton fichier adguard.subdomain.conf ? Et éventuellement du docker-compose d'Adguard (ou simplement dire comment il est configuré, si tu utilises un autre moyen) ? On dirait que plusieurs problèmes se cumulent, les délais à rallonge font penser à des soucis liés au DNS, mais l'erreur 500 à un problème de configuration de SWAG, pas d'Authelia. C'est le fichier /etc/resolv.conf de quoi ? Car là tu as juste une résolution publique, le serveur DNS local n'est pas exploité (sauf en IPv6).