Fenrir

Je ne l'ai pas testé en DSM 6, il y a peut être une incompatibilité. Il faut vérifier 3 points (en ssh) : les ports utilisés (déclarés dans haproxy) sont-ils disponibles ? s'il tourne déjà, il faut essayer de le couper puis de le relancer (il s'est peut être mal arrêté) et évidemment, les logs Si tu ne sais pas faire tout ça, tu peux essayer de relancer ton nas.

Il en existe d'autres, mais Handbrake est très bien, il manque juste un peu de flexibilité, mais dans ce cas ffmpeg fait le travail.

Sans rentrer dans les détails, en fonction des options des serveurs web et des failles ou bug, on peut énumérer assez vite des noms de domaine voir leaker des morceaux de conf. C'est loin d'être une science exacte, mais ça donne d'assez bon résultats en général. Si la sécurité t’intéresse, je suis certain que tu connais déjà au moins un outils capable de faire ça, tu n'as juste pas vu l'option ...

OpenVPN peut faire de l'authentification par certificat client, mais ce n'est pas proposé par Synology, donc c'est normal ici. Tu peux suivre la recommandation si besoin. Les mots de passe sont en cache pour permettre une reconnexion automatique en cas de micro coupure. À toi de voir. Ça c'est la conf Synology qui n'est pas top, ils sont loin d'être des expert en sécurité et préfère souvent privilégier la compatibilité à la sécurité. C'est une ligne à changer dans server.conf sur le nas. Normalement tu as du copier le certificat dans le dossier d'openvpn, à coté du fichier de conf. Le client s'en sert pour vérifier qu'il parle bien au bon serveur et pour chiffrer la connexion.

C'est aussi ce que je recommande Oui et non, ça dépend Oui car : si chaque port (indépendamment du nom de domaine) ne renvoi sur une application différente, tu exposes en direct plus de services aux bot, donc plus de failles potentielles => tu as parfaitement raison Non car : Si les 40 ports attendent aussi un nom de domaine c'est tout aussi sécurisé qu'avec un seul port vis à vis d'un bot. Si la faille est sur le reverse proxy lui-même, ça ne change rien non plus. Il existe plusieurs manières de déterminer les virtualhosts valides derrière une IP (et pas seulement via les DNS). Mais ici on ne parle que dans le cas d'applications WEB, il existe de nombreux autres services sur Internet (rstp, xmpp, smtp, ftp, imap, ssh, ipsec, ...) et ces services ne peuvent généralement pas se partager un port (du moins pas sans intermédiaire type sslh). Les bots ne s'appuient pas sur les numéro de port pour tester telle ou telle faille, mais sur la signature renvoyée par le serveur. Apache, Cherokee, IIS, Nginx, ... écoutent généralement sur les port 80 et 443 (puisqu'il s'agit de serveurs web), mais ils n'ont pas les mêmes failles, donc les bots font évidemment le tri avant de tester tel ou tel exploit. Mais peu importe, ce que je voulais indiquer c'est que n'utiliser qu'un nombre restreint de ports est plus un gain de confort que de sécurité, merci pour le commentaire, on voit que tu as creusé la question

Ce tuto ne s'adresse pas à tes "habitués" des conf réseau, c'est plus destiné à du grand public, donc c'est plus simple et fiable de la faire via DHCP (on ne se trompe pas de passerelle, de dns, pas de risque de conflit, ça marche si on change de box, si on change un paramètre sur le serveur dhcp, ...). Maintenant si tu es à l'aise avec les conf réseau, il n'y a aucun problème (autre que ceux liés à la gestion) à attribuer une adresse ip en dur sur un équipement.

Oui c'est classique chez eux, il y a toujours un décalage de quelques jours entre la sortie d'une version stable et sa publication sur le site principal, ça leur permet de prolonger un peu les tests avant de donner les versions en pâture à des centaines de milliers d'utilisateurs

Oui j’avais vu, elle est installée chez moi depuis samedi, pas de soucis pour le moment. @gaetan.cambier pendant que j'y pense, netconsole est maintenant présent si tu veux jouer avec les modules et avoir un peu de log pendant la phase de boot

S'il y a du NAT entre les clients et le serveur, vous pouvez rencontrer ce soucis lorsque plusieurs clients sont connectés en même temps (et pas nécessairement au même serveur). C'est une limitation de l'IKEv1. Pouvez vous tester avec un seul client Windows 7 (et en ayant bien appliqué les modifications dans la base de registre). Il faut aussi bien s'assurer que les ports UDP 500 et 4500 sont autorisés des 2 cotés (en sortie coté client et en entrée coté nas), ce qui devrait être le cas puisque W10 y arrive. Il faut aussi veiller à ce que le port UDP1701 soit bien fermé sur le routeur du nas mais autorisé sur le nas lui même. En gros je répète ce que j'ai indiqué dans le tuto, mais j'ai testé avec des W7 propre et à jour, ça fonctionnait au moment de sa rédaction. Sauf si une mise à jour du paquet VPN a créé une incompatibilité (dans ce cas il y aurait eu de nombreux commentaires je pense), le problème ne vient pas du NAS. Quelqu'un a encore un Windows 7 pour tester ?

c'est possible, dnsmasq est un serveur dhcp+dns après je ne sais pas si on peut le configurer simplement avec tomato

Ce fichier n'est pas important. Dans ton cas, le plus simple c'est de faire une copie du dossier dans un espace accessible Par exemple si tu as un partage nommé tmp : cp -r --preserve=all /var/log /volume1/temp/ Après tu pourras regarder le contenu des fichiers avec un éditeur de texte (notepad++ est très bien pour ça et plein d'autres choses).

Les photos c'est autre chose, si tu utilises photostation, les droits du dossier /homes/<user>/photo sont à gérer dans photostation Mais les droits avec filestation ou les lecteur réseau sont bien gérés au niveau des partages Oui, il faut simplement utiliser le bouton "Connecter un lecteur réseau" dans l'explorateur de Windows (sinon en commande avec net use ...)

Un autre utilisateur a eu un soucis similaire il y a peu, c'était un problème au niveau d'un des CDN de synology, mais ça avait été corrigé : Tu es peut être dans le même cas (et tu passes par un autre miroir)

https://www.synology.com/fr-fr/support/download/DS214 Tu dois avoir un soucis de corruption de l'index des applis. Si tu te connectes en ssh pour aller voir les logs dans /var/log, tu devrais trouver des indices je pense.

Non, seuls les administrateurs et le propriétaire du dossier peuvent voir le contenu de /homes/<user> Si d'autres utilisateurs qui ne sont pas admin arrivent à voir le contenu du dossier c'est que tu as changé les droits par défaut. Une recommandation en passant, il vaut mieux éviter de changer les permissions sur les dossiers, il est plus fiable et plus propre de ne le faire qu'au niveau des partages (dit autrement, il ne faut pas utiliser les permissions avancées ni utiliser filestation pour changer les droits). Pas à ma connaissance. Oui, on peut lancer des scripts perso via le planificateur de tâches. Les langage de base (ou installables via le centre de paquets*) sont : bash, sh, php*, java*, node.js*, perl*, python* et ruby* Ça te laisse le choix des armes. Je recommande bash car c'est le plus simple pour accéder aux commandes du système. nb : les systèmes Unix (dont le Linux du syno) sont sensibles à la casse (majuscule vs minuscule)

Difficile de t'expliquer sans faire un cours réseau, même en simplifiant à l’extrême. Pour comprendre la suite il faut bien intégrer le fait que les routeurs grand public sont généralement composés de 2 éléments, un routeur et un switch. Ces 2 composants ne vont pas du tout à la même vitesse car ils ne font pas du tout la même chose (le routeur doit faire bcp plus de choses et est donc nettement plus lent, parfois d'un facteur 10 ou pire). En faisant du loopback (le vrai terme est nat-loopback), tous les paquets réseaux doivent passer par le routeur et être transformés 2 fois (pour modifier l'adresse du client à l'aller et pour modifier l'adresse du nas au retour) Avec le DNS, le client et nas se parlent en direct au travers du switch, sans passer par le routeur Dit autrement, en loopback, chaque paquet (cette page web en compte 3000) subit un NAT + un transfert de port à l'aller et un NAT au retour. En le faisant via un DNS, il n'y a aucune transformation. Par analogie, on pourrait dire que le loopback c'est comme si pour passer un message à un correspondant au téléphone, le standardiste devait répéter toutes tes phrases à ton destinataire (et vice versa). nb : certains routeurs utilisent d'autres méthodes pour le loopback (spoofing arp et/ou routage asymétrique et/ou icmp redirect), donc c'est moins lent, mais c'est très très sale et ça cause souvent d'autres problèmes En passant, 2 autres intérêts à éviter le loopback : si tu as un forfait limité c'est risqué, parfois le trafic loopback compte dans le quota (si c'est le cas chez toi tu peux te plaindre à ton ISP, c'est illégal, mais ça existe) ton nas ne voit pas l'adresse du client mais l'adresse locale du routeur, ce peut être gênant pour le filtrage sur le nas Non, le DNS ne fait que donner l'ip qui est cachée derrière un nom, il ne gère pas le trafic, il indiquera donc au client que le nas est juste à coté, le client et le nas se parleront alors en direct. Oui pour 2 raisons (mais ce n'est pas systématique, ça dépend des routeurs) : sur certains routeurs, quand la connexion Internet tombe, l'adresse public disparait du routeur, donc le loopback ne peut plus marcher si tu n'as plus le net tu ne pourras plus joindre le serveur DNS public que tu utilises pour ton domaine, donc tu ne sauras pas à qui envoyer les paquets, même si l'adresse public est encore présente sur le routeur

Tu as probablement relancé le service DNS du tomato, il a donc purgé son cache. ------------------- Depuis une machine sur le lan, fais : nslookup ton.nom.de.domaine Si l'adresse n'est pas privée (10.0.0.0/8 ou 172.16.0.0/12 ou 192.168.0.0/16) tu fais du loopback, ce qui est dommage du point de vue performances (2 machines l'une à coté de l'autre doivent passer par le routeur pour se parler). À l'occasion, si ça t’intéresse de comprendre, essaye de le faire avec le DNS, c'est plus performant (ton pc et ton nas se parleront directement sans passer par ton routeur), plus fiable (si demain tu changes de routeur ça marchera encore, même si tu as une panne Internet ou que tu supprimes le routeur) et plus instructif.

En général, l'adresse du serveur DNS à utiliser est reçue en même temps que l'adresse ip, c'est le serveur DHCP qui fourni les infos. En IPv6 ça peut être différent (slaac), mais le principe reste le même, l'adresse des serveurs DNS est fournie automatiquement aux clients.

Il faut simplement faire en sorte que lorsque tu es chez toi, les DNS répondent avec l'ip local du nas et pas avec l'ip public du modem. De mémoire tomato permet de créer des enregistrements DNS (mais ça fait au moins 10ans que je n'en ai plus testé). Si c'est le cas pas de soucis. Sinon tu peux faire la même chose avec le DNS du synology, il faudra juste que tu configures ton routeur pour annoncer ton syno comme serveur DNS pour tes clients locaux. nb : le loopback est souvent une fausse bonne idée car en général il est mal implémenté et fait appel au NAT -> on perd bcp de perf

je ne peux rien dire de plus que dans mon post précédent si ce n'est que ton dernier message indique que le problème ne vient pas du nas (ou alors tu as le même soucis sur les 2 nas, ce qui est n'a presque aucune chance d'arriver). =>pb de câble ou de switch

ça des erreurs aux heures de ton test de mise à jour les fichiers sont triés par date de la dernière modification, donc commence par les plus récents et regarde dedans s'il y a des messages à l'heure de ta tentative de mise à jour

C'est le principe

non, c'est un exemple, tu peux choisir n'importe quel port disponible sur le nas (si un port est déjà réservé, le nas te prévient) il faut que tu ailles dans Portail des applications, que tu choisisses FileStation -> Modifier

je pensais que tu avais déjà fait ça, encore une fois j'ai mis des exemples dans "Portail des applications" (j'ai barré les morceaux que tu devrais oublier pour le moment) Pour les autres applications elles ont des ports spécifiques : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/What_network_ports_are_used_by_Synology_services