.Shad.

Non justement, tu ne remplaces rien, tu en crées d'autres (genre dsm-test en plus de dsm, etc...) qui pointent vers l'IP de SWAG, comme ça tu peux faire tous les tests dont tu as besoin sans toucher à ton installation actuelle. Ca ne marchera que localement tant que tu ne changes par la redirection dans le routeur, mais j'imagine que c'est préférable ainsi pour la phase de test. C'est normal, c'est pas gênant. Chez moi SWAG est en bridge sur ma Debian, Jeedom en macvlan, et bien j'ai ajouté un enregistrement pour l'IP du conteneur Jeedom dans ma zone DNS (ou Adguard dans ton cas) : ip-jeedom.xxx.ovh 192.168.100.164 Et dans le conf de Jeedom pour SWAG (il n'existe pas, j'ai copié celui de Heimdall que j'ai modifié) : server { listen 443 ssl; listen [::]:443 ssl; server_name jeedom.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app ip-jeedom.xxx.ovh; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; Pour ce qui est en bridge sur le NAS, tu dois utiliser l'IP virtuelle du NAS oui. Pour ce qui est en host aussi. Et pour tout ce qui est hébergé ailleurs que sur le NAS (VM de VMM ou autres périphériques), et bien tu utilises leur enregistrement A que tu as mis dans Adguard. C'est le point 9-A-1 du tutoriel. C'est un test à faire, je pense que non (je n'ai jamais testé). Ce qui ne passe par le proxy inversé, par exemple localement je pourrais atteindre mon NAS sur le port 5000, ça ne passe pas par SWAG, mais le NAS a f2b (Oui le blocage auto c'est juste une interface graphique pour fail2ban dans DSM). Et si j'ai des applications accessibles localement en HTTP sans authentification, c'est qu'elles sont tout sauf critiques. Du coup tu as parlé de Crowdsec je suis en train de le mettre en place, ça a l'air vraiment sympa et plus convivial que f2b. 🙂

@MilesTEG1 Pour les erreurs avec les logs, on dirait qu'il ne trouve pas les fichiers. Tu as regardé s'ils existaient bien ? Tu peux très bien ne rien toucher à ta config, il te suffit d'ajouter des entrées redondantes dans Adguard pour la résolution locale pointant sur SWAG au lieu du NAS et faire tous les tests dont tu as besoin. 😉 Normalement le fichier par défaut est adapté pour Vaultwarden et pas Bitwarden, sur Bitwarden tu n'as pas besoin de bloc location pour les notifications live, tout passe par un 2ème proxy inversé interne au conteneur. Si je me rappelle bien celui de SWAG prévoit un bloc pour les notifications. Ben le mieux est de la laisser, de la désactiver au besoin et de voir si SWAG prend le relais sur tous les points. La seule différence notable c'est que vu qu'ils mettent f2b en host sur l'image dédiée, ça dépasse les limites du proxy inversé, comme un f2b habituellement. Dans SWAG, fail2ban ne s'applique qu'au proxy inversé. Car oui il peut potentiellement lire n'importe quel log, suffit de le monter, mais il ne pourra que jouer avec les iptables du conteneur, s'il est en bridge ou macvlan. Alors dans mon cas je n'ai pas un seul service d'authentification qui ne passe par le proxy inversé, donc c'est égal, mais à voir dans ton cas. Et pour les services du NAS que j'expose localement en http, il y a le fail2ban du NAS qui prend le relais. Regarde quand même pour les grep, c'est bizarre. Si les fichiers n'existent pas tu peux les wget depuis le dépôt GitHub de SWAG.

@MilesTEG1 @bliz Ce serait plus opportun de créer un sujet dédié je pense. 🙂

@bliz Ca j'aurai du mal à t'aider 😞

Adguard fait juste office de serveur DNS local et de bloqueur de publicités. Depuis l'extérieur ce n'est pas sensé intervenir. Quand tu es à l'extérieur de chez toi, ta zone DNS c'est celle hébergée chez OVH. Tes enregistrements ramènent vers ton IP publique. Ton port 443 est redirigé depuis ton modem/routeur vers ton proxy inversé, et les autres ports éventuels pour les autres applications ne passant par le proxy. Rien d'autre.

Comme l'a précisé @Drayabob, tout dépend comment tu sauvegardes tes données. Si c'est par le client Drive pour Windows, la seule raison de la non-synchronisation pourrait être soit une connectivité défaillante avec ton NAS, soit une exclusion. Si tu sauvegardes par un autre moyen, il faut voir.

Quand on met un conteneur en mode host, c'est comme si c'était une application native, comme dsfile etc... Les réglages du pare-feu sont effectifs.

Pour le réseau bridge ou host : network_mode: bridge network_mode: host Par exemple dans un fichier compose : version: "2.1" services: exemple: image: coucou/exemple container_name: exemple-container network_mode: host environment: - ... Pour un réseau bridge personnalisé, s'il est lié au fichier compose (interne, pas externe) : version: "2.1" services: exemple: image: coucou/exemple container_name: exemple-container networks: - net-exemple environment: - ... networks: net-exemple: Et s'il est externe : version: "2.1" services: exemple: image: coucou/exemple container_name: exemple-container networks: - net-exemple environment: - ... networks: net-exemple: external: true

@CyberFr Dans son impression d'écran, ce que @MilesTEG1 te montre c'est la fonction de réécriture DNS d'Adguard, qui peut remplacer (pour cet aspect-là) le serveur DNS de DSM. Car quand tu passes par Adguard (et a priori depuis chez toi ou en passant par un VPN), tu lui dis que dsm est accessible localement (adresse IP privée), et par l'extérieur tu passes par la résolution publique, donc IP publique etc...). C'est l'équivalent d'un enregistrement A dans une zone DNS classique. Et tu peux aussi faire l'équivalent de CNAME.

