.Shad.

Pour le script de création du réseau, ça me semble pas mal, perso je n'ai réussi à créer qu'un seul réseau macvlan pour un port ethernet donné du NAS. Donc à ta place je ne ferais pas un /32 dans l'ip-range, histoire d'avoir quelques IP disponibles au cas où. Peut-être un /28 (13 IP dans ma config) ? vérifier avec un calculateur d'IP que tu ne chevauches rien. Attention par contre dans le script de création de l'interface, tu as mis 192.168.0.100/32 pour l'IP virtuelle. Dans le script de création du réseau macvlan, les IP dans ip-range sont les IP disponibles pour les conteneurs. L'IP virtuelle sera une "deuxième" IP du NAS (que tu verras par exemple dans Synology Assistant). Elle ne doit donc pas être comprise dans l'ip-range. J'ai une tâche planifiée qui exécute un script permettant de remonter effectivement l'interface à chaque redémarrage : #!/bin/sh # Script permettant la communication entre # un conteneur appartenant a un reseau macvlan et son hote # A lancer au demarrage de l'hote # Creation de l interface macvlan sur l hote ip link add mac0 link eno1 type macvlan mode bridge # Configuration de l interface avec l adresse reservee ip addr add 192.168.100.205/32 dev mac0 ip link set dev mac0 address 00:aa:bb:cc:dd:01 ip link set mac0 up # On fait une route entre les IP du reseau macvdef et l'interface ip route add 192.168.100.160/28 dev mac0

Alors chez moi ça marche maintenant, mais mon conteneur SWAG est sur une autre machine physique. Je pense que le fait d'utiliser un réseau macvlan peut potentiellement jouer un tour à DSM. 😉 A tester 🙂 mais dans ce cas-là il te faudra bien créer une interface virtuelle, pas comme dans mon tutoriel (que j'éditerai d'ailleurs, sinon fail2ban inutilisable pour tout ce qui est hébergé sur du Synology), et le backend ne sera plus l'IP physique actuelle mais l'IP virtuelle. Au cas où, je reprends la procédure à la fin de mon tutoriel introductif (voir signature).

A première vue, DSM 7 est moins exigent en ressource que que DSM 6. Mais je te conseillerais d'attendre la version officielle, il n'est pas facile de downgrader de 7 à 6. Le double reset supprime et réinstalle DSM oui, donc tu gardes toutes tes données, mais tu dois tout re-paramétrer. En revanche, il y a possibilité d'exporter les paramètres de configuration en amont, au risque de te trimballer le réglage foireux qui plante SSH. Si c'est juste un problème de fichier corrompu ou non fonctionnel, l'export de configuration ne l'embarquera normalement pas. En revanche si c'est un réglage dans DSM qui est la cause de tes désagréments, ça te suivra sûrement en cas de réimportation de la configuration. Sinon méthode à l'ancienne, des copies d'écran des menus importants. 😉

Hello, Tu dis en gros qu'avec un certificat wildcard pour *.ndd.net, tu as un avertissement de sécurité pour *.subx.ndd.net ? Ok, c'est possible, je t'avoue que je n'ai jamais eu à faire cela, c'est bon à savoir. 🙂

Bienvenue parmi nous ! 🙂

Je n'ai jamais dit que c'était une IP : Pour les deux options, pour moi c'est à utiliser seulement si on utilise un domaine réservé au lan : local.lan, lan, local, home, etc... Pour le domaine du DHCP, c'est un domaine qu'ajoute le serveur DHCP à tout nom d'hôte qu'un périphérique lambda propose lorsqu'il soumet une requête dhcp. Par exemple, mon Raspberry Pi a un hostname : raspberrypi, lors qu'il fait sa demande DHCP. Le serveur DHCP le rend accessible par ce nom d'hôte suivi du domaine qu'il est chargé de distribué. Supposons que je choisisse le domaine local, alors mon Raspberry Pi sera joignable en tapant raspberrypi.local.

Un certificat SSL est délivré pour un nom de domaine en particulier, un domaine que tu possèdes (Synology en fournit un gratuitement). Si tu utilises la synchro depuis l'extérieur vers ton NAS, je te conseille de te procurer un certificat Let's Encrypt directement dans DSM. Pour son obtention, tu trouveras facilement l'information sur le forum ou par Google. Ensuite il faudra que tu entres ce nom de domaine dans Synology Drive client, en t'assurant que l'adresse pointe bien sur ton NAS.

Tu as raison, j'observe le même comportement pour DSM, c'est l'adresse de mon proxy inversé qui est détectée dans le journal des logs, pas le PC que j'utilise. Comme toi, je ne trouve rien de probant, et effectivement ça ne me fait ça qu'avec Synology. Je vais continuer de chercher.

Bienvenue parmi nous !

Oui je n'ai pas précisé qu'il fallait faire ces opérations en tant que super utilisateur, ou en root directement, parce que ça me semblait évident, my bad. Si malgré tout, ça ne fonctionne pas, je pense que tu devrais faire un ticket auprès du support Synology, et si toujours rien, un reset mode 2, voir ici : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS

Bienvenue parmi nous !

Bienvenue parmi nous 😉

Première option : Réseau local en CIDR, donc par exemple 192.168.1.0/24 Deuxième option : IP du serveur DHCP Troisième option : Domaine poussé par le serveur DHCP, défini dans les paramètres de ton serveur DHCP normalement. Les noms d'hôte ne sont pas demandés dans ces champs.

