Einsteinium

Moi je suis partie du principe que cela n'aurait été que pour les dyndns de synology comme l'on a sur le RT, des utilisateurs l'ont confirmés derrière.. mais bon si tu dis que cela passe aussi, alors c'est une très bonne nouvelle, espérons que cela arrive sur nos RT alors.

Bah avant il fallait déclarer les sous domaines en champs autres, maintenant ce n’est plus le cas et cela cache du coup les sous domaines, maintenant il serait bon que synology le permettent aussi pour les domaines perso. Pour info tous les certificats sont déclarer... cela permet au bot de découvrir des sous domaines et de testé des attaques... donc le wildcard ce doit d’être systématique.

@StéphanH En gros plus besoin de faire des autos signés qu'il faut modifier à chaque rajout de sous domaine à mettre sur tous les postes derrières, maintenant cela ne marche que pour la DYNDNS synology.

Le soucis avec synology c'est l'import et le relancement des services... Le mieux c'est d'avoir un relais entre tout sa, moi mon vps gère sa, sur mon syno c'est des autos signés, mais à distance c'est les certificats du vps qui prennent la main ^^ Pas de prise de tête au final.

Faudra réduire plus le seul si tu veux detecter a 100% les humains.

Il faut d’abord réclamer le serveur plex, par contre il vaut mieux avoir plex en docker, plex via Pocket sa fou un peu le bordel....

Cela est du à la qualité optique de tes cams, la détection croit à un mouvement, il faudra donc modifier la sensibilité. Pour les personnes, il faut jouer avec le seuil et le réduire.

Effectivement un peu beaucoup HS, vue que c'est une option "routeur", rien a voir avec le VPN/VPS dans l'état. Je vois que tu as un RT2600ac, du coup je ne comprends pas cette utilisation chez toi, ton RT peut parfaitement le faire. (répond en privé pour ne pas HS ici) Je n'avais pas vue ton message (notification fofo grrrr) C'est un pare feu en amont qui fait anti-ddos, avant le VPS, c'est pour cela que je n'aborde pas la sujet dans le tutoriel, on ne s'emmerde pas a jouet avec iptable, ufw ou autre. https://docs.ovh.com/fr/dedicated/firewall-network/

Non regarde bien mon tutoriel, dans l’interface web OpenVPN il y a une option qui permet de dire que le client fait passer tout son traffic à travers 😉

cela me semble complet, je valide.

allemagne ou pologne, tu seras tranquille, il ne flash que les ip française 😉

Justement, il faut tapé "su" pour passé root 🙂 Une fois ton nas connecté au vps, son ip sera celle du VPS et plus celle de ton FAI, il suffit de prendre un vps d'ovh en allemagne (faible ping et débit identique) edit en faites non c'est bien dans le tutoriel déjà : Attention après re connection ssh à partir de maintenant, la connection se fera avec notre utilisateur créé précédemment et on tapera « su », on validera puis on tapera le mot de passe root.

@Jeff777 En gros il force désormais la fonction "Améliorer la compatibilité du navigateur en ignorant la vérification de l'IP"

Sauf que l’application anti virus du synology ne fait pas de scan live... que du manuel...

Y a une partie certificat monté dans mes dossiers, c'est en rapport avec mon tutoriel sur le vps qui sert de relais pour avoir une ip fixe (enfin même quand j'aurais la fibre je le garderais comme première ligne de défense à la facon cloudfire...), c'est un certificat pfx, si certains sont utilisateurs, je donnerais la ligne de commande.

Le SHR qu'il soit en ext4 ou btrfs cela ne change rien au commande pour remonté le lecteur perdue manuellement... le système de fichier n'a rien a voir la dedans... donc je ne sais pas pourquoi tu fais une fixette la dessus... Il y a une section du forum concernant le stockage, certes pas shr, mais les gens vont naturellement dans le raid, le shr étant un raid avec une surcouche. La commande que tu as faites... on la connait pas, dans tout les cas elle devait être foireuse, maintenant si tu étais en root, si tu as lancé une tache gourmande, elle c'est exécuté en haute priorité, attendre qu'elle ce termine été peu être la solution... Tu as stoppé a la brute le nas, y a eu répercution, sa arrive, c'est pareil avec windows... perdre le bénéfice du cache des disques, c'est une erreur colossale... le BTRFS est bien au dessus de l'ext4 en bien des points. Le raid n'est pas une protection, n'y un backup, c'est de la continuité de service avec tolérance de panne 😉

Voilà c'est fait 🙂

Je suis en train de faire la maj des captures 😉

Du coup cela va faire des malheureux ^^

Ouaip mais avant update, afin de ne pas avoir de paquet à réparer... cela pose souvent problème avec des échecs... pour les notifications des updates en France... c’est très long désormais...

@Jeff777 J’aurais dû précisé, vérifier avant les packages et faire manuellement les updates avant upgrade. DLZ : Dynamically Loadable Zones 😉

@.Shad. Pour lets encrypt : wildcard J'ai fais un google traduction 😄 Pour google print la... c'est définitif malheureusement. J'ai pas encore update... mais si c'est comme avec les routeurs... cela sera qu'avec les sous domaines synology...

Et pourtant je peux te dire que la récupération de volume pour du SHR a été mainte fois abordée sur le forum, je suis la depuis un paquet d'année et je t'assure que la solution ce trouve sur le forum et cela, a de multiple fois... maintenant à force d'être en boucle sur des solutions, car les gens sont fainéants ou alors bâcles leurs recherches... bah on reste spectateur... Maintenant tu auras appris une leçon, on ne bidouille pas en ssh sans avoir un minimum de connaissance et que le backup lui est important.

