Aller au contenu

Messages recommandés

Posté(e)
il y a 27 minutes, MilesTEG1 a dit :

ha non parce je ne pensais pas que ça serait utile.

Ce que tu as fait c'est uniquement une étape supplémentaire pour introduire une exception dans le mécanisme de défense de Bitwarden.

Ca n'aura jamais aucun impact si tu n'ajoutes pas un subfilter. Et dans le script, vu que Vaultwarden n'est pas explicitement mentionné dans les apps supportées par Theme-park, laisse bitwarden pour voir.

Posté(e)
il y a 43 minutes, .Shad. a dit :

Ce que tu as fait c'est uniquement une étape supplémentaire pour introduire une exception dans le mécanisme de défense de Bitwarden.

Ca n'aura jamais aucun impact si tu n'ajoutes pas un subfilter. Et dans le script, vu que Vaultwarden n'est pas explicitement mentionné dans les apps supportées par Theme-park, laisse bitwarden pour voir.

Heu j'ai pas tout suivi là XD Tu veux que je laisse bitwarden où ?

 

J'ai tenté de mettre les lignes dans les autres location, mais même topo, ça fonctionne pas. 😅 Bon je vais laisser tomber... J'ai ouvert une issue sur le GH de theme.park, on verra si j'ai une réponse un jour...

Posté(e)
Il y a 1 heure, MilesTEG1 a dit :

Heu j'ai pas tout suivi là XD Tu veux que je laisse bitwarden où ?

:

set $app bitwarden

 

  • 1 mois après...
Posté(e)

Génial merci pour cette découverte !

A chaque fois je galéré pour héberger mes applications, obligé de se rappeler des ports de chaque. Maintenant c'est de l'histoire ancienne. 

Plus que 2 ports à ouvrir est c'est fini.

Me reste une chose que j'ai pas bien compris et que je n'ai pas encore réussi.

Comment faire pour transférer un port autre que pour du http ? (surtout pour drive et sont port 6690). J'ai suivi la technique de @MilesTEG1 a savoir créer un sous domaine spécifique pour drive et mapper le port 6690 à la place de 443.

Mais sois j'ai pas compris une particularité sois ça ne fonctionne pas.

port 6690 ouvert et redirigé sur le container, port ouvert sur le container, fichier de configuration qui redirige sur DSM avec le port 6690.
Echec de la connexion sur drive.

Merci

Posté(e)
Il y a 1 heure, cmathias a dit :

Comment faire pour transférer un port autre que pour du http ? (surtout pour drive et sont port 6690). J'ai suivi la technique de @MilesTEG1 a savoir créer un sous domaine spécifique pour drive et mapper le port 6690 à la place de 443.

Mais sois j'ai pas compris une particularité sois ça ne fonctionne pas.

port 6690 ouvert et redirigé sur le container, port ouvert sur le container, fichier de configuration qui redirige sur DSM avec le port 6690.
Echec de la connexion sur drive.

Il ne faut pas faire passer les connexions vers le drive (sur port 6690) par le conteneur SWAG, ça ne fonctionnera pas. Il faut envoyer directement sur le NAS lui-même.

Depuis l'extérieur, c'est hyper facile : il faut juste que le port 6690 soit rediriger dans la box vers l'IP du NAS, et non pas l'IP du conteneur SWAG.
En revanche pour un accès depuis le LAN, il faut faire une réécriture DNS dédiée à la sychronisation Drive (dans AdGuard Home, Pi-Hole, ou le serveur DNS (paquet DNS Server, zone locale du NAS). Sinon point de salut.
J'ai ça comme réécriture DNS dans mon AdGuard Home :
OjJoFU5.png

la première entrée, réécrit toutes les URL de mes noms de domaines vers l'IP LAN de SWAG (je l'ai mis en macvlan), et la seconde entrée réécrit le domaine spécial pour la synchronisation de Drive (donc pour les clients desktop) qui réécrit vers l'IP du NAS lui-même.

En revanche, pour l'accès via navigateur au Drive, là ça passer par le reverse proxy, et mon .conf est
 

## Version 2021/05/18
# make sure that your dns has a cname set for <container_name> and that your <container_name> container is not using a base url
# Note for DSM Applications (Package)
# As SWAG is installed in macvlan mode, you have to set the virtual IP for $upstream_app
#       set $upstream_app 192.168.2.230

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name drv.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    #include /config/nginx/authelia-server.conf;

    # GeoIP Blocking with Maxmind Docker-MOD
    include /config/nginx/maxmind-geoblock_and_LAN.conf;

    # Custom error pages
    include /config/nginx/error_pages.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 192.168.2.230;
        set $upstream_port 12345;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;


    }


}

 

