Litsip

Bonjour @.Shad. Non malheureusement je n'ai pas trouvé l'origine du problème... J'ai botté en touche et j'ai basculé sur une connexion Nas to Nas par VPN (OpenVPN). Ce n'est pas optimal, parcequ'il ya quelques déco intempestives, mais ça fait le job'. D'ici quelques mois, je partirais surement sur un NDD .synology via DDNS. J'ai trouvé en utilisant ce service, que cela était devenu très pratique : Actualisation LetsEncrypt auto, ports 80 ouverts et fermés en auto, NDD Wildcard. Si tu trouves quelque chose, je reste intéressé évidement. N'hésites pas revenir ici.

Bon... Je suis bien embêté. Mon ticket chez Synology botte en touche. Pour eux, il n'y a pas de problème entres les NAS, car l'intervenant peut lancer une tâche hyperbackup avec authentification du certificat, alors que moi non... 🙄 Après avoir éliminé différentes hypothèses, mon serveur DNS local semble être la cause de mon problème. Mais... C'est là que ça coince. Voici la configuration du réseau qui héberge mon Nas 1, appelons là "réseau 1" : - Zone DNS du fournisseur de mon domaine "ndd.tld" - Internet --> IP WAN --> BBOX 192.168.1.1 -->DMZ 192.168.1.2 (IP fixe bail DHCP) ROUTEUR 192.168.0.1 --> LAN --> 192.168.0.X (Nas 1, etc ...) - Pare-feu : Ports 443, 6281 ouverts et transféré vers le Nas 1 - Routeur : Certificat Wildcard *ndd.tld installé DNS server configuré comme conseillé par Fenrir Cache DNS local et Vues activées Zone DNS master locale pour ndd.tld : - Nas 1 : Certificat Wildcard *ndd.tld installé Reverse proxy utilisé pour les applications, mais pas pour DSM (accès externe par VPN seulement) De l'autre coté, pour simplifier la compréhension du problème, je suis passé sur un DDNS synology - Nas 2 : ddns synology activé (ddns.synology.me) + certificat Letsencrypt -Nslookup : Depuis Nas 1, je me connecte en local à DSM via nas.ndd.tld, plutôt que par l'ip LAN 192.168.0.2. Je pense qu'Hyperbackup ne reconnait pas mon certificat local et comprend qu'il s'agit d'un dns "menteur", puisque nas.ndd.tld n'est pas redirigé depuis l'extérieur par reverse proxy. Malheureusement je ne vois pas de solution à ce problème... Ma Zone DNS locale est-elle correctement renseignée ? Quelqu'un pourrait-il confirmer mon hypothèse ?

J'ai effectivement évalué à partir d'un Pc les deux réseaux LAN, via la technique de @oracle7 mentionnée ici : D'ailleurs @bliz j'ai vu que tu mentionnes toi même la commande mssfix à tes clients OpenVPN. Est-ce que tu as remarqué qu'il est désormais possible de rentrer le mssfix via DSM, dans l'application VPN server ? Par défaut il est à 1450. En faisant de la sorte, j'ai essayé avec et sans mssfix dans le fichier de conf. client. Et ça semble fonctionner aussi bien.

Étonné par cette suggestion, j'ai moi même voulu essayer... Et bien mon constat est identique à @bliz : -> En utilisant le protocole TCP au lieu de l'UDP pour de l'OpenVPN, je multiplie par deux le débit de mes échanges ! Précisions importantes, ces échanges ont lieu dans le cadre d'une connexion OpenVPN Nas to Nas et avec Hyperbackup vers Nas distant. La configuration du client (Nas distant) est identique à l'exception de "proto udp -> tcp" : dev tun tls-client remote IP WAN 1194 (VPN serveur) #float #redirect-gateway def1 dhcp-option DNS 192.168.2.1 (serveur DNS local du Nas distant) pull # If you want to connect by Server's IPv6 address, you should use # "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode proto tcp-client script-security 2 mssfix 1470 comp-lzo reneg-sec 0 cipher AES-256-CBC auth SHA512 auth-user-pass <ca> -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- </ca> key-direction 1 <tls-auth> # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- -----END OpenVPN Static key V1----- </tls-auth> verify-x509-name ‘*.NDD.TLD name Dans ma situation il y'a peut-être un lien avec le fait qu'Hyperbackup utilise déjà du TCP. En tout cas si quelqu'un a une explication, je suis preneur. Tu utilises toujours le TCP de ton coté @bliz ?