Si, il y a moyen, mais pourquoi faire ? SWAG gère le ou les certificats de façon autonome et transparente (il utilise certbot, alternative à acme). La différence principale c'est que certbot ne permet pas de déployer le certificat dans DSM, ce dont on se fiche si c'est SWAG le proxy inversé. Et oui, tu peux créer autant de tokens que tu veux, j'en ai 4 perso.

@CyberFr J'ai regardé l'interface Docker DSM, ça faisait plus d'un que je n'avais pas regardé, il y a quelques belles améliorations pour la création de conteneurs, leur assistant est bien foutu. Néanmoins, tu ne pourras pas attribuer une IP à un conteneur dans un réseau macvlan par l'intermédiaire de l'interface graphique j'ai l'impression. Pour ça il faut passer par la ligne de commande ou par docker-compose.

@CyberFr docker network create | Docker Documentation aux-address est utile lorsque tu définis une ip-range pour un réseau donné et qu'il y a déjà des IP prises dans cette plage. Ca permet d'empêcher d'attribuer ces IP là. Pour le port 8080, je pense que tu n'as pas compris. Quand tu es en bridge, tu dois translater le port car dans le cas de DSM le port 80 est déjà pris par Webstation. C'est pour ça qu'on translate le port 80 du conteneur sur un autre port (par exemple le 8080). Ici, tu es en macvlan, donc ton conteneur est comme une machine physique indépendante, et tous ses ports par défaut son accessibles. Heimdall expose les ports 80 et 443. Essaie donc de taper http://192.168.1.104:80 (car si tu regardes bien ton impression d'écran avec l'inspection du réseau, tu vois que heimdall est sur l'IP 104 et pas 105).

Probablement un problème de permissions, est-ce que ce sujet t'aiderait dans un premier temps ?

Tu peux très bien continuer à utiliser celui de DSM tant que tu veux, il suffit que tes enregistrements de proxy inversé pointent vers le NAS au lieu de SWAG. Pour tes erreurs : Le plus probable est que dans le fichier de configuration d'Authelia tu as laissé le mot de passe par défaut, et que tu le précises également via le fichier externe comme je le préconise. Il se peut qu'au lieu d'en prioriser un, il essaie d'attribuer les deux et échoue logiquement. Là ça sent plus la faute de frappe, je n'ai pas de paramètre lstorage dans mon fichier de configuration. Envoie-moi par MP un pastebin avec le contenu de ton fichier de configuration je vais y regarder.

De quoi parles-tu ? Oui c'est normal, les réseaux n'apparaissent pas via ifconfig, uniquement les interfaces. C'est docker network ls pour les lister. Si tu n'as pas précisé l'IP que tu veux donner à ton conteneur, il a dû en attribuer une dans le range que tu as spécifié. Normalement je pense qu'il est possible de voir l'IP du conteneur en question via l'interface Docker de DSM ? Si pas, en SSH tu fais : docker network inspect lionel-macvlan-network Tu verras la liste des conteneurs adjoints au réseau macvlan. Il faut aussi regarder l'état du conteneur, s'il est mal configuré ou qu'il plante et qu'il redémarre en boucle, tu ne pourras pas joindre l'interface que tu t'attends visiblement à avoir sur le port 8080. Et ce ne sera pour autant pas la faute de la configuration du réseau.

