Swagme

Bonjour, si ça peut donner des indices, je confirme que chez moi (DS918+ sous DSM7 avec un HDHomeRun Duo et Plex dans un container Docker), ça fonctionne parfaitement quand je relis le fichier dans Plex (client web, appli android, appli ios, etc.). Je ne peux par contre pas tester avec VideoStation car je n'ai pas installé ce paquet (et ne souhaite pas le faire). J'espère que vous trouverez une solution, sinon Plex est vraiment pratique avec le HDHomeRun pour planifier les enregistrements, gérés les séries, etc.) Bonne investigation.

Ah, enfin un progrès !!! Je pense que j'ai un souci avec accueil.mondomaine.fr (qui est un Dashboard tournant dans un container sur le NAS, Dashmachine). Le reverse proxy de swag pour ce sous-domaine accueil (qui fonctionnait avant que je paramètre authelia) doit avoir un souci maintenant (j'arrive pourtant à y accéder via l'ip du nas, mais pas via le domaine, étrange...). Et comme c'était l'url de redirection d'authelia après une authentification réussie, ça coinçait. Cette fois, j'ai mis mon www.mondomaine.fr comme cible de la redirection, et quand je rentre mes id et mdp dans Authelia (que ce soit dans http://192.168.1.10:9091 ou dans authelia.mondomaine.fr, je suis bien redirigé vers mon site www. Mais je continue à avoir les mêmes erreurs dans les logs de nginx swag si j'essaye d'accéder à rss.mondomaine.fr : 2021/10/06 21:48:20 [error] 506#506: *2 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 21:48:20 [error] 506#506: *2 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" 2021/10/06 21:48:20 [error] 503#503: *9 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr", referrer: "https://rss.mondomaine.fr/" 2021/10/06 21:48:20 [error] 503#503: *9 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", host: "rss.mondomaine.fr", referrer: "https://rss.mondomaine.fr/" (PS : est-ce normal que l'ip du "client" dans ces logs soit celle de mon routeur DHCP, et pas de l'ordi d'où je fais mes tests en 192.168.1.51 ?)