J'imagine que tu le sais déjà, mais cette particularité du L2TP est mentionnée ici . nb : en L2TP/IPSec, il n'est pas possible d'avoir plusieurs clients connectés en même temps s'ils sont derrière le même routeur NAT Peut-être que ton problème venait de là ? Évidement si tes client sont en 4G (non partagée), ça ne devrait pas poser de soucis. En tout cas c'est ce que je comprends de cet avertissement, je n'ai jamais testé le multi clients en L2TP. Je ne comprends pas à quoi ces chiffres font référence, désolé. 🙈

Même chose ici aussi. Je préfère le L2TP, qui est fiable et stable sur MacOs. Sans compter que l'implémentation est native, ce qui n'est pas le cas avec OpenVPN par exemple. @alan.dub Si deux clients tentent d'utiliser L2TP, il est normal d'être embêté : Tu ne peux avoir qu'un seul client en L2TP à la fois.

Pour donner des suites à ce sujet, J'ai pas mal investigué pour comprendre les réactions d'Hyperbackup suivant certaines situations. Pour que cela serve à d'autres : j'ai compris, ou plutôt je me suis rappelé (merci aux remarques de @Mic13710 il y a de ça plusieurs années) que le comportement d'Hyperbackup n'était pas le même suivant les ports que vous ouvrez sur le Nas cible, en local, le pare-feu d'un autre Nas cible lui même en local, est en théorie ouvert au LAN, de fait les ports 5000/5001 sont ouverts sur le Nas cible, aussi quand vous initiez une sauvegarde vers le Nas cible en LAN, une fenêtre popup d'authentification DSM apparait, il faut alors se log pour poursuivre la procédure sur Hyperbackup. Avec un Nas distant, c'est à dire hors du LAN du NAS avec Hyperbackup, les choses sont différentes : les ports 5001/5000 du Nas distant ne sont pas ouverts au WAN (en tout cas vous avez plutôt intérêt) pourtant on peut quand même initier une sauvegarde - SI - le port 6281/TCP est ouvert et redirigé sur le Nas distant il n'y alors plus de popup d'authentification DSM et seul ceci apparait : --- Maintenant qu'on sait ça, qu'est ce qu'on en fait ? Hé bha personnellement, ça m'a beaucoup aidé à comprendre pourquoi je bloquais lorsque je tentais de faire la même chose (aka Nas 1 > Nas 2), mais en VPN. Comme @molinadiaz et @Manuka dans ce topic : Je ne pouvais pas me log sur DSM depuis le NAS avec Hyperbackup. Et quand on reprend ce que j'ai expliqué plus haut, c'est tout à fait logique : mon Nas distant écoutait tous les ports sur le réseau privé VPN Pour remédier au problème il faut alors que : Le pare-feu du Nas distant, soit fermé aux ports 5000/5001 ET au réseau privé associé au service VPN utilisait pour Hyperbackup. Concrètement, sur le Nas distant, on passe de ça : à ça (si on utilise OpenVPN pour du Nas to Nas et qu'on souhaite garder L2TP pour de la maintenance par exemple) Puisque DSM est bloqué, on retrouve un comportement similaire à une sauvegarde sans VPN. Bien évidement tout cela n'est pas l'objet de mon problème et même via OpenVPN j'ai toujours ce fichu. Mais comme ce forum m'a toujours été d'une grande aide, je me dis que cela ne coûte rien de rendre un peu la pareille... --- Pour revenir à nos moutons, mon problème c'est qu'Hyperbackup ne reconnait pas mon certificat. J'ai essayé NAS 1 > NAS 2, NAS 2 > NAS 1, NAS 1 > OpenVPN/L2TP > NAS 2. À force de bidouiller, j'ai pensé que le NAS 2 pouvait présenter certaines erreurs avec les certificats. Mais en poussant HBU Nas 2 > Nas 1, cela m'a prouvait que non, parce que je n'ai rien modifié dans les certificats du NAS 1. J'ai essayé avec un autre NDD que j'avais sous la main + certificat SSL payant associé Synology pensait que le problème venait du Wildcard, mais là encore non... Avec toute cette histoire, j'en viens quand même à me demander : suis-je le seul à rencontrer cet avertissement ? Est-ce que je m'inquiète pour rien et qu'en définitive ce qui assure le chiffrement de ma sauvegarde c'est le mdp rentré via hyperbackup lors de la configuration de la sauvegarde ?

