[TUTO] [Docker - macvlan] Pi-Hole (V6)

[.Shad.]

 

 

1. Préambule

Pi-Hole est un logiciel libre permettant le blocage de publicités sur les périphériques qui l'utilisent en tant que serveur DNS. Il sert aussi à contrôler les données de télémétrie que vos appareils envoient, parfois (souvent ? ) de manière non-désirée.
Vu que le blocage s'effectue au niveau de la résolution DNS, il a l'avantage de pouvoir s'appliquer à tous les types de périphériques, contrairement aux bloqueurs de navigateurs qui se limitent souvent aux ordinateurs.

Le tutoriel sera découpé de la sorte :

- STANDARD - 

• Déploiement de Pi-Hole via Container Manager et utilisation basique

- AVANCÉ -

• Ses différentes utilisations en tant que serveur DNS local
• La personnalisation du blocage suivant les périphériques

2. Prérequis

Difficulté : facile-moyenne

Vous devez disposer d'un NAS compatible Docker, vous pouvez en retrouver la liste mise à jour à cette adresse : https://www.synology.com/fr-fr/dsm/packages/Docker
Au niveau des connaissances :

• Avoir une idée de ce qu'est Docker, voir tutoriel introductif.
• Avoir Installé le paquet Container Manager
• Savoir se connecter via SSH avec un utilisateur ayant des privilèges d'administrateur ou root directement, voir tutoriel.

3. Méthode d'installation

Il existe plusieurs méthodes pour installer Pi-Hole, préférentiellement je conseille :

1. l'utilisation d'un matériel dédié type Raspberry Pi quand on en a un sous la main et sur lequel il est facile de l'installer nativement, la procédure est très simplement décrite ici
2. une machine virtuelle (avec le paquet Virtual Machine Manager, les prérequis de compatibilité étant les mêmes que pour Docker), avec une installation minimale de Debian avec 512Mo de mémoire vive et un cœur est amplement suffisante
3. un conteneur Docker.

Il faut savoir que l'utilisation via Docker demande certains ajustements, et ce pour plusieurs raisons :

• Pi-Hole utilise les ports 80 et 443, qui sont utilisés par DSM pour Webstation et Nginx (notamment le proxy inversé). 
• Si le conteneur est en mode bridge, les requêtes DNS passant alors par l'hôte (le NAS) avant d'arriver au conteneur, vous verrez l'ensemble des requêtes provenant de l'IP passerelle du NAS dans le réseau bridge par défaut, donc 172.17.0.1. Ce qui posera très vite problème si on souhaite différencier le comportement de blocage pour sa tablette, pour sa TV, etc... (voir à la fin du tutoriel)

On privilégiera donc l'utilisation d'un réseau macvlan, celui-ci a entre autres l'avantage de pouvoir donner une IP du réseau local à votre conteneur, par exemple 192.168.100.161, il est donc joignable par les périphériques de votre réseau comme n'importe quelle autre machine. Il y a cependant un écueil à l'utilisation d'un réseau macvlan : tous les conteneurs qui en font partie sont incapables de communiquer avec leur hôte par leur IP physique. Concrètement mon NAS sera incapable de joindre Pi-Hole, donc sa résolution DNS sera non fonctionnelle. Pour pallier ce problème, on va créer une interface virtuelle sur le NAS. En gros si la porte est fermée, on passe par la fenêtre. 🙂 
C'est une manipulation très simple, qui ne survit toutefois pas à un redémarrage du NAS, on exécutera donc un script au démarrage pour recréer automatiquement cette interface.
L'ensemble de cette procédure est décrite dans le tutoriel introductif, et est, par commodité, reprise dans la partie suivante.

4. Hypothèses

Pour faciliter la lecture du tutoriel, on définira un certain nombre d'IP et de notations, vous devez évidemment adapter ces valeurs à votre propre installation, notamment les sous-réseaux.

Les IP :

• de l'interface physique du NAS : 192.168.100.100
• de l'interface virtuelle du NAS : 192.168.100.200
• du conteneur pi-hole : 192.168.100.161
• de la passerelle du réseau (votre box ou votre routeur) : 192.168.100.1
• de votre serveur DNS local (si vous n'en avez pas mis en place, c'est l'IP de votre passerelle) : 192.168.100.120

Les sous-réseaux :

• de votre réseau local : 192.168.100.0/24 (correspond à 192.168.100.0/255.255.255.0).
• du réseau macvlan : 192.168.100.160/28 (correspond à une plage utilisable de 14 IP allant de 192.168.100.161 à 192.168.100.174). Voir ce site qui permet de calculer les masques.

Les notations :

• macvlan-network : c'est le nom du réseau docker macvlan.
• mac0 : c'est le nom de l'interface virtuelle du NAS.
• ovs_eth0 : le nom de l'interface qui a pour IP l'IP physique de votre NAS, 192.168.100.100 dans notre exemple. Pour trouver le nom de l'interface en SSH :

  ifconfig | grep -B 1 192.168.100.100

  C'est le nom qui apparaît à gauche de l'écran sur la première ligne : 
  
  

REMARQUE : ovs s'ajoute automatiquement au nom de l'interface lorsqu'on a activé Open vSwitch sur son NAS (automatique lors de l'installation de Virtual Machine Manager)