Posté(e) (modifié)

Y a t'il une autre solution pour faire du port forwarding ?

Je rentre un peut dans le détail :

J'ai une ligne fibre + 4G. 
Pour que mon domaine soit toujours accessible j'ai monté un VPN et pointé mon domaine sur mon VPN qui fait du port forwarding vers mon réseau. 
Le problème c'est que le NAS n'étant pas connecté au VPN je ne peux pas lui faire transiter directement les ports que j'ai besoin. 

Il me faut donc une autre passerelle (même si autre que swag) pour le connecter au vpn. 

Je sais que je pourrais connecter directement le NAS sur le VPN mais j'aime bien les défis.

------------------

Une autre question, comment avez-vous fait pour que votre domaine racine pointe vers DSM et pas sur la page d'accueil de swag ?

-----------------

EDIT : J'étais en train d'avancer sur mes sous domaines et je suis confronté à un souci.

Je n'arrive pas à atteindre l'ip du RPI qui héberge swag mais j'ai aucun souci sur le reste du réseau local.
J'ai juste adapté mon subnet 

Avez-vous déjà vu ça ?

docker network create -d macvlan --subnet=192.168.1.0/24 --ip-range=192.168.1.144/29 --gateway=192.168.1.1 -o parent=eth0 macvlan_net

version: '2.1'
services:

   swag:
       image: linuxserver/swag
       container_name: swag
       networks:
          macvlan_net:
             ipv4_address: 192.168.1.145
       cap_add:
          - NET_ADMIN
       environment:
          - PUID=1026
          - PGID=100
          - TZ=Europe/Paris
          - URL=mon-domaine
          - SUBDOMAINS=sous-domaine,
          - VALIDATION=http
          - DHLEVEL=2048
          - EMAIL=cmathias@cloudcaradoc.com
          - ONLY_SUBDOMAINS=false
          - STAGING=false
       volumes:
          - /var/lib/docker/volumes/swag/_data:/config
       restart: unless-stopped

networks:

   macvlan_net:
      external: true

 

Modifié par cmathias
Posté(e) (modifié)

Drive ne peut passer par un proxy inversé HTTP, le NAS doit être atteint directement.
Ou alors il faut un proxy TCP, comme HAProxy, mais on est sur un cran au-dessus en terme d'apprentissage.
Si tu ne veux pas que le NAS soit connecté à ton serveur VPN, la solution c'est de mettre en place un VPN site-à-site, mais c'est autrement plus compliqué.

Pour ton problème d'IP inatteignable, pourquoi avoir mis SWAG en macvlan sur un Rpi ? tu utilises déjà les ports 80/443 dessus ? Macvlan c'est bien quand les ports de l'hôte sont déjà occupés et pas transférables, mais c'est se compliquer inutilement la tâche si les ports sont disponibles, un simple bridge est alors bien plus facile à gérer.

Modifié par .Shad.
  • 3 mois après...
Posté(e)

Bonjour par ici 🙂

Ce qui suit va s'adresser aux utilisateurs de Fail2Ban.

Pourriez-vous essayer de vous faire bannir une IP (via 4G de préférence puisque mes tests sont fait depuis une IP 4G sur mon smartphone), et voir si via cette IP bannie vous continuez à accéder aux services du NAS ?

Car moi, bien que l'adresse soit marquée comme bannie par F2B (email de bannissement reçu), IP dans la jail, et ip présente dans iptable du NAS, je continue à pouvoir accéder aux services du NAS via cette adresse ip...

Par exemple, je me suis fait bannir volontairement en accédant à gitea depuis mon smartphone en 4G :

3D7yRUV.png

Sauf que j'accède toujours à Gitea depuis ce même smartphone, et son IP n'a pas changé.

Je tente calibre-web, je fais exprès de me planté de login/mdp, et paf, banni.
KjVozE3.png

Mais j'accède toujours à calibre-web, gitea, et tous les autres services qui passent par Swag.

Je me dois de préciser que mon fail2ban est celui d'une image dédiée, pas celui intégré à SWAG.
Aussi, si votre F2B intégré à swag fonctionne encore normalement, je créerais un nouveau sujet dédié à mon souci.

