[TUTO] [Docker] Authelia : serveur d'authentification

[.Shad.]

 

1. Qu'est-ce qu'Authelia ?

Authelia est un serveur d'authentification open-source proposant une authentification unique ou à deux facteurs à la demande.
C'est donc un moyen de venir appliquer une couche de sécurité supplémentaire sur une application critique ou sur une application qui en serait dépourvue d'élément d'authentification.
L'authentification deux facteurs peut se faire via :

1. TOTP (Time-based One-Time Password) : l'authentification à deux facteurs telle que Synology la propose, un code valable x secondes à valider après la saisie du mot de passe.
2. Notifications PUSH : via l'application DuoAPI, on va pouvoir recevoir des notifications push sur notre téléphone pour valider la connexion.
3. Clés de sécurité avec jeton type Yubikey.
4. OpenID Connect (en beta) : Vous vous servez de votre ID OpenID pour vous connecter à vos applications.

Seuls les points 1 et 2 seront développés dans ce tutoriel.

2. Prérequis

Difficulté : moyenne-avancé

• Vous devez disposer d'un NAS compatible Docker, vous pouvez en retrouver la liste mise à jour à cette adresse : https://www.synology.com/fr-fr/dsm/packages/Docker
• Avoir mis en place SWAG (proxy inversé multi-fonctionnel) dont un tutoriel de mise en route est disponible sur ce forum :

• Disposer d'une instance MySQL (ou MariaDB)
• Savoir se connecter en SSH en root
• Savoir éditer les différents fichiers de configuration par la méthode de votre choix (nano, vim, WinSCP, File Station, etc...)
• Utiliser Docker-compose

NOTE : Certaines notions sont longuement explicitées dans le tutoriel pour la mise en place de SWAG, une double astérisque ** sera présente à côté des points concernés.

3. Principe

Lorsque Nginx reçoit une requête vers exemple.ndd.tld et que ce sous-domaine est l'objet d'une entrée de proxy inversé, il vérifie si un appel à Authelia est demandé.
Si c'est le cas, la demande est transférée à ce dernier, qui va exiger une authentification (ou pas) afin de poursuivre. Suivant les ACL (Access Control Lists) qu'on aura défini dans sa configuration, l'accès peut être :

• refusé
• autorisé
• autorisé sous réserve d'authentification par login et mot de passe
• autorisé sous réserve d'authentification à deux facteurs

