.Shad.

Le tutoriel dont tu as fourni le lien ne permet en rien de mettre en place une interface pour OpenVPN. Uniquement un serveur OpenVPN headless. Tu as déjà une interface via VPN server, quelles fonctionnalités te manquent-ils ?

A ma connaissance le fail2ban ne s'applique pas à OpenVPN, donc l'IP ne sera a priori jamais bloquée. Concernant la mise à jour, quelle était la mise à jour précédente que tu utilisais ? il pourrait être bénéfique de refaire un export du fichier de configuration vers le client.

Ah oui j'ai lu en diagonale 🙂 Prévois quand même une sauvegarde hors site ou dans le cloud. 😉

Pas tout compris à ce que tu as fait, mais tant que ça fonctionne 👌

Ok donc a priori la solution évoquée par @Lelolo est la plus adaptée. En terme de connectivité, il faudra penser à : Translater le port choisi pour Rsync sur la box où se trouve NAS 1 vers celui-ci Régler le pare-feu de NAS 1 pour autoriser uniquement comme IP source l'IP publique de NAS 2, si tu as la chance d'avoir une IP fixe Si IP dynamique, limiter au maximum la surface d'exposition et avoir des mots de passe suffisamment robustes, idéalement un VPN site-à-site serait un gros gain de sécurité

Salut @goudurix Tu ne peux pas facilement utiliser le certificat de ton serveur mail pour ton proxy inversé, et surtout je n'en vois pas l'intérêt, il te suffit de créer un autre certificat pour ton domaine depuis le NAS et associer tes entrées de proxy inversé à celui-ci dans Panneau de configuration -> Sécurité -> Certificat -> Paramètres.

Salut @Julien Dussart Deux questions : Quel est le système de fichiers que tu utilises ? ext4 ? BTRFS ? Est-ce que tu utilises Synology Drive ?

Ok donc mon intuition était bonne, il y a bien plusieurs /64 qui sont tirés du préfixe initial, sûrement un /56 ou approchant. Par contre je vois que ton pare-feu IPv6 est désactivé ? est-ce qu'il est bien activé au niveau du routeur ?

@j0ffr37 Tu exécutes la commande dans le conteneur depuis l'hôte via le terminal : docker exec -it adguard ping -6 ipv6.google.com où "adguard" est le nom du conteneur Adguard. Quelque chose me chiffonne dans ton histoire de second préfixe, a priori tu ne reçois qu'un préfixe de ton FAI, mais celui-ci a une certaine taille, par exemple /52 ou /56. Parmi ce pool de réseaux, ton routeur va choisir par exemple un /64. Probablement que ton player utilise à lui seul son propre /64. Mais du coup je n'ai plus tout en tête, ça fonctionne ou pas ? 😄

Il n'y a pas besoin d'utiliser le fichier host si on a un serveur DNS local. Ca marche localement si le domaine est distribué par ton serveur DHCP. _________________________ Il y a peut-être un problème au niveau du CNAME de l'enregistrement du NS, essaie ainsi : lan.local NS ns.lan.local lan.local A 172.16.X.X ns.lan.local A 172.16.X.X dsm.lan.local CNAME lan.local Et pour l'autre zone (son nom n'a pas d'importance) : lan.local NS ns.lan.local lan.local A 10.0.8.1 ns.lan.local A 10.0.8.1 dsm.lan.local CNAME lan.local Pour vérifier que ça marche localement, assure-toi que c'est bien l'IP du NAS qui est spécifiée comme serveur DNS par le serveur DHCP de ton réseau. Et tu n'as qu'à faire depuis un PC dans une invit de commande un : nslookup dsm.lan.local Si c'est bien le NAS qui répond et renvoie sa propre IP, c'est ok localement. En VPN, il te suffit de te connecter via le point d'accès Wifi d'un téléphone en 4G pour simuler une connexion distante, assure-toi que dans ton ovpn tu aies spécifié : dhcp-option DNS 10.0.8.1 Tu peux faire la même vérification que précédemment en ligne de commande, c'est le NAS qui te doit te répondre aussi mais avec son IP de serveur VPN 10.0.8.1, et renvoyer cette même IP pour dsm.lan.local, à partir de là sur le papier tu peux joindre tes lecteurs réseaux avec le même FQDN quelque soit ta connectivité.

Si tu as suivi la tutoriel sur la sécurisation de ton NAS, tu as normalement désactivé le compte "admin" par défaut et créé un autre compte avec droits d'administrateurs. Ca indique visiblement aussi que ton NAS est ouvert sur l'extérieur, comment est-il exposé ?

Bienvenue, je confirme il y a tout ce qu'il faut sur ce tutoriel, même s'il est initialement prévu pour DSM 6.