- STANDARD - 

5. Création du réseau et de l'interface virtuelle

5-A. Création du réseau macvlan

On commence par se connecter via SSH avec un utilisateur admin ou root sur le NAS pour créer notre réseau macvlan. On va se placer dans le dossier partagé docker :

cd /volume1/docker/

On y crée un dossier "networks" et y commencer l'édition du script :

mkdir networks && cd $_
nano macvlan-network.sh

S'ouvre une fenêtre dans laquelle on va pouvoir rédiger notre script, en voici un canevas :

docker network create -d macvlan \
--subnet=192.168.100.0/24 \
--ip-range=192.168.100.160/28 \
--gateway=192.168.100.1 \
-o parent=ovs_eth0 \
macvlan-network

Notes :

• subnet : correspond à votre sous-réseau local.
• ip-range : correspond à la portion de ce sous-réseau qu'on se réserve pour le réseau macvlan, les 14 adresses IP définies dans les hypothèses. Ces 14 IP permettront d'accueillir d'autres conteneurs éventuels.
  Par conséquent, la plage du serveur DHCP et du réseau macvlan ne doivent absolument pas se chevaucher !
• gateway : c'est notre passerelle.
• parent : l'interface physique à laquelle on rattache notre réseau.

_________________________

Pour sauvegarder les modifications effectuées, on fait CTRL+O, on valide en appuyant sur Entrée puis CTRL+X pour sortir de l'éditeur et revenir sur le prompt. On va maintenant régler les permissions :

chmod 740 macvlan-network.sh

Le script est prêt, on peut l'exécuter :

bash macvlan-network.sh

Si tout va bien, on obtient une suite de caractères, cela signifie que le réseau est créé. On peut vérifier en tapant :

docker network ls

Et vérifier qu'il apparaît bien dans la liste.

En cas d'erreur dans la transcription, il suffit de supprimer le réseau malformé pour recommencer :

docker network rm macvlan-network

5-B. Création de l'interface virtuelle

On va créer un second script dans le dossier courant :

nano mac0-interface.sh

Le contenu du script :

ip link add mac0 link ovs_eth0 type macvlan mode bridge
ip addr add 192.168.100.200/32 dev mac0
ip link set dev mac0 address 5E:11:4F:AF:D6:D2
ip link set mac0 up
ip route add 192.168.100.160/28 dev mac0

Notes :
Concernant l'adresse MAC 5E:11:4F:AF:D6:D2 : c'est une adresse que j'ai choisie, sous les conditions suivantes :

- Elle n'existe pas déjà sur mon hôte et sur mon réseau.
- Elle respecte la base hexadécimale, les notations allant de 0 à F.
- Le premier nombre doit être pair, ici 5E = 94 en base 10, c'est donc OK (vous pouvez utiliser ce convertisseur en ligne, ou faire vos divisions euclidiennes 😄). S'il est impair, vous aurez un message :

RTNETLINK answers: Cannot assign requested address

Merci à @bruno78 pour la précision.

_________________________

On valide et on sort du fichier. On accorde les permissions :

chmod 740 mac0-interface.sh

On exécute le script :

bash mac0-interface.sh

Sauf erreur, rien n'indiquera que le script a bien fonctionné, on vérifie en tapant :

ifconfig | grep -A 9 mac0 

Ce qui doit donner un résultat du type :

Un autre moyen de vérifier que ça a marché est de lancer Synology Assistant, l'interface virtuelle devrait dorénavant apparaître en plus de l'interface physique du NAS.

5-C. Création de la tâche de rétablissement de l'interface virtuelle au redémarrage

Comme dit plus avant, cette interface ne persiste pas au redémarrage du NAS, on va pour cela définir une tâche planifiée, il faut aller dans DSM -> Panneau de configuration -> Planificateur de tâches -> Créer -> Tâche déclenchée :

Puis on valide.

REMARQUE : Lorsqu'on stoppe docker, ou qu'on le met à jour, l'interface disparaît également. La tâche n'étant lancée qu'au démarrage, vous devrez réexécuter la tâche manuellement pour rétablir l'interface.

6. Création des volumes

On va dans Filestation, puis dans le dossier partagé docker et on y crée un dossier pi-hole et son sous-dossier etc

Ainsi, même si le conteneur est supprimé, les données seront conservées.

7. Création d'utilisateurs et groupes dédiés et octroi de propriété

Nous allons créer un utilisateur ainsi qu'un groupe dédié.

Dans DSM : Panneau de configuration -> Utilisateur et groupe -> :

• Groupe -> Créer :
  • Nom : pihole
  • Description : Exécute le conteneur Pi-Hole
  • Autorisations dossiers partagés : Aucun accès pour tous les dossiers sauf docker (Lecture/Ecriture) et homes (on ne coche rien)
  • Autorisation applications : Tout refuser
