molinadiaz

Hello @.Shad., À mon tour désolé pour le délais de réponse, je suis toujours en déplacement. Alors, merci pour la petite astuce pour retrouver facilement l'ID de traitement. Tout se passe comme je l'imaginais, je peux te le confirmer : La commande ps -p <PID> au me retourne bel et bien le processus watchtower exécuté par l'utilisateur watchtower créé au préalable sur le système, et ce grâce à la stack déployée via Portainer de la manière suivante : version: "3.8" services: watchtower: image: containrrr/watchtower:amd64-latest user: xxxx:yyyy où xxxx et yyyy représentent respectivement le UID et le GID ! Pour mon container vaultwarden, même chose, il est bien exécuté par mon utilisateur vaultwarden ! Tout roule 🙂 Les processus sont mieux isolés s'ils ne sont pas gérés par root et la surface d'attaque est amoindrie (du moins, je crois et je l'espère lol). Forcément, je n'ai que le container portainer-ce qui est exécuté par root, puisque je ne suis pas en mesure de déployer une stack pour portainer lui-même si celui-ci ... n'existe pas encore ! Si maintenant il existe une manière de changer à la volée le user qui exécute le container portainer-ce (maintenant qu'il tourne) pour que celui-ci ne soit plus exécuté par root, je suis preneur ! Reste encore à se poser la question de savoir si ce sera possible de déployer des stacks si Portainer a des droits limités.

Hello @.Shad., Oui, oui 😅 Je suis toujours en déplacement. Je repasserai ici naturellement une fois que je serai un peu plus posé car j'ai quelques questions à poser, effectivement. En attendant, sais-tu pourquoi la commande ne retourne rien ? Je confirme que mon Docker est bel et bien en cours de processus, et que mes containers tournent. Par avance, merci !

Hello @.Shad., Je suis en déplacement. J'avais prévu de répondre longuement. Mais je vais morceler ma réponse afin d'avancer au compte goutte. Je voulais d'abord m'assurer de ça. Étrangement, la commande ne me retourne rien si ce n'est grep lui-même (forcément) exécuté par l'utilisateur du terminal. Comment ça se fait ? Docker avait été installé via le Centre de paquets Synology. Il tourne pourtant actuellement. Et 3 containers aussi, d'ailleurs. Merci 🙂

Merci pour vos réponses @.Shad. @bliz ! Je crois que je vais rester comme ça. C'est un peu fastidieux à gérer la première fois (c'est le seul inconvénient, en soi) mais une fois que c'est paramétré, on est tranquille. Comme dit @.Shad., je ne veux pas chmod le dossier partagé docker pour les raisons évoquées. Le coup de la VM minimale, ça ferait peut-être un peu trop de surcouche. Si je comprends bien, il y aurait DSM qui fait tourner Virtual Machine Manager (qui n'est pas installé chez moi, d'ailleurs), lui-même faisant tourner une VM légère comme Alpine Linux qui à son tour ferait tourner Docker, ce dernier exécutant mes containers ? 😅 À ce moment-là, je crois que je préférais encore faire tourner chaque container dans le home directory de son utilisateur. L'idée étant aussi de ne pas gonfler la RAM si une alternative plus légère est possible. Après tout, j'ai pas encore upgrade les barrettes du DS918+ 😂

Hello @.Shad., On est bien d'accord qu'avec : version: "3.8" services: vaultwarden: image: vaultwarden/server user: 1001:1001 C'est bel et bien l'utilisateur du système hôte ayant pour UID 1001 et GID 1001 qui exécute mon container ? Je ne me fais pas de fausse idée là-dessus ? En d'autres termes, mon container vaultwarden est bien exécuté en non-root, n'est-ce pas ? Je suis tombé sur ça : https://github.com/portainer/portainer/issues/1888 Bon, ça date un peu, c'est vrai. Et c'est pas vraiment la même image (le repo portainer/portainer est considéré comme déprécié). À ce que je comprends, le gars serait parvenu à exécuter portainer par un utilisateur non-root en mappant depuis l'extérieur un fichier config.json vide dans le container. Juste comme ça : volumes: - "./data:/data" - "./config.json:/config.json" J'ai essayé. Ça ne fonctionne pas.

