[TUTO] Certificat SSL & reverse proxy via Docker

[MilesTEG1]

@.Shad. Pour sendmail, j'ai vu, mais comment je luis done mon serveur SMTP et les identifiants de connexion ?

Ok pour les modification des .conf pour nginx 🙂

Question à propos du proxy.conf.

J'essaye d'avoir à peu près la même chose qu'avec celui de DSM, et y a-t-il une différence entre :

proxy_set_header Host $http_host;

              que j'ai dans le fichier du reverse proxy de DSM, et :

proxy_set_header Host $host;
              que je trouve dans le proxy.conf du NGINX de SWAG ?

 

Dernière chose, est-ce que ceci (présent dans le fichier de conf de DSM) est utile ?

if ( $host !~ "(^mon_service.mon_ndd.ovh$)" ) { return 404; }

Que je sache si je dois y ajouter manuellement dans les conf des sous-domaines que je vais utiliser.

 

PS : j'ai mon gitea-test qui fonctionne 😄 Bon Gitea me met un gros warning parce que l'URL n'est pas la bonne par rapport à ce qui est configuré dans Gitea 🤣 mais c'est pas grave 😉 

J'ai encore du boulot, et pas beaucoup de temps pour tout faire rapidement, donc je vais prendre mon temps ^^

Merci pour l'aide ^^

 

ha encore une dernière chose avant d'aller au dodo.

Dans le .conf d'une application, gitea par exemple, le serveur dans les fichiers examples sont donnés ainsi :

server_name gitea.*;

Faut-il transformer en :

server_name gitea.mon-ndd.ovh;

?

 

[.Shad.]

il y a une heure, MilesTEG1 a dit :

Pour sendmail, j'ai vu, mais comment je luis done mon serveur SMTP et les identifiants de connexion ?

Ça faut que tu regardes la doc de sendmail.

Sinon par Discord c'est très bien aussi.

Pour le reste normalement tout fonctionne out of the box, tu prends par exemple un fichier de configuration standard dans la liste de leurs fichiers. Et tu adaptes pour DSM.

Tu te tortures un peu trop. 😛

Ça a un intérêt de remplacer le wildcard si et seulement si tu as d'autres sous-domaines identiques pour des noms de domaines racine différents. Je doute que ce soit le cas ?

[MilesTEG1]

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

Ça faut que tu regardes la doc de sendmail.

Sinon par Discord c'est très bien aussi.

Je préfère passer par l’e-mail , je n’ai pas de serveur discord et ne compte pas en faire un 😅

Ok je vais regarder la doc de sendmail mais je ne suis pas sûr d’avoir accès à sa configuration…

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

Tu te tortures un peu trop. 😛

Possible mais j’aime bien comprendre ce que je fais et vois. Et surtout je veux que ça fasse bien ce que je veux que ça fasse 🤪

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

Ça a un intérêt de remplacer le wildcard si et seulement si tu as d'autres sous-domaines identiques pour des noms de domaines racine différents. Je doute que ce soit le cas ?

Effectivement ce n’est pas mon cas. Mais ce que je voudrais comprendre c’est pourquoi dsm met le domaine complet et pas le .* comme le fait swag-nginx …

[.Shad.]

Parce que si ton domaine doit apparaître, ils doivent passer par une variable qui doit être importée depuis ailleurs, suite à ce que tu as déclaré dans le fichier docker-compose.
C'est plus compliqué, et inutilement compliqué la plupart du temps.

[MilesTEG1]

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

Parce que si ton domaine doit apparaître, ils doivent passer par une variable qui doit être importée depuis ailleurs, suite à ce que tu as déclaré dans le fichier docker-compose.
C'est plus compliqué, et inutilement compliqué la plupart du temps.

Faudra que je te relise à tête plus réveillée car là j’ai pas vraiment tout compris 😅😅

mais je retiens que je laisse mon-service.* plutôt que de mettre mon-service.mon-ndd.ovh. 😅

[.Shad.]

