Fenrir

Par défaut, l'HTTPS utilise le port TCP 443, c'est tout, c'est juste le comportement par défaut des navigateurs (comme pour HTTP, par défaut ils vont sur le port TCP 80). Sinon 443, 7001, 9999, ... sont justes des "portes", c'est toi qui décide ce qu'il y a derrière. La seule contrainte, c'est que comme certains ports sont standardisés, il vaut mieux ne pas les utiliser pour autre chose (il faut éviter de faire du HTTPS sur le port 80 par exemple). Pour le nombre de ports ouverts, qu'il y en ait 1 ou 50, niveau sécurité réseau c'est la même chose. Ce qui compte c'est la sécurité de l’application qui est derrière. Dernier point, la traduction en français de proxy (inverse ou direct) c'est mandataire, un proxy fait donc les demandes à la place du client et peut, si on lui en donne le droit, modifier ces demandes (et les réponses). Par exemple : On configure : https://www.domaine.fr => http://localhost:7000 (filestation sur le NAS) On demande : https://www.domaine.fr => le proxy prend la demande (avec les éventuels paramètres, comme le nom de la page, les post/get, ...) et la transmet à http://localhost:7000 L'application qui écoute en local sur le port 7000 (filestation ici) répond au proxy (puisque pour le nas, le client c'est le proxy) et le proxy transforme la réponse pour la renvoyer au vrai client

Comme le nas est un 4 baies et que la volumétrie est très faible, je ferais 2 raid1 (donc 2 volumes), le premier pour les données de travail et le second pour une sauvegarde quotidienne de premier niveau et comme proposé, l'ancien disque servant pour des sauvegardes externe. Autre possibilité, au lieu d'acheter 4 nouveau disques, l'achat de 2 disques et d'un petit nas 1 ou 2 baies permettrait d'avoir 2 nas (le ds413 pour les donnés et l'autre pour les sauvegardes via le réseau). Ça devrait revenir à peu près au même prix.

@gaetan.cambier : je ne pense pas que le cache soit gênant, mais tu as raison, mieux vaut se méfier (perso je ferais tout même un mount en ro, juste pour voir) @ambrius Attends le retour de syno et profites du délai pour réfléchir à une solution de sauvegarde Par exemple ton nas pour les data et le DX pour un premier niveau de sauvegardes

Jamais regardé comment c'était monté chez syno, mais si c'est "juste" un cache lvm, le désactiver (lvconvert --uncache ...) voir le supprimer (lvremove ..) ne devrait avoir aucun impact sur les données s'il est vide (c'est le cas ici apparemment). En quoi est il gênant ?

Tu as juste à transférer les ports dont tu te sers, pas les autres.

oui Dans les navigateurs, la plupart des gens, on va dire 99,999% de la population, entrent monnas.mondomaine.com et pas https://monnas.mondmaine.com:8801 La redirection couplée au reverse proxy permet d'être sûr que la connexion est sécurisée tout en gardant le confort d'une adresse simple à retenir et à saisir. Le lien avec la sécurité ? Si c'est contraignant, les gens abandonnent, donc si on souhaite sécuriser, il faut faire en sorte que ça soit le plus transparent possible.

Pour les applis mobile, si tu souhaites faire du chiffré, il faut : cocher la case HTTPS sur l'écran de connexion de l'appli et avec certaines applis, avoir un certificat valide installé sur le nas Pour le navigateur, si l'adresse commence par https://, la connexion est chiffrée (elle peut ne pas être sécurisée si le certificat n'est pas valide).

Si tu veux être certain de n'utiliser que des connexions chiffrées sans passer par des redirections ou le reverse proxy, n'ouvre tout simplement pas les ports non chiffrés Par exemple, si 7000 est en http et 7001 et en https, n'ouvre que le 7001. Pour le message du navigateur, il faut faire la différence entre connexion non sécurisée et non chiffrée.

La case de redirection HTTP->HTTPS elle même ne présente pas grand intérêt car elle ne s'applique pas partout et créé parfois des problèmes. Il vaut mieux gérer les redirections d'une manière qui fonctionne pour toutes les applications, c'est ce que permet le petit bout de php combiné au reverse proxy (ce n'est pas pour ça que j'en avais parlé dans le tuto, mais il s'avère que c'est la méthode la plus fiable actuellement). Pour te répondre de manière plus générale. Le fait que la "connexion" soit en https limite les risques d’interception de données (login/pass par exemple) lors de l’utilisation de réseaux peu fiables (wifi ouverts, hotspot, certains pays, ...), c'est aussi valable pour les appli sur mobile Si un navigateur indique que la connexion n'est pas sécurisée c'est qu'il y a un soucis : le site n'utilise pas de certificat (ça peut être un choix), si c'est en local (pc et site dans le même réseau), ce n'est pas grave le certificat est invalide (pas signé, mauvais nom, expiré, ...) => ça il faut toujours le corriger, c'est important À titre personnel, je n'ai pas envie de me poser la question de l'adresse à utiliser et de la validité du certificat en fonction de l'endroit d'où je me connecte (maison, vpn, amis, ...), donc j'ai tout passé en HTTPS et j'utilise les mêmes adresses dans tous les cas. Ce n'est pas le plus simple à mettre en place, mais une fois qu'on a bien compris le fonctionnement, c'est tellement plus confortable à l'usage qu'on se demande pourquoi on ne l'a pas fait depuis le début. ps : mes 3 gros tuto (Sécu, VPN et DNS) sont liés, il ne faut pas forcement tout suivre, mais il faut tout lire, ça permet d'avoir une vision d'ensemble plus précise.