• Utilisateur -> Créer :
  • Nom : pihole
  • Appartient au groupe : pihole
  • Tout le reste est issu des permissions liées au groupe

En SSH, nous allons noter les uid et gid de notre utilisateur et groupe nouvellement créés, nous en aurons besoin pour personnaliser notre fichier compose :

REMARQUE : les valeurs ci-dessus sont propres à votre installation, ne les recopiez pas bêtement !

8. Configuration et initialisation

8-A. Création du projet

 

Dans un premier temps, supprimez toute image pré-existante de Pi-hole dans Container Manager.
Image -> clic droit sur l'image -> Supprimer

Puis on crée un projet pi-hole dans Projet :

8-A-1. Fichier compose

Dans le champ texte, on copie les données suivantes :

services:

   pi-hole:
      image: pihole/pihole
      container_name: pi-hole
      hostname: pi-hole
      # A decommenter si Pi-hole est aussi votre serveur DHCP (non recommande)
      #cap_add:
         #- NET_ADMIN
      networks:
         macvlan-network:
            ipv4_address: 192.168.100.161
      environment:
         # General
         - ADMIN_EMAIL=xxx@yyy.zzz
         - TZ=Europe/Paris
            # Exemples : IP de dns0.eu et Quad9
            # Si vous avez un serveur DNS en plus de Pi-hole - renseignez juste l'ip locale de ce dernier
         - FTLCONF_dns_upstreams=193.110.81.0;9.9.9.9
         - FTLCONF_dns_reply_host_IPv4=192.168.101.161
         - FTLCONF_dns_queryLogging=true
         - FTLCONF_dhcp_active=false
         - FTLCONF_dns_dnssec=false
         - FTLCONF_dns_bogusPriv=true
         - FTLCONF_dns_domainNeeded=true
         - FTLCONF_dns_listeningMode=all
         - FTLCONF_dns_interface=ovs_eth0
         # Pihole UID et GID
         - PIHOLE_UID=1045
         - PIHOLE_GID=65548
         # Conditional forwarding
            # 192.168.100.0/24 : le sous-reseau local
            # 192.168.100.xxx : voir paragraphe CONDITIONAL FORWARDING
            # ndd.tld : le domaine local
         - FTLCONF_dns_revServers='true,192.168.100.0/24,192.168.100.xxx#53,ndd.tld'
         # Reglages interface
         - FTLCONF_webserver_interface_boxed=boxed
         - FTLCONF_webserver_interface_theme=default-darker
         - FTLCONF_webserver_api_password=XXXXXXXXXXXXXXXXX
      volumes:
         - /volume1/docker/pi-hole/etc:/etc/pihole/
      dns:
         - 127.0.0.1
         - 8.8.8.8
      restart: unless-stopped

networks:

   macvlan-network:
      external: true

REMARQUES :

• Il est important de respecter l'indentation (l'alignement des paramètres).
• Si vos serveurs publiques définis dans FTLCONF_dns_upstreams prennent en charge DNSSEC, vous pouvez passer cette dernière variable à true. On a défini ici 2 serveurs publics différents, pour limiter les risques d'indisponibilité (merci à @Einsteinium pour sa suggestion).
• Ce fichier permet de définir dès le lancement avec précision la valeur de la plupart des paramètres, pour la liste exhaustive de toutes les variables d'environnement disponibles, consultez cette page.
• On choisit un mot de passe pour la variable FTLCONF_webserver_api_password

8-A-2. Conditional forwarding

Si vous pouvez vous contenter de l'affichage des IP au lieu des noms d'hôte des périphériques, vous pouvez vous abstenir de définir la variable d'environnement FTLCONF_dns_revServers dans le fichier compose.

Sinon :

Révélation

C'est une question qui revient souvent, les utilisateurs de Pi-Hole n'arrivent pas à afficher les noms d'hôte des périphériques.
Il faut comprendre que Pi-Hole n'a connaissance que de ce qu'on lui transmet.

La variable est composée de quatre champs avec les valeurs suivantes :

• true : indique qu'on va utiliser cette fonctionnalité
• 192.168.100.0/24 : comme indiqué dans le fichier docker-compose ci-dessus, on y inscrit notre sous-réseau local sous notation CIDR, voir hypothèses de départ
• ndd.tld : comme indiqué c'est optionnel, c'est le domaine qu'accole automatiquement votre serveur DHCP aux noms d'hôte des périphériques du réseau local. Par défaut les opérateurs envoient souvent local, localdomain, ou celui que vous avez configuré si votre routeur ou modem le permet
• 192.168.100.xxx : suivant votre installation, ça peut être plus ou moins simple, par exemple si utilisez déjà un autre serveur DNS sur votre réseau local par exemple, différents cas de figure sont à considérer :