Les fichiers que SWAG embarquent sont présents sur GitHub, mettre un wildcard permet d'éviter de prévoir une variable qui mette bien le nom de ton domaine.

L'avantage de SWAG c'est que c'est prévu pour fonctionner quasi automatiquement avec leurs images, et demande très peu d'adaptation pour le reste.

[MilesTEG1]

Ok, mais du coup, ces fichiers de configuration génériques sont fait pour s'adapter à une majorité de situation.
Ça n'aurait donc pas d'intérêt pour moi de passer les server_name avec le nom complet de mon domaine ?

 

Nouvelle question qui n'a rien à voir avec les précédentes. Elle concerne les deux conteneurs en macvlan que j'ai :

• swag
• adguard home

Hier j'ai essayé de mettre l'adresse IP réelle de mon NAS (192.168.2.200) pour le service gitea : 

set $upstream_app 192.168.2.200

Comme je m'en doutais, et comme tu l'avais dit, ça ne fonctionne pas. Ok, comportement prévu du conteneur en macvlan.

Mais dans dans AdGuard Home, j'ai mis l'adresse IP réelle du NAS et ça semble bien fonctionner :

Du coup, pourquoi ça fonctionne bien avec l'IP réelle du NAS avec AdGH, et pas avec SWAG ?

[.Shad.]

Il y a 1 heure, MilesTEG1 a dit :

Ça n'aurait donc pas d'intérêt pour moi de passer les server_name avec le nom complet de mon domaine ?

Ben comme je t'ai dit, le seul intérêt c'est si tu as plusieurs sous-domaines identiques pour des domaines différents.

Il y a 1 heure, MilesTEG1 a dit :

Mais dans dans AdGuard Home, j'ai mis l'adresse IP réelle du NAS et ça semble bien fonctionner :

Essaie de te connecter au conteneur Adguard. Et tu fais un ping sur l'IP réelle du NAS. Ça ne fonctionnera pas.

Adguard c'est un serveur DNS. C'est un plan d'orientation. À aucun moment il n'a besoin de se déplacer. On est sur deux sujets différents. En revanche le NAS quand il communique avec Adguard, il utilise son interface virtuelle. Je suis sûr que dans les logs tu verras apparaître l'IP virtuelle du NAS et pas la réelle.

[MilesTEG1]

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

Ben comme je t'ai dit, le seul intérêt c'est si tu as plusieurs sous-domaines identiques pour des domaines différents.

Ok je laisse le.* 😁

pourquoi dsm met le domaine complet du coup ?

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

Essaie de te connecter au conteneur Adguard. Et tu fais un ping sur l'IP réelle du NAS. Ça ne fonctionnera pas.

Adguard c'est un serveur DNS. C'est un plan d'orientation. À aucun moment il n'a besoin de se déplacer. On est sur deux sujets différents. En revanche le NAS quand il communique avec Adguard, il utilise son interface virtuelle. Je suis sûr que dans les logs tu verras apparaître l'IP virtuelle du NAS et pas la réelle.

Haa ok ! Je comprends mieux, j’avais une intuition lointaine de ça 😊

en gros la réécriture indique à celui qui fait la demande de dns où aller , c’est pas AdGuard lui même qui y va .

Et oui j’ai bien vu dans le log que l’adresse iP du nas est l’iP virtuelle 😊

en fait je n’avais pas compris que c’était dans les deux sens que la communication était impossible : nas vers conteneur macvlan et aussi conteneur macvlan vers nas.

 

[MilesTEG1]

@.Shad. 
Nouvelle question 😄 vu que j'avance dans la création de mes .conf.
Je suis en train de configurer le domaine pour Surveillance Station (camera.ndd.ovh) en le faisant pointer vers l'IP virtuelle du NAS avec le bon port. Jusque là pas de soucis.

Déjà, y a-t-il un moyen de recharger nginx dans SWAG sans redémarrer complètement le conteneur ?

