.Shad.

Oui il faut être premium en effet ! Et pour le script il faut que je vois avec lui s'il l'a toujours je reviens vers toi.

Il y a du boulot mais pas tant que ça je pense pour un initié ^^ Reste à le trouver !

Tu as un paquet appelé Centre des journaux dans DSM, s'il n'est pas installé fais-le, ça pourrait fournir des informations utiles entre deux périodes d'accessibilité.

Mince oui désolé 😛

Leur tutoriel n'est pas obsolète car il englobe en plus le redémarrage des paquets après l'installation du nouveau certificat. 😉 Ce sur quoi je bosse couvre le mode DNS manuel (je te laisse regarder sur le github de acme.sh), donc sans passer par une api pré-configurée. La vraie bonne méthode est de créer sa propre API pour son serveur DNS, si on héberge notre zone nous-même, ou d'utiliser le DNS alias mode si on a un 2ème nom de domaine avec une API. Mais la première est hors de ma portée, la seconde n'est pas applicable à tous.

Du côté de @Jeff777 et moi on a un script d'automatisation en cours pour le mode DNS manuel (donc typiquement si vous hébergez votre zone publique sur votre NAS), ça marche avec le nameserver primaire mais on bloque encore sur le notify pour que le nameserver secondaire (en esclave) rafraîchisse sa zone.

Bienvenue parmi nous 🙂

Ça ressemble fort à un conflit d'adresse IP ton histoire quand même, pour que tous les services rencontrent des problèmes... Tu peux faire un reset simple (mode 1) du NAS, ça reset le mot de passe admin et la configuration réseau repasse en DHCP. Synology Assistant t'aidera à retrouver ton NAS. https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS

Je parlais de la redirection sur DSM évidemment, pas d'une translation de port. Après on préfère l'utilisation d'un proxy inversé que d'ouvrir des ports supplémentaires sur sa box (dans le cas présent, il te faut transférer le port 5001 ou/et 5000 de ta box vers le NAS si tu veux accéder à son interface d'administration sans passer par un VPN, un proxy inversé n'utilisera qu'un seul et même port pour tous tes services, sur le NAS ou un autre périphérique).

http://ndd.tld:5000 ou https://ndd.tld:5001 pour être plus précis. C'est seulement si tu as mis en place une redirection 80 -> 443 que https://ndd.tld t'amènera vers Webstation. Ça suppose que la zone DNS de ton domaine soit correctement configurée également (pour que ndd.tld pointe vers l'IP de ton NAS ou ton IP publique si tu tentes de l'atteindre en externe).

Bienvenue, Il y a toute la lecture nécessaire sur le forum pour te dépatouiller.

Ça a quand même un an ce post 😉 Je doute que ce soit encore dispo ^^

Ah c'est sûr ça fait un sacré bon de génération 😛

À partir de moment où tu n'autorises pas l'IPv6 dans ton réseau macvlan, laisser l'interface virtuelle telle quelle ne changera rien 😉

Ici : https://docs.docker.com/network/macvlan/ Tu as défini l'équivalent IPv6 de tes réglages IPv4 ?

@jacaj : Je ne me lasse pas de tes analyses, je dois comprendre 15% peut-être mais ça me donne envie de m'investir en électronique 😛

Peut-être la liste des utilisateurs et des groupes et leurs droits, pour peu que ce soit un peu chiadé.

Alors commence par lire le tutoriel, ça ne résoudra pas tous tes problèmes, tu trouveras dans la pages suivantes du tutoriel @bruno78 qui a partagé sa configuration de Pi-hole en macvlan, ça peut être instructif 🙂 @bagu: c'était moi qui avais dit ça 😛 et je m'étais trompé j'avais vérifié entre temps car j'avais un doute et j'ai oublié de le stipuler ici 😞

Et tu as parfaitement raison. Il est préférable de faire une sauvegarde de tes données, partir d'une installation propre, et réimporter les données. Ça peut être fait manuellement ou avec HyperBackup (quoique est-ce que ça existe déjà sur le ds211j ?)

@bagu Pi-hole fait du cache DNS, et même résolveur DNS local (pas serveur DNS local, ce n'est pas un serveur autoritaire, mais pour du local on s'en fiche normalement). La seule limite si tu ne mets pas en place l'interface virtuelle c'est que le NAS ne sache pas contacter Pi-hole. En aucun cas ça ne t'empêche d'accéder à l'interface d'administration depuis n'importe quel autre périphérique, donc le problème est autre. 😉 @anorec Il n'y a pas plus simple qu'un Raspberry Pi, surtout si tu commences par l'installation graphique. Et pour installer c'est autrement plus simple, il faut taper en SSH : curl -sSL https://install.pi-hole.net | bash Et c'est tout, tu suis ensuite les instructions. Ce n'est pas pour te dissuader loin de là, arriver à faire tourner Pi-hole sur son NAS de manière tout à fait fonctionnelle est un bel exercice d'apprentissage, je te fais simplement part d'une solution qui me semble bien plus abordable dans un premier temps. 🙂

Avant de se lancer dans une entreprise comme Pi-hole via docker avec pilote macvlan, qui n'est pas une mince affaire pour un non-initié, je conseille la lecture du tutoriel sur Docker : Et je précise toujours qu'il est préférable d'utiliser un Raspberry Pi pour Pi-hole, c'est simple et c'est totalement prévu pour. Quitte à prévoir une instance en backup sur le NAS au cas où le Raspberry flancherait. Et il peut également faire DNS secondaire (bind9 avec une zone DNS esclave de celle du NAS). C'est top un Raspberry Pi pour se faire la main !

Pour l'accès à tes NAS, tu peux t'orienter vers un proxy inversé (reverse proxy), il y a un tutoriel à ce sujet dans la section Tutos. Pour les IP fixe de tes NAS, tu peux faire une réservation d'IP en fonction de la mac adresse de la carte réseau d'un périphérique dans toutes les box de FAI normalement. C'est beaucoup mieux que de fixer l'IP statiquement dans DSM.

Je confirme, si à 33 ans tu es largué... 😄 C'est plutôt là où on est le plus apte à 33 ans, on a déjà un bagage technique et encore toute sa tête ! (pour certains)

Ton proxy inversé écoute déjà sur ce port, donc il faut faire appel à ce qu'on appelle du partage de port, tu peux googler ça pour en apprendre plus, et un sujet en parle sur ce forum : Mais je pense qu'il faut avant tout bien comprendre pourquoi le pour et le contre, certainement pas pour juste avoir un sous-domaine personnalisé : Les + - Si tu fais passer le trafic par le port 443 en TCP, tu noies des données (qui sont déjà chiffrées au passage) dans le reste des données chiffrées passant par ton proxy inversé en entrant et les requêtes https en sortant. C'est plus difficilement traçable. - Le trafic passant par un port TCP est plus stable que par un port en UDP (plus adapté aux petites connexions type ADSL). - Le port 443 est très rarement bloqué, donc possibilité de se connecter depuis le travail, un wifi d'entreprise, etc... Les - - Le trafic via TCP est plus lent que par UDP - Il est plus difficilement traçable, donc si tu veux faire une capture de paquets, ce sera plus compliqué que sur le port 1194. - Il faut mettre les mains dans le cambouis pour le partage de port si le port 443 est déjà utilisé sur la machine hôte du serveur OpenVPN. Il te faut juger de l'intérêt de la manipulation au regard de ce genre de critère, pour ma part je pense que ça n'en vaut pas spécialement la peine, sauf si tu y trouves un intérêt ludique ! 🙂

Bienvenue parmi nous !