• Serveur DHCP et serveur DNS local sont confondus sur le même matériel, le serveur DHCP récupère le nom d'hôte envoyé par le périphérique , et l'inscrit dans sa zone DNS.
  En définissant 192.168.100.xxx avec l'IP du serveur DHCP/DNS (étant confondus dans ce cas précis), Pi-Hole affichera les noms d'hôte de l'ensemble de vos périphériques dans son tableau de bord.
  C'est le cas le plus fréquent, ces deux serveurs sont hébergés sur la passerelle (votre box ou routeur).
  Dans ce cas, vous devez mettre l'IP du serveur dhcp/dns, ou celle de la passerelle (box ou routeur) si tout y est localisé.
• Serveur DHCP et serveur DNS local sont distincts. Or, Pi-hole ne permet d'interroger qu'une seule IP.
  Dans ce cas-là vous devez faire pointer 192.168.100.xxx sur le serveur qui définit un nom d'hôte et un domaine pour chaque périphérique, donc a priori votre serveur DNS, mais attention, tous les périphériques pour lesquels vous n'avez pas associé d'enregistrement dans votre serveur DNS (car purement des clients par exemple, ce sont eux qui accèdent au monde, pas l'inverse, utilisation typique : vous n'auriez jamais besoin d'accéder à votre tablette, smartphone, etc...) n'auront pas de nom d'hôte attribué, et seule apparaîtra l'IP, si vous avez bien suivi c'est normal car c'est le serveur DHCP qui dispose de cette information. Il faut donc dans ce cas-là définir un nom d'hôte pour chacun des périphériques de votre réseau utilisant Pi-Hole comme serveur DNS dans votre zone DNS.
• La troisième possibilité (non recommandée) est d'utiliser Pi-Hole comme serveur DNS local, dans ce cas-là le conditional forwarding peut être désactivé.
  Ce point est abordé plus loin dans le tutoriel.

8-B. Finalisation du projet

On clique sur Suivant deux fois, le projet se crée et va démarrer automatiquement.

On peut ensuite se rendre sur l'adresse IP du conteneur http://192.168.100.161/admin, si tout va bien on arrive sur la page d'accueil de Pi-Hole. On utilise le mot de passe défini dans dans la variable d'environnement

9. Résolution locale

L'étape ultime, mais la plus importante, est de faire en sorte que votre serveur DHCP envoie à ses clients l'adresse IP de Pi-hole comme serveur DNS primaire.

Pour le vérifier, il suffit de taper dans une invite de commande Windows par exemple :

nslookup nas-forum.com

Si les deux premières lignes du résultat sont équivalentes à :

Serveur :   pi.hole
Address:  192.168.100.161

Félicitations, votre Pi-Hole est fonctionnel !

Pour vérifier que le blocage de publicités est actif, essayez d'aller sur http://doubleclick.net, si le nom de domaine ne peut être résolu, c'est que Pi-Hole a filtré la demande (veillez à désactiver tout bloqueur de pubs intégré au navigateur en amont).

Quid du serveur DNS secondaire ? Bien qu'il puisse être rassurant d'envoyer comme serveur DNS secondaire l'IP d'un serveur DNS publique, pour qu'en cas d'indisponibilité de Pi-Hole, la résolution DNS globale soit toujours active sur le votre réseau local, il arrive qu'un périphérique préfère s'adresser au DNS secondaire plutôt que primaire, et dans ce cas-là les requêtes n'étant accessibles que localement échoueront.

Pour éviter ces désagréments, on peut mettre en place un deuxième serveur Pi-Hole sur un périphérique simple comme un Raspberry Pi, une machine virtuelle sur un autre serveur ou un autre NAS compatible Docker si on en possède un.

La suite s'adresse aux utilisateurs souhaitant pousser plus avant la configuration de Pi-Hole.

- AVANCÉ -

10. Modes d'utilisation

10-A. Pi-Hole + serveur DNS local + serveur DHCP

Ce point n'est pas abordé dans le tutoriel, je ne trouve pas ça prudent de laisser un conteneur du NAS gérer le serveur DHCP, c'est beaucoup moins stable qu'un périphérique dédié comme un routeur, avec une installation native. Et sans DHCP, vos périphériques ne pourront non seulement pas discuter entre eux, mais pas accéder à Internet non plus.

10-B. Pi-Hole + serveur DNS local

Dans le cas où vous avez déjà un serveur DNS local actif sur votre NAS ou tout autre périphérique, vous pouvez placer Pi-Hole en amont du serveur DNS local. Il faudra alors donner comme valeur à la variable d'environnement DNS1 l'IP de l'hôte du serveur DNS. Si vous avez une redondance de serveurs DNS local, pensez à compléter DNS2 de manière analogue. Vos périphériques interrogeront d'abord Pi-hole, qui transmettra ensuite la requête à votre serveur DNS local, lui-même transmettra aux redirecteurs que vous lui avez précisés si la requête n'est pas résoluble localement.

Périphérique -> Pi-Hole -> Serveur DNS local -> Serveur publique "upstream"

ATTENTION : Si vous utilisez un serveur DNS sur l'hôte même (par exemple DNS Server), il faut utiliser l'IP virtuelle du NAS, pas son IP physique habituelle (merci à @anorec).

10-C. Pi-Hole en tant que serveur DNS local

