This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

.Shad.

Membres
  • Compteur de contenus

    4 372
  • Inscription

  • Dernière visite

  • Jours gagnés

    84

.Shad. a gagné pour la dernière fois le 6 septembre

.Shad. a eu le contenu le plus aimé !

À propos de .Shad.

Mon Profil

  • Pays / Ville
    Belgique - Nivelles
  • Mon NAS
    DS918+

Visiteurs récents du profil

5 417 visualisations du profil

.Shad.'s Achievements

Proficient

Proficient (10/14)

  • Conversation Starter Rare
  • Reacting Well Rare
  • Dedicated Rare
  • Very Popular Rare
  • First Post Rare

Recent Badges

395

Réputation sur la communauté

  1. 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. 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.
  2. Pour éviter toute attaque avec l'utilisateur admin, il te suffit de le désactiver. Et d'en créer un autre, avec un bon gros mot de passe des familles, et un nom d'utilisateur plus compliqué et moins évident que "admin".
  3. .Shad.

    [TUTO] Docker : Introduction

    Et du côté du pare-feu est-ce que tu autorises bien le sous-réseau 172.17.0.0 à communiquer avec le NAS ? Car ça expliquerait tous tes problèmes. Une impression d'écran du pare-feu si tu n'es pas sûr. PS : Ca va il ne s'est pas contenté de te dire de mettre en host, je suis (un peu) rassuré.
  4. .Shad.

    [TUTO] Docker : Introduction

    Les interfaces avec une IPv4 dans la plage 172.16.0.0/12 (de 172.16.0.0 à 172.31.255.255) sont les portes d'entrée/sortie des réseaux bridge avec le reste du monde. La docker3b0 correspond à l'interface d'appairage des conteneurs. Ce qui t'intéresse c'est le premier type. 172.17.0.1 représente le NAS dans le réseau bridge par défaut. 172.18.0.1 à 172.31.0.1 représentent le NAS dans les réseaux personnalisés. Ce sont les interfaces de passerelle que tu retrouves dans les logs de ton conteneur icloud. Dans les faits oui, ça revient à ça, mais Docker a son propre système de résolution interne. Normalement tu n'as rien à configurer. Si tu tapes la commande suivante en SSH : docker exec -it icloudpg cat /etc/resolv.conf Tu devrais avoir comme nameserver l'adresse 127.0.0.1 ou 127.0.0.11 D'ailleurs tu peux aussi tester la commande suivante : docker exec -it icloudpg nslookup www.google.fr Et poster le résultat. Pas sûr que la commande soit disponible dans l'image. 2 (3) autres questions : 10.0.1.1 correspond à l'IP locale du routeur ou de la box de ton réseau local ? Si tu recrées le conteneur et que tu ajoutes la ligne suivante dans le script, dis-moi si ça fonctionne : --dns 127.0.0.1 Si pas tu modifies la ligne précédente comme suit, tu recrées le conteneur et tu me dis ce qu'il en est : --dns 80.67.169.12
  5. .Shad.

    [TUTO] Docker : Introduction

    C'est la solution de facilité, car en fait ce n'est pas une solution. Je suis toujours étonné que des gens du métier se contentent de proposer de faire ça. On perd une partie de l'intérêt d'isolation de Docker en host, on ne le fait généralement que pour de bonnes raisons (problème de NAT, nécessité de broadcast sur le réseau physique). Le réseau bridge utilise la résolution DNS de l'hôte, tu devrais investiguer du côté de ton pare-feu et t'assurer que tu autorises a minima les requêtes DNS (port 53) depuis le sous-réseau 172.17.0.0/255.255.0.0. Dans ton cas il n'y aura aucune différence de fonctionnement entre réseau bridge par défaut et réseau personnalisé (user-defined bridge), les différences sont listées dans mon tutoriel introductif en signature. Car sinon c'est normal que le résolveur DNS renvoie un timeout. En host tu es sur l'IP du NAS, donc le pare-feu n'entre pas en compte (par défaut les requêtes de 127.0.0.1 sont autorisées).
  6. Tu peux aussi te connecter par socket distant, c'est même plus sécurisé (mais moins rapide à mettre en place que l'agent, et on ne peut pas parcourir les volumes distants). Voir mon tutoriel : https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/ https://www.nas-forum.com/forum/topic/71875-tuto-docker-authelia-serveur-dauthentification/ Oublie SSO de Synology, c'est une usine à gaz (tu trouveras juste un tutoriel à ce sujet sur le net, c'est de l'alpha ce paquet rien de mieux). Pas encore actif aux dernières nouvelles, je suis assez dubitatif personnellement. Et ce n'est pas auto-hébergé. Si je perds ma clé 2FA avec Authelia, il me suffit de le désactiver dans SWAG. Je ne perds rien.
  7. L'utilisateur "admin" appartient au groupe administrators qui donne par défaut tous les droits sur tous les dossiers. Mais il appartient aussi au groupe "user". Si tu mets des interdictions à ce groupe, l'utilisateur admin sera bloqué sur ce même dossier, car les interdictions prennent le pas sur tout le reste au sein des groups d'un utilisateur. Ca peut être une explication au problème que tu as rencontré.
  8. .Shad.

    Pour ne pas mourir idiot ;-)

    Les jours gagnés correspondent au nombre de jours où tu as eu le contenu le plus aimé.
  9. @Ricola62 Généralement, dans ce genre de cas, les créateurs d'image intègrent effectivement un conteneur nginx en frontend dans leur image. Ce conteneur fait office de proxy inversé au sein de l'application, ainsi la personne qui utilise un proxy inversé en amont de ton application redirigera toutes ses requêtes vers un seul et unique port, par exemple 80. Avoir un proxy inversé dans ton application évite à l'utilisateur qui souhaite utiliser son proxy inversé de rediriger vers des ports différents suivant les blocs location. Tu peux t'inspirer de ce que fait Bitwarden (officiel), c'est exactement ce qu'ils utilisent : Au sein de leur application : server { listen 8080 default_server; listen [::]:8080 default_server; server_name bitwarden.xxx.ovh; include /etc/nginx/security-headers.conf; set_real_ip_from 10.0.0.0/8; set_real_ip_from 172.16.0.0/12; set_real_ip_from 192.168.0.0/16; set_real_ip_from fd00:abcd::/32; real_ip_header X-Forwarded-For; real_ip_recursive on; location / { proxy_pass http://web:5000/; include /etc/nginx/security-headers.conf; add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://haveibeenpwned.com https://www.gravatar.com; child-src 'self' https://*.duosecurity.com https://*.duofederal.com; frame-src 'self' https://*.duosecurity.com https://*.duofederal.com; connect-src 'self' wss://bitwarden.aelnas.ovh https://api.pwnedpasswords.com https://twofactorauth.org; object-src 'self' blob:;"; add_header X-Frame-Options SAMEORIGIN; add_header X-Robots-Tag "noindex, nofollow"; } location /alive { return 200 'alive'; add_header Content-Type text/plain; } location = /app-id.json { proxy_pass http://web:5000/app-id.json; include /etc/nginx/security-headers.conf; proxy_hide_header Content-Type; add_header Content-Type $fido_content_type; } location = /.well-known/assetlinks.json { proxy_pass http://web:5000/assetlinks.json; include /etc/nginx/security-headers.conf; proxy_hide_header Content-Type; add_header Content-Type application/json; } location = /duo-connector.html { proxy_pass http://web:5000/duo-connector.html; } location = /u2f-connector.html { proxy_pass http://web:5000/u2f-connector.html; } location = /webauthn-connector.html { proxy_pass http://web:5000/webauthn-connector.html; } location = /webauthn-fallback-connector.html { proxy_pass http://web:5000/webauthn-fallback-connector.html; } location = /sso-connector.html { proxy_pass http://web:5000/sso-connector.html; } location /attachments/ { proxy_pass http://attachments:5000/; } location /api/ { proxy_pass http://api:5000/; } location /icons/ { proxy_pass http://icons:5000/; } location /notifications/ { proxy_pass http://notifications:5000/; } location /notifications/hub { proxy_pass http://notifications:5000/hub; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; } location /events/ { proxy_pass http://events:5000/; } location /sso { proxy_pass http://sso:5000; include /etc/nginx/security-headers.conf; add_header X-Frame-Options SAMEORIGIN; } location /identity { proxy_pass http://identity:5000; include /etc/nginx/security-headers.conf; add_header X-Frame-Options SAMEORIGIN; } location /admin { proxy_pass http://admin:5000; include /etc/nginx/security-headers.conf; add_header X-Frame-Options SAMEORIGIN; } location /portal { proxy_pass http://portal:5000; include /etc/nginx/security-headers.conf; add_header X-Frame-Options SAMEORIGIN; } } Nginx écoute sur le port 8080 et renvoie vers différents conteneurs composants l'application suivant le path demandé. Dans mon proxy inversé sur l'hôte : server { listen 443 ssl; listen [::]:443 ssl; server_name bitwarden.*; include /config/nginx/ssl.conf; client_max_body_size 128M; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app bitwarden-nginx; set $upstream_port 8080; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } Toutes mes requêtes sont redirigées vers le conteneur nginx sur le port d'écoute. Pas de double chiffrement SSL. Je ne sais pas si ça t'aide...
  10. .Shad.

    [TUTO] Docker : Introduction

    @Geoff1330 Tu n'as pas effacé un message concernant la résolution DNS ? je l'ai vu hier soir mais j'étais déjà couché, je comptais y répondre ce matin.
  11. .Shad.

    Bonjour la communauté

    Bienvenue parmi nous !
  12. .Shad.

    Bonjour Tout Le Monde

    @pluton212+ 2014
  13. Tu le recycles en NAS de sauvegarde. Ça conviendra parfaitement.
  14. .Shad.

    Bien le bonjour

    Bienvenue parmi nous !