Ensuite, par rapport aux paquets DSM, j'ai aussi un nom de domaine synology.
Quand j'aurais redirigé le port 443 vers SWAG plutôt que vers le NAS, comment je fais pour que les noms de domaine avec .synology.me aboutissent aux bonnes applications ?

[MilesTEG1]

@.Shad.

Bon bah voilà, j'ai fini tous les .conf pour mes domaines, que j'ai passé en production sur le LAN et tout semble fonctionner correctement 🙂 
Je me suis même fait un fichier ACL.IP-LAN.conf qui contient ça que je mets en

include /config/nginx/ACL.IP-LAN.conf;

dans certains .conf pour limiter l'accès au LAN+VPN (me restera à vérifier ça en 4G ^^) :

## ACL.IP-LAN.conf

# For my Synology DSM, I created an Access Control Profiles to restrict access only to LAN and VPN IP adresses

# This Access Control Profile is a file in the /etc/nginx/conf.d folder

# But for SWAG-Nginx, it must be with another file.

 

# Allow all from LAN IPs

allow 192.168.2.0/24;

 

# Allow all from VPNs IPs

allow 192.168.10.0/24;

allow 192.168.11.0/24;

 

# Deny all

deny all;

J'ai une nouvelle question : dois-je faire une entrée spécifique dans le pare-feu du NAS pour autoriser les connexions ? (pour le LAN il ne semble pas nécessaire de faire quoique ce soit...)

Modifié le 15 août 2022 par MilesTEG1

[Einsteinium]

Le 13/08/2022 à 23:30, MilesTEG1 a dit :

Si, mais je le met où le serveur SMTP que je veux utiliser ainsi que mon mot de passe pour le serveur SMTP ?

C'est un serveur, pas un client, donc inutile sauf si ton fai bloque le smtp, je peux à la limite te donné les confs de sendmail que j'utilisais pour l'envois (sinon il envoi rien de base si pas conf)

[MilesTEG1]

il y a 15 minutes, Einsteinium a dit :

C'est un serveur, pas un client, donc inutile sauf si ton fai bloque le smtp, je peux à la limite te donné les confs de sendmail que j'utilisais pour l'envois (sinon il envoi rien de base si pas conf)

Aucune idée si Free bloque le SMTP comme ça... Il me semble que c'est le cas.
Mais je veux bien ton fichier de conf s'il te plait 😇

 

Sinon, pour que l'accès fonctionne depuis l'exéterieur, j'ai du créer une nouvelle règle dans le pare-feu du routeur (j'ai mis bien 5 min à le comprendre 😅 quand j'ai vu que l'accès à mon PMS ne fonctionnait plus en 4G 🤪)

Faut que je désactive la ligne du dessous, elle ne sert plus à grand chose maintenant 🙂 enfin je pense.

Tout fonctionne bien via la 4G 😄
Même les restrictions fonctionnent bien 🙂 
Il me faut maintenant trouver un moyen de personnaliser ce qui s'affiche quand je tente d'accéder à DSM depuis l'extérieur et que c'est refusé. Actuellement j'ai :

NGINX
403 - Forbidden

 

Faut que je passe à Fail2ban maintenant 🙂
Et ensuite Authelia, puis CrowdSec
 

Modifié le 15 août 2022 par MilesTEG1

[Einsteinium]

il y a 10 minutes, MilesTEG1 a dit :

Aucune idée si Free bloque le SMTP comme ça... Il me semble que c'est le cas.
Mais je veux bien ton fichier de conf s'il te plait 😇

Dans ton compte freebox/ma freebox/fonctionnabilités avancées/blocage du protocole smtp sortant

 

Dans jail.conf avoir :

destemail = destinataire@tondomaine.fr

sender = fail2ban@tondomaine.fr

mta = sendmail

action_mw = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
            %(mta)s-whois[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]

action = %(action_mw)s

 

/fail2ban/action.d/sendmail-whois.conf

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
#

[INCLUDES]

before = sendmail-common.conf