10-C-1. Ajout des enregistrements

Il est possible d'utiliser directement Pi-Hole comme résolveur DNS local. C'est extrêmement pratique si vous n'avez encore mis aucune résolution locale en place (avec DNS Server par exemple).
ATTENTION : Pi-Hole n'est pas en mesure d'être source d'autorité pour une zone publique, il faut pour cela passer par exemple par des logiciels comme BIND ou DNS Server de DSM, qui n'en est qu'une surcouche.

Pour se faire on se rend sur la page d'accueil de Pi-Hole, on se connecte en cliquant sur Login, on utilise le mot de passe précédemment défini dans le fichier compose.

Dans le menu latéral System -> Settings -> Local DNS records, deux colonnes apparaissent : Local DNS Records et Local CNAME Records :

• Le premier permet de définir les enregistrements A pour le domaine et les périphériques de votre réseau.
• Le second permet de définir des alias pour les domaines précédemment définis.

Une image est plus parlante qu'un long discours :

Notes :

• Depuis mon réseau local, taper domaine1.fr dans mon navigateur m'amènera sur l'IP de ma passerelle. Si ma box ou mon routeur expose son interface sur le port 80, j'arriverai dessus.
• J'ai volontairement donné à domaine2.fr une IP inexistante sur le réseau, Pi-Hole ne vous indiquera aucune erreur, il se contente de vous indiquer la direction, même s'il y a un fossé trois mètres plus loin. 😉 C'est votre navigateur qui y sera confronté et vous renverra une erreur.
• nas.domaine1.fr pointe sur mon NAS, sur lequel par exemple je pourrais utiliser un proxy inversé.
• J'ai également ajouté un alias, qui permet de faire pointer storage.domaine1.fr vers mon NAS (nas.domaine1.fr)

 

REMARQUE : La seule règle doit être que la cible de l'enregistrement CNAME (le contenu de la colonne Target) doit avoir été préalablement définie dans la partie DNS records.
Le rafraichissement de la zone se faisant à chaque nouvel ajout, il faut qu'il soit valide.

10-C-2. Vérification

On peut vérifier par acquis de conscience que la résolution est bien effective, on lance une invite de commande depuis son ordinateur, et on peut taper quelques commandes pour vérifier les IP renvoyés :

nslookup domaine1.fr 192.168.100.161
nslookup domaine2.fr 192.168.100.161
nslookup nas.domaine1.fr 192.168.100.161
nslookup storage.domaine1.fr 192.168.100.161

Si tout est ok, les IP renvoyées doivent correspondre à ce qui a été paramétré dans Pi-hole.

11. Blocage différencié

Un des gros avantages de Pi-Hole face à la concurrence est la possibilité de créer des groupes de périphériques pour lesquels on peut personnaliser les listes de blocage, ou même désactiver Pi-Hole complètement. Ou a contrario d'être beaucoup plus restrictif.

Quelques exemples concrets :

• Jeux mobiles : certains jeux gratuits nécessitent de visionner des vidéos pour pouvoir continuer de jouer. Il y a des grandes chances que Pi-Hole bloque ces publicités et altère en conséquence votre expérience de jeu.
• Il n'est pas rare qu'on souhaite contrôler strictement ce que du matériel domotique (caméra, détecteur, etc...) peut envoyer sur la toile. En ajoutant certaines listes de blocage pour cette catégorie d'équipements, on peut avoir la maîtrise des données transférées sans pour autant générer un nombre importants de faux-positifs sur les autres périphériques du réseau.
• On peut laisser actif Google Shopping pour madame. 🙂 

C'est dans l'onglet Group Management -> Groups que ça se passe, j'y crée un groupe spécifiques aux publicités pour certains jeux :

 

REMARQUE : LaPas d'espace dans le nom du groupe, sinon ça créera un groupe par mots 😉

Si je clique sur Enabled, la valeur passera à Disabled et Pi-Hole sera désactivé pour ce groupe, les requêtes seront directement transmises au(x) redirecteur(s).

