.Shad.

Ça ne remplace pas les VLAN on est bien d'accord. Ça traduit simplement autre chose. Pour les décodeurs (ceux de Proximus en tout cas) il est nécessaire de s'assurer que le PVID correspond au VLAN untagged du signal TV, en plus d'avoir choisi le bon VLAN untagged. Pour les ports tagged, le PVID n'influe plus car les 2 périphériques parlent VLAN et donc ça n'a plus de sens de tagger les paquets entrants avec un VLAN par défaut. PS : pour partager sur plusieurs VLAN un périphérique en untagged, tu as l'option VLAN asymétrique. Très pratique si le périphérique ne sait pas causer VLAN, ça permet d'avoir plus VLAN untagged sur un même port.

Avec Emby j'ai aussi ce genre de problème parfois, en utilisant pourtant la même logique de nommage. Je pense que ça vient plutôt de la base de données dans ce cas-là. 😉

En fait j'y pense, le seul truc que je vois qui pourrait provoquer ce que tu as, c'est que les applications Synology ne s'exposent pas sur l'IP virtuelle. De souvenir, quand on interroge un port non utilisé du NAS il te renvoie DSM...

C'est ce vers quoi je m'orienterais également à ta place. De mon côté je vais essayer de reproduire ton cas d'utilisation, et essayer de comprendre le pourquoi du comment. Je ne vois aucune limitation théorique qui génère ce problème chez toi. Il faudra que j'adapte le tutoriel en conséquence. Merci de ton retour. 😉

Un VLAN isole un réseau d'un autre VLAN, ça tagge les paquets sortants. Pour tagger les paquets entrants dans un port de Switch, c'est sur le PVID que tu dois jouer. Par exemple tu devras mettre un PVID de 2 sur le port 2 de switch-2 qui va vers le décodeur TV. Si le décodeur était capable de causer VLAN, tu n'aurais pas eu besoin d'y toucher.

Belle machine, bon amusement. 🙂