[Definition]

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = printf %%b "Subject: [Fail2Ban] <name>: banni <ip> de TONDOMAINE
            Date: `LC_ALL=C date +"%%a, %%d %%h %%Y %%T %%z"`
            From: <sendername> <<sender>>
            To: <dest>\n
            Bonjour,\n
            L'adresse IP <ip> a été bannie par Fail2ban après
            <failures> tentatives d'accès à <name>.\n\n
            Quelques informations sur cet hôte:\n
            `/usr/bin/whois <ip> || echo programme whois manquant`\n
            Cordialement,\n
            Fail2Ban" | /usr/sbin/sendmail -f <sender> <dest>

actionunban =

[Init]

# Default name of the chain
#
name = default

 

/etc/fail2ban/action.d/sendmail-common.conf

# Fail2Ban configuration file
#
# Common settings for sendmail actions
#
# Users can override the defaults in sendmail-common.local

[INCLUDES]

after = sendmail-common.local

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart =

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop =

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck =

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban =

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban =

[Init]

# Recipient mail address
#
dest = root

# Sender mail address
#
sender = fail2ban

# Sender display name
#
sendername = Fail2Ban

 

😉

[.Shad.]

Il y a 19 heures, MilesTEG1 a dit :

pourquoi dsm met le domaine complet du coup ?

Parce que tu as plus tendance à avoir plusieurs noms de domaine sur le NAS que dans SWAG, donc il est utile de préciser le domaine en question.

Il y a 23 heures, MilesTEG1 a dit :

Je préfère passer par l’e-mail , je n’ai pas de serveur discord et ne compte pas en faire un 😅

Et pourquoi pas ?
C'est hyper personnalisable, gratuit, tous les soft récents intègrent de plus en plus des webhooks vers Discord et délaissent de plus en plus l'email. Faut vivre avec son temps. 🙂 

Il y a 16 heures, MilesTEG1 a dit :

Déjà, y a-t-il un moyen de recharger nginx dans SWAG sans redémarrer complètement le conteneur ?

Oui, mais ça n'a pas un gros intérêt, une raison particulière ?

Il y a 16 heures, MilesTEG1 a dit :

Ensuite, par rapport aux paquets DSM, j'ai aussi un nom de domaine synology.
Quand j'aurais redirigé le port 443 vers SWAG plutôt que vers le NAS, comment je fais pour que les noms de domaine avec .synology.me aboutissent aux bonnes applications ?

Tout ce qui est proxiable doit passer de préférence par un unique proxy inversé.
Donc port 443 -> SWAG et plus DSM.
Pour les autres applis : Hyper Backup, Drive, etc... tu utilises simplement un autre certificat pour ces applis non proxiables. Que ce soit le nom de domaine de Synology, ton OVH ou ce que tu veux. Géré indépendamment de SWAG, par DSM, Acme, ou autre. Moi j'utilise le ndd Synology pour ces applis.

il y a 44 minutes, MilesTEG1 a dit :

J'ai une nouvelle question : dois-je faire une entrée spécifique dans le pare-feu du NAS pour autoriser les connexions ? (pour le LAN il ne semble pas nécessaire de faire quoique ce soit...)

Les ACL c'est une bonne idée, ça fait office de pare-feu pour le proxy inversé, car l'IP étant indépendante du NAS, son pare-feu ne s'applique pas.
Tu peux également faire du blocage GeoIP comme DSM au niveau de SWAG, c'est prévu, c'est le mod Maxmind : https://github.com/linuxserver/docker-mods/tree/swag-maxmind

Si ton routeur/pare-feu en amont ne permet pas de faire du géoblocage, c'est une bonne alternative. Typiquement aussi dans le cas d'un VPS, où tu disposes uniquement d'une machine à protéger.

Sans parler des couches supplémentaires prises en charge : Authelia, f2b/Crowdsec (au passage ce dernier fonctionne super bien), etc...

Modifié le 15 août 2022 par .Shad.

[MilesTEG1]

@Einsteinium Merci pour les fichiers.
Je vais tenter avec tes éléments de configuration. À la différence près que j'utilise cette action :

