Fenrir

c'est un peu brutal comme réponse, même si c'est vrai dans le cas présent iSCSI n'est pas fait pour être utilisé sur des liens non fiables, comme la plupart des protocoles en mode bloc Les liaisons WAN (Internet) état rarement très fiable, il vaut mieux éviter à moins d'avoir de quoi faire du multipath (peu probable dans ton cas) C'est par contre parfaitement adapté pour un usage entre datacenter avec des liens fiables et redondés iSCSI est un protocole permettant de faire transiter du SCSI sur IP, il s'agit donc de faire transiter des informations de lecture/écriture de bloc disque. S'il y a la moindre perte de paquet qui n'est pas compensée par la couche IP, il y a une très forte probabilité de corrompre les données. comme il s'agit d'écrire des blocs, il faut un système de fichiers adapté pour l'utiliser à plus de 1 machine en même temps. Par exemple ocfs, gfs, ... NTFS ne le permet pas, d’ailleurs à ma connaissance il n'y a aucun système de fichier compatible Windows qui le permette C'est pour ça qu'il existe de systèmes de fichiers réseau (CIFS, NFS, AFP, ...). Je te recommande d'utiliser un système de fichier réseau (CIFS si c'est du Windows, NFS sinon) pour ton besoin, idéalement au travers d'un VPN site à site Tu as tout ce qu'il faut dans le syno pour ça.

J'ai souvent lu la même chose sur différents sites/forums, mais ils n'indiquent que trop rarement les conditions EXACTES des tests. Si le PC qui fait les tests a un lien 1Gbtis, même avec un NAS à 10Gbits tu ne dépasseras pas les 1Gbits. C'est toujours le maillon le plus faible lent qui donne le ton. Je n'ai pas testé l'aggregation avec un syno, mais j'en utilise quotidiennement au boulot et j'obtiens facilement des débits bien supérieurs à ce qu'un simple lien permet. Il y a différents type d'aggregation, le débit dépend des réglages, du matériel, de l'OS et du logiciel de copie utilisé. Par contre, dans la pratique et en conditions "home user", il est rare de pouvoir dépasser les 1Gbits/s car il faut : 1-un nas qui dispose d'au moins 2 cartes 1Gbits en 802.3ad et de disques suffisamment rapide (plus de 100Mo/s) 2-un pc qui dispose d'au moins 2 cartes 1Gbits en 802.3ad et de disques suffisamment rapide (plus de 100Mo/s) 3-le tout connecté à un switch qui gère l'agreggation et qui a un fond de panier supérieur au débit escompté 4-et d'un logiciel de copie qui gère le multiplexage Autant dire qu'on ne rencontre pas ça chez les Michu =>donc comme l'indique PiwiLAbruti, il y a peu de chances que tu en ai le besoin et que tu puisse en profiter.

Vérifie qu'il n'y ait pas d'erreurs sur le dd du syno (info smart), voir sur le syno lui même (dans les logs)

fais le même test avec un autre pc

ça ressemble à des pertes de paquets les causes les plus fréquentes sont : -câble défectueux -interférences : proximité d'un câble courant fort, d'un haut parleur ou d'un équipement électroménager avec l'un des maillons de la chaîne -carte réseau défectueuse -problème de mtu Il faut tester chacun des morceaux de ton installation (pc/câbles/switch/syno) Le plus simple pour tester : -configure une ip fixe sur le syno, par exemple 10.0.0.1/255.255.255.0 -configure une ip fixe sur le pc, par exemple 10.0.0.2/255.255.255.0 -branche les 2 en direct avec un câble de bonne qualité et pas trop long (selon le pc, il faudra peut être un câble croisé) -test Si tu n'as pas de soucis dans cette configuration, tu peux mettre hors de cause le pc et le syno. Il faudra alors tester le reste (en particulier les interférences et les switch)