Version: 6.2.3-25423 (2020-04-15) Note importante La mise à jour devrait être disponible pour toutes les régions au cours des prochaines semaines, bien que l'heure de sortie dans chaque région puisse varier légèrement. Cette mise à jour redémarrera votre Synology NAS. Suppression de la prise en charge de Google Cloud Print dans DSM 6.2.3 et supérieur. Pour éviter l'interruption du service iSCSI, la mise à jour DSM automatique et votre programme d'alimentation à arrêter peuvent ne pas être exécutés comme prévu s'il y a des sessions iSCSI actives. TWNIC supprimé de la liste des fournisseurs de services DDNS sur DSM 6.2.3 car TWNIC cessera d'accepter de nouvelles inscriptions pour DSM à compter du 1er juillet 2020. Vos services DDNS TWNIC actuels peuvent toujours être utilisés et modifiés mais ne seront plus disponibles une fois supprimés de DSM. Il s'agit de la dernière version DSM majeure (6.2) qui prend en charge la conversion vidéo en .flv et MPEG-4 Partie 2 sur certains modèles (RS814, RS214, DS414, DS414slim, DS414j, DS216se, DS215j, DS214 +, DS214, DS214se, DS213j, DS120j, DS119j, DS115, DS115j et DS114) en considération de la fin de la prise en charge d'Adobe pour Flash Player d'ici la fin de 2020. Nouveautés de DSM 6.2.3 Le LUN de Thin Provisioning sera protégé sur un espace de volume insuffisant, empêchant les clients d'écrire des données sur le LUN tout en autorisant un accès en lecture seule aux données existantes. Ajout de la prise en charge de la connexion à DSM à l'aide d'un UPN (nom d'utilisateur principal) d'un domaine via un portail Web et des protocoles de fichiers. Ajout de la prise en charge de l'option de forcer les modifications de mot de passe pour l'importation d'utilisateurs locaux. Amélioration de la compatibilité de la liste d'utilisateurs importée, fournissant des messages d'erreur plus clairs lorsque le fichier importé contient des erreurs de syntaxe. Prise en charge supplémentaire pour enregistrer uniquement les événements de transfert SMB sélectionnés par l'utilisateur, fournissant des journaux de transfert qui répondent plus étroitement aux exigences. Ajout de la prise en charge des utilisateurs clients pour surveiller les modifications des sous-répertoires sous les dossiers partagés via le protocole SMB. Ajout de détails sur les notifications de bureau pour faciliter les réponses rapides des utilisateurs. Ajout de la prise en charge des périphériques du système de fichiers UDF externes. Ajout de la prise en charge de l'option Open vSwitch dans un cluster à haute disponibilité. Ajout de la prise en charge de la détection des conflits IP, fournissant des journaux et des notifications en conséquence. Ajout de la prise en charge des certificats Wildcard Let's Encrypt. Ajout de la prise en charge pour renoncer à la nécessité de se connecter à nouveau DSM via une connexion HTTPS après un changement d'adresse IP du client. Ajout de la prise en charge du verrouillage assisté par matériel pour le LUN de provisionnement épais sur un volume ext4. Ajout de la prise en charge de Synology SSD et des paramètres pour fournir des avertissements appropriés lorsque la durée de vie estimée en fonction du temps atteint la valeur spécifiée. Ajout de la prise en charge du message de pied de page personnalisé sur les pages de connexion DSM. Problèmes résolus Correction d'un problème où certaines villes pouvaient être mappées à des fuseaux horaires incorrects. Correction du problème où les utilisateurs LDAP ne pouvaient pas être informés de l'expiration prochaine du mot de passe. Correction du problème où le téléchargement du certificat LDAP ne pouvait pas remplacer celui d'origine par le même nom de fichier. Correction du problème où les paramètres d'autorisations d'application pouvaient ne pas être appliqués correctement au groupe Utilisateurs du domaine lorsque ce groupe dans le domaine Windows AD était nommé autre que «Utilisateurs du domaine». Correction du problème d'heure imprécise de l'historique d'utilisation dans Resource Monitor. Amélioration de la réactivité du système en réduisant la latence du système de fichiers Btrfs dans certains scénarios. Correction du problème où SNMP ne fournissait pas correctement les indices de disque et RAID. Correction du problème où la corbeille d'un dossier partagé chiffré pouvait être vidée correctement. Amélioration des performances de connexion DSM pour plusieurs connexions simultanées. Ajustement du mécanisme de notification personnelle pour se conformer à la dernière API Gmail. Correction du problème où le service iSCSI pouvait être interrompu lorsque la tâche de sauvegarde LUN était arrêtée. Suppression de la fonction d'extension de la capacité d'un bloc LUN. Problèmes connus et limitations L'accès à DSM via HTTPS à l'aide de Google Chrome sur un appareil client exécutant macOS 10.15 peut échouer après une mise à jour DSM à partir d'une ancienne version. Bug connu avec photo station qui retourne des échecs de connection, vous trouverez le patch a cette adresse qui désactive la protection de compte pour ce dernier en attendant la sortie officiel d'une mise à jour du paquet : https://supfiles.synology.com/sharing/DuhwjyHNz Fixed multiple security vulnerabilities (Synology-SA-20_02).

oui les données ne sont pas chiffrés sur le nas, mais les données le sont certainement entre les deux nas, ce qui est inutile localement, désactive l'option et cela devrait être plus rapide.