MilesTEG1

Bon, un jour à l'occasion, je te demanderais probablement de l'aide à ce sujet ^^ Mais là ce n'est pas la priorité. 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... 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 ?) Ok donc c'est pas forcément le MOD à installer en priorité, sauf pour utiliser le dashboard nginx 😄 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 😇

@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... Ok, je comprends ^^ 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. 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). 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 🙂 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 ? 🤗😇

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

@.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...)

@.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 ?

Ok je laisse le.* 😁 pourquoi dsm met le domaine complet du coup ? 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.

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 ?

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. 😅

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… 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 🤪 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. 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; ?

Si, mais je le met où le serveur SMTP que je veux utiliser ainsi que mon mot de passe pour le serveur SMTP ? Autre chose, pour la configuration de NGINX : je veux modifier le fichier ngonx/ssl.conf Faut-il en faire un .local avec mes modifications ? Ou bien la modification du .conf est pérenne ? (genre après un reboot c'est pas remis à zéro)

Ha non pas du tout sûr ^^ C'est à confirmer/infirmer 🙂

Merci pour ces infos. J'essaye dès que je peux de créer une configuration pour une application. Mais sinon, je vois un soucis avec le fail2ban intégré : je ne vois pas comment spécifier un mot de passe pour l'envoi de mail... ni de serveur SMTP... bref, on peut paramétrer l'adresse email dans le jail.local, mais pour les paramètres serveurs smtp, je ne vois pas ... Comment fais-tu ?

Attention tout n’est pas sauvegardé via ce menu. déjà les données ne le sont pas , il faut utiliser hyperbackup pour les sauvegarder. ensuite il n’y aura que certains paramètres de dsm et peut être de quelques paquets qui seront sauvegardé. Il faut regarder l’aide en ligne pour savoir exactement quoi. il faut aussi savoir qu’une sauvegarde faite avec dsm 6.2.x n’est pas utilisable avec un dsm 7.0. Je dis ça car le nas actuel est probablement vieux et en dsm 6.x. Le futur nas ne le sera probablement pas. mais bon on n’a pas d’info sur le nas actuel ni sur le futur successeur. Ni même ce qui adviendra des disques durs. il faudrait davantage d’informations.

@.Shad. J'ai redémarré SWAG, et je n'ai plus les lignes d'erreur grep 🙂

@.Shad. Pour les grep qui trouvent pas les fichiers, ils sont bien présents (ce matin en tout cas 😅) : Du coup, je ne sais pas pourquoi hier soit ils n'y étaient pas soit le grep retourne qu'ils n'y sont pas... Tu veux dire que je remplace les réécritures dans AdGH pour qu'elles pointent vers l'adresse IP de SWAG ? Si c'est ça, ça peut en effet se faire facilement pour tester ^^ (bon faudrait que je laisse certains services gérés par le NAS = Plex sinon ça va gueuler ) J'utlise bien Vaultwarden et pas Bitwarden. Actuellement j'ai un script qui modifie le fichier de conf de nginx de DSM pour ajouter les blocs pour les websockets notifications. Ce que je voulais dire par "modifier les fichiers de conf fournis par swag", c'est que mes conteneurs ne sont pas dans le réseau macvlan de SWAG, ils sont pour la plupart en bridge, et quelques un en HOST. D'ailleurs, dans SWAG, c'est quelle adresse IP que je devrais mettre pour envoyer vault.mon-ndd.ovh vers la bonne adresse_IP:port ? Je mets l'IP réelle du NAS ? Ou bien l'IP virtuelle ? Je me rends compte que dans AdGuard Home (aussi en macvlan), la réécriture que j'ai paramètré est l'IP réelle du NAS... et ça fonctionne... Est-ce normal ? Haaa OK ! Donc son domaine d'intervention est limité alors... il ne pourra pas joindre l'IPTABLE du NAS ? Malgré le : cap_add: - NET_ADMIN Je n'ai pas bien saisi ce que tu veux dire... (trop de négation 🤪). Pourrais-tu reformuler ? Ce que tu appelles le fail2ban du NAS, c'est ce qui est configurable via DSM n'est-ce pas ? (blocage auto) Merci encore pour ton aide 🙂

https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7 Petite recherche rapide 😁

@.Shad. Voilà, j'ai créé mon conteneur SWAG. Il y a quelques erreurs dans le log (avec les grep), mais apparemment sans conséquence sur la création du certificat. J'ai créé une nouvelle API avec tes permissions (qui sont différentes de celles que j'ai utilisé pour ACME mais tant que ça fonctionne 😉 ) Bon pour le moment j'ai pas redirigé le port 443 vers swag, je ferais ça plus tard, car va falloir configurer les entrées du reverse proxy... j'ai regardé dans les fichiers de conf proposés, va falloir que j'adapte pas mal, notamment pour Vaultwarden... (je viendrais probablement te poser des questions quand je me lancerais ^^) Questions pour Fail2Ban : le conteneur SWAG possède une instance complète de F2B ? Je pourrais désinstaller complètement celle que j'avais mis en place avant ? Est-ce que l'instance dans SWAG est peu ou prou identique au nouveau conteneur qu'ils ont publié récemment : https://github.com/linuxserver/docker-fail2ban. (voir aussi les confs : https://github.com/linuxserver/fail2ban-confs ) Plus tard, je mettrais en place Authelia ^^ Et j'espère CrowdSec si j'y arrive 😉 Voilà le log du conteneur : Brought to you by linuxserver.io ------------------------------------- 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: 1010 User gid: 100 ------------------------------------- cont-init: info: /etc/cont-init.d/20-config exited 0 cont-init: info: running /etc/cont-init.d/30-keygen generating self-signed keys in /config/keys, you can replace these with your own keys if required Generating a RSA private key ............................+++++ ..+++++ writing new private key to '/config/keys/cert.key' ----- cont-init: info: /etc/cont-init.d/30-keygen exited 0 cont-init: info: running /etc/cont-init.d/50-config Variables set: PUID=1010 PGID=100 TZ=Europe/Paris URL=mon-ndd.ovh SUBDOMAINS=wildcard EXTRA_DOMAINS= ONLY_SUBDOMAINS=false VALIDATION=dns CERTPROVIDER= DNSPLUGIN=ovh EMAIL=mon-email@provider.com STAGING=false grep: /config/nginx/resolver.conf: No such file or directory Setting resolver to 127.0.0.11 Setting worker_processes to 4 Created .donoteditthisfile.conf Using Let's Encrypt as the cert provider SUBDOMAINS entered, processing Wildcard cert for mon-ndd.ovh will be requestedndd.ovh E-mail address entered: mon-email@provider.com dns validation via ovh plugin is selected Generating new certificate grep: /config/nginx/worker_processes.conf: No such file or directory Saving debug log to /var/log/letsencrypt/letsencrypt.log Account registered. Requesting a certificate for *.mon-ndd.ovh and mon-ndd.ovh Waiting 120 seconds for DNS changes to propagate Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/mon-ndd.ovh/fullchain.pem Key is saved at: /etc/letsencrypt/live/mon-ndd.ovh/privkey.pem This certificate expires on 2022-11-10. These files will be updated when the certificate renews. NEXT STEPS: - The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you like Certbot, please consider supporting our work by: * Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate * Donating to EFF: https://eff.org/donate-le - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - New certificate generated; starting nginx The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am). cont-init: info: /etc/cont-init.d/50-config exited 0 cont-init: info: running /etc/cont-init.d/60-renew cont-init: info: /etc/cont-init.d/60-renew exited 0 cont-init: info: running /etc/cont-init.d/70-templates cont-init: info: /etc/cont-init.d/70-templates exited 0 cont-init: info: running /etc/cont-init.d/90-custom-folders cont-init: info: /etc/cont-init.d/90-custom-folders exited 0 cont-init: info: running /etc/cont-init.d/99-custom-files [custom-init] no custom files found exiting... cont-init: info: /etc/cont-init.d/99-custom-files exited 0 s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service init-mods: starting s6-rc: info: service init-mods successfully started s6-rc: info: service init-mods-package-install: starting s6-rc: info: service init-mods-package-install successfully started s6-rc: info: service init-mods-end: starting s6-rc: info: service init-mods-end successfully started s6-rc: info: service init-services: starting s6-rc: info: service init-services successfully started s6-rc: info: service legacy-services: starting services-up: info: copying legacy longrun cron (no readiness notification) services-up: info: copying legacy longrun fail2ban (no readiness notification) services-up: info: copying legacy longrun nginx (no readiness notification) services-up: info: copying legacy longrun php-fpm (no readiness notification) s6-rc: info: service legacy-services successfully started s6-rc: info: service 99-ci-service-check: starting [ls.io-init] done. s6-rc: info: service 99-ci-service-check successfully started Server ready

Pourtant le SHR n'est pas une sauvegarde ! https://www.futura-sciences.com/tech/definitions/sauvegarde-sauvegarde-18146/ https://fr.wikipedia.org/wiki/Sauvegarde_(informatique) Si ton NAS rend l'âme avec les disques durs, tu n'as plus aucune données ! Donc le RAID n'est pas une sauvegarde... Tu fais cette erreur comme la plupart des personnes novices avec un NAS.

@CyberFr Il va falloir mettre à plat tous tes réglages : reverse proxy quels paquets installés ? (webstation ? Apache ? PHP ? quelles versions ?) Dans les paramètres DSM, as-tu coché une case HTTP -> HTTPS ?? (ça merde depuis DSM 6.x... il faut passer par un .htaccess sur le nas si tu as webstation installé). Fait des captures d'écran. Mais dans un nouveau sujet ^^ car là on est un peu HS vis-à-vis du sujet concernant Adguard home.

Tu peux définir exactement ce qui ne fonctionne pas ? Pour quel domaine ?

@.Shad. Je suis d'accord 🙂

@PiwiLAbruti Attention à ne pas mélanger les différents AdGuard ! Ça va créer de la confusion chez @CyberFr AdGuard Home : serveur DNS qui filtre les pub, exclusivement LAN, pas besoin de configurer chaque machine si l'IP de ce serveur DNS est mise dans le serveur DHCP AdGuard-dns.io : serveur DNS (gratuit avec nombre de requêtes limités ou payant en illimité), utilisable en 4G aussi bien qu'en LAN (mais nécessite de configurer chaque périphérique ou navigateurs pour avoir les statistiques par machines) Il y a un équivalent à AdGuard-dns.io : c'est NextDNS, avec les mêmes avantages/inconvénients. Ici @CyberFr veut utiliser le AdGuard Home, donc dans son LAN. Il semble avoir d'autres soucis pour utiliser son nom de domaine depuis l'extérieur, et il faudrait qu'il créer un nouveau sujet avec ^^

@bliz 1. Tente de redémarrer la box. 2. Si ça résout pas le soucis, réinitialise la box. 3. Si ça ne résout toujours pas le soucis... achète un vrai routeur et met le DMZ dans la box. 😅

Il n’y a pas de fichier ovpn avec une connexion L2TP. Vérifie que cette règle soit bien placée en haut de la liste du pare-feu. fait aussi une capture des règles du pare-feu 😉