En pondérant par la compatibilité des disques, tu devrais pouvoir utiliser tes anciens disques dans un synology. En écriture c'est le raid 5 qui consomme le plus de ressources car il faut faire des calculs de parité. Par contre le radi5 permet d'avoir des volumes plus grand. Pour faire un volume de 4To raid 1 : 2 disques de 4To - un disque entier sert à la redondance raid 5 : 3 disques de 2To - 1/3 de chaque disque sert à la redondance (le shr ou shr2 permet d'utiliser des disques de tailles différentes sans perdre trop de surface) Dans ton cas tu peux faire : raid 1 : 2* 2 disques de 4To => 8To dispo, deux volumes de 4To, chacun avec un disque pour la redondance raid 5 : 4 disques de 4To => 12To dispo, un volume unique de 12To et 1disque pour la redondance raid 6 : 4 disques de 4To => 8To dispo, un volume unique de 8To et 2 disques pour la redondance Si 8To te suffisent et que les perfs ne sont pas le principal critère, le raid6 est un excellent choix car hautement secouru. Ensuite il y a l'éternel débat raid mirroir VS raid parité : mirroir (raid1, raid 10) : en cas de crash il est possible de récupérer les données depuis un ordi parité (raid5, raid6, ...) : en cas de crash, c'est presque impossible Utilise le comparateur de raid (sur le site support synology) pour te faire une idée. Pour le boitier, il semble intéressant pour un usage domestique. Pour ta dernière phrase, il n'y a qu'une seule solution : faire des backups et les stocker ailleurs (chez des amis, la famille, à la banque si tu as un coffre, ...)

les cartes réseaux du Rasp n'ont pas de PXE, donc pour faire du PXE il faut d'abord booter le rasp sur un pre-os (un syslinux par exemple) qui se chargera de récupérer l'OS ailleurs (par exemple en tftp sur un syno). mais c'est inefficace (pas assez de ram sur un rasp pour faire ça efficacement) et lent (la carte réseau ne dépote pas assez) concernant ton problème de carte, je ne sais pas comment tu t'y prends pour les flinguer :s j'ai un rasp allumé H24 depuis plus d'un an, il me sert entre autre de miroir Debian (donc lecture/écriture importante) et aucun soucis. Pour l’anecdote il est alimenté par le port usb d'un syno j'en ai un autre qui me sert à faire joujou, donc il est installé/formatté/réinstallé assez souvent, là aussi aucun problème tu as peut être un pb d'alimentation, ou alors tu retire la carte sans éteindre le rasp si tu veux limiter les écriture sur la carte, il y a plusieurs méthode non exclusives -monter les dossiers dans lesquels il y a des écriture ailleurs que sur la carte : --par exemple dans un tmpfs en ram --en faire des liens vers /dev/null (attention, toutes les applis ne le supportent pas) --sur un media externe (clef usb, nas, ...) -désactiver/supprimer les composants qui écrivent comme les logs (syslog/rsyslog/...), les mta (postfix/...), ... -désactiver la swap ou la déplacer loin de la carte (c'est con et inutile mais on peut monter la swap en ramfs) -... Tu peux aussi limiter les lectures : -noyau statique et allégé -busybox -pas de cron -pas de services non indispensable -... En bref, tout ce qui est fait dans les linux embarqué (par exemple les box internet ou les routeurs grand public on juste un peu de rom pour stocker l'os et la conf, le reste est volatile)

Comme le dit Oooops!, c'est principalement pour faire de l’agrégation de liens (meilleur débit, tolérance aux pannes) mais il faut un switch compatible Oui, d'où l’intérêt des onduleurs et des backups Entre autre, mais pas seulement, ça permet aussi d'avoir une copie des données en cas de mauvaise manip ou pire (incendie, vol, ... si on ne laisse pas les 2 au même endroit) Les 7xx+ sont de bons modèles (j'en ai 3) à la condition de bien gérer son espace disque. Un 713+ sans disque c'est moins de 450€ 1 disque de 3To c'est environ 100€ 450+2*100 = 650 Donc il y a mieux ailleurs

