CoolRaoul

@Flamby55 par curiosité j'ai essayé de configurer la synchro de l'agenda Synology avec mon smartphone (c'est un Android) De mon côté je suis parvenu à le faire fonctionner (via l'application "DavX5" qui est necessaire sur Android) Juste une différence avec toi sur l'url : de mon côté j'ai utilisé l'URL https://MONNDD.myds.me:5001/caldav.php et renseigné les champs user et password dans le formulaire de l'application ( à ce propos j'ai été surpris de ne pas me trouver bloqué sur le MFA qui est activé pourtant sur mon compte Et ça se synchronise bien et dans les deux sens **edit** Ah j'ai compris, l'URL est différente si on configure accès par alias dans le portail de connection. Avec le nom que j'ai choisi, "caldav", alors https://NDD.myds.me/caldav/ fonctionne pour moi (mais je n'ai pas le "/User" toutefois ni le port DSM 5001, ça passe par le port 443 SSL standard) Comme je suis sous Android et toi sur IOS je ne pourrais hélas sans doute pas t'aider plus avant

Il est important de comprendre que même en changeant le port il sera forcément necessaire d'ouvrir l'accès externe au NAS dans la BOX avec une redirection de port. Que ça soit le port par défaut ou un autre ne change rien (juste peut-être la moindre visibilité dans la mesure ou le port choisi est plus "exotique", les scans de ports utilisés par les pirates potentiels se limitent en général à un nombre restreint de ports connus, mais pas toujours)

Ah oui. Et en effet c'est bien ça quand je me connecte directement dans le navigateur. Par contre ce libellé "syn6-" étrange n'apparait que quand je passe par "DS Finder" => "DSM mobile". Ça doit mettre en place une espèce de proxy/tunnel transparent sans doute. Bof, ça n'empêchera pas de dormir.

Bonjour, Tout d'abord je m'excuse d'avance de poster ici, je n'ai pas trouvé de section appropriée pour "DSM Mobile" Je m'interroge sur la signification de ce libellé "syn6-" sous le nom d'utilisateur ici. C'est sans importance bien entendu 😔

Comme c'est pour partager avec un pote (en fait c'est plutôt lui qui me partage des contenus) je ne veux pas lui imposer un achat de licence donc je pense rester sur Jellyfin. Sinon, la licence c'est uniquement côté serveur ou client aussi ?

Bon et bien ça sera Jellyfin (que je ne connaissais pas) alors et ça m'a l'air vraiment bien fichu.

Voyant ça, en précision j'ai tenté de tester si Plex pouvait m'assurer les mêmes services. A priori pour un access à distance à mon NAS il est necessaire de payer un abonnement Il faut payer pour visionner *ses* videos ? Sans déconner ?

La solution immédiate est donc de directement créer les partages nommés "multimédia" et "partages" (éviter "drive" qui pourrait devenir un jour un nom réservé) et affiner leurs droits d'accès selon les contraintes que tu souhaites leur imposer. (ou, comme dit @cadkey , un unique partage avec deux sous dossier, chacun avec des droits spécifique) mais il ne faudra pas oublier de donner au partage "maitre" un doit global (type lecture pour tout le monde, écriture désactivée) puis en dessous en ouvrant plus les droits. Et laisser "home" et "homes" avec leur configuration par défaut. Mais je persiste à m'étonner que tu indiques avoir créé *toi-même* "home" et "homes" alors qu'ils sont créés automatiquement par le système

C'est vraiment pas de chance : parmi les innombrables possibilités de choix de noms pour un dossier il a fallu tomber pile poil sur deux de ceux réservés par le système. C'est détaillé ici : https://kb.synology.com/fr-fr/DSM/help/DSM/AdminCenter/file_share_desc?version=6 Reste donc plus qu'à choisir autre chose. Au passage je me demande comment il à été possible en pratique de les *créer* alors que c'est fait automatiquement par la procédure d'installation. A noter aussi, pour lever toute ambiguïté, que "home" serait plutôt un dossier virtuel qui correspond dynamiquement au "$HOME" de l'utilisateur connecté (/home/<user>)

Ah en effet (et je le savait en plus) et j'ai zappé que @cadkey avait mentionné ce point important de contexte que c'est relatif uniquement aux certificats des noms fournis par le DDNS Synology. Mais le principal point de mon post était que je ne vois pas de risque supplémentaires face à des attaques externes à ouvrir le port 80 du moment que le port 443 est aussi (sous réserve de démonstration via un cas d'école).

Je n'ai pas compris la remarque 7 mais la 6 stipule le contraire il me semble : "Pour obtenir ou renouveler le certificat de votre domaine personnalisé, assurez-vous que le port 80 a été transmis à votre NAS. Cette limitation ne s'applique pas à Synology DDNS."

Quand je vois la pression qui est mise de plus en plus pour inciter à activer le 2FA sur nombre de services en ligne je suis inquiet d'une recrudescence de "nervouze breakdowns" lors de ce type de situations dans le grand public moins à l'aise avec la technique que nous.

Je serai intéressé par un cas d'usage pratique alors. Ce qui sera interceptible en clair par cette surveillance est uniquement le traffic des sessions venant d'utilisateurs assez stupides pour choisir explicitement de se connecter en http (car laisser la possibilité de se connecter en HTTP n'oblige personne à le faire). Les utilisateurs les plus lambda ne savent même pas de quoi il s'agit et donc utiliseront l'url (de type https donc) qu'on leur a communiquée. Et les autres n'ont aucune raison de le faire. Sinon, reste aussi la solution radicale de fermer le port 80 (sauf que ça pose un problème avec le renouvellement des certificats SSL Lets Encrypt, mais je ne suis pas sûr que ça s'applique aux domaines synology.me, myds.me etc qui utilisent peut-être un autre mécanisme pour le renouvellement... ,à tester) non, j'ai testé comme je l'ai écrit : Alors j'avoue ne pas avoir suffisament testé Ca fonctionne en effet pour une connexion via un navigateur, mais pas contre par dans par exemple l'appli mobile (DS File) Ah ben non, pas si sur finalement : j'ai activé une capture (tcpdump) sur le port 80, forcé la connexion DS File en http, et il semble bien que ça bascule en https aussi

En effet, mais comme je l'ai mentionné antérieurement, je n'ai toujours pas compris en quoi forcer https pouvait contribuer à protéger le serveur. Un potentiel attaquant ne dispose d'aucun avantage du fait que les connexions entrantes en HTTP sont accessibles. Et les utilisateurs légitimes, si par mégarde ils forcent "http:" dans l'URL (dans quel but d'ailleurs ?) , seront prévenu par une alerte de "connexion non sécurisée" dans leur navigateur. Mais *surtout*, la redirection forcée http=>https est déjà configurable dans l'interface DSM, dans la section portail de connexion : Et, même si le libellé parle de "DSM desktop", ça s'applique en pratique également aux services des applications accédées via des alias déclarés dans cette même section du panneau de configuration (je viens de vérifier). De ce fait, je ne vois pas trop l'intérêt de se compliquer à la vie à le faire via un .htaccess

J'avoue ne pas avoir eu le courage de me palucher ce tuto. Je suis intervenu dans ce fil en voyant que ca parlait de reverse proxy et, comme je l'utilise, j'ai pensé pouvoir être utile et surtout expliquer là ou il n'est pas nécessaire (aliases). Il est possible que ce htaccess ajoute des règles de sécurité/contrôle d'accès supplémentaires, où que ca s'applique à des applications spécifiques, mais je ne sais pas j'avoue.