@Lunav montre nous le .conf d’un de tes domaines qui pose souci.
Je pense qu’il te manque un entête (header) dans ta configuration.
Édit : ton conteneur swag est-il installé en mode bridge ? Auquel cas j’ai peur que ça ne soit peine perdue pour avoir autre chose que l’adresse iP du conteneur.
Il fault qu’il soit En host ou en macvlan.
@Lunav montre nous le .conf d’un de tes domaines qui pose souci.
Je pense qu’il te manque un entête (header) dans ta configuration.
Édit : ton conteneur swag est-il installé en mode bridge ? Auquel cas j’ai peur que ça ne soit peine perdue pour avoir autre chose que l’adresse iP du conteneur.
Il fault qu’il soit En host ou en macvlan.
Mon container été bien en mode bridge. J'ai donc créer un sous réseau propre à swag dans lequel j'ai ajouter tous les containers que je veux avoir derrière mon reverse proxy et désactivé l'option ip masquerable de ce sous réseaux. Mais je n'est pas mis swag dans mon réseaux host.
J'aurais aimais que ca marche mais si je dois absolument autoriser swag à accèder au réseau host de ma machine je le ferais.
Voici mon fichier nextcloud.conf qui considère que tout le trafic viens de mon ip interne au container swag :
location ^~ /nextcloud/ {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app nextcloud;
set $upstream_port 443;
set $upstream_proto https;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
rewrite /nextcloud(.*) $1 break;
proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;
proxy_ssl_session_reuse off;
# Hide proxy response headers from Nextcloud that conflict with ssl.conf
# Uncomment the Optional additional headers in SWAG's ssl.conf to pass Nextcl
oud's security scan
proxy_hide_header Referrer-Policy;
proxy_hide_header X-Content-Type-Options;
proxy_hide_header X-Frame-Options;
proxy_hide_header X-XSS-Protection;
# Disable proxy buffering
proxy_buffering off;
}
Je me fiche un peut de nextcoud car il n'y a rien de sensible dessus et surtout il à déjà sa propre politique de sécurité. Mais j'ai d'autres services comme vautwarden où j'aimerais pouvoir mettre des restrictions supplémentaire en interdisant par exemple plus d'une erreur et bannissant 1d l'ip sinon ou autre mais c'est impossible tant que les ip affiché dans ses log est toujours celle de swag
@Lunav
En mode bridge, même si tous les conteneurs sont dans le même réseau, tu auras encore le souci...
Et utilises, s'il te plait, la balise code pour choisir la coloration syntaxique souhaitée, ici NGINX.
[Wiki] Astuces / Aides pour la navigation / utilisation du Forum des NAS Bonjour, je vous propose de regrouper ici quelques astuces pour l'utilisation de notre forum favoris ! Principalement dans le but d'aider les nouveaux. Le sujet restera fermé afin que celui-ci reste organisé, et se...
www.forum-nas.fr
Car là, tu n'as aucune indentation, ni de coloration... ça ne rend pas lisible le code que tu as collé.
J'ai actuellement un DS220+, j'ai changé NPM pour Swag.
J'ai suivi ton super tuto, tout fonctionne bien à part la résolution des IPs.
La seule ip qui ressort de tous les logs pour fail2ban est celle-ci :
172.17.0.1 ⇒ Associer a aucuns containers docker
Au passage, j'ai installé Swag avec le Network Bridge.
Ensuite, j'ai vu quelques commentaires sur la résolution d'ip réel, en passant par un MACVLAN.
J'en ai donc créé un, mais ne fonctionne apparemment pas :
Alors ça pas de soucis, le MACVLAN ce créé, mais une fois que je mets Swag dedans, je n'ai aucuns accès.
Que cela soit 192.168.10.197 ou 192.168.10.197:81 pour le dashboard.
Dernier point, dans les logs de chaque container, j'ai une mauvaise résolution de base d'IP client.
Il me ressort la même 172.17.0.1, je ne vois pas comment résoudre mon problème.
Car du coup, fail2ban ne fonctionne pas parce qu'il me ressort que l'ip ci-dessus.
Je ne pense pas que cela vienne de Swag en Bridge, car les containers me ressorte la même IP que je sois en 4G sur mon téléphone ou non.
Et ADguard Home qui lui est en HOST me résout sans problème les IPs.
Si quelqu'un à une idée, ça fait deux jours que je cherche, mais en vain.
Je pense avoir suivi le tutoriel correctement, mais je rencontre une erreur dans les journaux (logs) de SWAG.
Code:
dns validation via ovh plugin is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for homelio.me and *.homelio.me
Error adding TXT record: Expecting value: line 1 column 1 (char 0)
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.
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.
Je pense avoir suivi le tutoriel correctement, mais je rencontre une erreur dans les journaux (logs) de SWAG.
Code:
dns validation via ovh plugin is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for homelio.me and *.homelio.me
Error adding TXT record: Expecting value: line 1 column 1 (char 0)
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.
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.
Si cela peut aider, j'utilise aussi une DynDNS OVH depuis mon changement d'hébergeur :
J'ai galéré aussi un peu pour le mettre en place :
Au niveau OVH : pour un domaine en mondomaine.fr
Dans l'onglet DynHost, il faut créer un sous domaine, par exemple : dynhost.mondomaine.fr
Dans l'onglet Zone DNS : il faut créer une règle CNAME avec un autre sous domaine qui sera le wildcard pour Swag tel quel.
Je prend le sous domaine 'swag' comme exemple :
To support the app dev(s) visit:Certbot: https://supporters.eff.org/donate/support-work-on-certbot
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID:1000
User GID:1000
───────────────────────────────────────
using keys found in /config/keys
chown: cannot dereference '/config/keys/letsencrypt': No such file or directory
**** Permissions could not be set. This is probably because your volume mounts are remote or read-only. ****
**** The app may not work properly and we will not provide support for it. ****
Variables set:0
0
TZ=Europe/Paris
URL=mondomaine.ovh
SUBDOMAINS=wildcard
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=dns
CERTPROVIDER=
DNSPLUGIN=ovh
EMAIL=monmail@gmail.com
STAGING=
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for mondomaine.ovh will be requested
E-mail address entered: monmail@gmail.com
dns validation via ovh plugin is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for mondomaine.ovh and *.mondomaine.ovh
Unsafe permissions on credentials configuration file: /config/dns-conf/ovh.ini
Error adding TXT record: Expecting value: line 1 column 1 (char 0)
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.
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.
using keys found in /config/keys chown: cannot dereference '/config/keys/letsencrypt': No such file or directory **** Permissions could not be set. This is probably because your volume mounts are remote or read-only. **** **** The app may not work properly and we will not provide support for it. **** Variables set:
Pour moi, cette erreur est la cause de tes soucis.
Tu as bien vérifié que ton utilisateur ayant les ID 1000:1000 avait bien les permissions requises pour accéder au dossier de configuration ?
Car à mon avis, c'est là que se trouve ton problème.
L’intérêt est de n'exposer le conteneur qu'a l'adresse IP de la machine qui l'héberge, sinon par défaut le conteneur est exposé à toutes les adresses par défaut (0:0:0:0) via une règle IPTable qu'il vas créer. De plus sur Portainer, tu peux comme cela accéder directement à ton conteneur en cliquant sur le lien.
C'est bien dit dans la doc officiel :
Code:
Important
Publishing container ports is insecure by default. Meaning, when you publish a container's ports it becomes available not only to the Docker host, but to the outside world as well.
If you include the localhost IP address (127.0.0.1) with the publish flag, only the Docker host can access the published container port.
Bonjour,
Cela fait un bout de temps que je vois des messages passer à propos de Swag et je me demande si cela vaut la peine que je l'installe.
J'utilise (énormément)le reverse proxy de DSM sur mes deux nas. J'ai une wildcard, utilise HSTS, pihole en docker sur chaque nas. Tout fonctionne très bien.
J'ai du mal a estimer si les options supplémentaires fournis par Swag valent la peine que je tente l'aventure. Merci de vos commentaires
