il y a 39 minutes, MilesTEG1 a dit :

Peux-tu juste me confirmer que je n'ai pas besoin de supprimer toutes les entrées du reverse-proxy de DSM pour que celles de SWAG fonctionnent ?

Tu peux très bien le laisser tel quel, et mieux même, si tu utilises une validation du futur certificat par DNS pour ton domaine, tu peux même ne pas changer le NAT du port 443 sur ton routeur.
Il te suffira de faire les tests localement, donc tu changes uniquement dans ta zone locale l'enregistrement A qui pointe vers ton proxy inversé pour le faire pointer vers le conteneur SWAG au lieu du NAS.

Et quand ce sera fonctionnel, tu pourras modifier le NAT pour que l'extérieur passe aussi par SWAG.

il y a 40 minutes, MilesTEG1 a dit :

À propos de ça, j'ai mis en place la méthode de @Einsteinium pour mon nom de domaine à moi. Est-ce que ça continuera de fonctionner avec SWAG ?

Oui c'est indépendant. Moi j'utilise le domaine Synology, mais ton domaine officiel géré par acme.sh c'est aussi complètement viable.

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

Tu peux très bien le laisser tel quel, et mieux même, si tu utilises une validation du futur certificat par DNS pour ton domaine, tu peux même ne pas changer le NAT du port 443 sur ton routeur.
Il te suffira de faire les tests localement, donc tu changes uniquement dans ta zone locale l'enregistrement A qui pointe vers ton proxy inversé pour le faire pointer vers le conteneur SWAG au lieu du NAS.

Et quand ce sera fonctionnel, tu pourras modifier le NAT pour que l'extérieur passe aussi par SWAG.

Haaaa cool, très bonne idée ça 🙂
Quand tu parles de ma zone locale, tu veux parler de la réécriture DNS que me fait AdGuard ? (je n'ai pas d'autre serveur DNS dans mon réseau)

Si oui, et bien tant mieux 😄

Très bonne idée du coup ^^ Comme ça quand le bazar fonctionnera en local, je pourrais rediriger le 443 vers l'IP de swag plutôt que celle du NAS.

Par contre, pas d'interface graphique pour gérer la configuration, ça va être moins sympa 😄 

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

Oui c'est indépendant. Moi j'utilise le domaine Synology, mais ton domaine officiel géré par acme.sh c'est aussi complètement viable.

Ok, donc je peux laisser tourner la solution de Einsteinium pour mon ndd OVH qui sera encore présent dans DSM.

Via ton tuto, j'aurais également mon nom de domaine OVH utilisé, j'aurais donc un autre certificat généré et géré par swag, on est d'accord ?
Car si j'ai bien suivi, SWAG ne va pas communiquer avec DSM pour ça (certificat) ?

@.Shad.

Dit, est-ce que je dois refaire la création des clés pour l'API OVH ? J'ai fait avec la méthode du tuto de Einsteinium qui semble identique à celle de @oracle7.

Tu peux utiliser les mêmes a priori mais moi j'aurais tendance à créer un autre set de clés.

Il y a 3 heures, MilesTEG1 a dit :

Via ton tuto, j'aurais également mon nom de domaine OVH utilisé, j'aurais donc un autre certificat généré et géré par swag, on est d'accord ?

Oui, tu peux avoir x certificats pour un même domaine, ça ne pose aucun souci, il n'y a pas de critère d'unicité.

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

Tu peux utiliser les mêmes a priori mais moi j'aurais tendance à créer un autre set de clés.

Pourquoi tu ferais un autre jeu de clés ?

cela dit ça me parait une bonne idée 👍🏻 

@.Shad.@MilesTEG1

Bonjour,

Pardonnez mon incrédulité, mais on peut avoir plusieurs jeux de clés pour un même domaine ? C'est possible çà ?

Cordialement

oracle7😉

il y a 24 minutes, oracle7 a dit :

@.Shad.@MilesTEG1

Bonjour,

Pardonnez mon incrédulité, mais on peut avoir plusieurs jeux de clés pour un même domaine ? C'est possible çà ?

Cordialement

oracle7😉

Et bien j’en sais rien 😅

je vous dirais quand j’aurais essayé quand j’aurais un moment de libre 😊

Dans OVH tu définis juste un accès à l'API avec des droits donnés, pourquoi tu ne pourrais pas en créer autant que tu veux ?