C'était il y a 4 ans 😛 C'est pas du tout mon métier 😉 Ici tu laisses la plage de ton réseau local, donc 192.168.1.0/24. Ca ne laisse pas beaucoup d'IP disponibles, je serais parti sur /29, quitte à décaler un peu. Par exemple 192.168.1.104/29 couvre six adresses IP, de 192.168.1.105 à 192.168.1.110 Et j'aurais appelé mon réseau autrement que "toto" 😛 Sinon c'est ok 👌

@CyberFr J'essaie de comprendre, il existe déjà ton réseau en 192.168.2.x ? Parce que si ton réseau physique est en .1, ton réseau macvlan doit l'être aussi, sauf à avoir un masque inférieur à /24, mais ce n'est visiblement pas ton cas. Tu dois prendre un ip-range compris dans ton réseau physique qui soit en dehors de ta plage DHCP et en dehors des éventuels adressages statiques (réservations d'IP) effectués dans ta box. Voir l'exemple dans le tutoriel.

@wanabo Pour info, je sais accéder à tes caméras (motioneye) ou au moins les vignettes sans être loggé où que ce soit, attention à ce qu'on fait quand on ouvre un serveur vers l'extérieur.

Est-ce que des champs se peuplent automatiquement dans cet écran après validation ou ça a l'air d'attendre que tu les remplisses ? Sinon sache que les périphériques Android fonctionnent uniquement en SLAAC (vs DHCPv6) en IPv6, donc si tu en as tu as tout intérêt à essayer de passer en mode sans état (ou SLAAC).

@Pinpon_112 La question c'est surtout pourquoi tu as le paramètre force dans ton script. @Tex5 Ca ça devrait fonctionner normalement, essaie de reprendre le tutoriel en amont. Non les guillemets sont à utiliser s'il y a des caractères spéciaux qui ont une fonctionnalité, un espace, un slash, etc... de souvenir les credentials OVH sont juste des chaînes de caractère de base. Mais les mettre n'empêche pas le bon fonctionnement.

@Tex5 Le tutoriel a été annoté mais pas corrigé intégralement. Quand tu ajoutes --set-default-CA tu définis le CA que tu vas utiliser par défaut (Letsencrypt dans ton cas et pas ZeroSSL qui est le CA par défaut d'acme.sh depuis quelques temps). Cette opération ne se fait qu'une fois, par la suite soit tu ne précises rien (plus de --set-default-CA --server Letsencrypt), soit tu enlèves juste --set-default-CA et laisse --server letsencrypt pour être sûr que c'est bien LE qui est utilisé (c'est ce que je fais chez moi). Concernant les fichiers dans /root, assure-toi que le chemin est bien défini, je crois que c'est la destination par défaut si le chemin que tu lui indiques n'est pas trouvé. Logiquement tu n'as pas à modifier le script, juste les variables éventuellement. Si elles ont changé de nom depuis le temps, il suffit de modifier le nom des variables que tu exportes dans le shell.

Généralement ce genre d'erreur est lié à un problème de token, est-ce que par hasard tu n'aurais pas mis une durée d'un an sur celui-ci et que du coup logiquement il n'est plus actif ? A moins de forcer la commande acme, avec le paramètre --force, il n'y a aucune raison que ça renouvelle plus tôt que tous les 60 jours. Car le script vérifie la date d'émission du certificat avant de le renouveler, s'il a moins de 60 jours il s'arrête automatiquement, sauf à le forcer. Voir la doc : https://github.com/acmesh-official/acme.sh/wiki/dnsapi#119-use-infomaniakcom-api

@Tex5 Le problème était dans le tutoriel, mauvaise indentation du paramètre external par rapport au reste (4 indentations dans la partie services entre les paramètres environment, volumes, etc... et les lignes commençant par un tiret, et 3 indentations dans le cas d'external). J'ai corrigé ça, assure-toi que l'indentation est ok de ton côté et ça devrait rouler.

Je suis en congés loin de chez moi, mais je regarderai sûrement dans les semaines qui viennent ou à la rentrée scolaire. Dur de libérer du temps avec les enfants. 😁

Tu as tous les fichiers de configuration pour acme ici par exemple : https://github.com/acmesh-official/acme.sh/tree/master/dnsapi Normalement tout est commenté. C'est la seule partie qui change du tutoriel. Et faut évidemment voir comment accéder à l'API du registrar ou hébergeur DNS concerné.