.Shad.

Et tu as un NAS ? 😛 Parce que c'est l'objet de ce forum. 🙂

Dans /etc/profile, comme sur Linux classique. En revanche je pense que certaines màj écrasent ce fichier.

Le problème c'est surtout que tu es obligé d'appliquer ce paramétrage à tout le NAS, pas que le dossier dont tu as besoin.

J'ai une solution qui implique Docker et un peu de SSH, si ça t'intéresse je peux rédiger un petit tutoriel, mais ce sera pas avant la semaine prochaine je pense.

Testé à l'instant :

Est-ce qu'ils utilisent les mêmes serveurs DNS ?

@Jeff777 Je retiens de tout ça que tu n'as pas de smartphone, vous êtes deux avec ma belle-mère. 😄

Ok je comprends mieux ton problème, tu peux essayer de créer un alias intermédiaire dans ta zone locale : dynhost-nas3.ndd.tld. CNAME nas3.ndd.tld. Et voir si ça amène bien à ton dynhost pour NAS3 (que j'imagine être nas3.ndd.tld ?), je n'ai jamais essayé ce genre de chose donc je ne garantis rien. Le problème c'est que tu interroges directement la zone qui fait autorité sur ce domaine, donc si la zone n'est pas capable de répondre, elle refusera normalement de transférer la requête. Alors certes c'est localement, sauf que la zone n'en a aucune conscience, elle est sensée répondre à toutes les requêtes pour ce nom de domaine, car elle est un serveur de nom. Tu comprends ? Si tu utilises un nom de domaine Synology pour joindre NAS3 tu n'auras plus de problème.

Je confirme que c'est chaud. 😄 Du coup pas de VPN entre les deux ? Si c'est le cas pourquoi ajouter un enregistrement nas3.ndd.tld dans ta zone locale si tu passes par une IP publique via ton Dynhost ? 🤔

La version officielle consomme effectivement plus de mémoire. Mais je n'ai plus jamais eu le moindre leak mémoire depuis les versions 1.1x.x

@maxou56 a bien résumé. C'est du VPN peer-to-peer tout simplement. On se connecte mutuellement à ce qu'on veut. Mais des applications comme Tailscale il y en a un paquet. Elles permettent souvent de trivialiser la mise en place d'un réseau maillé, car oui ce n'est pas si simple. Dans mon cas j'ai beaucoup galéré pour arriver à faire du site à site, mais je pense que je n'avais pas trop compris à ce moment-là comment ça fonctionnait. il faudrait que je m'y repenche.

@Jeff777 Est-ce que tu pousses un serveur DNS via dhcp-option ? Le cas qui pourrait arriver serait que tu tentes d'atteindre une entrée de ton proxy inversé, et que le DNS local ne participe pas à la résolution de l'adresse, résultat la requête va vers les serveurs publiques, et donc au final tu arrives avec une IP publique et ta requête est correctement rejeté par l'ACL. Tu peux tenter de régler un paramétrage statique de l'IP de ton smartphone (pas via DHCP donc), en mettant l'IP de ton serveur DNS local en DNS primaire. Si c'est un smartphone Android, Google a tendance à forcer 8.8.8.8 pour la résolution DNS même si le serveur DHCP envoie d'autres serveurs, avec un paramétrage statique normalement tu passes outre. Tu peux également tester la même opération avec le téléphone de ta femme, ça permettra de voir si c'est le téléphone qui pose problème ou pas.

Si tu actives redirect-gateway def1 dans ton fichier ovpn sur ton smartphone, est-ce que ça marche ?

Quel numéro d'erreur ? Ca serait déjà un indice. 🙂

Attention, cette situation est souvent temporaire des retours qu'on a eus de plusieurs utilisateurs, il faut absolument mettre en place un plan de sauvegarde de tes données importantes. Même si la panne du NAS ne devrait pas impacter les données des disques, mais mieux vaut faire preuve de prudence avec cette série.

Il a un DS414 donc bon, je n'ai pas proposé. 😄

Les paquets populaires qui posent problème à l'update sont assez bien identifiés sur les forums Synology. Je sais que Plex pose souci par exemple, mais que le site de Plex propose une solution. Le mieux est de réduire a minima l'utilisation de paquets hors applications intégrées à DSM (même les paquets dans le store Synology sont à éviter).

Ca s'appelle les "client specific overrides", il faut éditer en SSH le fichier de configuration du serveur et créer un certificat pour le client, puis de dire que le client utilisant ce nom d'hôte va recevoir du serveur une IP prédéterminée via "ifconfig-push". Voir par exemple : https://kifarunix.com/assign-static-ip-addresses-for-openvpn-clients/ Donc en gros, je te propose d'oublier de faire ça sur SRM. 😄 Maintenant, je crois que ça ne sera jamais répété suffisamment, quand on veut commencer à jouer avec des réglages un peu avancés de ce style, on n'utilise pas un RT, qui ne vaut pas beaucoup mieux qu'un bête TP-Link en terme de fonctionnalités. Sur pfSense (ou autre firewall) c'est 3 clics via une GUI.

Aucun changement de comportement par rapport à DSM 6.

Non OpenVPN n'est pas upgradable sur SRM, alors j'ai cru comprendre qu'une nouvelle mouture de SRM est en préparation, mais quand... ? Une solution, mais qui n'a plus rien à voir avec ce tutoriel, c'est que le VPS soit client VPN du NAS ou du RT (inversion des rôles client-serveur). Ca reviendrait au même en terme de fonctionnalités. Sur le RT tu as l'avantage d'avoir toutes les tables de routage et donc je pense qu'avec un paramétrage correct tu pourrais atteindre tout équipement de ton réseau local depuis l'extérieur, même s'il n'est pas client VPN. L'autre solution c'est d'avoir le proxy inversé sur le NAS et qu'il soit le serveur OpenVPN, puis de faire de la redirection de port sur le VPS ; tout ce qui arrive sur les ports 80/443 est redirigé vers le NAS. A la manière de ce que l'on peut faire sur une box. Il faut jouer avec iptables sur le VPS pour ça, de ce que j'ai feuilleté ça n'a pas l'air sorcier. Alors après si tu trouves moyen de formatter ton fichier de config ovpn pour le rendre acceptable par Access Server c'est aussi une solution, mais j'ai déjà creusé ce sujet par le passé, la doc d'OpenVPN est illisible et brouillonne je trouve, je n'ai jamais réussi à parvenir à mes fins (2.3 vers 2.5).

tls-crypt est une option uniquement disponible pour les versions d'OpenVPN 2.4+ Le problème étant qu'OpenVPN Access Server est en 2.5.x et que la version d'OpenVPN sur ton RT est la 2.3.11 (On parle de Mai 2016, ça se pose là en terme de sécurité /ggsyno). Si ton NAS est sous DSM 7 la version d'OpenVPN est passée à la 2.4.9, et tu ne devrais plus avoir de problème de négociation TLS.

Toujours bloqué ? J'ai dû une fois redémarrer mon NAS car l'indexation n'en finissait pas. Ce sont des conseils un peu bateaux mais ça résout quand même 95% des problèmes. 😄

Si tu passes par un proxy inversé, le port sur lequel DSM est exposé importe peu, car l'attaquant éventuel n'y a pas accès, il utilise toujours le même port 443. Donc je ne vois pas comment ça a pu arranger quoique ce soit. Mal lu ton message. A quoi ressemble ton entrée de proxy inversé ?

Tu n'as pas l'option d'extraire une image sur Filestation via le menu contextuel ? Je suis plutôt partisan de la ligne de commande, mais bon quand c'est utile. 🙂

Je doute qu'ils remettent à jour DS Cloud, qui n'a plus reçu de mise à jour depuis belle lurette. Quant à Drive, ils ont largement eu le temps depuis que l'application existe d'implémenter la fonction de synchronisation sur les versions mobile, ça reste incompréhensible à mes yeux que les deux moutures, desktop et mobile, ne disposent pas des mêmes fonctionnalités. Je n'ai pas non plus l'impression que Synology accorde énormément d'importance aux retours, il suffit de voir les levées de bouclier concernant les fonctionnalités de Photostation qui n'ont pas été portées sur Synology Photos, je n'ai pas vu l'ombre d'un mouvement de ce côté-là. Ou alors ils y travaillent et faut qu'ils virent leur équipe de communication.