.Shad.

Sauf erreur de ma part, c'est globalement mal foutu et tu n'auras pas moyen d'uniformiser le tout malheureusement. Synology ne prévoit visiblement pas qu'on puisse utiliser un proxy inversé (qu'eux-mêmes proposent) pour accéder à notre NAS. Ou un accès distant sans passer par QuickConnect.

Donc en te connectant par le LAN 2 tu parviens à supprimer le VID 1 sur le LAN 1, mais il revient seul par après ?

Bienvenue parmi nous !

C'est un peu du bashing, non ? Ca en devient gênant à force.

Quand on exporte un fichier .ovpn depuis Access Server, les certificats sont inclus dans le fichier. Le certificat, la clé privée et le ca-cert (certificate authority). Je pense que le message que tu as posté est là pour signifier que là aussi, le certificat est embarqué quand on exporte depuis les VPN Synology. @MarcoLoco5924 C'est très facile à vérifier, tu dois avoir à la fin de ton fichier .ovpn un encart <ca>...</ca>, <cert>..., </cert>, <key>...</key> (plus d'autres éventuellement, suivant les réglages d'Access Server). Sauf à vouloir utiliser des applications qui nécessitent une IP fixe (serveur mail par exemple), je ne vois pas ce que ça change si tu as un dynhost.

Salut et bienvenue ! Si tu comptes faire de la domotique sur ton NAS, je te conseille de prendre un modèle "+" . Car la plupart des dongles ne sont plus nativement gérés par DSM et tu devras passer par Docker ou Virtual Machine Manager, qui sont uniquement disponibles sur les modèles haut de gamme de la catégorie grand public.

c/c c'est copié/collé. Et tu as oublié un espace entre le guillemet de fermeture de WATCHTOWER_SCHEDULE et le \ de fin de ligne. D'où la remarque sur la majuscule de l'output. EDIT : et aussi un espace à la fin de WATCHTOWER_LABEL_ENABLE entre le true et le \.

La première commande tu as oublié le "\" après l'argument hostname. La 2eme il y a un c/c foireux avec un restart commenté en début de commande.

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).