On peut donc en résumer le principe suivant ce schéma (dans notre cas, nous détaillerons l'installation pour Nginx uniquement, mais Traefik et HAProxy sont également compatibles) :

 

Authelia doit être vu comme un complément de Nginx, même si les deux permettent un filtrage par ACL (et Nginx un blocage GeoIP de surcroît, qu'Authelia n'intègre pas).

Il utilise le port 9091, qui n'est pas un port utilisé par défaut par DSM, comme pouvaient l'être les ports 80 et 443, raison pour laquelle SWAG est déployé sur un réseau macvlan.
Il sera donc déployé sur un réseau bridge.

4. Hypothèses

Quelques conventions pour s'y retrouver par la suite :

• IP de l'hôte : 192.168.1.100
• IP virtuelle de l'hôte :  : 192.168.1.200
• Réseau bridge personnalisé : 172.25.0.0
• Les commandes via SSH sont exécutées en tant que root.

5. Création d'un réseau bridge personnalisé

A priori, on pourrait utiliser le réseau bridge par défaut (172.17.0.0/16), néanmoins afin de garantir un minimum de changement au cas où vous souhaiteriez utiliser Redis (voir fonctionnalités avancées) en conjonction avec Authelia, on va créer un réseau bridge personnalisé qui facilitera la communication inter-conteneurs.

mkdir -p /volume1/docker/networks && cd $_
nano net-db.sh

On y insère le code suivant :

docker network create -d bridge \
--subnet=172.25.0.0/16 \
--gateway=172.25.0.1 \
--opt "com.docker.network.bridge.name"="br_net-db" \
net-db

On rend le script exécutable :

chmod u+x net-db.sh

On l'exécute :

bash net-db.sh

Si la commande se termine avec succès, un identifiant composé de lettres et de chiffres s'affiche à l'écran.

6. Installation

6-A. Fichier docker-compose

Voici une proposition de fichier docker-compose adapté aux versions 2.x, libre à vous de vous inspirer de ce qui est recommandé dans la documentation d'Authelia :

version: '2.1'
services:

   authelia:
      image: authelia/authelia
      container_name: authelia
      networks:
         - net-db
      environment:
         - AUTHELIA_JWT_SECRET_FILE=/config/secrets/jwt
         - AUTHELIA_STORAGE_MYSQL_PASSWORD_FILE=/config/secrets/mysql
         - AUTHELIA_NOTIFIER_SMTP_PASSWORD_FILE=/config/secrets/smtp
         - AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE=/config/secrets/encryption
         - TZ=Europe/Brussels
      ports:
         - 9091:9091/tcp
      volumes:
         - /volume1/docker/authelia/config:/config
      restart: unless-stopped

networks:

   net-db:
      external: true

NOTE : Pour l'instant on ne crée pas le conteneur via la commande docker-compose, cela n'interviendra que bien plus tard.

6-B. Secrets

Authelia ne permet pas de stocker des credentials (login et mot de passe) directement en clair dans les variables, ni même dans un fichier .env.
On peut donc soit utiliser la fonctionnalité secrets de Docker (compatible sur les implémentations de Docker pour DSM 7 et +), soit définir les variables dans des fichiers et les monter au moyen de variables d'environnement, c'est cette seconde méthode que nous privilégierons (voir docker-compose ci-avant).

On crée les dossiers où seront stockées nos données en s'y plaçant dans la foulée :

mkdir -p /volume1/docker/authelia/config/secrets && cd $_

Puis on crée les fichiers contenant les mots de passe que le fichier de configuration d'Authelia utilisera. N'hésitez pas à utiliser des mots de passe longs (privilégiez la longueur du mot de passe sur la présence abusive de caractères spéciaux). 30 caractères par exemple est une valeur satisfaisante :

echo 'MOT_DE_PASSE_1' > jwt
echo 'MOT_DE_PASSE_2' > mysql       ## Le mot de passe pour MySQL doit conteneur au moins 1 caractere special !!
echo 'MDP_SMTP_MAIL' > smtp         ## Correspond au mot de passe du serveur SMTP qu'Authelia utilisera
echo 'MOT_DE_PASSE_3' > encryption  ## Minimum 20 caracteres, idealement 64

On vérifie la présence de nos fichiers :

ls -l

Ce qui devrait vous donner ceci :

total 12
-rwxr-xr-x+ 1 root root 31 Jul 25 00:15 jwt
-rwxr-xr-x+ 1 root root 31 Jul 25 00:16 mysql
-rwxr-xr-x+ 1 root root 14 Jul 26 00:09 smtp
-rwxr-xr-x+ 1 root root 14 Jul 26 00:09 encryption

Comme on peut le constater, malgré le fait que les fichiers appartiennent à l'utilisateur et au groupe root, DSM applique ses ACL (le "+" à la fin des permissions UNIX), ce qui fait que n'importe quel utilisateur possédant des droits de lecture et ou d'écriture dans le dossier partagé docker pourra consulter le contenu de ces fichiers.

On sécurise donc les fichiers :

chmod 660 ./*
chown your-personal-user:root ./*

NOTE : Il faut évidemment remplacer l'utilisateur your-personal-user par l'utilisateur dont vous souhaitez qu'il soit propriétaire des dits fichiers.

6-C. Configuration

6-C-1. Génération du fichier configuration.yml d'Authelia

On va exécuter une première fois le conteneur, qui s'arrêtera aussitôt, mais dont l'exécution permettra de générer un fichier de configuration, il a l'avantage d'être entièrement commenté et vous sera d'une aide précieuse si vous souhaitez creuser plus amplement les possibilités d'Authelia.

On exécute la commande suivante :

docker run --rm -v /volume1/docker/authelia/config:/config authelia/authelia

A la suite de quoi on a un fichier configuration.yml dans /volume1/docker/authelia/config

6-C-2. Préparation de SWAG

Le cadre d'utilisation par défaut prévu pour SWAG est d'être dans le même réseau bridge personnalisé qu'Authelia, ce n'est pas le cas ici vu que SWAG est déployé sur un réseau macvlan.

6-C-2-a. Modification de la configuration serveur

On va devoir éditer les fichiers de configuration pour Authelia dans SWAG, notamment le fichier authelia-server.conf :

cd /volume1/docker/swag/config/nginx && nano authelia-server.conf

Ce qui donne :

## Version 2021/05/28 - Changelog: https://github.com/linuxserver/docker-swag/commits/master/root/defaults/authelia-server.conf
# Make sure that your authelia container is in the same user defined bridge network and is named authelia

location ^~ /authelia {
    include /config/nginx/proxy.conf;
    include /config/nginx/resolver.conf;
    set $upstream_authelia 192.168.1.200;       ## On remplace "authelia" par l'IP virtuelle du NAS
    proxy_pass http://$upstream_authelia:9091;

}

location = /authelia/api/verify {
    internal;
    if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]]) {
        return 401;
    }
    include /config/nginx/resolver.conf;
    set $upstream_authelia 192.168.1.200;       ## On remplace "authelia" par l'IP virtuelle du NAS
    proxy_pass_request_body off;
    proxy_pass http://$upstream_authelia:9091;
    proxy_set_header Content-Length "";

    [...]
}

ATTENTION : Avec DSM 7, les appels API pour le bureau DSM comprennent des caractères normalement ignorés par Authelia (des accolades), il faut les ajouter dans la ligne :

if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]]) {             devient             if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]\{\}]) {

On valide les modifications.

6-C-2-b. Modification des entrées de proxy inversé**

Pour que Nginx prenne Authelia en compte, il suffit d'éditer une entrée de proxy inversé existante, et de décommenter les deux lignes suivantes :

#include /config/nginx/authelia-server.conf;
[...]
#include /config/nginx/authelia-location.conf;

Il faudra ensuite que le domaine correspondant à cette entrée soit pris en charge dans les ACL d'Authelia (voir point 6-C-3-f.)

6-C-2-c. Création d'entrée pour Authelia**

On va également en profiter pour créer une entrée de proxy inversé pour la page d'Authelia, dont on va se servir pour configurer nos accès :

cd /volume1/docker/swag/config/nginx/proxy-confs
cp authelia.subdomain.conf.sample authelia.subdomain.conf
nano authelia.subdomain.conf

Puis on adapte à notre besoin :

## 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.*;

    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.200;       ## On utilise l'IP virtuelle du NAS
        set $upstream_port 9091;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

_______________________

Une fois ceci fait, on redémarre le conteneur SWAG, on n'aura plus besoin d'y toucher.

docker restart swag

6-C-3. Personnalisation du fichier de configuration d'Authelia

Le fichier regorge d'options, parcourons-le donc et voyons ce qu'il convient de faire au fur et à mesure. Les parties que je ne mentionne pas ne sont pas sensées être modifiées (du moins pour l'application qu'on en fera ici (voir la documentation pour une utilisation plus experte)) ou ont un intérêt évident/trivial (theme par exemple).

6-C-3-a. server

# Configuration options specific to the internal http server
server:
  [...]
  path: "authelia"

Donner la valeur "authelia" à path est un prérequis du bon fonctionnement de l'application suivant la configuration embarquée dans SWAG.

6-C-3-b. log

log:

  level: info
  [...]
  file_path: /config/logs/authelia.log
  keep_stdout: true

Le niveau info est déjà suffisamment verbeux, n'utiliser debug ou trace qu'en cas de problème à résoudre.
Pour file_path et keep_stdout : préférence personnelle, j'aime bien avoir un fichier log, et garder pour autant l'output sur les logs du conteneur.
Faites comme il vous plaît.

6-C-3-c. jwt_secret

jwt_secret:

Il est important de noter que jwt_secret n'ait aucune valeur, afin que le secret défini dans le fichier jwt soit pris en compte. Si vous laissez la chaîne de caractères par défaut "a_very_important_secret", le contenu du fichier jwt ne sera pas utilisé.

NOTE : Cette remarque est valable pour toutes les autres clés faisant appel au contenu des fichiers définis par avant (jwt, mysql, etc...).

6-C-3-d. default_redirection_url

default_redirection_url: https://ndd.tld

Authelia est directement accessible par proxy inversé, c'est un des templates de fichier conf de SWAG.
Lorsque vous vous identifierez sur cette page, vous serez redirigé vers la page définie par default_redirection_url.

6-C-3-e. authentication_backend

Deux possibilités existent : l'utilisation d'un annuaire LDAP ou un fichier d'utilisateurs défini localement.
Nous utiliserons la seconde option. Il faut par conséquent commenter toutes les clés, listes, etc... liées à la configuration du serveur LDAP :

  ##
  ## LDAP (Authentication Provider)
  ##
  ## This is the recommended Authentication Provider in production
  ## because it allows Authelia to offload the stateful operations
  ## onto the LDAP service.
#  ldap:
     [...]
#    implementation: custom
     [...]
#    url: ldap://127.0.0.1

    ## Use StartTLS with the LDAP connection.
#    start_tls: false

#    tls:
     [...]
#      skip_verify: false

      ## Minimum TLS version for either Secure LDAP or LDAP StartTLS.
#      minimum_version: TLS1.2
     [...]
#    base_dn: dc=example,dc=com

     [...]
#    additional_users_dn: ou=users
     [...]
#    users_filter: (&({username_attribute}={input})(objectClass=person))
     [...]
#    additional_groups_dn: ou=groups
     [...]
#    groups_filter: (&(member={dn})(objectclass=groupOfNames))
     [...]

    ## The username and password of the admin user.
#    user: cn=admin,dc=example,dc=com
#    password: password

Nous utiliserons la deuxième option disponible : la définition locale d'utilisateurs dans une liste, cela se fait au moyen d'un fichier users_database.yml. On utilise le modèle disponible sur GitHub :

cd /volume1/docker/authelia/config
wget https://raw.githubusercontent.com/authelia/authelia/master/examples/compose/local/authelia/users_database.yml

Qu'on personnalisera de la sorte :

---
###############################################################
#                         Users Database                      #
###############################################################

# This file can be used if you do not have an LDAP set up.

# List of users
users:
  toto:
    displayname: "Thomas"
    password: "$argon2id$v=19$m=65536,t=1,p=8$VmFaM3FKckFRZVY5TUJ5eg$81mBJ3QSw8WQM2rm4yNJeS7j2YQMra183gHCxGALOAs"
    email: mail@ndd.tld
    groups: []
#      - admins
#      - dev
...

• toto sera le nom d'utilisateur qui sera utilisé pour l'authentification simple ou double facteur. De préférence choisissez un nom d'utilisateur plus long et complexe. 🙂 
• Thomas sera le nom d'affichage.
• <PASSWORD> sera le mot de passe utilisé pour s'authentifier, mais il ne sera pas lisible en clair, Authelia utilise un algorithme de chiffrement en ce sens. On va utiliser la commande suivante :

  docker run --rm authelia/authelia:latest authelia hash-password 'MOT_DE_PASSE'

  Suivant votre modèle de NAS et la complexité de votre mot de passe, cette opération pourrait prendre un certain temps, mais à la fin de quoi vous devriez obtenir un renvoi de la sorte :

  $argon2id$v=19$m=65536,t=1,p=8$aC8raDhGRWh4eDlmRmp5aw$PsiuwaVbWsXkIThpLLeI3JZdT3NCe3CUeAXORQzsSpg

  C'est cette ligne qu'il vous faut mettre à la place de <PASSWORD>.
• Pour l'email, c'est l'adresse qui sera utilisée en cas de demande de renouvellement de mot de passe, etc..., à personnaliser. 
• Pour les groupes, je conseille de ne pas vous en servir dans un premier temps, il vous suffit de modifier ainsi :

  groups: []
  #   - admins
  #   - dev

NOTE : Le fichier ne donnant pas d'information sensible, et afin de permettre aux différents utilisateurs de modifier éventuellement leur mot de passe, on peut laisser les permissions par défaut (celles de DSM avec les ACL).

_______________________

On décommente la section file :

authentication_backend:
  # Disable both the HTML element and the API for reset password functionality
  disable_reset_password: false
  [...]
  refresh_interval: 5m
  [...]
  file:
    path: /config/users_database.yml
    password:
      algorithm: argon2id
      iterations: 1
      key_length: 32
      salt_length: 16
      memory: 1024
      parallelism: 8

6-C-3-f. access_control

Une des parties les plus importantes, elle concerne les contrôles d'accès et la manière dont Authelia va se comporter en fonction de l'IP d'origine et le domaine demandé lors de la requête. Pour plus d'information, la documentation est consultable à cette adresse.

On va se placer dans le cas (pour exemple) où on autorise tous les accès en local et VPN, et on limite ensuite de façon granulaire au gré des sous-domaines :

access_control:
  # Default policy can either be 'bypass', 'one_factor', 'two_factor' or 'deny'.
  # It is the policy applied to any resource if there is no policy to be applied
  # to the user.
  default_policy: deny

  networks:

    - name: local
      networks:
        # LAN network
        - 192.168.1.0/24

        # Docker network
        - 172.16.0.0/12

    - name: openvpn
      networks:
        # OpenVPN subnet
        - 10.0.8.0/24

  rules:

    # Bypass 2FA when connected to VPN on pfSense or being connected to the LAN
    - domain:
      - ndd.tld
      - "*.ndd.tld"
      policy: bypass
      networks:
        - local
        - openvpn

    # Open public access
    - domain:
      - public.ndd.tld
      - public2.ndd.tld
      policy: bypass

    # Single authentication for applications lacking authentication system
    - domain: semi-private.ndd.tld
      policy: one_factor

    # 2FA for sensitive services
    - domain: private.ndd.tld
      policy: two_factor

NOTES :

• Dans la partie networks, on définit des alias pour faciliter la définition des règles et rendre moins fastidieuse leur rédaction.
• Dans la partie rules, je définis les sites qui auront un accès publique (sans protection supplémentaire que celle dont ils disposent déjà), ceux qui devront faire l'objet d'une simple authentification, et ceux qui doivent être soumis à la 2FA.
• Si l'accès à un sous-domaine vous est refusé sans raison, c'est qu'aucune des règles définies ne répond à la situation présente, dans ce cas Authelia rejette la demande (par le paramètre default_policy: deny).
• Vous pouvez temporairement ne pas mettre "*.ndd.tld" dans les domaines by-passés, le temps de mettre en route Authelia. Ou alors faire le test d'authentification depuis une connexion 4G.

6-C-3-g. session

session:
  ## The name of the session cookie.
  name: authelia_session
  [...]
  domain: ndd.tld

On pensera à renseigner le domaine racine qu'on souhaite protéger dans la valeur de la clé domain.
ATTENTION : Authelia ne peut pas protéger plusieurs domaines racines simultanément.

La mise en place de Redis est détaillée dans la partie Fonctionnalités avancées, on va s'en passer pour notre cas d'utilisation et commenter les paramètres qui y ont trait :

  ##
  ## Redis Provider
  ##
  ## Important: Kubernetes (or HA) users must read https://www.authelia.com/docs/features/statelessness.html
  ##
#  redis:
#    host: 127.0.0.1
#    port: 6379
    ## Use a unix socket instead
    # host: /var/run/redis/redis.sock

    ## Username used for redis authentication. This is optional and a new feature in redis 6.0.
    # username: authelia

    ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html
#    password: authelia

    ## This is the Redis DB Index https://redis.io/commands/select (sometimes referred to as database number, DB, etc).
#    database_index: 0

    ## The maximum number of concurrent active connections to Redis.
#    maximum_active_connections: 8

    ## The target number of idle connections to have open ready for work. Useful when opening connections is slow.
#    minimum_idle_connections: 0

6-C-3-h. storage

Depuis la version 4.33.0 d'Authelia, il est nécessaire de définir une clé de chiffrement (encryption key) pour éviter les corruptions de base de données.
C'est la chaîne de caractères définie dans le fichier encryption créé plus tôt (voir les prérequis ici : https://www.authelia.com/configuration/storage/introduction/#encryption_key)

storage:
  ## The encryption key that is used to encrypt sensitive information in the database. Must be a string with a minimum
  ## length of 20. Please see the docs if you configure this with an undesirable key and need to change it.
  encryption_key:

  ##
  ## MySQL / MariaDB (Storage Provider)
  ##
  mysql:
    host: 192.168.1.200
    port: 3307
    database: authelia
    username: authelia
    ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html
    password: 

Par défaut, Authelia suggère d'utiliser MySQL, ce que nous allons faire car le paquet MariaDB 10 est disponible dans le centre de paquets.
On spécifie l'IP virtuelle du NAS, ainsi que le port de MariaDB (3307 pour MariaDB 10).
On se connecte ensuite à phpMyAdmin (paquet) via le menu DSM avec le compte root, et on crée notre utilisateur :

On choisit un nom d'utilisateur, on reprend le mot de passe défini dans le fichier mysql créé précédemment et on coche "Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base."

On clique sur Exécuter en bas à droite de la page, si l'opération est un succès vous verrez le contenu de la requête affiché en vert dans le haut de la page. Notre base de données est maintenant prête à accueillir les données d'Authelia.

6-C-3-i. notifier

notifier:
  ## You can disable the notifier startup check by setting this to true.
  disable_startup_check: false
  [...]
  smtp:
    username: mail@ndd.tld
    ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html
    password: 
    host: ssl0.ovh.net
    port: 587
    sender: mail@ndd.tld
    ## HELO/EHLO Identifier. Some SMTP Servers may reject the default of localhost.
    identifier: localhost
    ## Subject configuration of the emails sent. {title} is replaced by the text from the notifier.
    subject: "[Authelia] {title}"
    ## This address is used during the startup check to verify the email configuration is correct.
    ## It's not important what it is except if your email server only allows local delivery.
    startup_check_address: mail@ndd.tld
    disable_require_tls: false
    disable_html_emails: false
  [...]
  ## Sending an email using a Gmail account is as simple as the next section.
  ## You need to create an app password by following: https://support.google.com/accounts/answer/185833?hl=en
  # smtp:
  #   username: myaccount@gmail.com
  #   ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html
  #   password: 
  #   sender: myaccount@gmail.com
  #   host: smtp.gmail.com
  #   port: 587
 

Authelia propose par défaut l'utilisation d'un SMTP externe (type OVH dans l'exemple ci-dessus) ou de passer par un compte Gmail. Dans ce dernier cas, pensez à autoriser les applications moins sécurisées dans les réglages de votre compte Google, sinon l'envoi de mails ne se fera pas.

7. Création et utilisation du code TOTP

Le plus dur est fait, il reste maintenant à se logger avec le compte qu'on a créé, on va sur la page https://authelia.ndd.tld (on s'assurera que l'entrée DNS de type A ou CNAME existe déjà, en local ou/et publique) :

On entre le nom de l'utilisateur, ici toto, et le mot de passe qu'on lui a attribué. On clique sur Sign In, on arrive sur la page suivante :

En cliquant sur Not registered yet?, un email sera envoyé à l'adresse renseignée pour l'utilisateur toto dans le fichier users_database.yml.
Dans ce mail, on clique sur l'hyperlien Register, qui nous amène à une page avec un QR-CODE. Si vous possédez déjà une application 2FA, il vous suffit de scanner le code.

Sinon vous pouvez suivre les liens pour Play Store et iOS. A titre personnel, j'utilise andOTP sur Fdroid, le store alternatif pour Android. Une fois le code ajouté dans l'application, il suffit de cliquer sur Done et on peut se connecter :

Si le code est bon, vous verrez le statut authentifié en vert, et vous serez redirigé vers la page que vous aviez précédemment définie dans default_redirection_url au point 6-C-3-d.

Maintenant, vous pouvez accéder à toutes vos applications en choisissant vous-même le curseur de sécurité. 😉 

8. Fonctionnalités avancées

8-A. Redis

A venir...

8-B. DuoAPI

A venir...

9. FAQ

Q : J'ai perdu le mot de passe de mon utilisateur, comment retrouver l'accès à mes sous-domaines ?
A : A l'écran de login, vous pouvez cliquer sur Reset password?.

Q : J'ai perdu mon code accès TOTP, que faire ?
A : Une fois loggé, vous pouvez cliquer sur Lost your device?. Vous recevrez alors un mail vous proposant un nouveau QR-CODE.

Q : Puis-je désactiver la possibilité pour les utilisateurs de récupérer leur mot de passe ?
A : Oui, il faut modifier la valeur de la clé disable_reset_password dans la section authentication_backend à true.

Q : J'obtiens une erreur 502 en accédant à mes entrées de proxy inversé, pourquoi ?
A : Il y a plusieurs raisons possibles, mais dans le cas présent il se peut que l'interface virtuelle du NAS ait disparu, suite à un arrêt, un redémarrage ou une mise à jour du paquet Docker. Vous avez normalement déjà mis en place un script qui permet de la recréer automatiquement au démarrage du NAS. Mais en cas de perte de l'interface il faudra simplement relancer la tâche manuellement depuis le planificateur de tâches.

Màj : 07/08/2023

Modifié le 7 août 2023 par .Shad.
ajout lien documentation 6-C-3-h

[Elusiveミッキー]

Je suis surpris que personne n'ait commenté ce tuto en plus d'un mois. Je voulais depuis longtemps utiliser Authelia, ce tuto me motive assez pour me lancer donc big thanks.

Je n'ai plus de NAS Synology et j'utilise Nxing Proxy Manager plutôt que SWAG donc j'aurai besoin de l'adapater un peu ma situation, mais la partie configuration d'Authelia est immensément utile (ce qui me faisait le plus "peur").

[.Shad.]

Hello, de rien. 😉

Dans la documentation d'Authelia il y a toute une partie dédiée à la configuration d'Nginx, et par extension j'imagine Nginx Proxy Manager.

Et si ta machine a ses ports HTTP et HTTPS libres, c'est plus simple d'utiliser le mode bridge que macvlan.

[Swagme]

Merci .Shad pour ce tuto. Je suis étonné aussi du peu de commentaire 😉

Je me suis lancé dans cette démarche, mais je rencontre des difficultés avec le serveur LDAP sur le NAS (LDAP Server sous DMS7).
(je me suis permis de le mettre ici, mais ça pourrait sans doute aussi aller sous le tuto sur le LDAP).

Ma configuration est un peu différente : j'ai un NAS (192.168.1.20) et un Raspberry pi (192.168.1.10), et c'est sur le Pi que je redirige toutes les requêtes des ports 80 et 443 du routeur. Ce Raspberry héberge le container SWAG (et aussi AdGuard Home pour info) pour gérer toute la partie reverse proxy. Celle-ci fonctionne (j'ai un certificat wildcard pour tout mon domaine chez OVH *.mondomaine.fr), et les redirections fonctionnent pour les autres services dans des containers sur le Pi (adguard.mondomaine.fr) ou sur le NAS (par ex. freshrss.mondomaine.fr) et aussi pour les appli natives du NAS (comme drive.mondomaine.fr).

Donc jusque là, tout semble ok.

Voulant installer Authelia, j'ai décidé de le déployer plutôt sur le Raspberry. J'ai donc déployé 3 autres containers MariaDB, Redis et Authelia (via Portainer, car je maitrise mal les commandes SSH) et les ai tous attaché à un "user_network" bridge appelé "swag_default".

(PS : au passage, j'ai fait ce déploiement via un docker-compose mais rédigé dans l'interface de Portainer, et pas moyen de faire se créer ce network, ou si je le crée avant, d'y attacher les containers à leur création. J'ai regardé sur la doc officiel de Docker compose, mais la syntaxe semble être pour les version 3 et suivantes, quand portainer-ce ne gère que la syntaxe v2. Si quelqu'un sait comment le rédiger, je veux bien apprendre).

Les 4 containers (SWAG, MariaDB, Redis et Authelia) communiquent entre eux (via le nom des container plutôt que les ip, puisqu'ils sont dans le même user_network).

Ensuite j'ai installé le serveur LDAP sur le NAS via le package officiel LDAP Server.
J'ai donné en nom FQDN "ldap.mondomaine.fr" (est-ce un problème ? je vois dans l'autre tuto sur LDAP un nom du genre ldap.local)
J'ai finalement créé sur SWAG un fichier de config redirigeant "ldap.mondomaine.fr" vers l'IP du NAS et le port 636 supportant le TLS (supposant que j'allais obtenir ainsi un certificat valide). 
EDIT : après lecture de différent article, il semble préférable de nommer son serveur truc.home
En effet cela fonctionne sous cette forme dans mon cas.

J'ai ouvert sur le parefeu du NAS le port 636. (je n'ai pas testé le port 389 non sécurisé).
J'ai finalement configuré les infos du serveur LDAP du NAS dans le fichier de configuration d'Authelia.

Et là ça coince.

Dans les logs d'Authelia, la connexion au LDAP semble refusée car mon serveur LDAP n'a pas de certificat valable (le message indique que le serveur a un certificat pour truc.synology.me mais pas pour ldap.mondomaine.fr).

QUESTION :

Faut-il que je copie/colle le certificat wildcard de SWAG du Pi vers le NAS pour que le NAS sache qu'il existe ?
(par exemple avec cette méthode, est-ce que je pourrai avoir mes certificats sur le Pi via SWAG, et en même temps sur le NAS ?)
Faut-il plutôt utiliser l'IP du NAS comme cible (mais là encore, j'aurai le message d'erreur car je n'aurai pas de certificat valide pour 192.168.1.20) ?
EDIT : puisque mes certificats pour mondomaine.fr sont gérés au niveau du Raspberry Pi via SWAG, j'ai configuré dans DSM un certificat moi.synology.me, et tous les services de Synology (dont le LDAP) utilise ce certificat.
Dans le fichier de configuration d'Authelia, j'ai donc indiqué ldaps://moi.synology.me comme serveur LDAP, et ça fonctionne (pas de message d'erreur dans les logs).
EDIT : Question qui reste valide ?
Est-ce que mon serveur LDAP n'est pas ouvert vers l'extérieur via ce réglage ? Je n'ai ni ouvert ni redirigé vers le NAS les ports LDAP 389 et 636, mais j'imagine que de passer par une adresse moi.synology.me rend quand même cela "visible" de l'extérieur ; est-ce un problème de sécurité ?

 

Merci d'avance pour votre aide.

 

PS : 2 questions subsidiaires au passage :
1- est-ce que quelqu'un a testé d'autres système d'authentification sur Synology, comme leur SSO server, ou peut être la nouvelle appli C2 Identity si elle propose cette fonctionnalité ?
2- est-ce qu'il y a une manière de convertir les utilisateurs locaux du NAS en utilisateurs LDAP ? EDIT : ça ne semble pas possible, et iol faut bien veiller à ne pas donner le même nom à un utilisateur local et à un du LDAP

Modifié le 1 octobre 2021 par Swagme
retours sur mes expérimentations

[.Shad.]

Il y a 6 heures, Swagme a dit :

Je me suis lancé dans cette démarche, mais je rencontre des difficultés avec le serveur LDAP sur le NAS (LDAP Server sous DMS7).
(je me suis permis de le mettre ici, mais ça pourrait sans doute aussi aller sous le tuto sur le LDAP).

Ma configuration est un peu différente : j'ai un NAS (192.168.1.20) et un Raspberry pi (192.168.1.10), et c'est sur le Pi que je redirige toutes les requêtes des ports 80 et 443 du routeur. Ce Raspberry  héberge le container SWAG (et aussi AdGuard Home pour info) pour gérer toute la partie reverse proxy. Celle-ci fonctionne (j'ai un certificat wildcard pour tout mon domaine chez OVH *.mondomaine.fr), et les redirections fonctionnent pour les autres services dans des containers sur le Pi (adguard.mondomaine.fr) ou sur le NAS (freshrss.mondomaine.fr) et aussi pour les appli natives du NAS (comme drive.mondomaine.fr).

Donc jusque là, tout semble ok.

Voulant installer Authelia, j'ai décidé de le déployer plutôt sur le Raspberry. J'ai donc déployé 3 autres containers MariaDB, Redis et Authelia (via Portainer, car je maitrise mal les commandes SSH) et les ai tous attaché à un "user_network" bridge appelé "swag_default".

(PS : au passage, j'ai fait ce déploiement via un docker-compose mais rédigé dans l'interface de Portainer, et pas moyen de faire se créer ce network, ou si je le crée avant, d'y attacher les containers à leur création. J'ai regardé sur la doc officiel de Docker compose, mais la syntaxe semble être pour les version 3 et suivantes, quand portainer-ce ne gère que la syntaxe v2. Si quelqu'un sait comment le rédiger, je veux bien apprendre. J'ajouterai ce soir la syntax utilisée pour ce stack).

Les 4 containers (SWAG, MariaDB, Redis et Authelia) semblent communiquer entre eux (via le nom des container plutôt que les ip, puisqu'ils sont dans le même user_network).

Jusque-là tout va bien en tout cas, c'est l'approche recommandée.
Il est beaucoup plus simple d'utiliser SWAG et Authelia sur un périphérique à part dont les ports HTTP et HTTPS ne sont pas utilisés comme tu l'as fait.

Il y a 6 heures, Swagme a dit :

Faut-il que je copie/colle le certificat wildcard de SWAG du Pi vers le NAS pour que le NAS sache qu'il existe ?
(par exemple avec cette méthode, est-ce que je pourrai avoir mes certificats sur le Pi via SWAG, et en même temps sur le NAS ?)
Faut-il plutôt utiliser l'IP du NAS comme cible (mais là encore, j'aurai le message d'erreur car je n'aurai pas de certificat valide pour 192.168.1.20) ?
Est-ce une bonne idée d'avoir son serveur LDAP ouvert vers l'extérieur via le reverse proxy ?

N'utilisant pas LDAP, je vais juste te faire part de ma réflexion.
Je ne suis pas certain que le domaine défini dans base_dn doive correspondre au domaine couvert par Authelia.
Par exemple, j'utilise le NDD fourni par Synology pour tous les services intrinsèques à DSM : Hyper Backup, Active Backup, FPTS, ... et je pense que LDAP doit en faire partie. Créer une entrée pour LDAP dans SWAG n'a donc à mon avis pas de sens car tu ne passes pas par le proxy inversé pour y accéder.

Soit tu utilises le domaine Synology, soit tu peux effectivement utiliser la méthode que tu as citée pour générer un autre certificat wildcard pour mondomaine.fr, ça ne gêne en rien, et te servir d'acme.sh pour le déployer dans DSM. Les deux sont aussi valables l'un que l'autre.

Pour revenir au fichier de configuration d'Authelia, dans "url" je mettrais le nom du NAS défini dans mon serveur DNS local. A défaut l'IP locale.
Je laisserais la vérification de certificat activée, cela dit tu peux toujours tester de la désactiver voir si la communication se fait bien.
Et dans base_dn et bien tu mets les dc correspondant au ndd utilisé pour le NAS.

Après je n'ai jamais utilisé LDAP, donc à prendre avec des grosses pincettes. 😉 

 

[Swagme]

Bonsoir .Shad. et merci pour tes réflexions.

Je commence par tenir ma parole, et poster la syntaxe que j'ai utilisée pour déployer ce stack via Portainer sur le Raspberry Pi. Si ça peut aider quelqu'un...

version: "2.1"
services:
  swag:
    image: linuxserver/swag:latest
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
      - URL=swagme.fr #ce n'est evidement pas le vrai domaine :-)
      - SUBDOMAINS=wildcard
      - VALIDATION=dns
      - DNSPLUGIN=ovh
      - CERTPROVIDER=letsencrypt
      - EMAIL=swagme@me.com
      - EXTRA_DOMAINS=dev.swagme2.fr,prod.swagme2.fr
      - MAXMINDDB_LICENSE_KEY=MJ*************
    volumes:
      - /home/pi/swag/config:/config
    ports:
      - 443:443
      - 80:80 #optional
    restart: unless-stopped
    depends_on:
      - authelia
      - authelia_mariadb
      - redis

  authelia:
    image: authelia/authelia
    container_name: authelia
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
    volumes:
      - /home/pi/authelia/config:/config
    ports:
      - 9091:9091
    restart: unless-stopped
    #healthcheck: #ne semble pas supporté par portainer et sa version 2.X de docker-compose
    #  disable: true
    depends_on:
      - authelia_mariadb
      - redis

  redis:
    image: redis:latest #un autre exemple s'appuye sur redis:alpine
    container_name: redis
    environment:
      - PUID=1000
      - PGID=1000      
      - TZ=Europe/Paris
    command: redis-server /usr/local/etc/redis/redis.conf
    volumes:
      - /home/pi/redis/data/redis.conf:/usr/local/etc/redis/redis.conf
      - /home/pi/redis/data:/data
    #ports:
    #  - 6379:6379
    expose:
      - 6379
    restart: unless-stopped


  authelia_mariadb:
    image: linuxserver/mariadb
    container_name: authelia_mariadb
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=f2b*********
      - TZ=Europe/Paris
      - MYSQL_DATABASE=authelia
      - MYSQL_USER=authelia-*******
      - MYSQL_PASSWORD=vB7Xa************
    volumes:
      - /home/pi/authelia_mariadb/config:/config
    ports:
      - 3306:3306
    restart: unless-stopped
    

De mon côté, je suis preneur de la manière de préciser le réseau (soit d'en créer un, soit de connecter les nouveaux containers créés à un réseau pré-existant).

Concernant tes réflexions, je vais m'y pencher après ce week end (là je manque de temps).
Merci en tout cas.

[oracle7]

@Swagme

Bonjour,

Très intéressant ton partage, merci. Comme çà, cela démystifie un peu plus la configuration à faire.🤗

J'aurais juste une remarque : tu utilises encore MariaDB v5 ? Si oui alors OK pour le port 3306. Mais si c'est MariaDB v10 alors sauf erreur de ma part, c'est le port 3307 qu'il faut utiliser avec cette version.

Sinon, et c'est juste pour comprendre car je ne connais pas Redis. Je crois comprendre que c'est un gestionnaire de couple (clé-valeur) aussi qu'elle utilisation peut-on en faire et quelle utilité de ce conteneur dans un environnement NAS ? C'est par exemple pour gérer des crédentials (Id, MdP) ? Merci de bien vouloir éclairer ma lanterne.

Cordialement

oracle7😉

[.Shad.]

@Swagme Pour les réseaux, tu ajoutes dans la définition d'un service ceux qu'il doit rejoindre :

service:

   exemple:
      name: ...
      [...]
      networks:
      - network1
      - network2
      - network3
      [...]

networks:

   network1:
   network2:
   network3:
      external: true

network1 et network2 sont des réseaux internes créés par docker-compose, network3 est un réseau défini de façon externe.
Autre remarque, tu n'as pas besoin de translater les ports autres que celui de SWAG. Car seul SWAG a besoin de contacter les autres conteneurs.

[Swagme]

Le 24/09/2021 à 12:17, oracle7 a dit :

@Swagme

Bonjour,

Très intéressant ton partage, merci. Comme çà, cela démystifie un peu plus la configuration à faire.🤗

J'aurais juste une remarque : tu utilises encore MariaDB v5 ? Si oui alors OK pour le port 3306. Mais si c'est MariaDB v10 alors sauf erreur de ma part, c'est le port 3307 qu'il faut utiliser avec cette version.

Sinon, et c'est juste pour comprendre car je ne connais pas Redis. Je crois comprendre que c'est un gestionnaire de couple (clé-valeur) aussi qu'elle utilisation peut-on en faire et quelle utilité de ce conteneur dans un environnement NAS ? C'est par exemple pour gérer des crédentials (Id, MdP) ? Merci de bien vouloir éclairer ma lanterne.

Cordialement

oracle7😉

Bonjour @oracle7, et de rien, j'ai profité de tellement de forum pour commencer à comprendre un peu Docker, alors si ça peut aider en retour (et surtout ne pas induire en erreur avec de mauvais conseils 😉

Concernant la version de MariaDB, je pense que c'est en effet une v10, car le container m'affiche ça :

build_version

Linuxserver.io version:- 10.5.12-r0-ls37 Build-date:- 2021-09-25T07:47:56+02:00

Maintenant concernant sa configuration, j'ai suivi simplement les indications de Linux Server io, et ils mentionnent bien le port 3306. Mais je suis preneur d'info pour corriger ça si besoin.

Car c'est possible que la connexion se fasse via le port 3307 même si je ne l'expose pas "officiellement" dans mes variables docker-compose, car si j'ai bien compris, en appartenant tous au même "user_network", tous les ports sont ouverts entre ces containers, exact ? 
D'où ta remarque @.Shad.de dire que je pourrai uniquement spécifier les ports dans le service SWAG et supprimer cette indication pour les autres services.

 

Le 24/09/2021 à 16:11, .Shad. a dit :

network1 et network2 sont des réseaux internes créés par docker-compose, network3 est un réseau défini de façon externe.

Concernant ce point (merci pour l'explication !), qu'entends-tu exactement par "réseau défini de façon externe" ? Cest par exemple le cas de mon "user_network" appelé "swag_default" que j'avais créé avant le stack via l'interface de Portainer ? Je pourrai donc mettre ça dans mon cas :

service:

   exemple:
      name: ...
      [...]
      networks:
      - swag_default
      [...]

networks:

   swag_default:
      external: true

Merci de ta confirmation 😉

 

Sinon pour finir sur Redis, j'ai compris de mon côté (mais sans avoir creusé très longtemps) que c'est un outil de mise en cache de certaines infos.
Là encore, il est recommandé sur la doc d'Authelia, et il fait aussi parti des template de Portainer, donc facile à déployer dans un stack ou dans un container unique.

[.Shad.]

@Swagme @oracle7 Le port 3307 c'était juste sur DSM car cohabitaient MariaDB 5 et 10, et le 5 utilisait par défaut le port 3306.

il y a 5 minutes, Swagme a dit :

D'où ta remarque @.Shad.de dire que je pourrai uniquement spécifier les ports dans le service SWAG et supprimer cette indication pour les autres services.

Oui, tous les ports sont visibles d'un conteneur à l'autre.

il y a 5 minutes, Swagme a dit :

Concernant ce point (merci pour l'explication !), qu'entends-tu exactement par "réseau défini de façon externe" ? Cest par exemple le cas de mon "user_network" appelé "swag_default" que j'avais créé avant le stack via l'interface de Portainer ? Je pourrai donc mettre ça dans mon cas :

Oui.

[Swagme]

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 😞

Modifié le 30 septembre 2021 par Swagme
(correction faute)

[Swagme]

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.

[.Shad.]

@Swagme Concernant ta configuration access control d'Authelia, pour moi elle est ok, hormis 2 remarques :

• Je ne vois pas pourquoi tu mets ton IP publique fixe dans le réseau internal
• L'ordre a son importance, je vois que as trié dans le sens bypass -> two_factor, je te conseillerais de trier plutôt par network. Donc dans ton cas d'abord ce qui prend origine dans le réseau "internal" puis le reste, avec en seconde règle de tri la règle appliquée actuellement.

On est d'accord que tu souhaites utiliser un accès 2FA que tu sois en interne ou en externe ? car c'est ce qu'implique ta configuration actuelle.

Il y a 9 heures, Swagme a dit :

Au passage, avant de me lancer dans l'installation d'Authelia, j'avais configurer le fichier internal.conf de Nginx Swag.

Je n'ai pas trouvé ce fichier. Il se situe où ?

Il y a 9 heures, Swagme a dit :

j'ai jeter un oeil au fichier resolver.conf de Nginx Swag :

Est-ce que Adguard serait en mode host sur ton NAS ? Si tu pouvais mettre une impression d'écran de ton fichier adguard.subdomain.conf ? Et éventuellement du docker-compose d'Adguard (ou simplement dire comment il est configuré, si tu utilises un autre moyen) ?

Il y a 9 heures, Swagme a dit :

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).

On dirait que plusieurs problèmes se cumulent, les délais à rallonge font penser à des soucis liés au DNS, mais l'erreur 500 à un problème de configuration de SWAG, pas d'Authelia.

Il y a 9 heures, Swagme a dit :

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

C'est le fichier /etc/resolv.conf de quoi ?
Car là tu as juste une résolution publique, le serveur DNS local n'est pas exploité (sauf en IPv6).

[Swagme]

@.Shad.,je réponds point par point :

Il y a 11 heures, .Shad. a dit :

• Je ne vois pas pourquoi tu mets ton IP publique fixe dans le réseau internal
• L'ordre a son importance, je vois que as trié dans le sens bypass -> two_factor, je te conseillerais de trier plutôt par network. Donc dans ton cas d'abord ce qui prend origine dans le réseau "internal" puis le reste, avec en seconde règle de tri la règle appliquée actuellement.

On est d'accord que tu souhaites utiliser un accès 2FA que tu sois en interne ou en externe ? car c'est ce qu'implique ta configuration actuelle.

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.

 

Il y a 11 heures, .Shad. a dit :

Je n'ai pas trouvé ce fichier. Il se situe où ?

Là j'ai suivi les recommandations ici : il s'agit d'un fichier à générer (il n'est pas existant par défaut.

Il y a 12 heures, .Shad. a dit :

Est-ce que Adguard serait en mode host sur ton NAS ? Si tu pouvais mettre une impression d'écran de ton fichier adguard.subdomain.conf ? Et éventuellement du docker-compose d'Adguard (ou simplement dire comment il est configuré, si tu utilises un autre moyen) ?

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 :

Il y a 12 heures, .Shad. a dit :

On dirait que plusieurs problèmes se cumulent, les délais à rallonge font penser à des soucis liés au DNS, mais l'erreur 500 à un problème de configuration de SWAG, pas d'Authelia.

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. 😞

[.Shad.]

A partir du moment où tu utilises SWAG, je te conseillerais de créer un réseau bridge personnalisé comprenant SWAG et les applications qui peuvent être "reverse proxi-ées", exemple :

Et dans net-proxy, qui est mon réseau où je mets toutes les applications sensées être accessibles par proxy inversé :

SWAG devant communiquer avec redis également, il est aussi dans un deuxième réseau "net-db" qui contient swag et redis (j'utilise MariaDB du NAS).

Pour ton problème, je t'avoue qu'à distance comme ça c'est un peu compliqué.
Je pense que le problème est ailleurs. Il faudrait qu'on puisse se faire un Teamviewer.

[Swagme]

@.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 😞

 

Modifié le 2 octobre 2021 par Swagme
(correction nom d'un fichier)

[oracle7]

@Swagme

Bonjour,

Il y a 1 heure, Swagme a dit :

Je te pose l'éventuelle question dans cet autre fil. Désolé de m'éparpiller à ces 2 endroits

Comme personnellement j'essaie de suivre vos échanges qui m'intéressent vivement, c'est vrai que jongler entre les deux fils, ne rend pas facile la compréhension de ce sujet qui est loin d'être simple et évident. Je suis personnellement bien content de ton intervention car indirectement, tes questions et les réponses de @.Shad. répondent à certaines de mes interrogations, non pas que le TUTO de @.Shad. ne soit pas clair, bien au contraire mais comme j'envisage de mettre en place une solution similaire à la tienne, j'entends bien comprendre auparavant tous les tenants et aboutissants avant de me lancer effectivement car il y a encore bon nombres (trop !) de points que je ne maîtrise pas et pour lesquels il me faut encore apprendre.

Aussi, je me permet de te demander si tu pouvais STP rester dans le présent fil, ce serait une bonne chose pour tous ceux qui comme moi voudraient se lancer, non ?

Merci de ta compréhension et n'y voit aucun mal/reproche de ma part quant à ma demande ...😋

Cordialement

oracle7😉

Modifié le 2 octobre 2021 par oracle7

[.Shad.]

@Swagme Je pense que tu devrais dans un premier temps effectivement créer une entrée de proxy inversé pour Authelia.
Ensuite si tu peux mettre une impression d'écran de :

docker ps

Et éventuellement m'envoyer en MP le contenu de ton fichier configuration.yml d'Authelia.

Modifié le 3 octobre 2021 par .Shad.

[Swagme]

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...

[.Shad.]

Il y a 11 heures, Swagme a dit :

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)

Ca dit que tu ne dois pas, a priori, modifier authelia.subfolder.conf, mais tu peux très bien configurer authelia.subdomain.conf.
Je pense comme toi que le problème doit être ailleurs. Dans le MP que tu m'as envoyé je vois une indentation décalée dans les access control, je ne sais pas si ça vient du c/c ?

Il y a 11 heures, Swagme a dit :

- domain:
        - accueil.mondomaine.fr
        - rss.mondomaine.fr
        - media.mondomaine.fr
        - drive.mondomaine.fr
      policy: one_factor
      networks:
        - internal

Normalement, les "-" des domaines sont alignés avec policy, networks, etc...
Les fichiers yaml sont susceptibles à l'indentation. 😄

J'ai peut-être une idée, essaie de passer adguard.mondomaine.fr dans le bloc cité ci-dessus, et passe la policy à "bypass", pour tester si ça fonctionne déjà.

Modifié le 6 octobre 2021 par .Shad.

[Swagme]

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;

 

[.Shad.]

Essaie parallèlement de :

• créer une entrée de proxy inversé pour authelia
• ajouter un bypass pour tous tes domaines en interne (commenter toute ta config "rules" actuelle)

  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

• redémarrer le conteneur

Modifié le 6 octobre 2021 par .Shad.

[Swagme]

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 ?

il y a 12 minutes, .Shad. a dit :

Essaie parallèlement de :

• créer une entrée de proxy inversé pour authelia
• ajouter un bypass pour tous tes domaines en interne (commenter toute ta config "rules" actuelle)

  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

• redémarrer le conteneur

ok, je teste ça et reviens éditer ici dans 5 min. Merci de ton aide 🙂

[Swagme]

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

 

[Swagme]

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 ?)

Modifié le 6 octobre 2021 par Swagme