Vous pouvez faire une clé par domaine ou générique, mais rien ne vous empêche d’utiliser plusieurs fois les clefs si vous avez plusieurs nas

L'avantage c'est que si une machine est compromise, tu peux supprimer l'accès API ça ne bloque que cette machine.

Salut, J'ai vu passer ces alertes de failles de sécu :

Citation

 

Voir la note de SWAG : https://github.com/linuxserver/docker-swag/releases/tag/1.21.0-ls94

Voir l'info de nginx : Mitigating the HTTPoxy Vulnerability with NGINX

 

 

Il faut s'attendre à ce qu'on ait une MAJ sur nos Syno car le reverse proxy de DSM est basé sur nginx aussi. mais quand ??

Il y a 2 heures, MilesTEG1 a dit :

Salut, J'ai vu passer ces alertes de failles de sécu :

 

Il faut s'attendre à ce qu'on ait une MAJ sur nos Syno car le reverse proxy de DSM est basé sur nginx aussi. mais quand ??

dans 6 mois ? 🤣

Bonjour,

 

Je suis débutant avec un NAS DS920Plus.

J'ai mis en place la solution acme.sh de Einsteinium pour mon certificat. Je souhaiterais la garder si j'installe SWAG.

J'ai suivi un autre tuto pour les DNS de Fenrir (DnsServer seulement les 2 premiers points cache local et loopback).

J'utilise le reverse proxy du Syno, mais je souhaiterais passer à une solution du type NGINX proxy manager.

Je suis tombé sur ce tuto. Je souhaiterais aussi mettre en oeuvre une solution du type adguard en docker.

Avant de commencer à tout mettre en oeuvre, mes capacités de compréhension des DNS sont très floues.

Je ne vois pas trop comment je vais faire cohabiter les serveur DNS du Syno et un docker Adguard ?

Je ne sais pas si c'est le bon sujet mais comme au-dessus on parle de Adguard ...

Je précise que j'ai une livebox avec un router Asus derrière donc les serveur DNS sont facilement changeables pour tous les clients).

SWAG et Nginx Proxy Manager sont deux logiciels différents.
SWAG n'offre pas d'interface comme NPM, mais embarque tout un lot de fonctionnalités en plus de Nginx.

Il y a moyen de faire en sorte que SWAG utilise le certificat d'acme.sh, c'est ce que je fais sur mon VPS.

Pour faire cohabiter DNS Server et un autre serveur/résolveur DNS, il faut utiliser le pilote macvlan (le conteneur aura une IP de ton réseau local, dès lors il n'y aura pas de conflit de port avec le NAS car pas de NAT entre le conteneur et l'hôte).

Tu trouveras plus d'info sur le pilote macvlan dans mon tutoriel en signature.

@.Shad. OK je vais commencer à regarder de plus près.

Pour l'interface moins user friendly de SWAG je m'en doutais mais ce qui m'intéresserai ce serai le fail2ban de SWAG.

Bonjour à tous, (et par ailleurs, merci .shad. pour tes tutos bien expliqués)

Je suis le tuto scrupuleusement (adapté à mon réseau), mais je me heurte à un problème de certificat let's encrypt. Le container monte normalement, mais en regardant les logs (docker-compose logs --follow)

swag    | Using Let's Encrypt as the cert provider
swag    | SUBDOMAINS entered, processing
swag    | Wildcard cert for ndd.fr will be requested
swag    | E-mail address entered: XXX@gmail.com
swag    | dns validation via ovh plugin is selected
swag    | Generating new certificate
swag    | Saving debug log to /var/log/letsencrypt/letsencrypt.log
swag    | An unexpected error occurred:
swag    | requests.exceptions.ConnectionError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f7e6afb8f70>: Failed to establish a new connection: [Errno -3] Try again'))
swag    | Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
swag    | ERROR: Cert does not exist! Please see the validation error above. Make sure you entered correct credentials into the /config/dns-conf/ovh.ini file.

Le log de Let's encrypt est vide.

