.Shad.

Sans problème. Ca fait l'inverse. Authelia te permet de différencier l'accès à une ressource en fonction du chemin après le domaine. Chez moi, j'accède à phpMyAdmin par ds918-services.ndd.ovh/phpMyAdmin, et Authelia sait qu'il doit me demander une authentification 2FA pour l'autoriser, même en local (parce que je l'ai configuré ainsi), tandis que ds918-services.ndd.ovh/photo est accessible depuis n'importe quelle source, locale ou distante. Sans rentrer dans les détails, si je faisais un rewrite de l'URL il serait plus difficile de différencier le comportement d'un service par rapport à l'autre. Ca je crois que tu devras essayer, c'est trop vague. SWAG est un proxy inversé comme un autre, pourquoi ça ne marcherait pas ? 😉 SWAG ne vient en rien corriger des problèmes avec le proxy inversé de DSM, qui est très bien comme ça et pour 99% des utilisateurs, mais limité si on veut pousser un peu plus loin. SWAG est une solution complète autonome qui intègre la prise en charge de la 2FA à la demande pour les applications qu'on héberge, le fail2ban, et le redirection HTTP -> HTTPS via Nginx au lieu d'Apache (mais ça tu le sais déjà).

Je crois que les développeurs cobol s'arrachent à prix d'or dans pas mal d'entreprises. 😛 Bienvenue parmi nous !

Si tu accèdes à l'interface Drive, pas de problème évidemment tu passes par le proxy inversé de SWAG. Pour la synchronisation des données via le client PC par exemple, il faudra utiliser un nom de domaine dont le certificat est dans DSM. Je vois pas comment être plus clair, je ne sais plus comment le tourner. 😛 Le "Synology Drive Server" que tu vois dans mon impression d'écran correspond au service de synchronisation de données, pas l'interface de Drive. Les quatres sont "reverse proxiables", donc ça ne pose aucun problème... J'ai cherché cinq minutes sur Google : https://www.digitalocean.com/community/questions/nginx-seamless-redirect-subdomain-subfolder Après si tu comptes utiliser Authelia, ta redirection t'embêtera plus qu'autre chose, mais tu fais comme tu veux.

Bah euhhh... d'où l'utilisation du ndd Synology pour être tranquille. Au passage tu confonds synchronisation des données de Drive et interface de Drive. C'est comme confondre le port par lequel Download Station ferait du partage BitTorrent et l'interface de Download Station. Plex et DSM sont reverse proxiables donc pris en charge par SWAG. Voir l'impression d'écran de mon certificat Synology pour les services intrinsèques à DSM pour lequel il faut un certificat dans DSM directement. Sûrement, faudra que tu cherches un peu, je laisse le /photos derrière personnellement car je m'en sers dans Authelia pour différencier l'accès à phpMyAdmin et Photo Station, tous les deux sur les ports 80/443 du NAS.