action = %(action_mwl)s

Va probablement falloir que je fasse plusieurs .local pour les sendmail*.conf ou les mail*.conf ... je sais pas trop lesquels sont utilisés avec sendmail...

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

Parce que tu as plus tendance à avoir plusieurs noms de domaine sur le NAS que dans SWAG, donc il est utile de préciser le domaine en question.

Ok, je comprends ^^

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

Et pourquoi pas ?
C'est hyper personnalisable, gratuit, tous les soft récents intègrent de plus en plus des webhooks vers Discord et délaissent de plus en plus l'email. Faut vivre avec son temps. 🙂 

Parce que 😋
Non, plus franchement, c'est surtout que je n'ai pas envie de mettre en place davantage de chose... et que je ne me servirais pas vraiment d'un serveur discord. Et aussi parce que Discord peut accéder à tout ce qui passe par le serveur, non ?

Bref, il y a certes des trucs intéressants faisable avec, mais là je n'ai pas trop le temps de regarder.

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

Le 14/08/2022 à 16:23, MilesTEG1 a dit :

Ensuite, par rapport aux paquets DSM, j'ai aussi un nom de domaine synology.
Quand j'aurais redirigé le port 443 vers SWAG plutôt que vers le NAS, comment je fais pour que les noms de domaine avec .synology.me aboutissent aux bonnes applications ?

Tout ce qui est proxiable doit passer de préférence par un unique proxy inversé.
Donc port 443 -> SWAG et plus DSM.
Pour les autres applis : Hyper Backup, Drive, etc... tu utilises simplement un autre certificat pour ces applis non proxiables. Que ce soit le nom de domaine de Synology, ton OVH ou ce que tu veux. Géré indépendamment de SWAG, par DSM, Acme, ou autre. Moi j'utilise le ndd Synology pour ces applis.

Et bien justement, tu fais comment ?
Je remarque que je n'utilise jamais le nom de domaine synology mis dans DSM. Donc ce n'est pas trop un soucis, mais j'aimerais comprendre comment tu fais, ou tu ferais dans mon cas particulier : swag en macvlan sur le NAS, derrière un routeur.

J'ai bien redirigé le port 443 vers swag.

Et je constate un effet de bord lorsque je suis sur le LAN que je ne sais pas encore corriger : pour la synchronisation Drive avec les clients desktop.
Aucun soucis lorsque je suis connecté en 4G via mon smartphone, la synchro se fait sans soucis, vu que ça passe par le port 6690 et que ce dernier est redirigé vers le NAS dans le routeur.
Mais quand je suis connecté au wifi du RT, la synchro est bloquée :

Je précise à nouveau que j'ai des réécriture DNS avec AdGuardHome :

• mon-ndd.ovh -> IP macvlan de SWAG
• *.mon-ndd.ovh -> IP macvlan de SWAG

@.Shad.