Pas forcément l'IP de la box, tu peux mettre des DNS publiques comme ceux de Cloudflare, ceux de Quad9, de Google, ou de la FdN : 80.67.169.12 et 80.67.169.40 Probablement, mais utiliser le nom de serveur n'est plus forcément intéressant si tu as un serveur DNS local non ? A toi de voir, moi je le ferais dans les vues, mais je ne suis pas sûr qu'il y a un consensus là-dessus. Tes zones me paraissent ok, ainsi pour tes montages SMB si tu utilises //ds218.lan.local/dossier_partage ça fonctionnera que tu sois en lan ou connecté via le serveur VPN.

Attention, il faut être prudent quand on parle de synchronisation et de sauvegarde en même temps. Si j'efface mes données sur NAS 2, elles seront également effacées sur NAS 1 si j'ai mis une synchro en place entre les deux. Ca c'est effectivement Sharesync, rsync ou autre alternative. Si j'ai mis en place une sauvegarde de NAS 2 vers NAS 1, mes données sont récupérables même si je les efface de NAS 2, ça c'est Hyper Backup, un script ou alternative. Quel est exactement l'objectif, sauvegarder ou synchroniser ?

Hello, alors pour ta zone lan, j'aurais fait quelque chose du genre : lan.local NS ns.lan.local lan.local A 172.16.X.X ns.lan.local CNAME lan.local dsm.lan.local CNAME lan.local Même chose pour ta zone vpn, en changeant le sous-réseau privé : lan.local NS ns.lan.local lan.local A 10.0.8.1 ns.lan.local CNAME lan.local dsm.lan.local CNAME lan.local Ces zones ne se différencient que par l'IP finale pointée, les noms de domaine sont identiques, donc passer du LAN au VPN est transparent pour tes montages réseaux. Au niveau de tes vues ça devrait être bon. En revanche, je ne comprends pas pourquoi tu as le mis l'IP du NAS en second redirecteur. Si ta requête n'est pas résolue par ta zone locale, lui redemander ne changera rien. Soit tu actives un ou deux redirecteurs, et dans ce cas-là tu disposes d'un serveur récursif, càd la requête est transmise à un(des) serveur(s) publique(s) de ton choix qui va(vont) retrouver pour toi l'IP de destination. Soit tu ne les actives pas, et dans ce cas-là ton résolveur fonctionne de manière itérative, il va lui-même interroger les serveurs root et redescendre la chaîne des domain level jusqu'à trouver la zone faisant autorité sur l'enregistrement que tu recherches. Dernière chose, joindre un NAS par son nom NetBios ne fonctionne pas en VPN, donc c'est soit par IP soit par nom de domaine.

Bienvenue !

J'ai regardé un peu mais je ne trouve rien de probant, sachant que je ne peux pas non plus faire de tests en direct. De mes recherches, je vois deux "solutions" (je mets entre guillemets car les gens n'expliquent pas pourquoi ça marche d'après eux) : - ajouter include /etc/nginx/mime.types dans le bloc serveur de ton entrée de proxy inversé Pour la deuxième ça me semble déjà plus compréhensible, le principe est d'ajouter un filtre regex sur un deuxième bloc location et de forcer le format pour les fichiers de type .js location ~ .*(\.js) { default_type application/javascript; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app IP_ROUTEUR; set $upstream_port 5000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; }

Il suffit d'enlever l'include qui pose problème dans ton srm.subdomain.conf, et d'ajouter dans ce fichier tout ce qui est habituellement inclus, modulo ce qui pose problème. Ca va être du try and retry pour trouver.

Salut, Ce n'est pas dans Redirections mais dans Zone DNS que tu dois ajouter un enregistrement AAAA vers l'IPv6 de ton NAS. Pour ta box, tu es bien dans la configuration du pare-feu de l'IPv6 et pas dans un onglet de NAT on est d'accord ?

@MilesTEG1 Pour moi c'est lié au fichiers "mime.type" inclus par SWAG dans ses blocs server. Il faut comparer avec ce que tu trouves dans les configs dans /etc/nginx sur ton NAS.

@MilesTEG1 Ca a trait au fait que que le script js exécuté renvoie le mauvais MIME type, "text/plain" au lieu de "text/javascript" de ce que j'en comprends, ici par exemple : https://stackoverflow.com/questions/39228657/disable-chrome-strict-mime-type-checking Après je ne m'y connais clairement assez pour te débugger plus avant personnellement. Il existe visiblement un workaround dans Nginx, mais qui n'est pas conseillé. Est-ce que tu as testé avec d'autres navigateurs ?

Bienvenue parmi nous

Oublié de mettre le lien :

Difficile de dire comme ça ce qui pourrait clocher, je suis tombé sur ce post en recherchant une solution à ton problème, je ne sais pas si ça peut être une piste ? Sinon éventuellement contacter le support, ils sont a priori plus compétents pour ce genre de souci.

Justement, il ne peut pas faire grand chose, c'est tout l'intérêt. Ca permet que si l'image du conteneur était vicitime d'une faille de sécurité, tes données ne seraient aucunement en danger. Tu évites une potentielle backdoor. Sinon, ajout du tutoriel suivant dans la liste des tutoriels en début de post :