.Shad.

QuickConnect est beaucoup moins dangereux qu'un utilisateur local avec des fichiers vérolés qui aurait un accès open bar au NAS. QuickConnect permet d'établir un tunnel sécurisé entre un client et le NAS, et accessoirement on peut faire transiter les données de façon chiffrée par les serveurs de Synology. Beaucoup plus sécurisé qu'un accès local sur un port non sécurisé avec des droits R/W. 😉

Bienvenue parmi nous, au plaisir. 🙂

@Mic13710 @PiwiLAbrutiOui en effet, mais attention, mettre juste une IP dans la liste des IP permises ne bloque pas les autres IP. En tout cas chez moi je n'ai autorisé qu'un périphérique, et j'ai su me connecter avec un autre périphérique. En revanche si je bloque une IP l'accès à l'application est effectivement bloqué. Donc a priori il va falloir rentrer tous les sous-réseaux d'IPv4 à la main 😞 (https://ipinfo.io/countries) ou alors une option m'échappe ? Ah, et le répéter pour chaque application, du fun en perspective. Et pour l'IPv6 si @Insecto l'utilise, bonjour la galère aussi. 🙂 Ou alors trouver le fichier où se trouvent ces infos via le terminal, dès lors il serait facile de recopier les blocs d'IP d'un fichier à l'autre, j'imagine que ça doit être segmenté par application ?

Salut, A ma connaissance tu ne peux pas faire ça par utilisateur. Et c'est étrange comme demande, parce qu'un utilisateur, tu lui fais confiance, ou pas confiance, mais ça ne devrait pas dépendre de sa situation géographique. Jouer avec les règles du pare-feu ne changera rien, car IPTABLES n'a pas de notion d'utilisateur, uniquement des IP, des sous-réseaux de source et de destination, et des ports. Si tu peux décrire le contexte du pourquoi tu voudrais mettre ça en place, car entre les règles de pare-feu basées sur les IP, le géoblocage, le contrôle d'accès de Nginx, il y a normalement moyen de répondre à toutes les demandes. Il y a aussi l'authentification 2 facteurs que tu peux activer pour un utilisateur ou groupe spécifique. Peut-être que d'autres comme @PiwiLAbruti ont une idée lumineuse sur la question, mais moi ça me semble un peu tordu. 😄

Tu confonds port interne et externe. Au sein du conteneur, Adguard-Sync ne sait même pas que le port 8780 est utilisé. Lui il utilise le port 8080, c'est ce que tu précises quand tu écris 8780:8080. Tu peux faire l'analogie avec le NAT que tu peux faire entre deux ports différents entre ton modem qui est exposé publiquement, et un périphérique de ton LAN. Donc tu remets le port 8080. Deuxième chose (une fois de plus je ne connais pas le logiciel, je peux donc me tromper), mais quand on parle d'interface d'API, tu n'as pas forcément un webserver derrière, c'est l'interface qui reçoit les infos entre tes deux instances d'Adguard. Toi tu n'as peut-être rien à voir là-dedans. Tu espères y configurer quoi au passage ? Il me semble que le fichier yaml contient toutes les infos dont Adguard-sync ou toi-même peuvent avoir besoin.

Tu as bien ajouté et personnalisé le fichier yaml de config dans sync_config ? https://github.com/linuxserver/docker-adguardhome-sync/blob/main/root/defaults/adguardhome-sync.yaml SInon il est dans dit dans la doc que l'autoconfig se fait sur le port 3000 pendant la mise en route, si tu n'utilises pas de fichier YAML il faut donc également translater ce port et te connecter sur IP_DU_NAS:3000 pour remplir les champs. Le plus simple étant quand même de personnaliser ton fichier à la base. Après je n'utilise pas le logiciel, je me contente de lire la doc, donc possible que des subtilités m'échappent.

Salut, Il aurait été plus judicieux d'intercaler tes images entre tes paragraphe pour faciliter la lecture de ton post. Là on doit faire l'aller-retour entre les images et le texte, pas pratique. Première remarque : Ok quand le NAS n'est accessible que localement, mais à distance même pour des tests, non, surtout pas. Applique le set de règles par défaut précisées dans le tutoriel relatif à la sécurisation d'un NAS. Cela étant dit, est-ce que si tu testes ton IP:443 le port est bien vu comme ouvert ? Essaie de demander un certificat wildcard plutôt que nominatif pour ton NDD Synology. Pour ce faire, au lieu de mettre portainer dans les alias (dans le wizard de création de certificat), tu mets *.xxx.synology.me Est-ce que le port 9000 de Portainer est bien translaté sur le NAS dans la configuration du conteneur ?

Non mais ça pourrait faire l'objet d'un ticket d'ajout de fonctionnalité auprès de Synology.

Ton Adguard-Sync semble chercher à atteindre l'IP 192.168.64.105 sur le port 80. Est-ce que l'IP est correcte ? Est-ce qu'Adguard est bien disponible sur le port 80 (et pas plutôt un port translaté ? 8080 ou 808x, au vu de ton fichier compose)

@PhD59240 Fallait la trouver celle-là 🤪 Bien joué et merci pour le retour.

Welcome !

C'est du failover que tu veux. Ca peut être très simple ou très compliqué, suivant le niveau d'exigence en terme de rapidité et d'automatisation/autonomie que tu vises. La solution sûre et simple serait d'écrire un script qu'un périphérique tiers, idéalement dans le cloud, exécute pour basculer la redirection DNS d'un périphérique à l'autre. Via un healthcheck il est facile de vérifier qu'un périphérique est accessible ou pas à distance. Ca peut se faire via l'API OVH, tu auras sûrement un peu de lecture à faire, mais à mon avis rien d'insurmontable. Une autre solution serait qu'un périphérique tiers de ton réseau 1 héberge un serveur VPN, pas le même périphérique qui héberge Plex. Idéalement, sur ce périphérique tu installes un proxy inversé également. NAS 2 est connecté au serveur VPN. Quand NAS 1 est down, le périphérique tiers le détecte, réécrit la config nginx de Plex pour modifier le backend, passant de NAS 1 à NAS 2 (via son IP VPN). Problème si la connexion du réseau 1 est down, le périphérique tiers ne servira à rien. Autre solution encore, qui se rapproche de la première, c'est d'avoir un VPS bas de gamme qui est le point d'entrée sur tes deux réseaux, et dans ce cas-là, tu fais la même chose qu'à la solution 2, sauf que tu te détaches des problèmes de connexion du réseau 1, tout se passe dans le cloud (avec les SLA classiques de 99.95%, etc...). Dans tous les cas, ça demande un peu de travail, ou beaucoup de travail si tu n'es pas familier avec tous ces sujets. Et hormis pour le défi et la curiosité, qui sont des bons arguments pour se lancer là-dedans, se poser la question de l'intérêt. Car s'il s'agit de basculer uniquement en cas de panne longue de NAS 1, alors il suffit de souscrire à des DNS "rapides" type Anycast, les propagations se font généralement très vite, et il te suffit de changer manuellement l'enregistrement A chez ton hébergeur DNS pour pointer sur l'IP du réseau 2.

Bienvenue à toi !

Bienvenue !

Bonjour, Votre question n'a rien à voir avec Synology. Elle devrait se trouver dans la catégorie Linux ou le Bar. Ensuite pour répondre, les Rpi 3 ont une connexion Gigabit partagée entre tous les ports Rj/USB. Donc si vous activez l'IDS, les données passent par le Pi et le débit s'en ressent. Si vous voulez limiter la perte de débit tout en activant l'IDS il faut le faire tourner sur une machine disposant d'une connexion 1Gb dédiée.

Salut, Pourquoi aller dans le dossier de python3.8 si initialement tu dis qu'il ne reconnaît pas les versions supérieures à 2.7 ? Tu peux essayer de tagger @ArnaudLM voir si ça l'invoque, il est passé début Janvier.

Mise à jour proposée ce soir finalement. 🙂

Bienvenue parmi nous !

Si tu utilises les alias pour te connecter aux applis de DSM, tu dois utiliser l'accès natif en HTTPS à DSM sans passer par le proxy. Donc que nas.toto.fr pointe bien vers l'IP du NAS et pas d'entrée correspondante dans le portail des applications. Par contre, pour quelle raison ne pas faire passer l'accès aux applis par le proxy inversé ?

@maxou56 Ok je regarderai ce soir, je t'avoue que j'attends généralement d'avoir la notification. Vu que j'utilise MariaDB pour la plupart de mes applications, j'évite de trop toucher à la machine.

Perso mes NAS sont toujours en update 1, aucune nouvelle notification reçue sur aucun depuis le temps.

C'est là qu'il y a un problème, tu ne dois pas utiliser nas.toto.fr en tant qu'adresse IP du NAS en lui-même, et aussi en tant qu'entrée du proxy inversé. Tu peux par exemple utiliser dsm.toto.fr à la place de nas.toto.fr dans ton entrée de proxy inversé. Tu te loggeras à DSM via https://dsm.toto.fr:433, essaie de voir si tu as vraiment besoin de l'alias pour accéder à Calendrier, pas certain...

A partir du moment où tu le mets dans une entrée de proxy inversé, s'il voit ce nom de domaine, il essaie de le rediriger vers ce pour quoi tu l'as programmé. Ne pas oublier que https://nas.toto.fr c'est https://nas.toto.fr:443, comme tu l'as fait pour Plex. Il y a un cafouillage quelque part, nas.toto.fr ne peut pas à la fois être une entrée de proxy inversé ET le nom de domaine que tu utilises pour te connecter à DSM ou celui utilisé avec des alias. Donc : - Avec quel domaine+port tu te connectes sur DSM (session depuis laquelle tu tentes d'accéder aux applis via leurs raccourcis sur le bureau) - Tu peux faire une impression d'écran de ton entrée de proxy inversé nas.toto.fr ?

Bienvenue, au plaisir ! 😀

Je suis un peu perdu, tu utilises le proxy inversé pour Plex mais pas DSM ? Car si tu te connectes via https://nas.toto.fr:5010 (normalement c'est 5001, sauf si tu l'as changé), tu ne passes pas par le proxy inversé, tu passes par le port sécurisé de DSM (c'est pas gênant). Sur ta dernière impression d'écran, tu utilises un alias pour te connecter à Calendrier, une fois de plus c'est pas le proxy inversé tel qu'on l'entend habituellement. Si nas.toto.fr pointe bien vers l'IP locale de ton NAS ET que nas.toto.fr n'est PAS une entrée de proxy inversé, alors tu as sûrement dû mettre nas.toto.fr / 80 / 443 dans Panneau de configuration -> Accès externe -> Avancé, d'où la génération de ce lien erroné. Essaie d'entrer l'URL https://nas.toto.fr:5010/calendrier (ou 5001, si faute de frappe dans ton dernier message)