Dans Clients, je peux choisir dans la liste déroulante Known clients un des périphériques vus par Pi-Hole par son adresse MAC (ainsi que l'IP et éventuellement le nom d'hôte s'il en a connaissance). Il faut également choisir à quel groupe le périphérique appartient dans la cellule Group assignment puis appuyer sur Add :

Dans Domains, je peux ajouter des domaines (liste blanche ou noire) manuellement (avec ou sans wildcard), ici j'utilise une chaîne regex pour autoriser certaines publicités pour un jeu installé sur mon smartphone :

Dans le dernier sous-menu Adlists, je n'ai rien touché aux listes, j'ai laissé celles par défaut pour tous mes périphériques :

 

MàJ : 12/07/2025

 

Modifié samedi à 09:57 par .Shad.
Refonte du tutoriel pour la v6

[anorec]

Bonjour et merci infiniment pour ce super tutoriel tres clair qui va probablement me permettre de faire enfin fonctionner correctement mon installation de Pi-hole sur le NAS en créant l'interface virtuelle.

@.Shad. Un détail, en lisant la documentation de Pi-hole au sujet des variables d'environnement (lien que tu donnes dans le tuto), il semble que les variables 'CONDITIONAL_FORWARDING...' fonctionnent encore mais elles ont été déprécié et remplacé par d'autres.

[bruno78]

@.Shad. Très beau tuto ! Merci

[.Shad.]

@anorec : Bien vu, j'avais fait la modification sur le Pi-hole de mon serveur Debian, pas sur celui de mon NAS, et je me suis basé sur celui du NAS 😉 
Je vais corriger ça. 🙂 

[bruno78]

@.Shad.

j'ai juste une remarque : dans l'assignation des adresses MAC, elles ne sont pas tout à fait au hasard : le dernier bit du premier octet doit être positionné à 0, càd un premier octet pair. Sinon c'est refusé.

Bruno78

[.Shad.]

@bruno78

Alors c'est étrange, j'ai un peu triché car en réalité je n'ai pas utilisé cette adresse MAC, mais c'est celle qui apparaissait dans mon impression d'écran. 😛 
Donc si l'interface s'attribue elle-même une adresse MAC, elle peut s'affranchir de cette limitation ?

Modifié le 12 février 2021 par .Shad.

[bruno78]

Le 06/02/2021 à 19:04, .Shad. a dit :

ip link set dev mac0 address 5E:11:4F:AF:D6:D2

@.Shad., je ne sais pas te répondre si l'adresse est "auto-attribuée", mais là dans ton exemple c'est bon : 5E est bien pair. Après, de mémoire, c'est lorsque je spécifie une adresse MAC dans le docker-compose que j'ai eu ce problème. Et du coup je ne crois pas avoir fait l'essai avec le link.

On trouve quelques références à ce propos : par exemple ip - Why the first octet of a MAC address always end with a binary 0? - Network Engineering Stack Exchange

[.Shad.]

Ok, merci, je vais ajouter une note à ce sujet.

[bruno78]

@.Shad. je viens de faire l'essai : 

PAIR (5E) : OK

root@ds918blam:~# ip link add mac1 link ovs_eth0 type macvlan mode bridge
root@ds918blam:~# ip link set dev mac1 address 5E:11:4F:AF:D6:D2
root@ds918blam:~#

IMPAIR (5F) : KO

root@ds918blam:~# ip link add mac1 link ovs_eth0 type macvlan mode bridge
root@ds918blam:~# ip link set dev mac1 address 5F:11:4F:AF:D6:D2
RTNETLINK answers: Cannot assign requested address
root@ds918blam:~#

bruno78

[.Shad.]

Ok super merci j'ajoute une précision. 😉 

[anorec]

@.Shad.

Dans le paragraphe Pi-hole + serveur DNS local

Il peut être intéressant de rappeler/préciser que si le serveur DNS se trouve sur l'hote (Synology DNS Server), il faut renseigner l'@IP de l'interface virtuelle dans DNS1. (Si j'ai bien compris!)

[.Shad.]

Tu as tout à fait raison, je vais ajouter la précision. 😉 

EDIT : Le tutoriel te paraît clair autrement ? je pense que tu es le seul à l'avoir parcouru pour l'instant. 😛 

Modifié le 18 février 2021 par .Shad.

[anorec]

@.Shad. Je n'ai suivi que certaines partie (script de création de l'interface virtuelle) car j'ai déjà un docker pihole fonctionnel mais le tutoriel me semble clair.

Je pense à le suivre à partir de zéro quand j'aurais plus de temps car j'ai essayé de modifier certaines variables d'environnement de mon instance Pihole existante (pour le conditional forwarding) mais ensuite le docker Pihole ne parvient plus à démarrer. 

[Tordux]

@.Shad.

Bonjour et bravo pour ce tuto 🙂

J'ai rencontré un problème lors de docker-compose pull && docker-compose up -d . En effet, le dossier var-logs/lighttpd ne s'est pas créé ainsi que les fichiers access.log et error.log à l'intérieur

Je les ai créé à la main ne sachant pas le faire avec docker ^^

De plus j'ai vu 2 petites coquilles :

Le 06/02/2021 à 19:04, .Shad. a dit :

En cas d'erreur dans la transcription, il suffit de supprimer le réseau malformé pour recommencer :

docker network rm macvlan-net

Plutôt : docker network rm macvlan-network
 

Le 06/02/2021 à 19:04, .Shad. a dit :

Ici on est dans le dossier /volume1/docker/networks/mac0-interface.sh

 

Tout fonctionne maintenant.

Encore bravo 👏

[.Shad.]

Merci beaucoup @Tordux de ton retour, bien vu pour les coquilles, je vais corriger ça.

Pour le dossier var-logs je vais regarder, j'ai une petite idée du pourquoi ça pourrait planter, je mettrai la solution ici quand j'aurai trouvé.

[.Shad.]