Mon ovh.ini est a priori ok (j'ai fait plusieurs appli et les ai supprimé puisque ca ne fonctionnait pas en me basant sur la conf proposé par .shad. et par Oracle7 dans son autre tuto)

Entre temps, j'ai supprimé les certificats HTTP-01 de mon ndd sur DSM

Si quelqu'un a une idée de ce que je pourrais tester, voir s'il manque des infos que je pourrais vous donner...

Bonne soirée
 

Modifié le 18 décembre 20213 a par Taribam

Ok, je suis un gros looser...

Mon DNS est sur le NAS, donc, j'ai remplacé l'adresse DNS par l'ip virtuelle... Ca fonctionne nettement mieux...

Est-ce que les informations auraient pu être plus claires dans le tutoriel à ce sujet ?

Non, pas particulièrement... Tu as bien dit et répété qu'en macvlan, les conteneurs ne pouvaient pas joindre l'adresse ip du NAS. Avec les logs, j'ai vu que swag n'arrivait pas à joindre let'sencrypt, je me suis donc connecté au conteneur, ping de google.fr KO, et ping de l'adresse IP de google OK... donc problème DNS.

J'ai donc vérifié ma conf réseau et j'avais forcé le DNS du synology. Je ne pense pas que tu puisse gérer toutes les confs de tout le monde 😅

En tout cas merci pour la découverte de docker.

Je profite de la réponse pour exposer un petit soucis... 😇  => je laisse le texte que j'ai écrit au cas où ca serve a quelqu'un

Je viens de faire ma première conf nginx sur un conteneur et étonnamment, pas de problème depuis internet, par contre, j'ai un 403 en local... 

Il faut faire pointer le DNS sur le conteneur 😅

 

Modifié le 19 décembre 20213 a par Taribam

Bonjour !

j'ai un petit problème pour configurer swag pour guacamole. En effet, mon guacamole.subdomain.conf ne prend pas en compte le "/guacamole" en bout d'URL. 

url pour se connecter à guacamole : guacamole.ndd.fr/guacamole

j'ai bien essayé de l'ajouter au bout du proxy_pass, mais ca ne fonctionne pas.  

Modifié le 23 décembre 20213 a par Taribam

Pour clarifier si tu mets juste guacamole.ndd.tld sans le /guacamole ça fait quoi ?

Bonjour,

 

Avec SWAG avez-vous réussi à activer les règles NGINX avec GEOIP2 lite ?

J'ai essayé de mettre en place mais j'ai cette erreur :

"nginx: [emerg] "map" directive is not allowed here in /config/nginx/geoip2.conf:1"

Mon fichier geoip2.conf :

map $geoip2_data_country_iso_code $denied_highrisk {
    default yes; #If your country is listed below, remove it from the list
    CN no; #China
    RU no; #Russia
    HK no; #Hong Kong
    IN no; #India
    IR no; #Iran
    VN no; #Vietnam
    TR no; #Turkey
    EG no; #Egypt
    MX no; #Mexico
    JP no; #Japan
    KR no; #South Korea
    KP no; #North Korea
    PE no; #Peru
    BR no; #Brazil
    UA no; #Ukraine
    ID no; #Indonesia
    TH no; #Thailand
 }

 

@CHILLY996 Si ça peut aider :

Moi j'ai ajouté une règle personnalisée dans le fichier général geoip2.conf :

map $geoip2_data_country_iso_code $allowed_frbe {
    default no;
    BE yes;
    FR yes;
}

Puis j'ai créé un fichier geoip2_frbe.conf, avec ce contenu :

## Allow FR-BE

# By-pass for RFC1918 private subnets
if ( $lan-ip = yes ) {
    set $allowed_frbe yes;
}

# Block everything else
if ( $allowed_frbe = no ) {
    return 403;
}

Puis dans les entrées de proxy inversé pour lesquelles je veux avoir un géo-blocage pour mon VPS :

    [...]

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

    # enable GeoIP bloking
    include /config/nginx/geoip2_frbe.conf;

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

    [...]

Modifié le 25 décembre 20213 a par .Shad.

Merci @.Shad.. je vais faire des tests.

Dans le fichier nginx.conf j'avais ajouté la ligne "include /config/nginx/geoip2.conf;" pour éviter d'avoir à mettre le filtrage GEOIP dans toutes les entrées proxy inversées.

Tu as utilisé une clé API pour la mise à jour de la base de données GEOIP ?

Je constate que mon répertoire est vide dans le dossier geoip2.

Modifié le 26 décembre 20213 a par CHILLY996