La redirection HTTP->HTTPS concerne uniquement DSM, pas les applications, de plus elle peut créer d'autres soucis. Pour arriver à tout passer en HTTPS avec redirection, je te recommande le combo php+reverse proxy (j'ai donné des exemples dans le tuto).

La ram n'a presque aucun impact sur les actions liées aux disques. C'est pour les applications (machin station, docker, base de données, ...). Sinon pour le modèle, je pense aussi que le changement de nas n'est pas pertinent, un DSxx15+ ne t'apportera pas grand chose de plus niveau perf.

Il faut installer et utiliser wordpress avec l'adresse définitive dès le départ. C'est une limitation de wordpress, il utilise l'adresse présente dans le navigateur pour créer la configuration et les liens du contenu.

De manière générale sous Windows, avant (ou éventuellement après) avoir fait le clone, il faut faire un sysprep pour créer une nouvelle identité de machine. Il faut bien évidemment changer le nom de la nouvelle machine après. Dans ton cas, tu peux faire le sysprep sur la nouvelle machine (normalement c'est ton "master" qui devrait avoir eu le sysprep). C:\Windows\system32\sysprep\sysprep.exe /generalize

Le fait de désactiver/réactiver quickconnect a forcé une mise à jour, mais rassures toi, le problème va se reproduire . Il faut faire un choix Si en local ça fonctionne, on peut s'occuper de la partie "accès depuis Internet", c'est le point 3.3 du tuto que tu as trouvé L'étape suivante sera de faire en sortie que ça fonctionne avec un nom de domaine.

Si tu test bien avec un fichier tout simple, tu dois avoir un problème de conf au niveau webstation et/ou reverse proxy. Le NAT consiste à indiquer à ton routeur qu'une demande arrivant d'Internet sur un port donné, doit être transférée sur ton NAS sur un port donné (en général le même, mais ce n'est pas une obligation). Pour le tuto, tu n'en es pas encore là, essaye déjà de faire marcher webstation/php en local (un pb à la fois c'est plus simple).

Le code 401 indique que c'est la destination qui refuse ta connexion car tu n'es pas authentifié. Pas de lien avec les permissions des fichiers.

Et quelque soit le modèle, cela a une très forte chance d'endommager tout ou partie des données du disque.

Commence par supprimer QuickConnect. Créé un fichier test.php (un bête echo) à la racine de /web. Ensuite vérifie que le port est bien autorisé à la fois dans le firewall du nas et dans la box (transfert de ports). Puis détermine ton adresse IP publique, par exemple ici : http://ip.fenrir.fr Enfin, connecte toi directement avec ton ip depuis ton smartphone : http://x.x.x.x/test.php Si tu accèdes à ton fichier, il te reste à gérer la partie DNS, sinon, tu as un soucis de firewall/nat/ip publique/fai

<?php echo "test"; ?> voila un site pour tester

Ton site "appelle" ou "renvoi sur" ?

L'erreur open_basedir indique que ton code php essaye d'atteindre un fichier qui n'est pas dans la listes des emplacements que php peut consulter. Avec DSM6 c'est réglable dans WebStation, mais je ne me rappelle plus si l'option existait en DSM5.2. Le problème c'est qu'ici ton code est bien placé (/var/services/web est un lien vers /volume1/web). Si tu fais un simple include (ou require), ça fonctionne ?

La première chose c'est de ne pas utiliser de .htaccess pour ça (d'ailleurs il ne faudrait pas en utiliser de manière générale, c'est mal). Sinon, pour y arriver, il faut séparer tes domaines dans différents vhosts (ce que tu devrais faire de toute manière) et ne faire la redirection que lorsque c'est nécessaire. https://httpd.apache.org/docs/2.4/fr/rewrite/avoid.html Tu peux aussi y arriver avec un rewrite, mais je le déconseille (rewrite ça ne sert pas à passer de http à https). Enfin, le reverse proxy permet aussi de faire ça (indirectement, mais le résultat est le même). edit : si tu tiens vraiment à le faire avec un htaccess et rewrite, tu peux utiliser RewriteCond avec la négation (!) RewriteEngine on Rewritecond %{HTTP_HOST} !^www\.example\.com RewriteRule ^(.*)$ https://www.example.net/$1 [R=301,L]

C'est la même erreur que sur un poste Windows "classique", ton nas est derrière un NAT, par contre aucune idée de comment configurer un Windows Mobile (je n'en ai jamais eu).

Tu fais erreur, mais rien de grave, le raid0 (qui est à éviter le plus possible) consiste à répartir les données sur tous les disques (ce qui a pour conséquence que la perte d'un disque entraine la perte de toutes les données !!). Une fois en raid0 on ne peut plus le changer sans tout formater. Dans ton cas, ton 2nd disque est simplement en attente d'affectation (Statut Initialisé), tu dois aller dans Volume puis Gérer, l'assistant devrait te proposer d'étendre le volume (le terme est mal choisi) pour passer ton SHR sans protection de données à un SHR avec protection de données (qui est un raid1 en pratique). Cela n'affectera pas tes données, mais il est toujours plus prudent d'avoir une sauvegarde sur un autre support (à minima des données importantes). Si ton disque 1 a un soucis lors de la création du raid1, tu risques de perdre tes données. Le risque est faible, mais les WD Red 3To ont une assez mauvaise réputation. Si tu as un doute, post les différents écrans au fur et à mesure.

System Requirements: Surveillance Station 8.0 package is required to be installed on your Synology products. Supported operation systems: Windows 7 and onward Mac OS 10.11.3 and onward on ne dirait pas