C'est très bizarre, il doit y avoir un problème quelque part, car j'ai aussi installé les package Synocli (super paquets d'ailleurs) et les chemins ont toujours été ajoutés au PATH. PS : Pense à te présenter dans la section adéquate. 🙂

Quand tu fais : source /etc.defaults/profile tu as toujours le même problème ? Parce qu'en l'état pour moi il va juste append les chemins liés à JRE au PATH, je ne vois pas de raison que ça plante.

Bienvenue parmi nous 🙂

Bonjour, On aime bien que les nouveaux membres se présentent avant de poser leurs questions. Ca permet de connaître le matériel de l'utilisateur et son niveau global. Je ne sais pas ce que vous avez fait, mais ce n'est sûrement pas une installation de paquet usuelle, vous avez installé ça en SSH ? Faites un : cat /etc/profile Est-ce que le PATH est correct ici ?

https://eu.dlink.com/be/fr/-/media/business_products/dgs/dgs-1100/datasheet/dgs_1100_05_pd_datasheet_en_eu.pdf Je lis en Maximum power consumption : 23.92W, donc je pense que ça ne conviendra pas si tu es limité à 15W par port. Tous mes switchs D-Link (4) ont deux encoches dans le châssis pour venir y glisser des têtes de vis pour une fixation murale. Je ne l'ai jamais vu mentionné dans aucune fiche technique par contre chez eux.

@Drickce Kangel Comme répondu il y a quelques minutes sur le tutoriel en question, c'est un tutoriel important, avec beaucoup de notions, mais extrêmement intéressant, il te faudra d'autres sources d'informations par contre. Le tutoriel a l'inconvénient que tout étant sur le NAS (proxy inversé, DNS local, applications, ...) on ne distingue pas facilement vers quoi on fait pointer des noms de domaine pour telle ou telle fonctionnalité vu que tout pointe sur la même IP. 😞 Donc te renseigner par ailleurs peut-être intéressant pour avoir un point de comparaison. 😉 Docker tu as franchement le temps 😄 je te conseille de mûrir un peu le reste sinon tu risques d'être submergé.

Salut, Le DHCP ne sert qu'à fournir l'IP de ton NAS (qui héberge une zone DNS) comme DNS primaire à ses clients (dans l'absolu ça fait bien d'autres choses, mais dans le cas qui t'intéresse j'entends). La plupart des box ne permettent même pas changer les DNS que le DHCP (celui de la box) distribue, ce qui n'est pas le cas des Freebox de ce que j'ai pu voir, c'est une très bonne nouvelle. D'un point de vue DHCP tu auras juste à préciser comme DNS primaire (dans les paramètres du serveur DHCP de la box !! pas les paramètres DNS de la box) l'IP de ton NAS. Et tous les périphériques qui obtiennent leur IP via DHCP utiliseront le NAS comme serveur DNS local. Le DNS est sûrement le tutoriel le plus dur à comprendre dans son entièreté sur ce forum, prend le temps de te renseigner comme le préconise Fenrir sur la signification des nombreux termes relatifs au protocole DNS. Les consignes seront déjà moins obscures. 🙂

Celui-ci de Zyxel me semble intéressant : https://www.ldlc.com/fr-be/fiche/PB00230638.html Budget PoE de 60W (30W max par port), 4 ports compatibles PoE, alimentation externe, administrable. Sinon celui-ci chez D-Link : https://www.ldlc.com/fr-be/avis/PB00229809.html, moins cher (-20% jusqu'à ce soir en plus), mais attention !, alimenté également par PoE, donc top si tu as un déjà injecteur à disposition. Je n'ai pas trouvé d'équivalent avec bloc d'alimentation en 5 ports administrable. Le Zyxel me parle plus personnellement.

@Drickce Kangel Tu dois utiliser la fonction Profil de contrôle d'accès intégré à DSM, en définissant les règles qui régissent ce contrôle d'accès, dans ton cas par exemple : Tu peux être plus granulaire en modifiant ce qu'il y a après le /, qui correspond au masque de sous-réseau (cette notation est appelée CIDR). Si par exemple tu ne veux autoriser que les IP 192.168.50.1 à 192.168.50.254, tu écriras 192.168.50.0/24 ou 192.168.50.0/255.255.255.0, c'est équivalent. Si ton serveur VPN est en 10.8.0.1 (OpenVPN sur DSM), tu peux mettre 10.8.0.0/24. Puis penser à refuser tout le reste 🙂 mais seulement en fin de liste, c'est résolu séquentiellement donc comme pour le pare-feu, si tu mets ça en début de liste, tu te bloques. Une fois le profil défini, il faut l'utiliser dans une règle de proxy inversé : Tu valides et normalement c'est bon. Ici tu n'auras accès à DSM que si ta connexion prend son origine sur le LAN ou le VPN, depuis l'extérieur tu auras un message comme quoi la ressource n'est pas accessible.

Compte un switch administrable par endroit où tu as un décodeur + un au niveau de la box et du routeur. Pour moi c'est la solution la plus simple pour ce que tu veux faire. Éventuellement si un jour tu veux isoler tes cameras sur un réseau en particulier (et que ton routeur a un vrai pare-feu, pas juste du NAT), il t'en faudra à la jonction de tes cameras. Perso j'utilise des switch D-Link, c'est très abordable, l'interface est clairement moins fancy qu'Ubiquity, mais ça fait exactement la même chose : https://www.ldlc.com/fr-be/fiche/PB00229813.html

Donc si tu veux essayer de joindre ce qui est hébergé sur le port 80 du NAS : Tu tapes par exemple : https://site.ndd.tld avec site.ndd.tld pointant vers l'IP macvlan du conteneur SWAG (comprise dans ta plage 192.168.0.100/28). Dans SWAG tu rediriges les requêtes site.* vers 192.168.0.112 et sur le port 80. C'est bien ce que tu as ?

Ce que dit @maxou56 c'est ce que j'ai chez moi (voir ce que je disais plus haut) : Schéma très simplifié mais ça illustre le propos. Je n'ai ni OpenWRT ni DD-WRT, j'utilise pfSense, tout simplement parce que j'avais trouvé une excellente affaire en deuxième main, et contrairement à ce que croit @church, je n'ai jamais eu à configurer quoique ce soit via SSH, tout se fait par l'interface (sauf l'installation de l'OS). Il y a une telle appréhension et de préjugés sur ces produits, ça me sidère que la curiosité ne l'emporte pas. Par exemple tu peux t'amuser à créer une VM pfSense sur ton NAS ou n'importe quelle machine, un PC, etc... et faire joujou avec. Pareil avec OPNSense. Bref, prend ton temps pour choisir. 😉

Je ne suis pas le mieux placé pour te répondre, je n'ai pas de RT, je n'ai pas de Livebox. Pour séparer des réseaux un switch administrable suffit, mais ça implique de laisser les décodeurs sur la box, c'est ce que je fais chez moi pour distribuer le VLAN IPTV aux différents décodeurs répartis dans ma maison. Je fais passer dans un même câble le réseau IPTV ayant pour DHCP la box, et le réseau Internet ayant pour DHCP mon pare-feu. Perso à ta place je regarderais ce que fait la concurrence dans la même gamme de prix : https://www.wifi-france.com/mikrotik/rb4011igs-5hacq2hnd-in https://mikrotik.com/product/RB2011UiAS-IN RouterOS est 1000 fois plus capable que SRM. Pareil avec du routeur Linksys, dans la gamme de prix du RT2600AC : https://www.ldlc.com/fr-be/avis/PB00218282.html Tu peux flasher ça avec DD-WRT, et là tu as quelque chose d'extrêmement solide. En plus d'un excellent Wifi.

Même chose ça a l'air réglé. 😉

Ouais donc il faut réexécuter la tâche depuis le planificateur quand par exemple on met à jour le paquet.

Bienvenue parmi nous 🙂

Tournure très maladroite, je voulais dire que que si l'IP de DSM est normalement 192.168.0.100, en créant une interface virtuelle, je pourrai avec un conteneur dans la plage d'IP spécifiée du réseau macvlan (dans mon cas par exemple 192.168.0.140) accéder à DSM via l'interface virtuelle à l'adresse 192.168.0.200 Je profite pour reformuler, merci @EVOTk👌 D'ailleurs j'y pense, mais je pense qu'on peut limiter l'accessibilité à cette interface aux seuls conteneurs sur réseau macvlan, histoire d'éviter d'avoir 2 NAS qui apparaissent dans Synology Assistant, dans l'explorateur Windows, etc... Il suffira de limiter les sources pour cette interface, j'ai un petite idée de comment faire mais il faut que je regarde plus en détail. Pour ton problème, peux-tu remettre ton script de création de réseau macvlan, et ton script de création d'interface, qu'on ait toutes les cartes en main ? 😉 @bruno78 : Pour moi ça paraît étrange qu'un redémarrage de Docker puisse entrainer quoique ce soit. En effet quand tu crées l'interface virtuelle, tu ne fais appel en rien à ce qui concerne Docker, hormis le sous-réseau macvlan : ip link add macvlan-swag link ovs_eth0 type macvlan mode bridge ip addr add 192.168.0.112/32 dev macvlan-swag ip link set dev macvlan-swag address AA:BB:CC:DD:EE:FF ip link set macvlan-swag up ip route add 192.168.0.100/28 dev macvlan-swag Or ce sous-réseau est recréé quand tu redémarres le paquet Docker. Comme je le vois, une fois que l'interface est là elle ne bouge plus jusqu'au prochain redémarrage. Ce qui peut poser éventuellement problème, c'est que le sous-réseau macvlan ne soit pas encore initialisé quand le script de création de l'interface virtuelle s'exécute, le système pourrait te dire que le sous-réseau macvlan n'existe pas, et qu'il n'aille pas plus loin, dans ce cas-là, à moins de complexifier fort le script, je pense qu'il suffit d'allonger le timer (60s -> 120s par exemple).

Je n'ai pas dénigré ta solution, pourtant je me sens un peu visé. 🙂 Je dis juste qu'en terme de confiance c'est s'en remettre à un prestataire comme un autre, et que je le trouve quand même un peu intrusif au vu de ce qu'on voit sur interface. 😉 Mais peut-être est-il juste transparent sur ce qu'il collecte simplement ? Moi même j'utilise DoT via Quad9 donc bon, quelque part je leur fais confiance. Tout à fait matière à débat je le reconnais.

@Einsteinium Je ne suis surtout pas certain de ce que NextDNS apporte par rapport à une gestion locale. Par contre, corrige-moi si je me trompe, mais que ce soit du DoH ou du DoT, le serveur DNS upstream qui va recevoir ta requête pourra la décrypter (sinon il ne pourrait pas la résoudre). Donc tout dépend de la confiance que tu accordes à ton serveur DNS upstream. Que tu choisisses Cloudflare, NextDNS, Quad9 ou autre, ça ne change rien à cela. Je pense que si on veut favoriser la privauté des données, alors il est plus intéressant de demander à son serveur DNS de résoudre récursivement (et activer DNSSEC par la même occasion). Car là au moins tu sais que tu vises les serveurs racines, et pas une autorité déléguée.