Alors j'ai regardé pour le problème avec le dossier var-logs.
J'ai extrapolé une configuration que j'ai faite chez moi, sauf que là où elle fonctionne sur une Debian, elle ne fonctionne pas sur le NAS.
Cela donnait l'avantage d'avoir les logs rapidement à portée, mais il existe plein d'autres méthodes pour les visualiser, typiquement la commande docker logs, Docker dans DSM, Portainer ou encore directement dans le conteneur.

Je supprime ce montage de volume.

Merci encore @Tordux de ton retour.

Modifié le 20 février 2021 par .Shad.

[MilesTEG1]

Hooo ! Le beau tuto tout neuf 😄 

Je l'ai lu assez vite en diagonale, mais le peu que j'ai lu me semble clair, comme d'habitude avec tes tutos ^^

Est-ce que tu serais d'accord que je me serve de ton tuto pour en faire une variante pour AdGuard-Home ? Je n'utilise plus Pi-Hole au profit d'AdGuard-Home.
Il faudra cependant que j'applique ton tuto à mon AdGuard-Home qui est actuellement en mode HOST (je ne peux donc pas faire du DNS chiffré). Ça fait un moment que je voulais tenter le macvlan pour AdGuard, mais j'ai jamais pris le temps de m'y pencher dessus, et ton tuto tombe à pic 😛 

Merci en tout cas pour ce super tuto 😉

[.Shad.]

Salut,

Je ne sais pas à quel point c'est réplicable pour Adguard, mais si tu y trouves ton inspiration, n'hésite pas.

Après tu peux toujours pointer vers ce tutoriel concernant la mise en place du réseau macvlan, et traiter la partie configuration d'Adguard uniquement.

[MilesTEG1]

👋🏻@.Shad.
Je peux faire ça en effet 😉 
À voir, mais dans tous les cas, je te citerais comme étant l'auteur de ce que j'utiliserais 😇

Mais faut tout d'abord que j'essaie de mettre AdGuard en macvlan 😉 

Au fait, elle fait quoi la variable $_ dans la commande suivante ?

 

mkdir -p /volume1/docker/pi-hole && cd $_

J'ai bien une idée de ce que ça fait : ça va dans le dossier précédemment créé, mais trouve pas la doc qui va avec sur le net pour expliquer cette variables.
Je connais un certain nombre :

$* $1 $2 $? $@ $# $0

mais la $_ je la trouve nulle part expliquée.

PS : il manque vraiment des langage dans la balise code... Y aurait pas moyen d'en rajouter ? (Shell, yaml, etc...)

Modifié le 20 février 2021 par MilesTEG1

[.Shad.]

Ici : https://askubuntu.com/questions/1198935/what-is-the-purpose-of-the-special-parameter-single-underscore-in-environm

 

[MilesTEG1]

Ok merci :) 

C'est pas si simple que ça en a l'air ;)

Mais purée, fallait la trouver l'explication. Tu as appris ça tout seul ? Ou bien en cours d'info ?

[MrLiink49]

Merci Shad pour le tuto 😻

Malgré la création de l'interface virtuelle je n'arrive pas à me reconnecter sur mon NAS (je suis obligé de repasser sur le DHCP de ma box)

Pourriez-vous m'aider à comprendre ce qui bloque s'il vous plait ?

Réseau macvlan du PiHole (docker network inspect macvlan_pihole) :

[~] # docker network inspect macvlan_pihole
[
    {
        "Name": "macvlan_pihole",
        "Id": "a372a582a1818d27a1c18c2059208468b8a5c5492aba0ff3e3724bf653d22e7e",
        "Created": "2021-02-19T16:39:07.562501074+01:00",
        "Scope": "local",
        "Driver": "macvlan",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "192.168.1.0/24",
                    "IPRange": "192.168.1.101/32",
                    "Gateway": "192.168.1.254"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "55dd144ec9e0326d8588c1e287a5eac7e8778488ac5d51f3aa5f332bde6c32a7": {
                "Name": "pihole",
                "EndpointID": "524a3ca9e7982dc483d9d56bb23fe68118956b09f1c46e24789bc258200dba80",
                "MacAddress": "XXXXXXXXXX", #masqué
                "IPv4Address": "192.168.1.101/24",
                "IPv6Address": ""
            }
        },
        "Options": {
            "parent": "eth0"
        },
        "Labels": {}
    }
]

Script utilisé pour créer l'interface virtuelle (adapté du tuto à ma config) :

ip link add mac0 link eth0 type macvlan mode bridge #"eth0" dans mon cas
ip addr add 192.168.1.200/32 dev mac0 #J'ai laissé la même plage que dans le tuto
ip link set dev mac0 address 5E:11:4F:AF:D6:D2 #même adresse mac, n'existe pas sur mon réseau
ip link set mac0 up
ip route add 192.168.1.101/32 dev mac0 #192.1.101/32 est la plage défini lors de la création de mon réseau macvlan (voir ci-dessus)

Si je vérifie, l'interface virtuelle est bien créée :

[~] # ifconfig | grep -A 9 mac0
mac0      Link encap:Ethernet  HWaddr 5E:11:4F:AF:D6:D2
          inet addr:192.168.1.200  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4116 errors:0 dropped:0 overruns:0 frame:0
          TX packets:421 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:798090 (779.3 KiB)  TX bytes:79729 (77.8 KiB)