Pour qu'apparaissent l'IP et le DROP dans le iptables, j'ai du suivre ceci : https://github.com/sosandroid/docker-fail2ban-synology/issues/6
(Renommer le fichier (que j'avais déjà depuis le début) :

.../action.d/iptables-common.local

en :

.../action.d/iptables.local

 

Posté(e) (modifié)

Tu as bien ajouté les capacités NET_ADMIN et NET_RAW ?

PS : Ton image semble devoir fonctionner avec des privilèges élevés, alors qu'elle est basée sur celle de Crazymax, qui n'en a pas besoin.

C'est tout l'intérêt d'ajouter les "cap", c'est de ne pas avoir de conteneurs avec privilèges.
A ta place je regarderais à switcher sur autre chose.

Pourquoi pas utiliser Crowdsec au passage ?

Modifié par .Shad.
Posté(e)
Il y a 1 heure, .Shad. a dit :

Tu as bien ajouté les capacités NET_ADMIN et NET_RAW ?

Oui c’est bien présent dans mon docket-compose .

Il y a 1 heure, .Shad. a dit :

PS : Ton image semble devoir fonctionner avec des privilèges élevés, alors qu'elle est basée sur celle de Crazymax, qui n'en a pas besoin.

C’est l’image même de crazy-max que j’utilise.

Il y a 1 heure, .Shad. a dit :

Pourquoi pas utiliser Crowdsec au passage ?

Il est déjà installé et configuré pour une partie des noms de domaines. Mais c’est beaucoup trop sensible pour certains services où je me fais bannir dès que j’accède à une page.

 

Posté(e)
il y a 13 minutes, MilesTEG1 a dit :

C’est l’image même de crazy-max que j’utilise.

Ok je pensais que tu utilisais l'image dont tu as donné le lien Github. 😉 

Malheureusement je n'utilise plus Fail2ban avec Swag, uniquement Crowdsec, je pourrais pas t'aider. 😞 

Posté(e)
Le 10/02/2023 à 13:27, MilesTEG1 a dit :

Pour qu'apparaissent l'IP et le DROP dans le iptables, j'ai du suivre ceci : https://github.com/sosandroid/docker-fail2ban-synology/issues/6

Il n'y a pas d'image Docker dans ce dépôt 🙂

il y a une heure, .Shad. a dit :

Malheureusement je n'utilise plus Fail2ban avec Swag, uniquement Crowdsec, je pourrais pas t'aider. 😞 

Tu as définitivement abandonné Fail2ban au profit de Crowdsec ?

Peut-on discuter de Crowdsec ici ? Ou mieux vaut-il créer un sujet dédié ? (et dans quelle section ?)

Car j'ai quelques questions 😉 

Posté(e) (modifié)

Moi j'ouvrirais un autre sujet, car je n'aborde pas ce logiciel dans le tutoriel.

Peut-être section Docker ? Ou Linux ?

Modifié par .Shad.
Posté(e)
il y a 39 minutes, .Shad. a dit :

Moi j'ouvrirais un autre sujet, car je n'aborde pas ce logiciel dans le tutoriel.

Peut-être section Docker ? Ou Linux ?

Ok 👍🏻 

j’irais ouvrir un nouveau sujet sur Crowdsec dans la section docker.

et je te citerais 😊

  • 1 mois après...
Posté(e)

Hello 👋🏻 @.Shad.

J'avance dans mon projet d'augmentation de débit de transfert avec les NAS avec un reseau 2,5Gbps.
Actuellement j'ai mis un switch Asustor ASW205T (5 ports) pour raccorder le Syno DS920+ via un adaptateur 2,5G USB-A<->ETH (Club3D) et l'Asustor AS6704T qui est lui nativement en 2,5Gbps. Dessus sont raccordés aussi mon MBA et l'iMac de ma femme, les deux via deux adaptateurs 2,5G USB-C<->ETH (Asustor AS-U2.5G2 pour mon MBA et Asustor AS-U2.5G pour l'iMac).

Le tout fonctionne parfaitement maintenant, les débits sont bien au rendez-vous. (voir le sujet "passer son réseau en 2,5Gbits" de @Jeff777 )

Ce qui m'amène à poster ici c'est surtout ce qui va découler de mon installation : la désactivation de l'interface eth0 qui me sert actuellement pour le reseau macvlan et l'interface virtuelle pour SWAG.

Ma question pour toi, @.Shad., et aux autres qui suivent et lisent ce sujet si vous savez, c'est comment je passe de l'interface eth0 à eth2 sans tout casser ? Car changer les valeurs dans les 2 scripts, ce n'est pas dur :

  • le script de création du réseau macvlan, lancé une seule fois
  • le script de création de l'interface virtuelle, lancé à chaque (re)-démarrage du NAS.

Du coup, tu ferais comment @.Shad. ?
Car modifier un réseau macvlan ne me parait pas possible comme ça... si ?

Mes deux conteneurs qui utilisent le réseau macvlan ont comme configuration ceci :

networks:
  macvlan-network:        # Ce réseau devra bien entendu être créé avant avec le script
    external: true

Voilà ce que j'imagine de faisable :

  1. Arrêter les deux conteneurs (SWAG et AdGuard Home) utilisant le macvlan ? 
    Et là j'ai plusieurs possibilités via portainer : (exemple avec SWAG ci-dessous)
    ckmIzXG.png
    • Option 1 : je stoppe les deux stacks
    • Option 2 : je supprime purement la stack (faudra la recréer de zéro après)
    • Option 3 : je stoppe les conteneurs dans les deux stacks
    • Option 4 : je supprime les conteneurs dans les deux stacks (à quelque chose près, c'est la même chose que l'option 2, non ?)
  2. Je supprime l'interface virtuelle (j'ai les commandes suivantes (commentées dans mon scripts) :
    # Anti-commandes des précédentes :
    # ip route del 192.168.2.210/32 dev macv0
    # ip link set macv0 down
    # ip link delete dev macv0 address 5E:11:87:DD:DD:DD
    # ip addr del 192.168.2.230/32 dev macv0

    Ça devrait le faire non ?

  3. Ensuite je supprime le réseau macvlan ;
    Faut-il redémarrer le NAS ?
  4. Je le recrée ensuite le réseau macvlan sur interface eth2, puis l'interface virtuelle ;
  5. Et enfin je relance/recréé les stacks/conteneurs.

Donc quelle méthode choisir ? (Notamment pour l'étape 1).

 

Merci d'avance pour l'aide apportée 😇

Posté(e)

Bon et bien j'ai appliqué la méthode avec "Stop this stack" mais sans reboot.
D'ailleurs, faut que je tente de redémarrer le NAS pour voir si mes modifications survivent bien ^^

Sinon, effet de bord non prévu : ma stack de monitoring était, elle, paramétrée pour l'IP .200 pas .201 XD
Un petit tour dans l'édition JSON recherche et remplace, et hop, souci réglé ^^

Faudra un jour que je songe à tenter le monitoring de l'Asustor.

Posté(e) (modifié)

Pas eu le temps de te répondre, mais effectivement :

- Supprimer le réseau macvlan, donc avant ça stopper les conteneurs
- Supprimer l'interface virtuelle
- Recréer le réseau macvlan
- Recréer l'interface virtuelle
- Relancer les conteneurs

A priori rien d'autre.

il y a 54 minutes, MilesTEG1 a dit :

Faudra un jour que je songe à tenter le monitoring de l'Asustor.

Il y a l'air d'y avoir ce qu'il faut pour ici Guide ASUSTOR NAS MIB - ASUSTOR NAS

Modifié par .Shad.
Posté(e)
il y a 7 minutes, .Shad. a dit :

Il y a l'air d'y avoir ce qu'il faut pour ici Guide ASUSTOR NAS MIB - ASUSTOR NAS

Oh mais ça m'a l'air bien documenté tout ça ! Mieux que chez Syno on dirait.

Je m'y pencherais dessus quand j'aurais un moment 🙂

Merci pour le lien en tout cas, et merci pour l'autre partie de ta réponse 😉 

PS : l'avantage de passer par une interface virtuelle, c'est qu'une fois recréée, je n'ai pas eu besoin de reprendre tous les .conf de nginx 😁

Posté(e) (modifié)

@.Shad. et a tous ,

je suis en train de faire des essais avec le fail2ban intégré à SWAG.

Déjà, première chose j'ai réussi à faire en sorte d'envoyer des emails avec cette version de f2b ! 🥳🎉
snapshot_28247524976746d02e79922c3.jpg

Et aussi les notifications sur Gotify :
snapshot_1622650073d5b968c30b1edf28.jpg

Je suis bien heureux ^^

Je vous ferais un topo sur comment j'ai réussi à faire en sorte que l'envoi d'emails fonctionne en passant par le serveur smtp d'OVH.

Et sur l'essai que je viens de faire avec calibre-web, entrer plus de 3 fois des ID de connexion erroné, j'ai bel et bien été banni, et l'accès à calibre-web n'était plus possible ensuite !
Donc ça fonctionne bien avec le f2b intégré à SWAG. Je ne comprends pas pourquoi ça ne fonctionne plus avec l'image de crazy-max...

Du coup, je vais finaliser l'ajout des jails dans le jail.local (car tous mes essais du jour pour tenter de faire fonctionner les fichiers de jail.d/ ont échoué...

Bref, voilà une bonne étape de faite : refaire fonctionner un fail2ban ! 

Je ferais un topo plus tard sur tout ça si ça vous intéresse 🙂 

Modifié par MilesTEG1
Posté(e)

Alors, la fatigue aidant à ne plus avoir la motivation de finir le paquet de copies, je vais faire mon petit retour ^^

En préambule, lorsque je parlerais du conteneur Fail2ban, il s'agira de celui créé à partir de l'image de crazy-max (voir lien juste au-dessous). Sinon SWAG fera référence à SWAG, donc le fail2ban intégré sera celui de SWAG.

Alors, pour que l'envoi d'emails de notification par le fail2ban de swag fonctionne, j'ai épluché les fichiers du dépôt de crazy-max à savoir : le dockerfile et le entrypoint.sh.
Je savais qu'il y avait le binaire ssmtp de présent dans son image et absente de celle de SWAG, mais je ne savais pas si c'était juste ce binaire qui faisait que l'envoi d'email via un serveur SMTP comme celui de gmail ou d'OVH fonctionnait.

Bref, en épluchant les deux fichiers mentionnés ci-dessus, j'ai vu que le binaire ssmtp pouvait être installé dans l'image SWAG via un de leurs mods : linuxserver/mods:universal-package-install. (J'en avais déjà une vague idée...).
Il faut donc ajouter ce docker-mod à ceux potentiellement déjà présents dans le docker-compose et la ligne spécifiant quel paquet installer :

      - DOCKER_MODS=linuxserver/mods:swag-auto-reload|linuxserver/mods:swag-dashboard|linuxserver/mods:swag-maxmind|ghcr.io/gilbn/theme.park:swag|linuxserver/mods:swag-crowdsec|linuxserver/mods:universal-package-install
      - INSTALL_PACKAGES=ssmtp

Pendant mes recherches dans le conteneur Fail2Ban (image crazy-max), j'ai pu trouver le dossier /etc/ssmtp/ et les deux fichiers dedans :

  • ssmtpd.conf : ce fichier contenait des variables construites à partir des variables d'environnement qu'on a mis à la création du conteneur : j'ai pu voir dans le entrypoint.sh comment était construit ce fichier ssmtpd.conf.
    Je mettrais le contenu du fichier qui fonctionne avec SWAG plus bas.
  • revaliases : ce fichier était "vide", que des lignes commentées.

En effectuant une recherche sur le fichier ssmtpd.conf, je suis tombé sur cet article : https://doc.ubuntu-fr.org/ssmtp.

Il donne des infos sur les variables présentes dans le fichier ssmtpd.conf et j'ai adapté un peu ce qui était présent dans le fichier de mon conteneur Fail2ban.

Pour que le binaire ssmtp fonctionne, il faut lui fournir les fichiers de configuration. Donc, nouvelle ligne dans le fichier docker-compose.yml pour ajouter un point de montage dans la partie volume :

    volumes:
      - /volume4/docker/swag_macvlan/config:/config
      - /volume4/docker/swag_macvlan/etc-ssmtp:/etc/ssmtp

Maintenant, le contenu des deux fichiers à placer dans /volume4/docker/swag_macvlan/etc-ssmtp.
Alors, chose étrange, ce n'est pas le fichier ssmtpd.conf qu'il faut placer mais un fichier ssmtp.conf, dans le d ! Même contenu cependant.

  • Fichier ssmtp.conf :
    #
    # /etc/ssmtp.conf -- a config file for sSMTP sendmail.
    #
    # The person who gets all mail for userids < 1000
    # Make this empty to disable rewriting.
    # root=postmaster
    # The place where the mail goes. The actual machine name is required
    # no MX records are consulted. Commonly mailhosts are named mail.domain.com
    # The example will fit if you are in domain.com and you mailhub is so named.
    # mailhub=mail
    # Where will the mail seem to come from?
    #rewriteDomain=localhost
    # The full hostname
    #hostname="localhost"
    
    
    mailhub=ssl0.ovh.net:587
    hostname=Fail2ban-SWAG
    FromLineOverride=YES
    UseTLS=YES
    UseSTARTTLS=YES
    AuthUser=monmail@mon-ndd.ovh
    AuthPass=Mon_Supper_Password-de-la-mort-qui-tue-sans_2FA...
    root=monmail@mon-ndd.ovh
  • Fichier revaliases (je ne suis pas sûr que celui-là serve vraiment... mais je l'ai personnalisé avec l'articule de ubuntu-fr) :
    # sSMTP aliases
    #
    # Format:	local_account:outgoing_address:mailhub
    #
    # Example: root:your_login@your.domain:mailhub.your.domain[:port]
    # where [:port] is an optional port number that defaults to 25.
    
    root:monmail@mon-ndd.ovh:ssl0.ovh.net:587
    #Other System user: (for Apache)
    #www-data:monmail@mon-ndd.ovh:ssl0.ovh.net:587

Voilà voilà ! Il m'a fallu pas mal de recréation et de redémarrage de SWAG, et de réactivation/désactivation du conteneur Fail2ban 🤣

PS : j'ai aussi personnalisé les mails d'envois en ajoutant une mention SWAG ^^

PPS : et enfin, pour avoir une notification email qui ne contient pas un nom aléatoire de machine, j'ai ajouté ça hostname: DS920Plus--SWAG au docker-compose, et j'ai aussi mis quelques DNS (mais pas sûr que ça soit utile) :

---
version: "2.4"
services:
  swag:
    image: lscr.io/linuxserver/swag:latest     # https://github.com/linuxserver/docker-swag
    container_name: swag

    hostname: DS920Plus--SWAG
     
    dns:
      - 192.168.2.203
      - 192.168.2.210
      - 1.1.1.1
      - 9.9.9.9

 

Posté(e)

@MilesTEG1 Beau boulot, remarques :

  • Avoir UseTLS et UseSTARTTLS simultanément est contradictoire. Si tu utilises le port 587 c'est STARTTLS et tu peux désactiver UseTLS.
  • Attention aux droits lorsque tu montes le fichier ssmtp.conf sur ton NAS
  • Ajouter des DNS n'est utile que s'ils diffèrent de ceux utilisés par la résolution DNS Docker, qui se base sur celle de l'hôte.
Posté(e)

@.Shad. merci ^^

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

Avoir UseTLS et UseSTARTTLS simultanément est contradictoire. Si tu utilises le port 587 c'est STARTTLS et tu peux désactiver UseTLS.

Ok, je désactive UseTLS.

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

Attention aux droits lorsque tu montes le fichier ssmtp.conf sur ton NAS

C'est-à-dire ? Faut que je fasse quoi exactement ?
Je suppose que ça ce n'est pas bon :
.rwxrwxrwx pour l'user root ?

  • 3 semaines après...
Posté(e)

Hello @.Shad.

Merci pour les différents tutos en liant avec Docker qui sont clair et bien détaillé 

J'ai installé le conteneur swag mais  je n'ai pas encore effectué la deuxième partie pour fail2ban

J'ai crée un réseau macvlan et mis en place les reverse proxy pour les conteneurs installé  

  • IP (physique, pour utilisation avec réseau macvlan) du conteneur swag : 192.168.0.145
  • IP de l'hôte (le NAS ) : 192.168.0.110.
  • IP virtuelle de l'hôte : 192.168.1.140

Exemple du fichier vaultwarden.subdomain.conf qui fonctionne 

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        #set $upstream_app vaultwarden;
        set $upstream_app 192.168.0.140;
        set $upstream_port 9900;
        set $upstream_proto http;

Par contre, je rencontre un problème pour la mise en place des reverse proxy pour les applications style File station ou Synology Photos.

J'ai bien compris que swag ne pouvait pas communiquer directement avec le NAS 192.168.0.110  donc dans le fichier filestation.subdomain.conf  j'indique l'IP virtuelle 

Quand je tape http://192.168.0.140:7000 j’accède à File Station mais quand je tape https://filestation.ndd.fr j'ai ¨500 Internal Server Error¨

Voici mon fichier de .conf 

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name filestation.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

    # enable for Authentik (requires authentik-location.conf in the location block)
    #include /config/nginx/authentik-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.0.140;
        set $upstream_port 7000;
        set $upstream_proto <http>;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

}

Dans Portail des applications , j'ai mis port HTTP 7000 et HTTPS 7001 Screen_20230505.png.5631afc404a49c07c0eefc3dcbf50051.png

Je n’arrive pas à comprendre où est le problème dans ma config actuel

Merci d'avance de votre aide 

Bonne journée 

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.