Bonsoir @maxou56, merci de ton retour. Oui comme indiqué, du coté du NAS 2 (backup), le certificat wildcard est bien associé à Hyperbackup, comme au "Paramètres système par défaut". Un paramètre auquel j'avais d'ailleurs fais attention, suite à une de tes interventions. J'ai testé pour NAS 1 et 2 : d'éteindre/relancer l'application Hyperbackup / restart du NAS / désinstallation de l'application (en conservant les paramètres). Je me suis même méfié du cache de mon navigateur et l'ait refresh/restart. Pour dire. C'est là tout le problème. Il n'y a aucune information, qu'il s'agisse de cliquer sur le "i" ou au survol. Avec un auto-signé, ou un certificat autre que celui ciblé, on voit bien qu'il ne s'agit pas du bon certificat. Mais là rien. J'ai l'impression que mon soucis est plus lié à une ouverture de port, mais je ne l'explique pas. Déjà d'un point de vue sécurité, je ne comprends pas pourquoi il est nécessaire d'ouvrir le 5001 pour faire apparaitre une fenêtre popup de login DSM. Depuis HBU en ouvrant juste le port 6281, je peux authentifier mon utilisateur dédié. Mais dans ce cas il n'y a pas d'authentification du certificat et on revient à mon problème.

Bonjour et d'avance merci du temps que vous accorderez à la lecture de mon thread. 🙏 Historiquement, j'effectue depuis 5 ans un backup en local de mes données d'un NAS(1) vers un second NAS(2). Tout se passait très bien jusqu'ici. Aujourd'hui j'ai la possibilité d'externaliser mon backup hors de mon réseau et à plusieurs kilomètres du NAS principal. Après avoir configuré en théorie correctement l'accès externe au NAS 2 je rencontre le problème suivant : Cette fenêtre survient après authentification de mon utilisateur dédié à Hyperbackup, après avoir sélectionné dossier partagé et répertoire, lorsqu'on clic sur "Suivant". Ce qui est d'autant plus incompréhensible, c'est que l'infobulle à coté de "Échec" n'indique aucune information complémentaire au survol... Pour aller plus loin, je n'ai donc que deux choix : Juger le certificat comme Fiable ou Ignorer Si je sélectionne "Fiable", je peux alors rentrer la clé de chiffrement pour me reconnecter à ma ancienne sauvegarde. -> Mon problème est que je ne suis pas à l'aise à l'idée que mon certificat n'ait pas été authentifié et je n'en comprends pas le comportement ? ---- En effet, à la différence d'un certificat auto signé, qui est la principale cause de ce type de problème, je dispose ici d'un certificat Wildcard payant de chez Infomaniak importé tant sur le NAS1 que NAS2 et attaché à Hyperbackup Vault. Lorsque j'étais en local, couplé avec dns server, je pointais mon backup depuis son NDD sans problème d'authentification, j'ai donc cherchais à retrouver ce confort d'utilisation. En externe, j'ai compris qu'il me fallait provisoirement ouvrir le port 5001 du NAS 2 pour pouvoir me log à l'utilisateur dédié à Hyperbackup. Naïvement je pensais que cela suffisait, couplé à un wildcard, pour valider l'authentification du certificat auprès d'Hyperbackyp. Mais non... Mon architecture est configurée comme suit : NAS 1 > RT 6600ax > Bbox Ip fixe ---- DDNS > LiveBox 4 > Routeur RT 1900ac - 6281/TCP > NAS 2 - 6281/TCP DNS Local sur les RT selon tuto de @Fenrir NAS 2 accessible en LT2P Pare-feu et bonnes pratiques de sécurité comme préconisé sur le forum (et qui sont souvent les seuls vrais bons conseils sur le web) Si une bonne âme passe par là et pouvait donner de l'eau à mon moulin, je lui en serais très reconnaissant.