Je pense que ça peut venir du fait que tu sois en bridge. Essaie ce que je propose dans le tutoriel, tu mets swag en macvlan, et si tu n'as pas mis en place d'interface virtuelle pour communiquer avec le NAS, tu rejoins aussi un réseau bridge comme je le propose, et tu te serviras de l'IP passerelle de ce réseau pour communiquer avec tes applis Synology. Parce que du coup moi quand je NAT depuis le routeur, c'est vers l'IP du conteneur dans son réseau macvlan, il n'y a pas de NAT hôte-conteneur nécessaire comme en bridge. A mon avis le NAT hôte-conteneur n'y est pas pour rien.

Quand tu NAT vers d'autres périphériques que le NAS tu n'as pas ce problème ?

Je trouve les listes par défaut déjà suffisantes, mais tu trouveras des listes au fil de ce sujet. Attention que plus tu en ajoutes, plus les risques de faux-positifs se présentent.

Tu peux montrer tes informations de connexion dans Synology Drive, l'agent Windows (à quelle IP il se connecte, ou nom d'hôte) ? Est-ce que tu utilises un VPN sur ton NAS (en tant que client) ?

Maintenant, si tu veux avoir les noms d'hôte plutôt que les IP, tu vas dans Settings -> DNS -> tu vas tout en bas dans conditional forwarding. Là tu rentres les 3 informations qu'il te demande, tu valides et tu attends quelques minutes, tu devrais voir les noms d'hôte apparaître à la place des IP.

Non normalement c'est bon, car chez toi le port 53 est redirigé depuis la box vers ton serveur DNS qui héberge ta zone publique, et pas pi-hole, donc pas de risques. Cela dit les 2 premières options suffisent normalement dans ton cas. J'avais dans l'idée que en changeant le réglage ici, tu pouvais voir un "hop" plus loin que le serveur DNS, car oui là il voit tout arriver depuis le serveur DNS, vu qu'il intervient avant dans la chaîne de résolution. C'était une solution que je proposais à @oracle7 car il n'arrive pas à se défaire de sa case grisée. Dans ton cas tu as tout intérêt à faire intervenir Pi-hole en premier dans la chaine de résolution : Périphérique => Pi-hole => Serveur DNS => Redirecteurs Ainsi tu verras la liste de tous les périphériques de ton réseau, enfin les IP car il faut aussi configurer le conditional forwarding dans le même onglet Settings -> DNS de Pi-hole pour voir les noms d'hôte tels qu'enregistrés dans le serveur DHCP. Ou alors tu passes des variables dans le fichier compose, comme tu peux le voir sur l'exemple que j'avais donné de mon fichier compose pour Pi-hole un peu plus haut.

Alors le fail2ban je ne l'ai pas installé sur le NAS, car je me connecte en SSH chez moi depuis l'extérieur uniquement via mon serveur debian, qui n'accepte qu'une clé publique. Et lui possède les clés pour mes différents NAS et périphériques du réseau. Par contre je l'utilise sur mon VPS, et là en faisant une configuration identique : On voit bien les IP publiques qui sont bannies dans les logs remontés par Loki. Pour les applications, où tu passes par le proxy inversé, normalement /config/nginx/proxy.conf contient : proxy_set_header X-Real-IP $remote_addr; Et les fichiers de configuration dans /config/nginx/proxy-confs/ y font appel via un include : # for Synology DSM GUI server { listen 443 ssl; listen [::]:443 ssl; server_name dsm-ds918.*; 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; resolver 127.0.0.11 valid=30s; set $upstream_app ds918.ndd.tld; set $upstream_port 5000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Si je regarde les logs d'Emby, en me connectant en 4G avec mon smartphone : 2020-12-10 22:42:53.392 Info Server: http/1.1 Response 200 to 178.144.167.69. Time: 4ms. http://emby.ndd.tld/Items/49541/Images/Thumb?maxWidth=509&tag=29287fdde9c02f68f2e9d1928219d32a&quality=90 2020-12-10 22:42:53.468 Debug ImageProcessor: Image encoding to /config/cache/images/resized-images/1/14c9ca76-8074-cb88-71f7-6d6f09060a08.webp took 75ms for /config/metadata/library/df/df0881c61686b56c0fd4a14516bb68f8/landscape.jpg 2020-12-10 22:42:53.468 Info Server: http/1.1 Response 200 to 178.144.167.69. Time: 76ms. http://emby.ndd.tld/Items/49525/Images/Thumb?maxWidth=509&tag=dd3e4629b2a834901fc1372408ed0966&quality=90 Les logs de pfSense : Dec 10 23:55:24 php-fpm 43363 /index.php: Successful login for user 'username' from: 192.168.100.105[178.144.167.69] (Local Database) Dans tous les cas on voit l'IP réelle, vérifie donc déjà que tu inclus bien cette directive dans ta config Nginx, mais par défaut c'est le cas normalement. J'avoue que je ne vois pas le rapport avec Synology, car ici tu translates directement depuis ton routeur vers ton conteneur swag, pour moi c'est transparent.

Tu as quoi dans Settings -> DNS ->

Càd ? Tu ne vois que l'IP des serveurs DNS locaux dans tes clients sur Pi-hole ?

Honnêtement pas la moindre idée, l'autorité de certification qui délivre le certificat n'entre pas dans la ronde d'acme normalement (du script j'entends).

A partir du moment où tu ajoutes un fichier, et que tu n'édites pas un fichier existant, je pense que ça devrait tenir d'une màj à l'autre (en tout cas pour les mineures, pour les sauts de version c'est effectivement moins certain 🙂).

J'ai trouvé ça, si ça peut t'aider (mais ce n'est pas très exhaustif non plus) : https://community.synology.com/enu/forum/17/post/2623 EDIT : Encore mieux : https://www.synology.com/fr-fr/knowledgebase/DSM/help/WebStation/application_webserv_general (à la fin de l'article)