Échec de la vérification du certificat - Nas distant

[Litsip]

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.

Modifié le 7 juin 2022 par Litsip

[maxou56]

Il y a 2 heures, Litsip a dit :

Si une bonne âme passe par là et pouvait donner de l'eau à mon moulin, je lui en serais très reconnaissant.

Bonsoir,

Tu as bien configuré ton certificat pour qu'il soit aussi utilisé avec le paquet HyperBackup Vault?

 

Si tu passes la souris, ou clique sur le "i" à coté d'échec, c'est bien ton certificat ou celui de synology?

Modifié le 5 juin 2022 par maxou56

[Litsip]

Bonsoir @maxou56, merci de ton retour. 

Il y a 2 heures, maxou56 a dit :

Tu as bien configuré ton certificat pour qu'il soit aussi utilisé avec le paquet HyperBackup Vault?

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. 

Il y a 2 heures, maxou56 a dit :

Si tu passe la souris, ou clique sur le "i" à coté d'échec, c'est bien ton certificat ou celui de synology?

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.

Modifié le 5 juin 2022 par Litsip

[Litsip]

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 ?

Modifié le 21 juin 2022 par Litsip

[Litsip]

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"

• Citation

  ndd.tld A @IP WAN réseau 1

  *ndd.tld CNAME 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 : 

  Citation

  ndd.tld A 86400 @192.168.0.2

  nas.ndd.tld A 86400 @192.168.0.2

  routeur.ndd.tld A 86400 @192.168.0.1

  *ndd.tld CNAME 86400 ndd.tld

  ndd.tld NS routeur.ndd.tld

  -> paramètres de zone

  

- 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 ?

Modifié le 21 juin 2022 par Litsip

[.Shad.]

Salut @Litsip

Je rencontre le même problème, je ne sais pas si tu as trouvé une solution depuis.

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