Kramlech

Et tu as bien une entrée CNAME chez OVH pour ton www.xxx.fr ?

Que donne un test smart étendu du disque ?

C’est comme pour chez toi : si tu n’as pas de porte d’entrée où que tu la laisse ouverte c’est très simple mais pas sécurisé. Si tu veux poser une porte blindée avec une serrure 5 points, la sécurité est meilleure mais c’est nettement moins simple à installer. Mais il y a dans ce forum d’excellents tuto pour te guider... Pour ce qui est de Plex je laisserai d’autres plus compétents que moi t’en parler. Personnellement, je n’utilise pas, je reste avec Vidéo Station qui convient très bien à mes besoins... (je passe mes semaines à l’hôtel et je n’ai aucun problème pour accéder à mes films...). Quand je vois sur le forum le nombre de questions sur ce produit, personnellement ça ne me donne pas envie d’essayer...

Record battu pour une arrivée sur le forum : pas de présentation, pas la bonne section et appel à nos boules de cristal !!!!

Oui parce que toi tu comprend comment ça marche. Pour le commun des mortels, laisser le dhcp attribuer l’IP (avec un bail permanent) permet de s’affranchir de tous ces problèmes...

Conclusion : ne jamais fixer l’adresse IP directement dans la Nas... Pour résoudre ton problème, un simple reste et c’est réglé...

Je voulais juste faire une petite remarque concernant la méthode pour prendre en compte le tuto ( et d’ailleurs tous les tutos) : toujours tester si un étape fonctionne correctement avant de passer à la suivante ... Par exemple, si sans aucun test intermédiaire, on met en place par exemple : Un nom de domaine Des redirections de ports Une redirection HTTP vers HTTPS Un reverse proxy Un firewall il y a fort peu de chance que cela fonctionne. Et trouver où est l'erreur devient un vrai jeu de piste ...

Si tu veux passer en https, il faut taper https://music.ndd.fr. Si tu saisis une url sans préfix, ton navigateur l'interprète comme un requête http, et si un port n'est pas explicitement précisé, il l'envoie sur le port 80 par défaut. Mais le port 443, c'est le port par défaut du https, port qui n’accepte que du https. Donc ta requête part en http sur un port qui n’accepte que du https => d’où "bad request" Le message renvoyé est d’ailleurs assez explicite:

Un disque en train de rendre l’âme ?

Tu ne peux pas tester une redirection de port en interne ... Ce que tu as fait c’est simplement tester le bon fonctionnement du service qui écoute sur le port ....

Je pense qu’il y a encore des choses que tu n’as pas compris sur l’utilité de la redirection de port. En interne ça ne sert à rien : tous les ports sont accessibles par défaut sur toutes les machines.

Alors je n’ai pas du comprendre ce que tu voulais dire ...

Quelques soient les ports que tu ouvriras, une adresse IP interne ne sera jamais atteinte depuis l’extérieur. Ce qui peut être atteint depuis l’extérieur, c’est ton IP externe (celle de ma box). Et c’est la redirection de port qui permet de rediriger la requête vers une IP interne...

C’est normal c’est une IP interne, non accessible depuis l’extérieur... Pour reprendre depuis le début, est ce que tu as essayé de faire un Ping sur wmsyno-files.ndd.fr pour vérifier que la résolution se fait bien ? (depuis l’extérieur bien sûr)

octet = byte. Donc la taille en bytes = la taille en octets Tu veux quoi exactement ? Voir le mot « octets » à la place du mot « bytes » ?

Un reverse proxy, c’est pourtant la bonne solution. Si ça ne marche pas c’est que tu dois manquer quelque chose. Le principe est le suivant : tes deux noms de domaines doivent pointer sur l’IP de ta box. Sur le routeur tu rediriges le port 443 (si tu veux accéder en https) vers le reverse proxy. Et au niveau du reverse proxy tu rediriges le premier ndd vers l’IP/port du premier serveur et le deuxième ndd vers l’IP/port du deuxième serveur. Rien de bien compliqué...

Il existe un utilitaire « Hyper Backup Explorer » qui permet de lire les .hbk depuis un PC...

