Fenrir

Pour le message, c'est simplement qu'OpenVPN permet d'utiliser une authentification par certificat en plus (ou à la place) d'un login/password. Synology ne laisse pas cette possibilité => ce warning peut être ignoré. Pour l'IPsec, si le transfert de ports est correctement fait (500 et 4500 en UDP) mais qu'aucun trafic ne parvient au nas, il n'y a pas 36 causes : le client est mal configuré le client bloque le trafic l'adresse n'est pas bonne l'opérateur source (ou un FW en entreprise) bloque le trafic l'opérateur cible (ou un FW en entreprise) bloque le trafic la box cible bloque le trafic Je sais que certaines livebox ont ce comportement détestable, peut être que les freebox aussi, mais je ne peux pas tester.

Et il faut bien utiliser l'adresse "vpn" du nas, celle en 10.xxxxx

Les ip en questions sont les seules qu'on peut retrouver dans un réseau privé (sauf conf très très exotique ou ipv6). Pour tester depuis ton bureau, note "l'ip du jour" et mets la dans le fichier de conf openvpn.

Pour les tables de routage, j'ai mis quelques exemple pour windows/linux, qu'est ce que tu ne comprends pas ?

@Djibe avec une ip dynamique, tu es soumis aux aléas des caches DNS, prendre un nom de domaine ne changera pas la chose => le pb vient probablement de ta gestion DNS au bureau

Exact Ton trafic va du téléphone, vers ta box, puis ton nas, puis ta box, puis internet avant de revenir via ta box, ton nas, ta box => c'est plus lent qu'en direct mais si tu as la fibre, ça devrait être meilleur que ça, vu la suite de ton post, il est possible qu'orange ou free brident le débit en itinérance => c'est ton opérateur qui pose problème, pas le matériel ni le logiciel Si tu regardes bien le TUTO, j'indique plusieurs manières de ne faire passer dans le VPN que le trafic vers le nas, ça limitera un peu ta gène.

Dans le cas d'un tunnel, les mécanismes d'intégrité sont ceux du protocole "interne" (les tunnels ont certains mécanismes eux aussi, mais trop long à détailler) => si tu surf via un VPN, tu fais du tcp dans de l'udp, donc tu as bien les SYNC/ACK/... et en cas de perte de paquet (de ton appli ou du tunnel), tu disposes des mécanismes de TCP pour corriger. Mais tu as le droit de faire un tunnel en TCP (openvpn le permet), c'est juste moins efficace (entête plus gros donc tunnel plus petit et plus de choses à gérer donc moins performant). edit : TCP c'est lourd et ça coute cher mais c'est fiable UDP c'est léger et ça ne coute presque rien T(trivial) FTP

Je pourrais me re-citer ... relis attentivement ce que j'ai écrit dans le tuto, mes phrases ont généralement nettement plus d'importance que les quelques captures que j'ajoute pour faire jolie.

Je n'en vois pas l'intérêt de la demande puisque le nas est en interne.

C'est indiqué dans le tuto :

ip dynamique => pas de serveur DNS et un dyn host n'est pas une ip fixe

Si c'est le routeur qui fait serveur ipsec/l2tp, il faut effectivement ajuster les règles. Mon tuto est valable pour un serveur VPN derrière un NAT (routeur/box/...)

Sur le routeur : ok TCP uniquement, pas besoin d'UDP ok, mais tu en as besoin depuis tous les pays ? ok, mais tu en as besoin depuis tous les pays ? inutile comme indiqué par @PiwiLAbruti, mais pas gênant (au moins c'est explicite) Sur le nas : ok inutile, déjà couvert par la règle 1 aucune idée car tu utilises les applications, mieux vaut utiliser explicitement le n° de port (443 si tu es cohérent) ok, mais tu en as besoin depuis tous les pays ? ok

Depuis l'explorateur windows, clique droit, prop, sécu ...

Le fichier hosts c'est une version locale d'un serveur DNS (en nettement moins puissant) => serveur DNS en remplacement Pour ton problème initial, il peut y avoir plusieurs causes, la première est un wordpress mal installé ou mal configuré. J'ai déjà expliqué en détail la manière de s'y prendre il n'y a pas très longtemps, tu devrais pouvoir retrouver le post. En version courte, je pense que ton WP n'est pas configuré pour le nom que tu utilises mais uniquement l'ip

ça doit rester vide sauf besoin très spécifique, je pense qu'en modifiant cette option tu as simplement forcé le syno à ré-appliquer le reste de la conf

Commence par ne pas rendre DSM accessible directement depuis Internet, surtout sur les ports 80 et 443. Réserve ces ports pour les applications publiques (photostation et webstation). Il faut donc rediriger le port 80 sur le port 80 et le 443 sur le 443.

Tiens ça a changé, je corrige le tuto.

effectivement, mais le lien de l'autre est dans celui que j'ai posté en double : https://lafibre.info/remplacer-freebox/utiliser-un-serveur-linux-a-la-place-de-la-freebox-pour-debrider-la-connexion/?PHPSESSID=bci8m7d9at6v8h1olo1b0tti52

perso je ne ferais pas ça avec le fichier hosts, sauf si le pc est fixe (et encore)

Test tu verras bien, comme tu n'as pas de données sur les disques tu ne risques rien et c'est en essayant et en se trompant qu'on apprend.

Pourquoi mettre les 2 règles du VPN dans "plages de ports" alors qu'il s'agit de 2 ports uniques ? Et tes ports 5000 et 5001 ne devraient pas être exposés depuis Internet, c'est la porte ouverte aux ennuis.

Si les 2 nas sont reliés en VPN (l'un fait serveur, de préférence un qui a une box avec ip fixe), c'est comme s'ils étaient en LAN

Personnellement pour des échanges distants de ce type, je passerais par un tunnel VPN entre les 2 nas.

C'est peut être possible (pas testé avec un Synology) mais surement assez complexe à faire et à maintenir en entreprise. La fonction que tu cherches se nomme ABE (access based enumeration), en général on l'utilise avec un serveur DFS. Essaye ça avec FileStation : coche "Désactiver la navigation dans le répertoire" pour le partage place les permissions de manière explicite sur chacun des sous-dossiers Ensuite il faut jouer avec les permissions NTFS sur chacun des dossiers, ça marchera peut être.