Bonjour @laclac Tu peux aussi acheter un certificat SSL externe et l'importer manuellement dans le NAS. De cette manière tu n'ouvres jamais ton nas à l'extérieur pour le renouvellement des certificats, et ils sont d'une durée supérieure (environ une année). Mais bien-sur : il faut payer. 🙃

Regardes de coté-ci : Je confirme concernant le direct download. Renseignes toi davantage sur le p2p et l'usage que tu sembles en faire, ou tu risques d'avoir des soucis...

Coucou! Je vais essayer d'apporter de l'eau à ton moulin. On m'arrêtera ou complétera si je me trompe. NordVPN et VPN Serveur sont pour des usages différents. VPN Serveur te permet comme son nom l'indique de faire de ton NAS un serveur VPN accessible par des clients (portables, pc, etc.) NordVPN est un serveur VPN auquel tu te raccordes, c'est donc toi dans ce cas de figure qui est le client, que ce soit avec ton nas, mais aussi tout autre device. Donc pour connecter ton NAS à NordVPN, ça se passe dans Réseau>Interface réseau>Créer un profil VPN Des lectures que j'ai pu faire, connecter simplement ton NAS à NordVpn(par exemple) n'est pas si sécurisant que ce qu'internet laisse paraître. En effet, comme tu te connectes à un réseau (Nord), le transit de tes données est certes "dissimulé", mais ton propre réseau est aussi accessible (sans actions de ta part, autre que te connecter à Nord). Il y'a des façons de se protéger, mais cela m'échappe encore. En espérant t'avoir été utile.

Penses à remettre ton Pare-feu en fonction, et ne fixes pas toi même l'adresse IP LAN de ton NAS, laisses faire le DHCP de ta box. Pour éviter que ce désagrément ne survienne à l'avenir, regardes le tuto de Fenrir sur la sécurité de ton NAS : Il y fait entre autre référence au paramétrage du pare-feu, plus "large" que ce que tu avais probablement pu mettre dans ta précédente configuration.

Oui, j'aurais effectivement pu le mentionner. Bien-sûr je parlais du reset "mot de passe administrator réglages réseau", qui réinitialise seulement ceci : Restaurer le compte admin à sa valeur par défaut. Restaurer le port de gestion UI à 5000/5001. Réinitialiser l'IP, DNS, la passerelle et d'autres interfaces web vers DHCP. Désactiver PPPoE. Désactiver le blocage automatique. Désactiver des règles de pare-feu : Démonter les fichiers chiffrés et désactiver Monter automatiquement au démarrage. Supprimer un cluster high-availability :

Salut! Sans être un expert, j'aurais comme ça dis qu'il s'agit d'une histoire de pare-feu Tu le sais peut-être surement déjà, mais ton adresse LAN (192.168.X.X) a changée en passant de Free à Orange. Chez Orange tu es en 192.168.1.X Peut-être avais tu configuré ton pare-feu sur le NAS pour un accès uniquement sur le 192.168.0.X (Free) ? Le plus simple selon moi, effectuer un reset, en voici la marche à suivre : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/How_to_reset_your_Synology_NAS Attention à bien reconfigurer derrière, en particulier le pare-feu et la désactivation du compte admin. Tu pourrais le faire aussi via SSH, mais ça implique d'avoir ouvert le port donc...