Très bon tuto .... Juste un petit détail : Chez Free, les IP fibre sont aussi partagées... Je suis en train de passer chez Free Fibre, et j'ai cela : Il y a longtemps que je pense à faire aussi un tuto (ou plutôt une super vulgarisation) sur IP, ports, passerelle, routeur, NAT, firewall, etc ... pour que les gens en comprennent vraiment les bases et puissent suivre les tutos d'une manière intelligente en comprenant ce qu'ils font .... Malheureusement, c'est le temps qui me manque le plus... Vivement la retraite !!!!

Ah, ça je ne savais pas .... De toute manière, je n'ai pas accès à l'espace client (il s'agit de l'abonnement Pro d'une petite société, j'ai accès à la box - bien obligé pour mettre en place et gérer le NAS, mais je n'ai pas les plein pouvoir sur tous les codes et comptes de la société 😊)

La nuit portant conseil, je me rend compte que je ne suis pas allé au bout de mon raisonnement... En effet, une fois la connexion VPN stoppée, le NAS distant aurait du retrouver son adresse IP, et donc le DDNS auraIi du se mettre à jour... Or ça n'a pas été le cas. Si j'ajoute à cela le fait que j'ai pas eu le message quotidien sur le résultat de la sauvegarde, la conclusion c'est que le NAS distant s'est planté !!!! Donc il va falloir que je contacte quelqu'un sur place pour redémarrer le NAS ... La suite au prochain épisode ....

Ben si, c'est le principe même d'un serveur VPN : pourvoir "sortir" sur internet avec une adresse IP qui n'est pas la tienne. C'est ce que permet l'usage de la gateway distante. Et quand tu fais cela, le système du NAS qui détecte les changements d'IP pour prévenir le DDNS de ces changements s'active et il met à jour le DDNS avec cette nouvelle adresse. Pour t'en convaincre, connecte toi sur le VPN du NAS depuis l'extérieur de chez toi, fait un coup de monip.com, et tu verras que l'IP renvoyée est celle du NAS ...

Alors il semblerait que finalement lors de ma dernière tentative la connexion ait fini pas s'établir ... Va comprendre ... Comme quoi même nos NAS peuvent tomber en marche !!! 😂 Par contre, il vient de m'arriver ce que l'on peut appeler un gros GAG !!! Donc en résumé, j'ai un NAS local qui me sert de serveur VPN, et un NAS distant qui veut être client du VPN. Lors de cette dernière connexion, pour que ce soit dit que j'avais tout testé, j'ai coché toutes les case présentes sur l'écran de connexion, y compris la case : "Utiliser la passerelle par défaut sur le réseau distant". Et comme la connexion s'est établie, et comme j'ai un DDNS sur ce NAS distant, et bien le DSM a bêtement fait son travail, : il a détecté le changement d'adresse IP (car le NAS distant sort maintenant sur le réseau du NAS local, et il a attribué l'adresse IP de mon NAS local sur au DDNS du NAS distant !!!! Moralité : je ne peux plus accéder à mon NAS distant car toutes ses redirections se font maintenant sur le NAS local ... Beuhhh... Dit madame Orange, c'est quand que tu vas changer l'adresse IP pour que je puisse à nouveau accéder à ce NAS distant ????

Comme je disais en introduction, la connexion au VPN se fait très bien depuis mon MacBook. Et pour éviter tout risque d'erreur de saisie, c'est à partir des mêmes copier coller que je fais les connexions sur les deux machines.... Donc pour moi, le problème ne viendrait pas du serveur, mais plutôt du client ....

Oui, bien vu, effectivement, cela peut être une raison ....

Je viens de reprendre la lecture de ce tuto et je me pose une question : Il est indiqué, pour les applications standards, qu'il faut leur attribuer un numéro de port via le "Portail de applications" Puis de gérer les redirections via le reverse proxy. Personnellement, je n'ai pas utilisé cette méthode. Car juste à coté de la colonne HTTP, il y a une colonne "Domaine". On peut y saisir un nom de domaine ("video.mondomaine.fr" par exemple). Et cela permet d'accéder directement à l'application via ce nom de domaine. Pas besoin de déclarer la redirection dans le Reverse Proxy. C'est le DSM qui se charge de tout. Existe-t-il une raison pour ne pas utiliser cette possibilité (plus légère que le Reverse Proxy) ?