Hello @.Shad., Via File Station. Cela dit, je pense que le comportement était normal, en fait. Certes, j'avais bien coché la case "Masquer les sous-dossiers et les fichiers des utilisateurs sans autorisations" dans les options du dossier partagé docker ... MAIS j'avais omis via File Station depuis mon compte administrateur de créer des permissions de type "Refuser / Contrôle Total" dans les propriétés de chaque sous-dossier de /volume1/docker/. Par exemple, pour le dossier /volume1/docker/portainer-ce (dont l'utilisateur portainer-ce est le propriétaire), et avec des permissions "Refuser / Contrôle Total" pour les utilisateurs mongodb et vaultwarden : De cette manière, et uniquement de cette manière, le dossier /volume1/docker/portainer-ce n'apparaît plus dans File Station lorsque connecté à DSM avec les utilisateurs mongodb et vaultwarden. Je crois qu'on ne peut pas isoler autrement, en fait. J'avais éventuellement songé à arrêter d'utiliser /volume1/docker/dossier_par_container_propre_à_un_utilisateur pour faire tourner chaque container dans son home directory respectif, par exemple le container portainer-ce dans /volume/homes/portainer-ce, le container vaultwarden dans /volume1/homes/vaultwarden pour m'éviter d'enregistrer les permissions à la main comme sur le screenshot juste au-dessus, mais pour tout un tas de raison cette solution me semblait pas folle. Je crois que ça aurait justement poser problème si un jour un container devait partager plusieurs dossiers, non ?

Bonjour, Synology DS918+ DSM 7.1.1-42962 Update 3 Utilisateur : portainer-ce Groupe : docker Image : portainer/portainer-ce https://registry.hub.docker.com/r/portainer/portainer-ce/ Je passe en revue chacun de mes containers Docker. L'objectif étant que chaque container soit exécuté par un utilisateur non-root. Par exemple, pour le container vaultwarden, le docker-compose.yml ressemble à ceci où user: 1001:1001 permet de faire exécuter le container par l'utilisateur PUID 1001 du groupe PGID 1001 du système hôte. version: "3.8" services: vaultwarden: image: vaultwarden/server user: 1001:1001 Tous mes containers s'exécutent en non-root. Il ne me reste plus qu'à sudo docker-compose up -d mon fichier .yml pour Portainer. Mais le coup du user: 1001:1001 ne prend pas. Voici les logs : L'arborescence ainsi que les privilèges pour config.json sur lequel il y a une permission non accordée : Merci pour votre aide. Cordialement,

Bonjour, Synology DS918+ DSM 7.1.1-42962 Update 3 Utilisateurs : mongodb, portainer-ce, vaultwarden Groupe : docker Images : mongo:4.4.9 https://registry.hub.docker.com/_/mongo/, portainer/portainer-ce https://registry.hub.docker.com/r/portainer/portainer-ce/, vaultwarden/server:latest https://registry.hub.docker.com/r/vaultwarden/server/, Dossier partagé : docker dans /volume1 Lorsque je suis connecté à DSM sur File Station avec mon compte administrateur (différent du compte utilisateur admin par défaut), je vois tous les sous-dossiers de /volume1/docker, à savoir : /volume1/docker/vaultwarden, /volume1/docker/portainer-ce et /volume1/docker/mongodb. Comme suit : Lorsque je suis connecté à DSM sur File Station avec, mettons l'utilisateur mongodb, je vois exactement la même chose. D'un point de vue sécurité, ne serait-il pas plus sage de n'afficher que le sous-dossier /volume1/docker/mongodb (et pas les autres sous-dossiers) à l'utilisateur mongodb ? Si oui, comment faire puisque tous ces utilisateurs font partie du groupe docker ? Chacun voit actuellement les sous-dossiers des autres, ça me semble pas très safe. Idéalement, j'aimerais que l'utilisateur mongodb ne puisse même pas avoir d'accès en lecture aux dossiers des utilisateurs portainer-ce et vaultwarden. Masquer l'affichage de ces dossiers dans le File Station de l'utilisateur mongodb. Possible ? L'option "Masquer les sous-dossiers et les fichiers des utilisateurs sans autorisations" est déjà cochée dans les paramètres du dossier partagé docker. Alors, étrange, non ? Merci pour votre aide. Cordialement,

Bonjour @.Shad., merci pour ta réponse ! J'ai checké la page admin de mon switch Netgear Nighthawk S8000 (celui en 192.168.C.X sur le schéma isoflow.io btw) mais il ne semble pas gérer le protocole STP. Aurais-tu deux switches gérant ce protocole à me recommander ? Je les placerais en 192.168.D.X et 192.168.E.X 😉 Aussi, j'ai cru comprendre que je pouvais encore améliorer le schéma. Pour le moment, le switch 1 et/ou le switch 2 devraient passer obligatoirement par la passerelle pour communiquer avec le switch 3. Il pourrait y avoir un multilayer switch L3 qui géreraient la communication entre tous les switches et périphériques, ce qui m'éviterait de passer par la passerelle routeur, si je comprends bien ? Mais bon, un peu overkill pour un réseau domestique, non ? 😅

Bonjour, Je désire ajouter de nouveaux périphériques réseaux à domiciles. Pour ce faire, je dois ajouter de nouveaux équipements. Je compte remplacer mon routeur Wi-Fi par un pare-feu Protecli Vault faisant office de passerelle (192.168.A.X). Je ne sais pas encore si j'utiliserai pfSense ou OpnSense. L'actuel routeur Wi-Fi sera transformé en simple point d'accès sans fil. Afin de minimiser le point de défaillance unique, chacun de mes deux NAS seront connectés à deux switch Ethernet. Considérez plutôt le schéma en pièce jointe. Ma question : pourrai-je facilement joindre mes NAS en 192.168.D.Y ou 192.168.E.Y depuis mon desktop en 192.168.C.Y avec pfSense/OpnSense ? Admettons également une box Android de type Nvidia Shield devant accéder au contenu multimédia du NAS 1 en 192.168.D.Y (ou 192.168.E.Y). Est-il plus propre de placer Nvidia Shield derrière un des deux switch, ou directement derrière la passerelle en 192.168.A.X ? Merci pour votre aide et bonne journée 🙂

@Mic13710 J'imagine que si je ne parviens pas à joindre l'adresse 192.168.1.x à Paris depuis le NAS en 192.168.0.x à Madrid, c'est à cause de l'absence de loopback sur la box de l'ISP à Madrid ?

Merci pour ces précisions, @Mic13710 ! Ce fonctionnement est valable aussi pour OpenVPN ? Ou bien est-ce propre au protocole L2TP/IPSEC ?

Bonjour, Comment dois-je m'y prendre pour faire correspondre une adresse privée 10.2.0.x à l'adresse locale de mon desktop 192.168.1.x ? Je voudrais WOL mon desktop à Paris depuis Madrid. Je peux déjà WOL avec une connexion VPN établie au préalable depuis un smartphone client vers le serveur OpenVPN de mon DS918+ (Paris), ce dernier assurant alors le relais du paquet vers 192.168.1.x (desktop). Mais ayant créé un profil VPN de type L2TP/IPSEC entre mes 2 NAS Paris-Madrid, je devrais pouvoir WOL directement via le réseau privé en 10.2.0.x et non plus via le réseau local en 192.168.1.x, non ? Merci 😉

Merci pour vos réponses @oracle7 et @Mic13710 😉 Signature DKIM okay ! On avance. Mon serveur mail est finalement celui d'o2switch. Problème : je ne peux avoir qu'un seul MX sur les serveurs d'o2switch, déclaré en priorité 0 vers mail.domaine.tld (hébergé chez o2switch). J'aimerais avoir un serveur MX de secours. Mais o2switch n'en propose pas. Puis-je créer la même adresse email contact@domaine.tld chez OVH afin de définir dans ma zone publique un second record MX en priorité 10 pointant vers mail2.domaine.tld (hébergé chez OVH) ? Ça fonctionnerait, ça ?

Bonjour, J'ai mon domaine.tld qui enregistré chez OVH. Sur mon panel OVH, j'ai modifié les zones DNS de mon domaine.tld comme suit : ns1.domaine.tld (qui redirige vers le paquet DNS Server de mon Synology DS720+ à Madrid) ns2.domaine.tld (qui redirige vers le paquet DNS Server de mon Synology DS918+ à Paris) Je désire utiliser une adresse email contact@domaine.tld qui ne soit PAS hébergée sur mon Synology DS720+ à Madrid. En effet, je préfère utiliser le serveur mail de mon hébergeur OVH. Comment puis-je dès lors spécifier un enregistrement TXT pour la signature DKIM pour ma zone publique dans le paquet DNS Server si je n'utilise pas de serveur mail sur mon Synology ? Merci pour votre aide !

Bonsoir, Je suis également confronté à l'apparition d'une fenêtre en pop-up lorsque je tente de joindre mon serveur de backup sous adresse privée 10.2.0.0 (L2TP/IPSec). Il m'est dès lors impossible de poursuivre la procédure de connexion au NAS distant via VPN. Ce pop-up est un bug ? Je précise que depuis le NAS source en SSH, je peux ping mon NAS distant sur 10.2.0.0. Tout l'intérêt du VPN (ici avec le protocole L2TP/IPSec) est complètement réduit à néant dans le cadre de tâches de sauvegarde Hyper Backup / Hyper Backup Vault. Cordialement, EDIT : le modem de l'ISP en cause, probablement, car pas de loopback. En effet depuis l'autre côté (celui du NAS distant derrière un routeur en bridge), si on inverse le schéma, cela semble fonctionner 😉

@oracle7 Ceci vient confirmer mon hypothèse : https://openvpn.net/faq/why-does-the-app-not-support-tap-style-tunnels/ En l'état, donc, si je veux pouvoir atteindre mes 2 NAS lorsque je suis connecté en VPN sur un réseau distant tout en gardant le redirect-gateway def1 pour conserver le full tunneling, il faut que les 2 NAS appartiennent au même sous-réseau. Pas le choix.

Bonjour @oracle7, Oui, je n'ai pas de problème de compréhension vis-à-vis des 2 notions. C'est simplement Android qui ne gère pas de la même manière que Windows. Cela semble se vérifier. EDIT : Et pour preuve .. Depuis Windows via OpenVPN, mon sous-réseau 192.168.0 est accessible quand je suis connecté sur la passerelle en 192.168.1. La carte réseau virtuelle OpenVPN du Centre Réseau & Partage permet cela. Sur Android, mon sous réseau 192.168.0 n'est pas accessible quand je suis connecté sur la passerelle en 192.168.1.

J'ai bien l'IP publique IPv4 du réseau Madrid dans les 2 cas (Windows ou Android). Le soucis étant partiellement réglé depuis que j'ai commenté la ligne redirect-gateway def1 pour la connexion VPN depuis Android, je pense en déduire que : Madrid étant sur le sous-réseau 192.168.0 .. Et Paris étant sur le sous-réseau 192.168.1 .. La ligne décommentée (et donc active !) redirect-gateway def1 fait en sorte que le serveur de destination doit être utilisé comme passerelle par défaut pour les clients. Avec Windows, pas de problème puisqu'il y a 2 cartes réseau (la physique + la virtuelle OpenVPN). Mais Android, ne gérant possiblement pas les cartes réseaux de la même manière qu'un Windows, ne parvient pas à faire en sorte de joindre la passerelle distante puisqu'elle n'est pas sur le même sous-réseau ! Mon raisonnement semble-t-il correct ? Le meilleur moyen de s'en rendre compte serait encore de tout mettre sur le même sous-réseau 192.168.0 OU 192.168.1 et de refaire le test.

Bonjour, On avance. Le DNS du réseau Paris contient 2 zones locales : domain1.tld domain2.tld Depuis le réseau Wi-Fi Madrid, lorsque j'accède via OpenVPN au réseau Paris avec Windows 10 : résolution domain1.tld OK résolution domain2.tld OK Toujours depuis le réseau Wi-Fi Madrid, lorsque j'accède via OpenVPN au réseau Paris avec Android : résolution domain1.tld OK résolution domain2.tld PAS OK (d'ailleurs, la résolution de l'IP privée non plus !!) Pourtant, les connexions VPN sur Windows 10 et Android utilisent le même fichier .ovpn. Une idée d'où ça pourrait provenir ? J'ai le sentiment que la gestion des cartes réseaux virtuelles se fait pas de la même manière sur Windows que sur Android. Et que ça pourrait provenir de ça. EDIT : pour que ça fonctionne sur Android, je dois commenter (avec un "#") la ligne redirect-gateway def1. À ce moment-là, je peux résoudre les 2 domaines mais c'est embêtant car je ne bénéficie pas de l'IP publique distante. Pas d'autre solution ?

Effectivement, c'est réglé. Merci !

Bonjour, Je suis actuellement connecté au réseau Paris sur lequel j'ai un NAS. J'ai accès au réseau Madrid sur lequel il existe un NAS aussi. Depuis Paris, lorsque je me connecte à 192.168.1.100 du réseau local, j'accède au NAS Paris. Logique. Lorsque je me connecte à Madrid en VPN et que je me connecte à 192.168.1.100, j'accède au NAS du réseau Madrid. Logique aussi. Mais comment faire pour continuer d'avoir accès au NAS du réseau local Paris lorsque je suis connecté au VPN sur Madrid ? Cordialement,

@oracle7 Oui, oui, je savais bien ça, mais c'est surtout l'idée de n'utiliser qu'OpenVPN qui m'intéresse. J'ai cru comprendre que L2PT/IPSEC avait été compromis.

Effectivement @oracle7, mais jusqu'à maintenant je n'avais qu'un seul serveur OpenVPN : celui sur Synology. Puisque je veux que mon Synology soit client VPN d'un autre NAS à distance, j'ai dû faire en sorte d'avoir un serveur VPN sur mon routeur actuel.

Bonjour @oracle7, Et désolé le monde pour le déterrage des enfers, mais c'est toujours mieux que de polluer avec la création d'un nouveau thread 😛 Je suis dans le cas de figure où j'ai 2 serveurs VPN : Le premier serveur OpenVPN sur mon routeur Le second serveur OpenVPN sur mon Synology Lorsque je me connecte au serveur OpenVPN sur Synology, j'ai accès à l'interface de mon routeur (qui fait passerelle, d'ailleurs) via l'IP locale 192.168.x.x. Lorsque je me connecte au serveur OpenVPN du routeur, je ne peux avoir accès qu'au routeur via son IP locale 192.168.x.x .. mais impossible d'accéder au NAS via sa propre IP locale. Gnéh ? 😅 Merci pour l'aide ! Cordialement, EDIT : le pare-feu du Synology semble être en cause. Je vais creuser pour trouver la règle qui fait foirer l'accès. Je tiens au jus.