Bonjour, C'est le "travailler sur le même fichier en même temps" qui risque de poser problèmes car la limitation vient des applications, pas des nas. Selon les applications et selon le type d'action, les comportements peuvent être très différents, certains applications posent des verrous, d'autres copie intégralement le fichier en mémoire, voir sur le disque, par exemple : -selon les réglages et les versions, les outils de la suite Office MS modifient les fichiers dès qu'ils sont ouverts, même sans faire "save", si on veut éditer un même fichier à plusieurs, on doit le mettre en mode "partagé", de plus à l'ouverture une copie du fichier est créée sur le nas, donc si le fichier est gros, l'ouverture peut prendre le double de temps -à l'inverse, les applications qui font du streaming de données (lecture d'une ISO, d'un fichier multimédia, d'une image disque, ...) ne posent aucun problème Pour la gamme, la plupart des modèles en "+" devraient convenir, après c'est fonction du budget et de l'environnement réseau. Si tu as un switch capable de faire de l’agrégation, prends un syno avec au moins 2 cartes réseaux. Bien sur si tes utilisateurs sont en wifi, ce n'est pas la peine, c'est le wifi qui sera la limitation (même avec un nas bas de gamme) L'un ou l'autre de ces modèles devrait convenir (le 1514+ et peut être le 1814+ devraient sortir bientôt) : DS1813+ : 8disques, 4*rj45 DS1513+ : 5disques, 4*rj45 DS713+ : 2disques, 2*rj45 Sans agrégation de liens, tu seras limité par le réseau à 1gbits, tous ces modèles peuvent faire plus (pour des gros fichiers) Tu peux regarder les perfs ici : http://www.synology.com/fr-fr/products/performance/#4_bay Ma recommandation personnelle va à 1 DS1513+ accompagné d'un autre modèle (peu importe le quel tant que c'est du raid avec un espace disque suffisant) servant uniquement à faire les backups du premier, l'idéal et d'avoir 2 modèles équivalents pour s'en servir en remplacement en cas de gros problèmes.

Les homes sont tous sous /homes (donc /volumeX/homes/login). Il faut donc monter /volumeX/homes sur /home. En complément il faut que tes utilisateurs locaux aient le même uid/gid que tes comptes syno (il faut adapter l'un ou l'autre) ou faire du remapping d'UID sur ton linux. perso j'ai laissé tombé le nfs syno au profit du cifs depuis DSM5, même si c'est nettement moins performant, c'est beaucoup moins pénible à maintenir. Mais maintenant que les syno gèrent le kerberos et le nfsv4, je vais peut être y revenir...