ok, j'ai donc mis ça dans configuration.yml d'Authelia : access_control: default_policy: deny networks: - name: internal networks: - 192.168.1.0/24 - 172.16.0.0/12 - 127.0.0.0/8 - 10.0.0.0/8 rules: - domain: '*.mondomaine.fr' policy: bypass networks: - internal (sauf erreur de ma part, il faut mettre des ' simple autour du *.mondomaine.fr 😉 Et ça dans le reverse proxy d'Authelia : ## Version 2021/05/18 # make sure that your dns has a cname set for authelia # the default authelia-server and authelia-location confs included with letsencrypt rely on # subfolder proxy at "/authelia" and enabling of this proxy conf is not necessary. # But if you'd like to use authelia via subdomain, you can enable this proxy and set up your own # authelia-server and authelia-location confs as described in authelia docs. server { listen 443 ssl; listen [::]:443 ssl; server_name authelia.mondomaine.fr; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.1.10; set $upstream_port 9091; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Je suis par contre sceptique sur le fait que ça puisse marcher en l'état : en effet la doc d'authelia explique que par défaut le service va utiliser un subfolder (soit service.mondomaine.fr/authelia . Je comprends dans leur entête ci-dessus que si je veux utiliser au contraire authelia.mondomaine.fr, il faut paramétrer autre chose dans authelia-location.conf et authelia-server.conf, or là je n'y ai rien changé. Résultat : l'interface de login d'Authelia est bien visible sur authelia.mondomaine.fr mais j'ai tourjours l'erreur 500 si j'essaye de charger rss.mondomaine.fr (avec les lignes authelia actives) et si je désactive les lignes Authelia, j'accède bien à rss.mondomaine.fr Bizarerie (qui peut être te donnera une idée), si je mets dans ce reverse proxy subdomain "authelia" au lieu du l'ip du raspberry hôte "192.168.1.10", j'obtiens l'erreur 500. set $upstream_app authelia; #ne fonctionne pas -> erreur 500 set $upstream_app 192.168.1.10; #fonctionne (bizarre car pourtant swag et authelia sont dans le même network, et c'est bien le nom des containers

J'ai été voir les fichier de log d'erreur de Nginx dans le container Swag (soit dans swag/config/log/nginx/error.log) et si je garde les 2à dernières lignes environ, j'ai ça : 2021/10/06 18:45:13 [crit] 504#504: connect() to [2a02:26f0:2b00:13::5f64:55a4]:80 failed (99: Address not available) while requesting certificate status, responder: r3.o.lencr.org, peer: [2a02:26f0:2b00:13::5f64:55a4]:80, certificate: "/config/keys/letsencrypt/fullchain.pem" 2021/10/06 18:45:13 [crit] 504#504: connect() to [2a02:26f0:2b00:13::5f64:5595]:80 failed (99: Address not available) while requesting certificate status, responder: r3.o.lencr.org, peer: [2a02:26f0:2b00:13::5f64:5595]:80, certificate: "/config/keys/letsencrypt/fullchain.pem" Ensuite j'ai : 2021/10/06 18:45:21 [error] 505#505: *3 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 18:45:21 [error] 505#505: *3 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" 2021/10/06 18:45:21 [error] 505#505: *14 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr", referrer: "https://rss.mondomaine.fr/" 2021/10/06 18:45:21 [error] 505#505: *14 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", host: "rss.mondomaine.fr", referrer: "https://rss.mondomaine.fr/" 2021/10/06 18:45:24 [error] 505#505: *3 no host in upstream ":10080", client: 192.168.1.1, server: accueil.mondomaine.fr, request: "GET / HTTP/2.0", host: "accueil.mondomaine.fr" 2021/10/06 18:45:24 [error] 505#505: *14 no host in upstream ":10080", client: 192.168.1.1, server: accueil.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", host: "accueil.mondomaine.fr", referrer: "https://accueil.mondomaine.fr/" 2021/10/06 18:48:33 [error] 506#506: *2 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 18:48:33 [error] 506#506: *2 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" 2021/10/06 18:48:36 [error] 506#506: *2 no host in upstream ":10080", client: 192.168.1.1, server: accueil.mondomaine.fr, request: "GET / HTTP/2.0", host: "accueil.mondomaine.fr" 2021/10/06 18:50:08 [error] 504#504: *4 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: adguard.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "adguard.mondomaine.fr" 2021/10/06 18:50:08 [error] 504#504: *4 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: adguard.mondomaine.fr, request: "GET / HTTP/2.0", host: "adguard.mondomaine.fr" 2021/10/06 18:50:08 [error] 504#504: *7 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: adguard.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", subrequest: "/authelia/api/verify", host: "adguard.mondomaine.fr", referrer: "https://adguard.mondomaine.fr/" 2021/10/06 18:50:08 [error] 504#504: *7 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: adguard.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", host: "adguard.mondomaine.fr", referrer: "https://adguard.mondomaine.fr/" 2021/10/06 18:50:11 [error] 504#504: *9 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 18:50:11 [error] 504#504: *9 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" 2021/10/06 18:50:14 [error] 504#504: *9 no host in upstream ":10080", client: 192.168.1.1, server: accueil.mondomaine.fr, request: "GET / HTTP/2.0", host: "accueil.mondomaine.fr" 2021/10/06 19:36:11 [error] 504#504: *27 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 45.146.164.110, server: _, request: "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "MON-IP-PUBLIQUE", referrer: "http://MON-IP-PUBLIQUE:80/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php" 2021/10/06 19:36:12 [error] 504#504: *34 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 45.146.164.110, server: _, request: "GET /index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "MON-IP-PUBLIQUE", referrer: "http://MON-IP-PUBLIQUE:80/index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21" 2021/10/06 19:36:14 [error] 504#504: *42 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 45.146.164.110, server: _, request: "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "MON-IP-PUBLIQUE", referrer: "http://MON-IP-PUBLIQUE:80/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php" 2021/10/06 20:38:40 [error] 506#506: *2 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 20:38:40 [error] 506#506: *2 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" hum, des idées ? ok, je teste ça et reviens éditer ici dans 5 min. Merci de ton aide 🙂

J'ai donc mis ça (et uniquement ça, aucune autre règle) : networks: - name: internal networks: # réseau LAN local - 192.168.1.0/24 # réseau Docker - 172.16.0.0/12 # localhost - 127.0.0.0/8 # a priori les vpn - openvpn serait sur 10.0.8.0/24 - et wireguard ? - 10.0.0.0/8 rules: ## Rules applied to everyone - domain: - nas.mondomaine.fr - www.mondomaine.fr - mondomaine.fr - adguard.mondomaine.fr - rss.mondomaine.fr - accueil.mondomaine.fr policy: bypass networks: - internal ...et nope, ça me renvoie toujours cette erreur 500. Et dès que je décommente les lignes d'Authelia ci-dessous, la redirection refonctionne... Argghhh ! server { # enable for Authelia # include /config/nginx/authelia-server.conf; location / { # enable for Authelia # include /config/nginx/authelia-location.conf;

Hello @.Shad. J'ai changé le nom du daemon.json pour qu'il ne soit plus pris en compte. J'ai rebooté et Portainer et les containers fonctionnent normalement. J'ai mis à jour tous les containers. Voici ce que donne "docker ps" : CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 023122bc6a23 authelia/authelia "/app/entrypoint.sh …" 48 minutes ago Up 24 minutes (healthy) 0.0.0.0:9091->9091/tcp, :::9091->9091/tcp authelia 9cf2a7c07ac8 linuxserver/swag:latest "/init" 49 minutes ago Up 25 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp swag 373724ea8175 linuxserver/phpmyadmin:version-5.1.1 "/init" 50 minutes ago Up 25 minutes 443/tcp, 0.0.0.0:8080->80/tcp, :::8080->80/tcp phpmyadmin 9c44f231e5d4 linuxserver/mariadb "/init" 50 minutes ago Up 25 minutes 3306/tcp authelia_mariadb 1aa11213a81a redis:latest "docker-entrypoint.s…" 51 minutes ago Up 25 minutes 6379/tcp redis 105398912b8f portainer/agent "./agent" 51 minutes ago Restarting (1) 35 seconds ago portainer_agent 8f28dadaf608 adguard/adguardhome:latest "/opt/adguardhome/Ad…" 51 minutes ago Up 25 minutes 0.0.0.0:53->53/udp, :::53->53/udp, 80/tcp, 68/udp, 0.0.0.0:53->53/tcp, :::53->53/tcp, 0.0.0.0:853->853/tcp, :::853->853/tcp, 443/tcp, 3001/tcp, 443/udp, 5443/tcp, 5443/udp, 0.0.0.0:3000->3000/tcp, 0.0.0.0:67->67/udp, :::3000->3000/tcp, :::67->67/udp, 8853/udp, 6060/tcp adguardhome 0cd7a71ba8f4 containrrr/watchtower "/watchtower" 52 minutes ago Up 25 minutes 8080/tcp watchtower 4acfa320672d portainer/portainer-ce "/portainer" 4 days ago Up 25 minutes 0.0.0.0:8000->8000/tcp, :::8000->8000/tcp, 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp, 9443/tcp portainer Je t'envoi en MP le fichier configuration.yml. En revanche je n'ai pas créé de reverse proxy pour Authelia (de la forme https://auth.mondomaine.fr) car selon la doc, il faudrait que je modifie en conséquence les fichiers authelia-server.conf et authelia-location.conf mais je ne sais pas de quelle manière (cf. texte ci-dessous en entête du fichier authelia.subdomain.conf.sample) ## Version 2021/05/18 # make sure that your dns has a cname set for authelia # the default authelia-server and authelia-location confs included with letsencrypt rely on # subfolder proxy at "/authelia" and enabling of this proxy conf is not necessary. # But if you'd like to use authelia via subdomain, you can enable this proxy and set up your own # authelia-server and authelia-location confs as described in authelia docs. Or je comprends que par défaut, ça devrait fonctionner avec ma requête renvoyée vers mondomaine.fr/authelia, donc le problème doit être ailleurs. Merci pour ton aide, je commence à désespérer de trouver la solution...

il faut donc que je remette le fichier /etc/docker/daemon.json dans son état d'origine. En l'état j'ai juste 1 ligne : { "dns": ["80.67.169.12", "80.67.169.40"] } Faut-il l'effacer, mettre autre chose, ou tout simplement effacer ce fichier daemon.json ? Concernant cette remarque : Mon container Adguard a les paramètres de translation suivant : donc sauf erreur de ma part, c'est bon ?

@.Shad. je me doute bien que pour toi c'est compliqué de m'aider, et je te remercie déjà pour toute cette aide. Tes commentaires et remarques m'aident néanmoins à avancer je pense. Concernant les réseaux, je comprends tes recommandations. En revanche, ma situation est un peu différente puisque toute la partie reverse-proxy est déportée sur le raspberry pi, et que les autres services (freshrss, dashmachine, etc.) sont sur le NAS. Sur le Pi, j'ai : sur le réseau host "system" : rien sur le réseau bridge "system" : Adguard Hom + Watchtower + Portainer (+ Portainer agent pour accèder aussi depuis le Portainer du NAS) sur un bridge "perso" (nommé "swag_default") : Swag + Authelia + MariaDB + Redis + phpMyAdmin Concernant mon problème, je pense que je commence à circonscrire son origine. J'ai les indices suivants : le reverse proxy de SWAG fonctionne sans Authelia j'arrive à atteindre la page d'Authelia sur 192.168.1.10:9091 (IP du Pi), et quand je teste un utilisateur, les logs d'Authelia montre que les id et mdp sont ok par contre, je ne suis pas redirigé sur la page que j'ai précisé dans authelia/config/configuration.yml : default_redirection_url: https://accueil.mondomaine.fr/ si j'active les lignes d'Authelia dans les .conf de SWAG, j'ai l'erreur 500. Mais si je désactive ces lignes (sans rien changer d'autre), la redirection refonctionne J'en déduis donc que le problème survient quand je demande à accéder à (par exemple) rss.modomaine.fr, que SWAG voit qu'il doit rediriger vers telle adresse ET qu'il doit me faire passer par Authelia. Et là ça coince avec l'erreur 500 nginx. Donc je suppose que ça coince pour afficher rss.modomaine.fr/authelia Donc on progresse 🤔 J'ai regardé les logs de swag/config/log/nginx juste après cette tentative d'accès à rss.mondomaine.fr : 2021/10/02 18:05:56 [error] 502#502: *2 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/02 18:05:56 [error] 502#502: *2 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" Ces messages t'évoquent quelque chose ? Dans le fichier authelia.subdomain.conf.sample (que je n'ai pas activé), je lis ça : ## Version 2021/05/18 # make sure that your dns has a cname set for authelia # the default authelia-server and authelia-location confs included with letsencrypt rely on # subfolder proxy at "/authelia" and enabling of this proxy conf is not necessary. # But if you'd like to use authelia via subdomain, you can enable this proxy and set up your own # authelia-server and authelia-location confs as described in authelia docs. Donc je pense que c'est là que ça coince : Je n'ai pas de DNS server sur mon réseau local (j'y songe mais rien en l'état, ni sur le NAS ni ailleurs). Chez OVH (mon domaine), j'ai mis en place une redirection globale vers mon ip fixe (*.mondomaine.fr -> 86.123.43.23) J'ai AdGuard Home (sans DNS rewrite) J'ai le reverse proxy SWAG, mais je n'ai créé aucune règle pour authelia (puisque ces lignes au dessus disent que c'est inutile puisque par défault c'est un subfolder /authelia qui est utilisé). Donc je crois que le problème est peut être là : # make sure that your dns has a cname set for authelia Je pensais que les containers pouvant se parler (puisque dans le même réseau docker) et que ça suffisait. Mais peut être faut-il "mieux déclarer" Authelia ? Est-ce que justement de configurer le DNS server sur le NAS pourrait aider ? PS : je vais lire (en étant concentré) ton message dans l'autre fil sur le DNS server ; je me dis que j'ai peut être mis le bazar dans les réglages DNS du Pi en allant modifier etc/dhcpcd.conf et /etc/docker/daemon.json. Je te pose l'éventuelle question dans cet autre fil. Désolé de m'éparpiller à ces 2 endroits 😞

@Jeff777 heu bah non, pourquoi tu dis ça, ça m'avait l'air très clair (et là tu jettes le doute...). Avec l'ordre d' @oracle7 je pense qu'on obtiendrait ta config "bof" avec dans AdGuard toutes les requêtes qui seraient vues comme provenant du NAS (pas terrible pour créer des filtrage différencié). Alors qu'avec ton ordre "recommandé" j'aurai dans Adguard chaque client bien séparé. Donc je préfère ta config "recommandée" (qui finalement a fonctionné, exact ?) et ça donnerait : dans le routeur DHCP : je mets comme DNS principal (et uniquement lui) l'ip du raspberry avec AdGuard Home (192.168.1.10) NB : tous les clients du réseau utiliseront donc cette ip comme DNS : est-ce problématique pour le NAS (sorte de boucle ?) dans le raspberry pi, il faut mettre l'ip du NAS (192.168.1.20) en DNS à 3 endroits (est-ce bien ça ?) : dans etc/dhcpcd.conf (paramètre global du pi) dans /etc/docker/daemon.json (paramètre de docker, donc des containers) et dans les réglages de AdGuard Home lui même (via l'interface graphique) dans le DNS serveur du NAS : je mets en DNS principal et secondaire par exemple Cloudfare (1.1.1.1 et 1.0.0.1) ou ceux de la FDN (80.67.169.12 et 80.67.169.40). Vous confirmez ?

@.Shad.,je réponds point par point : 1- en effet je mettais mon IP publique pensant que parfois mes requêtes depuis chez moi auraient cette ip (c'est ma méconnaissance des DNS). Donc je devine que cette IP n'a pas besoin d'apparaître où que ce soit dans cette partie Access control, exact ? (je pense que ça vient du fait que je vois souvent dans les tutos en ligne le parefeu du Synology avec une règle allow pour l'adresse IP public, mais c'est peut être aussi une erreur, ou la logique n'est pas la même ?) 2- ok pour l'ordre, je procèderai par network. D'ailleurs je vois souvent les plages d'IP 172.16.0.0/12 et/ou 127.0.0.0/8 (et même 10.0.0.0/8) dans "internal", est-ce nécessaire par exemple pour que les échanges entre les container soient bien traités ? 3- oui j'avais mis une règle d'accès 2FA en interne et externe dans le but de tester. J'enlèverai sans doute le two_factor et mettrai one_factor ou bypass pour l'interne quand tout marchera. Là j'ai suivi les recommandations ici : il s'agit d'un fichier à générer (il n'est pas existant par défaut. Non, il est sur le réseau Bridge d'origine (pas un que j'ai créé) avec l'IP 172.17.0.5. Et il n'est que sur ce réseau (par sur le réseau "swag_default" du stack Swag+Authelia. Voilà le code de adguard.subdomain.conf : ## Version 2021/05/18 # make sure that your dns has a cname set for adguard and that your adguard container is named adguard server { listen 443 ssl; listen [::]:443 ssl; server_name adguard.mondomaine.fr; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for Authelia -> décommenté pour l'authentification via Authelia include /config/nginx/authelia-server.conf; location / { # enable for Authelia -> décommenté pour l'authentification via Authelia include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; #include /config/nginx/internal.conf; # ajouté - exclu l'accès depuis l'extérieur - autorise depuis local set $upstream_app 192.168.1.10; set $upstream_port 3000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location /control { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; #include /config/nginx/internal.conf; # ajouté - exclu l'accès depuis l'extérieur - autorise depuis local set $upstream_app 192.168.1.10; set $upstream_port 3000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Pour le container Adguard, j'ai créé le container via le GUI de Portainer, en précisant des volumes (depuis j'ai appris et je passe par une syntax docker-compose toujours dans le GUI). Donc je te mets paramètres ci-dessous : IMAGE adguard/adguardhome:latest@sha256:50682ca547fb1e5fb5c587bfd67dd053174c8375c40b0c917207aa2ca9cfbef2 PORT CONFIGURATION 0.0.0.0:3000 3000/tcp :::3000 3000/tcp 0.0.0.0:53 53/tcp :::53 53/tcp 0.0.0.0:53 53/udp :::53 53/udp 0.0.0.0:67 67/udp :::67 67/udp 0.0.0.0:853 853/tcp :::853 853/tcp CMD --no-check-update -c /opt/adguardhome/conf/AdGuardHome.yaml -h 0.0.0.0 -w /opt/adguardhome/work ENTRYPOINT /opt/adguardhome/AdGuardHome ENV PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TZ Europe/Paris LABELS maintainer AdGuard Team <devteam@adguard.com> org.opencontainers.image.created 2021-05-19T13:30:19Z org.opencontainers.image.description Network-wide ads & trackers blocking DNS server org.opencontainers.image.licenses GPL-3.0 org.opencontainers.image.revision $( git rev-parse --short HEAD ) org.opencontainers.image.source https://github.com/AdguardTeam/AdGuardHome org.opencontainers.image.title AdGuard Home org.opencontainers.image.url https://adguard.com/adguard-home.html org.opencontainers.image.vendor AdGuard org.opencontainers.image.version v0.106.3 RESTART POLICY unless stopped VOLUMES Host/volume Path in container adguardhome_config /opt/adguardhome/conf adguardhome_data /opt/adguardhome/work Network IP Address Gateway MAC Address Actions bridge 172.17.0.5 172.17.0.1 02:42:ac:11:XX:XX Après concernant les DNS : C'est aussi mon impression, mais je maîtrise peu cette partie. Le fichier /etc/resolv.conf est selon moi celui global du raspberry (c'est le /etc à la racine ; mes autres applis comme swag sont dans /home/pi/nom_du_container/) Je constate d'ailleurs qu'après un "sudo apt update -y && sudo apt full-upgrade -y && sudo reboot", le fichier a été régénéré et qu'il contient maintenant ça : # Generated by resolvconf nameserver 192.168.1.10 nameserver fd0f:ee:b0::1 J'ai aussi regardé /etc/dhcpcd.conf je me souviens y avoir configurer (tout en bas) un fallback vers mon ip static au cas où le serveur DHCP aurait un souci) : # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. # Allow users of this group to interact with dhcpcd via the control socket. #controlgroup wheel # Inform the DHCP server of our hostname for DDNS. hostname # Use the hardware address of the interface for the Client ID. clientid # or # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361. # Some non-RFC compliant DHCP servers do not reply with this set. # In this case, comment out duid and enable clientid above. #duid # Persist interface configuration when dhcpcd exits. persistent # Rapid commit support. # Safe to enable by default because it requires the equivalent option set # on the server to actually work. option rapid_commit # A list of options to request from the DHCP server. option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes # Respect the network MTU. This is applied to DHCP routes. option interface_mtu # Most distributions have NTP support. #option ntp_servers # A ServerID is required by RFC2131. require dhcp_server_identifier # Generate SLAAC address using the Hardware Address of the interface #slaac hwaddr # OR generate Stable Private IPv6 Addresses based from the DUID slaac private # Example static IP configuration: #interface eth0 #static ip_address=192.168.0.10/24 #static ip6_address=fd51:42f8:caae:d92e::ff/64 #static routers=192.168.0.1 #static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1 # It is possible to fall back to a static IP if DHCP fails: # define static profile profile static_eth0 static ip_address=192.168.1.10/24 static routers=192.168.1.1 static domain_name_servers=1.1.1.1 1.0.0.1 80.67.169.12 80.67.169.40 # fallback to static profile on eth0 interface eth0 fallback static_eth0 Merci encore pour ton aide, là j'avoue que ça dépasse mes compétences. 😞

Merci @Jeff777 et @oracle7, Je crois que j'ai compris. Je vais tester ça ce week end si je trouve un peu de temps. Merci pour votre aide 😉 PS : @Jeff777 avec ta configuration "recommandée", tu arrives à récupérer les noms de tes clients dans ton Pi-Hole (et en imaginant que la logique soit la même dans mon AdGUard) ? Moi je n'obtiens que des adresses IP, et j'avais cru comprendre que ça ne pouvait pas en être autrement sauf à ce que AdGuard soit aussi le serveur DHCP ? Si ce n'est pas automatique, tu as associé manuellement les IP local à des noms dans Pi-Hole ? (genre tv->192.168.1.53) ... ce qui impliquerait de passer tous les clients en ip fixe (via des baux DHCP fixes sur la freebox, laborieux mais faisable au moins pour tous les appareils permanents, pas contre impossible pour les appareils de passage de la famille et des amis...)

Merci @oracle7, et selon toi, c'est donc l'IP du NAS que je mets dans ma Freebox comme DNS principal ? Et l'IP du raspberry peut aller en DNS secondaire ? (ou ça risque de créer une boucle et la création d'un trou noir ?) Donc le circuit d'une requête serait : client -> DCHP -> DNS (principal) sur le NAS -> AdGuard sur le raspberry Pi (aussi DNS secondaire) -> DNS externes de FDN J'imagine que dans ce cas, il ne faut pas préciser les DNS de la FDN en secondaire dans le DNS serveur du NAS, au risque de court-circuiter AdGuard parfois, exact ?

Hello @.Shad., suite à ta remarque sur un autre fil (Authelia) au sujet des possibles problèmes de DNS que j'ai, j'ai jeté un oeil à ce tuto pour mieux comprendre les DNS. Avant d'éventuellement tenter de déployer DNS server, il y a un truc qui m'échappe. Comment intégrer dans cette "configuration DNS" un bloqueur comme Pi-Hole ou AdGuard Home qui tourne sur un raspberry pi différent du NAS ? J'essaye de comprendre, mais sans y parvenir... Voici ma configuration : mon routeur, une freebox pop avec : IP extérieure fixe, et un domaine perso chez OVH qui pointe dessus IP locale : 192.168.1.1 ports 80 et 443 ouverts et redirigés vers le reverse proxy serveur DHCP, avec comme DNS l'ip locale du Raspberry Pi hébergeant AdGuard un Raspberry Pi : IP locale : 192.168.1.10 SWAG comme reverse proxy AdGuard comme serveur de DNS bloquand les pub les DNS d'AdGuard sont ceux de la FDN un NAS : IP locale : 192.168.1.20 des services comme Drive de Synology accessible sur drive.mondomaine.fr ...et pas encore de serveur DNS (mais si je suis ici, j'y pense 😉 Donc si je suis le tuto et mets en place le cache et la zone locale via DNS server sur le NAS, où et comment intégrer le raspberry pi avec Adguard dans la chaîne ? Merci d'avance pour vos conseils et explications qui me permettront d'y voir clair.

Une autre idée qui me traverse l'esprit (parce que j'ai souvenir qu'on dit souvent "c'est toujours un problème de DNS"), j'ai jeter un oeil au fichier resolver.conf de Nginx Swag : # This file is auto-generated only on first start, based on the container's /etc/resolv.conf file. Feel free to modify it as you wish. resolver 192.168.1.10 valid=30s; Comme je fais tourner Adguard Home sur le même host (le raspberry), et que c'est lui qui sert de DNS à tout mon réseau local, j'avais donc cette valeur avec l'IP locale du raspberry comme DNS. J'ai testé en mettant : resolver 1.1.1.1 valid=30s; mais pas de changement (à part qu'il faut juste 1sec pour afficher l'erreur 500 là où avec l'IP du raspberry il fallait 6sec). J'ai donc aussi regardé le fichier /etc/resolv.conf (si je comprends bien c'est le réglages DNS plus global au raspberry et pas juste au container Nginx Swag), et j'ai ça : # Generated by resolvconf nameserver 1.1.1.1 nameserver 80.67.169.12 nameserver 80.67.169.40 nameserver fd0f:ee:b0::1 ... en effet, j'ai souvenir d'avoir eu des souci par le passé pour mettre en place Nginx Proxy Manager puis SWAG, et que je les avais résolus en mettant des DNS "sérieux" et pas ma propre IP d'Adguard. Un avis ? Merci.

Arghhh, ça me rend fou ! Impossible de faire fonctionner normalement Authelia. Si je configure comme actives les 2 lignes d'Authelia dans mes fichiers .conf de Nginx Swag (par exemple "adguard.subdomain.conf") : server { ... # enable for Authelia include /config/nginx/authelia-server.conf; ... location / { # enable for Authelia include /config/nginx/authelia-location.conf; ... alors j'obtiens une erreur 500 si je tente d'accéder à la page adguard.mondomaine.fr En revanche si je les désactive, ma redirection fonctionne à nouveau et j'accède bien à mon service. Si je tape 192.168.1.10:9091, j'affiche bien la page de login d'Authelia. J'ai même testé avec un utilisateur valide sur le LDAP, et je vois dans les log du container que l'utilisateur est bien reconnu. Je ne vois aucun autre message d'erreur (je suis en mode debug). time="2021-09-30T22:56:48+02:00" level=info msg="Authelia v4.31.0 is starting", time="2021-09-30T22:56:48+02:00" level=info msg="Log severity set to debug", time="2021-09-30T22:56:48+02:00" level=debug msg="Storage schema is being checked to verify it is up to date", time="2021-09-30T22:56:48+02:00" level=debug msg="Storage schema is up to date", time="2021-09-30T22:56:48+02:00" level=debug msg="Notifier SMTP client attempting connection to smtp.XXXX.XXXX.com:587", time="2021-09-30T22:56:48+02:00" level=debug msg="Notifier SMTP client connected successfully", time="2021-09-30T22:56:48+02:00" level=debug msg="Notifier SMTP server supports STARTTLS (disableVerifyCert: false, ServerName: smtp.XXXX.XXXX.com), attempting", time="2021-09-30T22:56:49+02:00" level=debug msg="Notifier SMTP STARTTLS completed without error", time="2021-09-30T22:56:49+02:00" level=debug msg="Notifier SMTP server supports authentication with the following mechanisms: LOGIN PLAIN ATOKEN", time="2021-09-30T22:56:49+02:00" level=debug msg="Notifier SMTP client authenticated successfully with the server", time="2021-09-30T22:56:50+02:00" level=info msg="Listening for non-TLS connections on '0.0.0.0:9091' paths '/' and '/authelia'", time="2021-09-30T22:56:49+02:00" level=debug msg="Notifier SMTP client attempting AUTH PLAIN with server" Je pense que je dois merder dans la partie "access control" du "configuration.yml" d'Authelia. J'ai pourtant passé du temps pour le comprendre, et simplifier les paramètres pour mes essais. Mais rien n'y fait. Si vous avez un avis, je suis preneur... access_control: default_policy: deny networks: - name: internal networks: - 192.168.1.0/24 - X.X.X.X # mon ip publique ici cachée évidement ;-) rules: - domain: - nas.mondomaine.fr - www.mondomaine.fr - mondomaine.fr policy: bypass - domain: - snapdrop.mondomaine.fr - imprimante.mondomaine.fr policy: bypass networks: - internal - domain: - accueil.mondomaine.fr - rss.mondomaine.fr - media.mondomaine.fr - drive.mondomaine.fr policy: one_factor networks: - internal - domain: - adguard.mondomaine.fr policy: two_factor Au passage, avant de me lancer dans l'installation d'Authelia, j'avais configurer le fichier internal.conf de Nginx Swag. J'ai repassé ce fichier en internal.conf.sample et j'ai décommenté les lignes y faisant références dans mes fichiers de configs. Est-ce qu'on peut imaginer qu'il intérfère quand même encore quelque part ? (je ne pense pas car j'ai testé depuis mon réseau local et depuis mon smartphone en 4G et j'ai les mêmes erreurs 500). Merci d'avance pour vos réflexions 😞