Comment puis-je faire pour que la synchronisation fonctionne ? (c'est peut-être la question le plus importante à résoudre pour moi actuellement).

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

Les ACL c'est une bonne idée, ça fait office de pare-feu pour le proxy inversé, car l'IP étant indépendante du NAS, son pare-feu ne s'applique pas.
Tu peux également faire du blocage GeoIP comme DSM au niveau de SWAG, c'est prévu, c'est le mod Maxmind : https://github.com/linuxserver/docker-mods/tree/swag-maxmind

Si ton routeur/pare-feu en amont ne permet pas de faire du géoblocage, c'est une bonne alternative. Typiquement aussi dans le cas d'un VPS, où tu disposes uniquement d'une machine à protéger.

Haa ! Je pensais que le pare-feu du NAS s'appliquait aux conteneurs...
Mon routeur Synology RT2600AC permet de n'autoriser que les IP française à accéder au port 443 qui est transmis à SWAG. Regarde la capture de mon précédent message, elle est prise sur le routeur : 

Cela dit, je pense quand même regarder le geoIP que tu me dis ici 🙂  Ça fera toujours une protection supplémentaire 🙂 

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

Sans parler des couches supplémentaires prises en charge : Authelia, f2b/Crowdsec (au passage ce dernier fonctionne super bien), etc...

Oui carrément, je suis en train de paramétrer le F2B intégré en utilisant ce que j'avais fait pour l'instance dédiée et ce qui est dispo sur le dépot de Linuxserver/fail2ban-conf.

La prochaine étape, quand la synchronisation Drive fonctionnera, sera Authelia, puis CrowdSec (tu ferais pas un tuto pour ça par hasard ? 🤗😇

 

 

Modifié le 15 août 2022 par MilesTEG1

[.Shad.]

il y a 18 minutes, MilesTEG1 a dit :

Et aussi parce que Discord peut accéder à tout ce qui passe par le serveur, non ?

Non pas du tout, c'est un webhook, Discord crée un token d'accès pour une application donnée avec des droits définis, comme tu trouves sur Spotify, Google, Youtube, etc...

il y a 22 minutes, MilesTEG1 a dit :

Je précise à nouveau que j'ai des réécriture DNS avec AdGuardHome :

• mon-ndd.ovh -> IP macvlan de SWAG
• *.mon-ndd.ovh -> IP macvlan de SWAG

Ben la réponse est dans ce que tu viens d'écrire, normalement dans la fenêtre en question ce que tu dois mettre c'est l'IP ou un ndd menant à l'IP du NAS.
Pourquoi avoir mis drive.ndd.tld ? c'est pas une entrée de ton proxy inversé ça ? SI c'est le cas il y a grosse confusion.

Si tu veux avoir une certificat pour le même nom de domaine pour SWAG et le NAS, c'est simple, tu laisses ton setup acme.sh qui exposera un certificat pour les applications type Drive sur le NAS (bien vérifier les associations certificat - application dans DSM).

Et parallèlement tu auras un certificat pour le même nom de domaine avec SWAG.
Rien n'empêche d'avoir plusieurs certificats wildcard pour un même nom de domaine.

Ainsi c'est transparent pour toi.

Moi j'utilise le ndd Synology uniquement pour joindre localement et à distance (via le DDNS gratuit) mon NAS principal pour ses services intrinsèques, ca marche très bien.

il y a 37 minutes, MilesTEG1 a dit :

Haa ! Je pensais que le pare-feu du NAS s'appliquait aux conteneurs...

Oui, en bridge ou en host, car tu es lié à l'hôte. Pas en macvlan.

il y a 39 minutes, MilesTEG1 a dit :

Mon routeur Synology RT2600AC permet de n'autoriser que les IP française à accéder au port 443 qui est transmis à SWAG

Oui donc tu as ce qu'il faut en amont, donc c'est ok pour la sécurité par rapport à l'extérieur.

il y a 41 minutes, MilesTEG1 a dit :

tu ferais pas un tuto pour ça par hasard ?

A toi l'honneur. 😄 Je fais pas de tutoriel de toute façon sur quelque chose dont je ne maîtrise pas tous les aspects, c'est au moins parti pour quelques semaines d'observation.

[MilesTEG1]

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

Non pas du tout, c'est un webhook, Discord crée un token d'accès pour une application donnée avec des droits définis, comme tu trouves sur Spotify, Google, Youtube, etc...

Bon, un jour à l'occasion, je te demanderais probablement de l'aide à ce sujet ^^
Mais là ce n'est pas la priorité.

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

Ben la réponse est dans ce que tu viens d'écrire, normalement dans la fenêtre en question ce que tu dois mettre c'est l'IP ou un ndd menant à l'IP du NAS.
Pourquoi avoir mis drive.ndd.tld ? c'est pas une entrée de ton proxy inversé ça ? SI c'est le cas il y a grosse confusion.

Si c'est une entrée de mon proxy inversé, et effectivement je n'avais pas prévu le bug.
J'ai créé une nouvelle entrée : drive-sync.ndd.ovh avec ce fichier :
 

## 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 6690 ssl;
    listen [::]:6690 ssl;

    server_name drv-sync.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

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

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

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

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

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

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.2.230;
        set $upstream_port 6690;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

}

Mais ça ne fonctionne pas en local XD
La seule solution que j'ai trouvé c'est de faire une réécriture du drive-sync.ndd.ovh vers l'IP réelle du NAS. Et là ça fonctionne mais que en local ! Si je suis à distance (via la 4G), ça ne fonctionne plus 😮  à priori même à distance en 4G 😉. Ça va mériter davantage de tests...

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

Si tu veux avoir une certificat pour le même nom de domaine pour SWAG et le NAS, c'est simple, tu laisses ton setup acme.sh qui exposera un certificat pour les applications type Drive sur le NAS (bien vérifier les associations certificat - application dans DSM).

Et parallèlement tu auras un certificat pour le même nom de domaine avec SWAG.
Rien n'empêche d'avoir plusieurs certificats wildcard pour un même nom de domaine.

Ainsi c'est transparent pour toi.

J'ai laissé ACME fonctionner, donc j'ai encore les certificats pour mon ndd.ovh dans DSM 🙂 
Mais on est d'accord que ceux-çi ne peuvent plus vraiment fonctionner ? puisque le port 443 sur lequel ils sont accessibles est redirigé sur SWAG.

Donc si tu voulais utiliser le ndd synology, il faudrait que je précise un port et que ce dernier soit ouvert dans les parefeu, et routé vers le NAS dans le routeur, tu valides ce schéma ?
Mais du coup, utilises-tu ton ndd synology comme ceci :   service.synology.me:14443 
Avec le port 14443 ouvert et transféré sur ton NAS ?

(bon je me dis que ton cas est aussi particulier que le mien vu que tu utilises un VPS pour t'y connecter en 4G... tu n'as toujours pas la fibre chez toi ?)
 

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

Oui donc tu as ce qu'il faut en amont, donc c'est ok pour la sécurité par rapport à l'extérieur.

Ok donc c'est pas forcément le MOD à installer en priorité, sauf pour utiliser le dashboard nginx 😄

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

A toi l'honneur. 😄 Je fais pas de tutoriel de toute façon sur quelque chose dont je ne maîtrise pas tous les aspects, c'est au moins parti pour quelques semaines d'observation.

Oué 😅 c'est un peu la même chose pour moi 🙂 Et puis j'ai déjà un chantier ouvert et tout juste commencé avec Adguard Home XD et le tuto Vaultwarden qu'il faudrait que je réécrive pour le rendre un poil plus lisible (voir signature ^^) 

Bon en tout cas, merci beaucoup pour l'aide apportée 😇

[MilesTEG1]

edit : ha bah truc bizarre, sans rien changer, le client drive de mon pc windows se connecte sans soucis avec drive.ndd.ovh...

Mais pas le mac de ma femme... 🤣

[.Shad.]

Tu n'as pas compris comment fonctionne la synchronisation de Drive.
Et pareil pour l'histoire des certificats sur le NAS, le port 443 n'a plus rien à faire ici dans ton cadre d'utilisation.

Ce serait trop long de tout reprendre, on peut en parler en vocal si tu veux, je t'envoie mes dispos en MP.

[MilesTEG1]

Pourtant je pensais avoir compris 😅

la synchronisation fonctionne sur le port 6690 ça j’en suis sûr vu que ce port est nécessaire à ouvrir sur l’extérieur pour que ça fonctionne.

les certificats sur le nas sont liés aux noms de domaines donc si tu utilises les noms de domaines tu utilises les certificats.

Mais comme les noms de domaines .ovh pointent sur mon iP internet, depuis l’extérieur, je dois passer par le reverse proxy qui est maintenant swag, le tout passant uniquement par le port 443, port routé et dirigé vers swag. Donc même si j’utilise le nom de domaine synology, dsm.ndd.synology.me, il va arriver sur swag. Et swag n’a pas le certificat synology , donc ça va faire une erreur de sécurité.

D’où ma question sur ton utilisation conjointe du ndd synology et ovh le tout passant par swag. A moins qu’il y ait un paramètre à mettre dans Swag pour permettre le transfert au nas du ndd tel quel, je ne comprend. pas.

Je n’ai peut être pas des connaissances super développées en réseau mais je pense quand même saisir le minimum pour savoir comment on se sert d’un reverse proxy sur un unique port.

Ce que je n’avais pas prévu car oublié, c’est le port de la synchronisation drive qui est 6690. Mais ça ne fonctionne pas en passant par le reverse proxy (ou alors j’ai mal fait mon fichier de configuration 😅).

J’ai contourné le soucis pour le moment. Je pourriez essayer de mettre le nom de domaine synology sur drive, ou rentre de mettre drive.ndd.ovh pointant sur le nas directement via adguard (pour le lan).

On peut tenter un vocal (discord je suppose 😁) faut que je vois tes dispos 😊 je te réponds là dessus en mp 😉

[Einsteinium]

Le 14/07/2020 à 10:23, .Shad. a dit :

Ou alors via le paquet Docker de DSM ou encore Portainer

Question shad car je regardais ton tutoriel... Portainer prends enfin le

cap_add:
         - NET_ADMIN

du docker compose ?

Car de mémoire le déploiement échoue si on met cette argument, il faut alors le mettre en extra args : --cap-add=NET_ADMIN

 

Le 15/08/2022 à 21:20, MilesTEG1 a dit :

Je n’ai peut être pas des connaissances super développées en réseau mais je pense quand même saisir le minimum pour savoir comment on se sert d’un reverse proxy sur un unique port.

Globalement tu ne communiques qu'avec swag, c'est swag qui derrière communique avec tes différents serveurs et te l'affiche derrière, qu'importe que le serveur derrière est un certificat ou pas, qu'il soit en http ou https, au final tu ne verras que le certificats de swag qui est ton tiers de confiance, il sécurise entre toi et lui.

[MilesTEG1]

il y a 52 minutes, Einsteinium a dit :

Question shad car je regardais ton tutoriel... Portainer prends enfin le

cap_add:
         - NET_ADMIN

du docker compose ?

Car de mémoire le déploiement échoue si on met cette argument, il faut alors le mettre en extra args : --cap-add=NET_ADMIN

Je n’ai jamais eu de soucis avec ça pour les déploiements avec Portainer pour les conteneurs avec de capadd netadmin.

 

il y a 53 minutes, Einsteinium a dit :

Globalement tu ne communiques qu'avec swag, c'est swag qui derrière communique avec tes différents serveurs et te l'affiche derrière, qu'importe que le serveur derrière est un certificat ou pas, qu'il soit en http ou https, au final tu ne verras que le certificats de swag qui est ton tiers de confiance, il sécurise entre toi et lui.

C’est bien ce que j’avais compris, d’où mon interrogation concernant le nom de domaine synology… si tu l’attaques avec le port 443 qui passent par swag alors il faut le certificat dans swag 😅

a moins de passer par un autre port.

mais peut être que @.Shad.a une redirection de ce ndd vers l’ip de son nas avant de faire la redirection vers swag pour les autres ndd.ovh.

[.Shad.]

@Einsteinium Ca fait longtemps que je n'ai pas testé sur le NAS, mais de mémoire ça marchait bien.

@MilesTEG1 Mais de quelle application tu aurais encore besoin sur le 443 sur le NAS directement ? Tout passe par SWAG comme l'a dit @Einsteinium, ce qui ne passe pas par SWAG (Drive, HBK, etc...) passe par un port dédié (6690, 6281, etc...) et là il te faut un certificat pour ces applis là sur le NAS, méthode acme par Docker ou ndd Synology, peu importe.

[Einsteinium]

Il y a 2 heures, MilesTEG1 a dit :

Je n’ai jamais eu de soucis avec ça pour les déploiements avec Portainer pour les conteneurs avec de capadd netadmin.

Une bonne avancée alors, merci pour le retour 🙂