Le premier article date de 2009, il aurait été intéressant s'il n'avait pas fait abstraction d'un point crucial : tous les disques font des erreurs et le savent, il y a donc une partie du disque en réserve pour ré-allouer les secteurs défectueux automatiquement (pour info, c'est aussi valable sur un SSD). Le taux de panne est donc considérablement réduit (de même que les performances). Je suis aussi tombé sur l'article de clubic, même s'il n'est pas faux en soit, il est rempli de "si ceci, et si cela, dans le cas où, ...". Avec tant de suppositions, rien n'est fiable. Au jugé on doit avoir quelques milliers de DD en salle machine (certains ont plus de 10ans) et on doit en jeter/remplacer une grosse dizaine par an (parfois dès le premier démarrage). Ce n'est pas négligeable. Donc un disque unitaire n'est pas une chose super fiable. Par contre j'utilise différents raid au quotidien en usage professionnel (sur de l'emc, du netapp et du quantum), avec une volumétrie à plat (comprendre en surface brute) de plusieurs centaines de To. Je n'ai "presque" jamais vu un raid tomber en panne en 7ans. Des disques individuels oui, mais du moment qu'ils sont vite remplacés (hotspare + supervision), aucune casse. Donc un raid supervisé c'est fiable. Dans le monde professionnel, pour limiter les risques de pannes, on utilise plusieurs méthodes (disques haut de gamme, panachage de disques, hotspare, supervision proactive, contrôleurs redondés, ...). Tout ça à un cout, ce n'est donc pas pour M. ToutleMonde. Pour le grand public, il y a moins de possibilités et le matériel est souvent moins fiable (question de budget). Mais certaines bonne pratiques permettent d'éviter la plupart des problèmes : -il faut par exemple éviter d'utiliser des "contrôleurs" raid qui nécessitent d'installer un truc (s'il y a un truc à installer, c'est que le raid est géré par le soft, donc si le disque en panne contient le soft, il n'y a plus de soft pour recalculer la parité ...), comme ceux qu'on trouve dans beaucoup de carte mère de PC -à l'opposé, les raid 100% softs (même celui de windows) sont assez fiable car ils ne dépendent plus d'un contrôleur et peuvent donc être remontés sur un autre hardware, de plus ils gèrent bien mieux les secteurs défectueux que la plupart des contrôleurs matériel (y compris de gamme pro) -un disque dur doit être régulièrement testé (au moins smart, si possible test de surface). Un contrôleur raid de bonne qualité le fait de lui même, indépendamment de l'OS installé (même sans OS en pratique) -il ne faut JAMAIS mettre des données critiques sur un même raid que le système -mieux vaut plusieurs disques mono plateau de faible capacité qu'un gros disque multi-plateaux avec plein de To -l'achat d'un onduleur est souvent plus rentable que l'achat d'un gros disque A titre perso, le PC devant moi a 3 disques (1ssd système et 2 disques en raid 1 pour les données), de temps en temps (1 à 2 fois par an), j'enlève un des disques du raid et je le tests (après l'avoir remplacé par un 3ème de même taille). Si le disque passe par le test, il fera la rotation suivante, sinon j'en rachète un. Bien sur en faisant cette manip, je cours un risque (panne du disque restant le temps de la manip). C'est pour ça que mes données sont sauvegardées sur un syno et que ce dernier est sauvegardé sur un autre syno (pas au même endroit). Pour les données critiques, j'en ai une copie...ailleurs. Pour en revenir au raid, le raid1 offre à peu prêt le même niveau de protection que les raid5 et 6, l'avantage de ces derniers n'est donc pas leur fiabilité, mais le fait que l'on perde moins d'espace (n-1 ou n-2 contre 50% avec un raid1) et que les performance sont bien plus élevées. Entre le raid1 et les raid5 et 6 on trouve le raid 1+0 qui offre un bon compromis perf/redondance mais qui coute cher (4 disques mini, 50% de perte en surface). Ce qu'il faut retenir des 2 articles et du raid en général : -un disque dur c'est fragile : quand c'est allumé, on ne doit pas y toucher (utilisateurs de portables sur les genoux méfiez vous) -un disque dur c'est fiable : quand c'est utilisé avec soins, ça peut durer des années sans problèmes. Amusez vous à comparer le nombre d'heure avant une panne de disque dur avec le nombre d'heure avant de devoir changer de voiture, c'est édifiant (un indice, une voiture c'est beaucoup moins fiable) -le raid n'est pas une solution de sauvegarde -une sauvegarde au même emplacement physique que l'original n'est pas une sauvegarde -une sauvegarde non testée régulièrement n'est pas une sauvegarde -avant de créer une grappe raid, il faut s'assurer des capacités/limitations des disques mais aussi et surtout du contrôleur

Si tu veux supprimer toute trace de CloudStation : Via l'interface WEB, désinstalle l'appli CloudStation. Normalement ça supprime aussi les fichiers de synchro (ça peut prendre du temps). tu peux ensuite vérifier, en ssh, c'est dans /volumeX/@cloustation (ou un nom du genre) que CS stoke ses fichiers, si ce dossier existe encore après avec désinstaller l'appli, il suffit de le supprimer. Si tu veux limiter la place occupée par CS, je te renvoi à mon post juste au dessus CloudStation Il fonctionne très bien pour des petits volumes de données (on va dire moins de 10Go), c'est une autre histoire pour des gros volumes. Sinon il y a OwnCloud (prend le sur le site officiel, le paquet de la communauté syno semble avoir des pb) qui marche aussi très bien L'appli est légalement gratuite sur android, mais seulement via F-Droid, pas sur le store Google.

je fais le test et je repost ici dans quelques minutes ... c'est installé où est le problème ? 1-j'ai activé web station et les extentions php nécessaires 2-j'ai dézippé owncloud dans le dossier web 3-via l'interface du syno, j'ai donné les droits d'écriture à http sur le partage web 4-http://monnas/owncloud 5-login+password en utilisant une base sqlite 6-ça fonctionne (en web et avec le client lourd owncloud)

le ldap et le kerberos sont OK d'après le log c'est winbind (ou au moins le call RPC) qui ne marche pas. Il y a plusieurs façon de créer un objet dans un ad, il est possible que la méthode employée par syno ne soit pas autorisée chez toi. Quelques pistes : -essaye de créer l'objet (le syno) par avance -vérifie au niveau par feu (surtout les ports 135 à 139 et 445) -essaye avec un autre nom de machine (le nom est peut être déjà pris) -essaye avec un autre compte (par défaut, un compte non admin ne peut créer que 10 machines) J'ai déjà enregistré plusieurs syno dans des ad (pas testé au travers d'un rodc par contre), normalement ça marche très bien.

Par défaut CloudStation fait du versionning très agressif (10 ou 32 versions par défaut, j'ai un doute). Donc si tu mets 100Go dans le cloudstation, en quelques heures (en fonctions des actions), tu peux vite avoir 1To de pris Pour régler le problème, essaye de limiter le nombre de version à 1 (c'est le minimum) et/ou de ne pas mettre trop de données dans le CloudStation. Je l'utilise depuis sa sortie avec environ 2Go de documents (des documents de travail, pas de film ou truc du genre) et ça marche très bien en usage "raisonnnable". Il consomme tout de même 3Go en plus des 2Go de données malgré un versionning à 1, donc ça deborde On va dire que ce n'est pas (encore esperons) fait pour gérer des gros volumes.

je plussois

Normalement ce dossier ne se rempli que si tu utilise DownloadStation Commence par vérifier qu'il n'y a rien qui traine dans l'appli via l'interface Pour supprimer le contenu à la main, il faut : 1-activer le ssh (paramètres->terminal) 2-se connecter en ssh au syno (sous windows tu peux utiliser putty, pour les autres OS c'est en stanrd depuis un terminal) : login "root" et le password du compte admin 3-il faut aller dans le dossier (X à remplacer par le n° de volume, probablement 1 chez toi) : cd /volumeX/@download/ 4-lister le contenu : find . 5-Voir ce qui prends de la place : du -sh * 6-S'il n'y a rien d'important et que tu es certain d'être dans le bon dossier : rm -rf truc_a_supprimer 7-Si tu es vraiment certain de toi (la commande suivante supprime TOUT ce qu'il y a dans le dossier où tu es) : rm -rf *

le webdav du syno n'a aucun rapport avec celui d'owncloud (qui gère son propre webdav avec Sabre). Si tu as ce message c'est problablement lié à la configuration du serveur web. Je n'ai pas testé sur un syno par contre A noter que parfois on a cette erreur quand OC n'arrive pas à communiquer avec lui-même (pb de firewall en général), mais ce n'est pas nécessairement bloquant pour son fonctionnement.

c'est pas un appart ça, c'est une fnac Si je comprends bien on a : Internet | modem/routeur--TV1 et TV2 | routeur2--le syno et le switch1 (avec plein de trucs) | switch2--plein de trucs Si c'est bien ça, passe 2 liens entre les 2 switchs (de manière générale, dès qu'il est compliqué de passer un cable, ou qu'il y a d la longueur, il faut en passer au moins 2, tant qu'on peut encore), même si tu ne t'en sers pas tout de suite Pour le reste, je brancherais les syno sur le switch1, pas sur le routeur (sauf gap de gamme, un switch est nettement plus rapide qu'un routeur en commutation). Je te propose ceci (en mettant le routeur2 et le switch1 au même endroit) : Internet | modem/routeur--TV1 et TV2 | routeur2 | switch1--plein de trucs (dont le syno) || switch2--plein de trucs

Tes débits sont "normaux" pour ce modèle en cifs (partage windows), mais même mon vieux 107+ allait plus vite Avec mon 710+ j'arrive juste à saturer un lien 1gbits et même avec le 712+ je ne sature pas mon ssd. tu peux aller un peu plus vite avec du nfs ou du ftp (+10% au doigt mouillé), mais tu ne satureras pas ton ssd de même sans raid, tu pourras peut être gagner quelques mo/s, mais au prix d'une absence totale de sécurité Pour ce qui est du jumbo frame, il faut que tous les élements de la chaine le supportent (pc+switch+nas), sinon au mieux tu aurras de la fragmentation (donc débits catastrophiques), au pire rien du tout (ce qui t'es arrivé). Sous linux : ifconfig eth0 mtu 9000 Sous Windows c'est faisable avec netsh, sinon dans les propriétés de la carte réseau Pour les switchs, ça dépend des contructeurs (un switch grande surface ne sera suremment pas compatible)

Comme évoqué plus haut, tu peux relier tes switchs entre eux avec des agregats de liens ou répartir des liens sur différents switchs d'un même groupe, mais pour un usage domestique, ça commence à faire lourd. De plus, ton syno ne sera pas capable d'alimenter 4x1Gbits, de mémoire, le controleur peut sortir 2 ou 300MBs max en accès simple, avec des accès conccurentiels (accès à plusieurs en même temps, à des fichiers différents), il sera vite au max de ses capacités. Pour les câbles, ça dépend de l'environnement et des distances. En usage domestique, j'ai tendance à ne jamais prendre moins que du FTP et quand je dois tirer des câbles qui sont là pour rester, je prends du sstp si j'ai le budjet (sinon ftp). Mais dans tous les cas en 6a (le 7 n'est pas fait pour le rj45 et les prises murale GG45<->RJ45 sont trop cher, trop grosses et trop pénibles à brancher).

On s'est fait botté le c*l par les gallois Non, même si ça implique d'avoir un minimum confiance en l'hébergeur. OVH, tout comme Iliad et quelques autres, présentent mêmes quelques avantages par rapport à amazon(aws/ec2)/google (apps/compute engine)/ms (azure), ... : ils sont français et leurs datacenter sont (pour les principaux) en france =>soumis aux lois françaises (même si avec la LPM ont est mal barré, c'est toujours moins pire que dans certains pays) =>moins de problèmes de latence et de peering car physiquement plus proche qu'un datacenter en Irlande ou dans le Delaware Le fait que ton disque soit chiffré est toujours un plus (par contre ça va être plus compliqué de le redemarrer à distance ) mais attention à mettre un frein au mode parano. Si tu en es là, n'oubli pas les antirootkit, grsec, selinux, ... en gros, tu vas probablement passer plus de temps à sécuriser ta passerelle que tu ne vas l'utiliser. Je ne dis pas que c'est mal, je le fais de temps en temps pour garder la main, mais il faut savoir rester raisonnable. A titre perso (et pro aussi), quand j'ai besoin de confidentialité (qui est un aspect de la sécurité), j'héberge moi même, dans un placard (ou un datacenter), dont je suis le seul (avec mes collègues pour le mode pro) à avoir les clefs. Pour le reste je me contente la plupart du temps de sécuriser les com et les accès logiques, pour l'accès physique, je fais confiance, sinon on ne s'en sort plus. Pour ça que "simple" était entre guillemets, mais ça reste moins compliqué à mettre en place coté serveur. Pour les clients lambda, j'ai 2 réponses faciles : 1-accéder à des données sensibles depuis un poste qu'on ne maitrise pas est un hérésie (keylogger, vers, ...) 2-la plupart des systèmes intergent plusieurs clients vpn en standard (à commencer par ipsec) et il existe de nombreux vpn "click & connect" (qui s'installent à chaud, voir de manière volatile) Mais je suis d'accord, un reverse proxy est plus confortable si on ne souhaite accéder qu'à des services compatibles (donc pas de cifs/nfs par exemple). Après, comme dit avant, il faut trouver un équilibre entre le confort, la sécurité et la paranoïa.

tu complique pour rien oubli le reverse proxy Etape 1 a-installe une passerelle bien sécurisée b-ajoute lui un serveur openvpn c-créé un compte pour ton client (login+pass+certificat) d-configure ton client pour passer par ce vpn pour aller vers le syno (voir vers le reste du monde pendant que tu y es, si le débit est suffisant) Etape 2 : même chose coté syno a-sécurité b-serveur openvpn c-compte pour la passerelle d-client sur la passerelle Etape 3 le reste c'est juste du routage (sur la passerelle) pour que ce qui arrive via le vpn1 soit routé dans le vpn2 ou alors tu remplace l'étape2 par la 1 en remplaçant client par syno (pas certain que ça soit possible sur le syno par contre) ps : je fais trop de fautes, il est l'heure d'aller au dodo bonne nuit

pas nécessairement, trop tard pour détailler, mais il y a plein de façon de faire oui et non le vpn est effectivement là pour sécuriser le canal de com, mais il permet aussi de faire l'identification fiable du client c'est comme l'https et le login/password du site de ta banque sans l'un ou l'autre, c'est tout de suite moins sécurisé -pas de login/password (pas d'identification) et tout le monde peut accéder à ton compte -pas de https (canal sécurisé) et toutes les grandes oreilles peuvent connaitre ton login/password le vpn c'est juste un moyen "simple" de faire le 2 d'un coup

pour la connexion local, normalement le problème ne se pose pas quand le client se connecte, s'il peut directement contacter le syno il ne passe pas par le net, mais par le lan maintenant pour la méthode de détection, je ne sais pas exactement, mais comme il se connecte à la passerelle puis au syno juste après, je suppose que synology voit que le client et le nas ont la même ip publique et donne donc l'instruction au client de se connecter directement edit : pour faire la même chose à la main, il suffit de ne pas lancer le vpn quand on est dans le lan, ou de bien régler le vpn pour ne l'utiliser que quand on veut aller sur l'ip de la passerelle.