Oui Oui, après faut pas croire que ça apporte de la sécurité, personne ne t'attaquerait avec un nom de domaine. C'est l'IP qui intéresse les bots. Avec un certificat wildcard, tu valides ndd.tld et *.ndd.tld, donc si tu ajoutes un nouveau service pour lequel tu veux un accès par nom de domaine publique, tu n'as pas à recréer de certificats, il est déjà pris en charge par *.ndd.tld C'est un choix personnel, SWAG te permet d'obtenir un certificat que tu peux très bien exporter dans ton NAS et importer via l'interface DSM. Ce n'est pas comme acme.sh qui permet de faire le déploiement. Vu que certains services sont liés à DSM et ne peuvent pas passer par le proxy inversé (Synchro données port 6690 pour Drive, même chose pour Hyper Backup et Active Backup for Business), si je veux utiliser le même certificat que celui utilisé dans SWAG, je dois importer dans DSM ce certificat et configurer les services sus mentionnés pour qu'ils l'utilisent. C'est fastidieux. Du coup, j'utilise l'interface DSM pour générer un certificat wildcard pour mon domaine gratuit Synology (DSM ne le permet que pour ses noms de domaine, d'où les tutos acme.sh pour les autres ndd), et je m'assure que les services Synology non déportables utilisent ce certificat : Tu peux aussi utiliser acme.sh pour utiliser un certificat pour le même domaine et le déployer automatiquement dans DSM. C'est juste que ce seront deux certificats distincts, ça ne gêne en rien. 😉 Quand tu crées un certificat wildcard Synology, donc identifiant.synology.me et *.identifiant.synology.me, la validation passe par la zone DNS de ton domaine hébergée par Synology, tu n'as besoin d'ouvrir aucun port, tu es juste le demandeur, tu n'es pas dans la boucle de vérification. Quand tu valides les domaines manuellement (ta méthode actuellement), LE vient vérifier un fichier à la racine de ton serveur web pour vérifier l'authenticité de la demande, il le fait par le port 80. Si par exemple tu as juste une adresse associée à un domaine, pour un site web par exemple (donc généralement ndd.tld et www.ndd.tld), je ne vois pas spécialement l'intérêt d'avoir une validation par DNS. Le wildcard est intéressant si tu as plusieurs sous-domaines. Pour que la validation DNS soit possible, il faut que l'hébergeur de ta zone DNS mette une API à disposition d'acme.sh (ou certbot par exemple dans le cas de SWAG), tous les hébergeurs ne le font pas, dans ce cas-là il faut soit ajouter les enregistrements acme-challenge manuellement, soit passer par une validation HTTP. Tu peux l'enlever, je mettrai à jour le tutoriel. Note que ça n'empêchera pas le bon fonctionnement, ce sera justement sûrement plus pris en compte lors de la création du conteneur. Tu ne t'en serviras plus, c'est Nginx dans SWAG qui gèrera ça (par défaut c'est activé, il y a moyen de le désactiver, mais pas vraiment de bonne raison de le faire). Merci de te lancer en tout cas, ça va permettre de voir où les explications sont insuffisantes (je note le manque de numérotation des paragraphes 😛).

@MilesTEG1 Moi je l'ai laissé, mais tu peux sûrement réduire, c'est histoire d'être sûr que l'interface physique est opérationnelle. Tu n'as qu'à faire l'essai sans la temporisation voir si ça pose problème ou non.

Pas de souci, voir ce post pour le lien avec ton erreur je pense : https://github.com/larsks/blog.oddbit.com/issues/3#issuecomment-612187561

@MilesTEG1 Pour ton problème concernant l'erreur RTLINK, essaie justement comme tu le proposes avec 192.168.2.208/28, ça te donnera une range de 209 à ... Chez moi, j'utilise la plage 192.168.100.160, ça commence aussi à 161 jusqu'à ... Et du coup tu mettras 209 pour SWAG par exemple, pour ne pas laisser d'IP non utilisée en début de pool du sous-réseau macvlan.

Si tu as autorisé qu'une seule IP dans ton sous-réseau macvlan, c'est normal que tu ne puisses pas y ajouter un nouveau conteneur. Tu peux essayer de supprimer ton réseau macvlan, et retenter de créer avec un /30 au lieu de /28 pour l'ip-range, voir si ça change quelque chose. Une interface physique ne peut avoir qu'un seul réseau macvlan qui lui est rattaché. Ou alors tu utilises un autre port RJ45 de ton NAS. Tu n'as pas une interface virtuelle par conteneur, tous les conteneurs macvlan utilisent la même IP virtuelle pour communiquer avec le NAS. Pour ça je te conseille de chercher sur Google, c'est pas spécialement ce qu'il y a de plus fun. C'est du calcul, et les calculateurs sont là pour ça. Fais-leur confiance. Pour le broadcasting, pas sûr que ça t'aide, c'est l'adresse de diffusion réservée sur un sous-réseau. Dans ton réseau local, c'est 192.168.2.255 https://en.wikipedia.org/wiki/Broadcast_address

Connection refused, c'est généralement lorsqu'un port n'est pas accessible ou fermé. Je plaide pour une redirection de port 443 sur ta box ou ton routeur qui a sauté (sans redirection, la demande atterrit sur le premier périphérique, donc ta box, dont le port 443 est a priori inutilisé ou inaccessible).

Non, quand tu modifies un enregistrement ça écrit sur le serveur. Par contre tu as un cache local en lecture seul, que tu aies accès à la dernière version de ton coffre même si pas de connectivité. Oui Les bot n'utilisent pas les noms de domaine mais la liste des IP disponibles pour chaque pays pour faire du brute-forcing. Si ton serveur VPN a une faille (et avec une implémentation OpenVPN sur Synology qui date de 4 ans, ça n'a rien d'impossible), c'est tout ton NAS mais aussi ton réseau local qui est menacé. Il ne faut pas être parano, si tu actives par exemple la double authentification sur Bitwarden, en terme de sécurité le risque est proche du néant. Tu peux également limiter géographiquement l'accès au proxy inversé par pays. Et en HTTPS les données sont transmises chiffrées.

Tout dépend l'utilisation qu'on prévoit d'en avoir, je précise aussi que PiVPN propose les mêmes fonctionnalités de ce qu'on peut lire sur leur site (et j'en avais déjà entendu parler). et dans ce cas-là c'est totalement dissocié du NAS.

@declencher Si tu comptes l'utiliser sur un smartphone (gros plus) en 4G, ton coffre sera en lecture seule, pas gênant pour toi ? Ou alors ton VPN devra être activé pour ajouter des mots de passe ou les modifier. Et d'après la doc Bitwarden : Essaie du coup d'utiliser le port 444 en HTTPS par exemple (refaire l'installation), tu n'auras peut-être plus les erreurs. Même si je pense qu'il serait plus facile que tu mettes un proxy inversé en place, et ça fonctionnera sans la moindre anicroche. @MimiraK Tu utilises quelle image pour avoir à configurer un conteneur manuellement (cf impression d'écran avec les ports) ? Pour la version officielle, c'est un script qui gère tout ça.

Il y a des solutions plus simples à mettre en place via Docker. Moi à ta place je regarderais Wireguard (dispo aussi via PiVPN), globalement plus simple à mettre en place, et tu trouveras plus d'informations pour faire un VPN site-à-site. Et en terme de performances, bien meilleur qu'OpenVPN. 😉

Je pense que dans ce cas-là il faudra revoir tes exigences. Tu peux t'orienter vers une solution PiVPN site-to-site : https://www.pivpn.io/ et https://www.raspberrypi.org/forums/viewtopic.php?t=295452 Il faut jouer avec les routes mais ça me semble faisable, et ça te dispense d'utiliser le client vpn du NAS.

Perso j'utilise BorgBackup qui gère tous les aspects d'une sauvegarde, chiffrage, versionning, incrémentabilité... Pour sauvegarder mon VPS et mes Rpi sur mon NAS.

Tout dépend de l'utilisation que tu fais du NAS quand il est connecté en VPN. Parce qu'avec Docker ce serait très facile de se connecter sur ton raspberry.

@dbouchy Je ne dis pas que c'est forcément la différence de version qui fait que cela ne fonctionne pas, mais que c'est une possibilité. As-tu besoin que le serveur soit sur le Rpi et pas sur le NAS ? Si c'est interchangeable ça pourrait te faciliter la vie.

On parlait de synchro pour laquelle le port 6690 est hardcodé dans DSM et le proxy inversé ne fonctionne pas. @MimiraK Tu as fait un nslookup via la 4G sur DS Video, qu'obtiens-tu pour les autres sous-domaines de ton proxy inversé, toujours la même chose ?

Voir message de @MilesTEG1 un peu plus haut : Et pour : Je t'ai répondu entre temps. 😉

Quid des autres applications ? elles devraient fonctionner normalement. As-tu bien désactivé "Rediriger automatiquement les connexions HTTP vers HTTPS pour le bureau DSM" dans Panneau de configuration -> Réseau -> Paramètres de DSM ? Pour Drive c'est normal que ça marche pas, l'application Drive sur le port 10002 n'est qu'une application de gestion de Drive pour un utilisateur. Les données transitent par le port 6690/tcp, et ne peuvent pas passer par un proxy inversé. Si tu veux que tes collègues synchronisent leurs fichiers sur le NAS depuis l'extérieur, il faut faire une redirection de ce port dans ta box vers ton NAS, et l'autoriser dans le pare-feu du NAS. Dans le client, ils doivent indiquer un domaine pointant sur ton IP publique, par exemple ndd.com. Tu as bien coché HTTPS dans l'appli à l'écran de connexion ? Tu peux te connecter avec un PC portable sur la 4G de ton smartphone en mode point d'accès mobile, et depuis une invite de commande Windows, tu tapes : nslookup exemples.ndd.com exemples étant évidemment un domaine correspondant à un de tes proxy. Normalement ça doit renvoyer ton IP publique.

Il nous faut toute une série d'impressions d'écran, parce que là on y va à tâtons : - tes redirections au niveau de la box - tes règles de pare-feu - les ports utilisés pour les applications Synology (Portail des applications) - les entrées de proxy inversé (Portail des applications -> Proxy inversé) et leur contenu

Ben si tu comptes t'en servir oui, sinon tu peux l'effacer, c'est toi qui vois.

Les IP qui étaient là par défaut correspondent généralement à l'hébergement gratuit de quelques Mo que propose un fournisseur de nom de domaine lors de l'achat. Bien suivre les conseils de @Mic13710 et dis-nous ce qu'il en est une fois les enregistrements corrigés.

C'est là que ça a l'air de planter, mais ce n'est pas beaucoup plus limpide. Tu génères un fichier ovpn depuis ton raspberry ? Tu utilises OpenVPN AS (Access Server) ? Attention que la version d'OpenVPN des NAS Syno date de ... 4 ans bientôt (juin 2017, oui c'est une honte, surtout pour un service qui concerne la sécurité). Il y a des grandes chances que le fichier ovpn que tu utilises comporte des options incompatibles ou dépréciées. Vérifie que ton serveur peut accepter des connexions depuis un client en version 2.3.17