veth144d8db Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX #masqué
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Je repasse sur le DHCP du PiHole (en désactivant celui de la box) : OK + reboot de la box

Accès à l'interface web de mon NAS (IP : 192.168.1.86) : KO

Accès web via l'IP de l'interface virtuelle (192.168.1.200) : KO

Check via l'interface web de Pihole : je retrouver tous mes autres équipements mais pas le NAS :(

 

Merci d'avance à celui ou celle qui voudra bien voler à mon secours 😭

[.Shad.]

Salut,

Il n'y a que depuis le conteneur Pi-hole que tu dois utiliser l'IP de l'interface virtuelle pour accéder au NAS, tous les périphériques autres que l'hôte peuvent y accéder via l'IP habituelle.

Que donne, depuis le NAS, un ping sur l'IP du conteneur 192.168.1.101 ?
Inversement, tu peux tester depuis le conteneur, tu te connectes en SSH sur ton NAS et tu tapes :

docker exec -it pihole ping 192.168.1.86

où pihole est le nom de ton conteur pi-hole.

Autre chose, j'éviterais d'inclure dans la plage de mon serveur DHCP la plage que se réserve le réseau macvlan (dans ton cas une seule IP, mais autant éviter).

Modifié le 21 février 2021 par .Shad.

[.Shad.]

Le 20/02/2021 à 13:57, MilesTEG1 a dit :

Ok merci 🙂

C'est pas si simple que ça en a l'air 😉

Mais purée, fallait la trouver l'explication. Tu as appris ça tout seul ? Ou bien en cours d'info ?

J'ai jamais suivi de cours d'informatique. 🙂

Mon métier n'a rien à voir. 😉

C'était juste que je cherchais comment entrer directement dans un dossier après l'avoir créé, et j'étais tombé sur cette commande ma foi bien utile. 😉

 

Modifié le 21 février 2021 par .Shad.

[MrLiink49]

Il y a 19 heures, .Shad. a dit :

Autre chose, j'éviterais d'inclure dans la plage de mon serveur DHCP la plage que se réserve le réseau macvlan (dans ton cas une seule IP, mais autant éviter).

J'ai effectivement remodifié le range jusqu'à 192.168.1.100 hier soir 🙂

----------------------------------------------------------------------------

Il y a 19 heures, .Shad. a dit :

Il n'y a que depuis le conteneur Pi-hole que tu dois utiliser l'IP de l'interface virtuelle pour accéder au NAS, tous les périphériques autres que l'hôte peuvent y accéder via l'IP habituelle.

Justement mes autres périphériques n'arrivent pas à se connecter avec l'IP habituelle (192.168.1.86) 😞

----------------------------------------------------------------------------

Il y a 19 heures, .Shad. a dit :

Que donne, depuis le NAS, un ping sur l'IP du conteneur 192.168.1.101 ?

DHCP de la box : ON, ping : OK (si je passe sur le dhcp pi hole, je n'ai plus accès en SSH au NAS donc .. ^^)

[~] # ping 192.168.1.101
PING 192.168.1.101 (192.168.1.101): 56 data bytes
64 bytes from 192.168.1.101: seq=0 ttl=64 time=2.654 ms
64 bytes from 192.168.1.101: seq=1 ttl=64 time=0.108 ms
64 bytes from 192.168.1.101: seq=2 ttl=64 time=0.095 ms

----------------------------------------------------------------------------

Il y a 19 heures, .Shad. a dit :

Inversement, tu peux tester depuis le conteneur, tu te connectes en SSH sur ton NAS et tu tapes :

docker exec -it pihole ping 192.168.1.86

où pihole est le nom de ton conteur pi-hole.

Mon container s'appelle pihole ça tombe bien : DHCP box : ON, ping KO :

[~] # docker exec -it pihole ping 192.168.1.86
PING 192.168.1.86 (192.168.1.86) 56(84) bytes of data.
From 192.168.1.101 icmp_seq=1 Destination Host Unreachable
From 192.168.1.101 icmp_seq=5 Destination Host Unreachable
From 192.168.1.101 icmp_seq=6 Destination Host Unreachable

Mais si je ping sur le 192.168.1.200 (interface virtuelle), ping : OK (ce qui me semble normal donc)

[~] # docker exec -it pihole ping 192.168.1.200
PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data.
64 bytes from 192.168.1.200: icmp_seq=1 ttl=64 time=0.107 ms
64 bytes from 192.168.1.200: icmp_seq=2 ttl=64 time=0.096 ms
64 bytes from 192.168.1.200: icmp_seq=3 ttl=64 time=0.096 ms

De plus, dans le network overview, je vois bien que PiHole détecte l'interface virtuelle 192.168.1.200, c'est donc mon nas qui ne passe pas par cette IP pour communiquer avec le container PiHole ?

Modifié le 21 février 2021 par MrLiink49
added : ping interface virtuelle