Mic13710

Je ne vois pas le rapport. Votre borne AX92 est connectée en ethernet à votre RT. Si vous la passez en point d'accès et non en routeur comme c'est le cas à présent, ça ne change rien au niveau du wifi (vous gardez votre SSID et votre mdp), par contre les clients eux sont connectés au réseau du RT au travers de la borne et reçoivent leurs IP du RT. Dans ce cas, votre PC portable (comme tous les clients de la borne) reçoit une IP en 192.168.2.x et peu directement communiquer avec vos NAS, votre imprimante, etc....

Les adresses IP des smartphones ne sont pas fixes. Elles varient en fait très souvent. Deux possibilités : soit vous ouvrez toutes les plages d'IP couvertes par votre opérateur (je vous laisse chercher), soit vous passez par le VPN du NAS (ou celui du routeur s'il en est pourvu) et vous autorisez la seule plage IP de votre VPN. Le risque 0 n'existe pas. Si vous avez correctement paramétré le parefeu de votre NAS, que les tentatives de connexion en échec sont bloquées comme indiqué dans le tuto et que vous avez limité les accès au reverse proxy aux seules adresses de confiance, les risques sont assez limités.

Oui, à condition que l'IP soit la bonne !

Il faut rajouter une règle Refuser après la dernière règle :

Il faut paramétrer la borne wifi en point d'accès et non en routeur pour que les adresses ip attribuées aux clients de la borne soient attribuées par le DHCP du routeur ou de la box.

Le plus direct c'est de créer des lecteurs réseaux sur chaque PC qui pointent vers les "home" respectifs. En utilisant exclusivement l'IP LAN du NAS (en 192.168.x.y), ces lecteurs sont accessibles localement et à travers le VPN.(\\192.168.x.y\home, identifiants de l'utilisateur, valider pour que le lecteur soit activé au démarrage du PC). Mais pour cela, il faudrait autoriser l'accès au LAN. Sinon, vous pouvez utiliser l'IP du VPN mais à ce moment là les lecteurs ne seront pas accessibles localement. C'est un choix. Pas de NetBIOS car ils sont beaucoup moins stables que les IPs. Je ne suis pas du tout familier avec les ibidules et imachins. Et donc, je ne suis pas à même de commenter ce qu'il se passe du côté de vos clients. Le problème qui peut exister concerne le certificat utilisé dans le fichier .conf qui est peut être expiré. Lorsque vous créez le fichier à partir de DSM, le certificat qui est utilisé est celui que vous avez indiqué dans les paramètres. L'ennui c'est que si vous utilisez le certificat Let's Encrypt, ce dernier est renouvelé tous les deux mois et il faut alors remettre à jour le fichier .conf sur tous les clients pour actualiser le certificat. Pour résoudre cela, je ne saurais trop vous conseiller d'utiliser à minima le certificat par défaut du NAS dont la validité est beaucoup plus longue. Le mieux étant de créer un certificat autosigné dont la durée de validité est la plus longue possible. J'ai pour ma part un certificat autosigné avec une échéance en 2038 et que je n'utilise que pour le VPN (bien que je ne passe plus par le serveur VPN du NAS depuis bien longtemps) Ce qui signifie qu'il faut d'abord indiquer à DSM quel certificat utiliser pour le serveur VPN AVANT de créer le fichier .conf. Si vous le faites après, il n'y aura pas de correspondance entre fichier et certificat.

Sans les disques je suppose ?

Je comprends mieux. Mais dans ce cas, je ne crois pas que le serveur VPN puisse être invoqué, ni même le nom de domaine et son certificat qui sont situés sur le LAN. Je peux me tromper mais sans accès au LAN, vous ne pourrez pas obtenir les résultats escomptés.

Indépendamment du problème d'alim, je vois que vous avez des WD60EFAX sur votre NAS. Comment sont-ils montés : en RAID (ou SHR) ou en groupes séparés ? Ces disques sont en techno SMR et ne sont plus compatibles avec les NAS. Ils ont d'ailleurs été retirés des listes de compatibilité chez Synology. Un peu de lecture : Ce n'est pas cela qui a pu provoquer votre problème actuel, mais il faut être conscient que vos disques peuvent subir des dysfonctionnements sur la gestion et l'accès aux données.

Quickconnect n'est pas recommandé ici. C'est une solution de facilité pour faire une installation rapide pour néophytes, mais elle est très lente et très questionnable du point de vue sécurité puisque vous dépendez de services externes. A ne pas utiliser et lui préférer un nom de domaine (celui proposé par Synology est suffisant dans la majorité des cas). Je vous invite à aller faire un tour dans la section des tutoriels où vous trouverez un tuto sur la sécurisation de nos NAS dans lequel on y parle de ces questions. A mettre absolument en pratique.

Y'a pas comme un truc qui cloche ? En l'absence de test des disques, il n'est pas évident de définir la source du problème, mais s'ils tournent comme vous le dites dans votre dernier message, alors il y a de fortes chances pour que ce soit un problème sur le bloc d'alimentation.

Où plus simplement un port Gb limite le transfert à ... 1Gb/s 🙃 Et probablement que tout votre réseau est en Gb (soit 125mo/s), à ne pas confondre avec des Go ou GB !

Wifi ou ethernet ? Protocole ?

Le DDNS et l'IP n'ont pas de rapport avec le certificat. Ce que je demandais c'est si les applications étaient bien associées au certificat xxxx.synology.me dans les paramètres de la page des certificats de DSM. C'est un prérequis indispensable. Qu'est-ce que vous appelez le split tunnel ? Cette notion est assez complexe à mettre en oeuvre et je m'étonne que vous en parliez. Pour bien comprendre ce qu'on vous explique, le VPN vous permet de joindre votre LAN. Si vous utilisez un nom de domaine pour atteindre vos applications, il faut que l'URL que vous utilisez puisse être résolue localement soit à l'aide du loopback si votre routeur le permet, soit à l'aide d'un serveur DNS local, cette dernière proposition étant de loin la meilleure. Sans cela, vous ne pouvez pas utiliser localement vos noms de domaine, que ce soit en direct ou au travers du VPN.

A moins d'avoir un minimum de matériel (charge variable, appareil de mesure) il est impossible de tester. Si vous avez la possibilité d'emprunter une alimentation, vous pouvez essayer avec un autre bloc, sinon, il faut commander, en espérant que ce soit ça. Il faudrait avant cela tester les disques dans un dock pour voir s'il n'y en aurait pas un HS. Qu'a donné le test de la CM ?