Outils pour utilisateurs

Outils du site


tutoriaux:docker-related:stacks-pi-hole

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
tutoriaux:docker-related:stacks-pi-hole [2024/07/06 12:21] – [unbound] fratertutoriaux:docker-related:stacks-pi-hole [2024/07/31 09:59] (Version actuelle) frater
Ligne 3: Ligne 3:
 Il n'est plus nécessaire de présenter [[https://pi-hole.net|pi-hole.net]] tant cet outil rends le contrôle et la réduction des trackers/publicité facile. Il n'est plus nécessaire de présenter [[https://pi-hole.net|pi-hole.net]] tant cet outil rends le contrôle et la réduction des trackers/publicité facile.
  
-En migrant mon instance pi-Hole vers docker, je me suis heurté à un soucis imprévu, l'[[https://github.com/pi-hole/docker-pi-hole/#running-pi-hole-docker|image officielle]] ne contient pas de serveur "upstream" intégré; elle est parfaitement fonctionnelle avec des DNS upstream tel que google, quad9, cloudflare, mais si l'on veut réellement être indépendant, il manque son propre référentiel.+En migrant mon instance pi-Hole vers docker, je me suis heurté à un soucis imprévu, l'[[https://github.com/pi-hole/docker-pi-hole/#running-pi-hole-docker|image officielle]] ne contient pas de serveur "upstream" intégré (c'est en discussion pour une future révision); elle est parfaitement fonctionnelle avec des DNS upstream tel que google, quad9, cloudflare, mais si l'on veut réellement être indépendant, il manque son propre référentiel
 + 
 +il existe des images [[https://hub.docker.com/search?q=pihole-unbound|Pihole modifiées]], mais celle-ci peuvent ne pas suivre la cadence d'update ou contenir des packages en plus que l'on ne désire pas.
  
 Avec docker, il est très facile d'ajouter un container "unbound" et de le configurer en serveur upstream, pour ensuite faire pointer pi-Hole sur ce container. Avec docker, il est très facile d'ajouter un container "unbound" et de le configurer en serveur upstream, pour ensuite faire pointer pi-Hole sur ce container.
Ligne 9: Ligne 11:
 ===== Cahier de charges ===== ===== Cahier de charges =====
  
-Le stack doit être basé sur des images officielles et maintenues, pour l'image de pi-hole, c'est facile, ca sera l'image officielle, pour ce qui est unbound, il y a un peu plus de choix; j'ai choisis celle de [[ https://github.com/MatthewVance/unbound-docker|Matthew Vance]].+Le stack doit être basé sur des images officielles et maintenues, pour l'image de pi-hole, c'est facile, ça sera l'image officielle, pour ce qui est unbound, il y a un peu plus de choix; j'ai choisis celle de [[ https://github.com/MatthewVance/unbound-docker|Matthew Vance]].
  
 J'ai décidé de composer mon propre "stack" pour lier les deux containers tout en gardant une configuration un peu particulière: je veux que le serveur unbound soit sur un port différent : 5335 du serveur dns. J'ai décidé de composer mon propre "stack" pour lier les deux containers tout en gardant une configuration un peu particulière: je veux que le serveur unbound soit sur un port différent : 5335 du serveur dns.
Ligne 15: Ligne 17:
 Les raisons sont multiples, mais la plus évidente est d'éviter que unbound soit publier par accident sur le réseau (ce DNS serveur n'est absolument pas filtré et peut donc présenter des risques importants). Les raisons sont multiples, mais la plus évidente est d'éviter que unbound soit publier par accident sur le réseau (ce DNS serveur n'est absolument pas filtré et peut donc présenter des risques importants).
  
-pour parvenir a ce résultat, il va falloir modifier les configurations du serveur unbound, mais aussi de modifier le //healthcheck// de ce container+pour parvenir a ce résultat, il va falloir modifier les configurations du serveur unbound, mais aussi de modifier le //healthcheck// de ce container
 + 
 +==== En résumé ==== 
 + 
 +  * pi-hole dns serveur sur le port udp#53 
 +  * pi-hole web admin sur le port http#8053 
 +  * recursive dns root query (no forwarder) 
 +  * recursive dns serveur interne sur le port udp#53
  
 ===== Architecture ===== ===== Architecture =====
  
 {{drawio>tutoriaux:docker-related:dns-pihole-unbound-arch.png}} {{drawio>tutoriaux:docker-related:dns-pihole-unbound-arch.png}}
 +
 +cette architecture est décrite dans le fichier compose (en fin d'article), mais il est important de préciser quelques paramètres, notamment votre timezone pour les deux containers.
 +
 +==== unbound ====
 +dans la partie service "unbound":
 +
 +<code yaml>
 +   environment:
 +      - "TZ=Europe/Brussels"
 +</code>
 +
 +==== pi-hole ====
 +dans la partie service "pi-hole", il convient également de préciser le mot de passe de votre pi-hole, sans quoi pi-hole génèrera un mot de passe aléatoire qu'il faudra retrouver dans les logs.
 +<code yaml>
 +   environment:
 +      - "TZ=Europe/Brussels"
 +      - "WEBPASSWORD=[MONPASSWORD]"
 +</code>
  
 ===== unbound ===== ===== unbound =====
  
-Le container de Matthew contient tout ce qu'il faut pour avoir un unbound serveur avec un résolveur privé et un indicateur de ''healthcheck''; mais ces deux éléments sont défini pour "écouter" sur le port udp:53 et vérifier la santé du container sur ce même portil faudra donc modifier la configuration du service unbound ET le compose du container, heureusement le container défini un volume de stockages des configurations:+Le container de Matthew contient tout ce qu'il faut pour avoir un unbound serveur avec un résolveur privé et un indicateur de ''healthcheck''
 + 
 +Par [[https://github.com/MatthewVance/unbound-docker/blob/master/README.md#override-default-forward|défaut]] l'image de Matthew utilise les résolvers de cloudflare, ce qui ne me convient pasle serveur "écoute" sur le port udp:53 (port par défaut des DNS) et docker vérifie la santé du container en testant ce même portil conviendra donc de modifier ces paramètres en éditant les fichiers de configuration qui sont stocké dans un volume persistant:
  
 <code yaml> <code yaml>
Ligne 30: Ligne 59:
 </code> </code>
  
-Par [[https://github.com/MatthewVance/unbound-docker/blob/master/README.md#override-default-forward|défaut]] l'image de Matthew utilise les résolvers de cloudflare, ce qui ne nous convient pas; il conviendra donc de modifier ces paramètres.+Nous allons donc modifier certains fichiers "par défautde Matthew.
  
-Nous allons donc remplacer les fichiers "par défaut" de Matthew, en s'inspirant de la documentation de pi-Hole concernant l'usage de [[https://docs.pi-hole.net/guides/dns/unbound/|unbound]] comme résolveur.+Je me suis inspiré de la documentation de pi-Hole concernant l'usage de [[https://docs.pi-hole.net/guides/dns/unbound/|unbound]] comme résolveur.
  
-<code yaml> +on va surtout modifier les paramètres d'écoute du serveuren remplaçant le binding localhost ''127.0.0.1'' par tout les interfaces ''0.0.0.0'' et en vérifiant le port d'écoute ''53''
-server: +
-    # If no logfile is specifiedsyslog is used +
-    # logfile: "/var/log/unbound/unbound.log" +
-    verbosity: 0+
  
 +<code yaml>
 +    # Listen to for queries from clients and answer from this network interface
 +    # and port.
     interface: 0.0.0.0     interface: 0.0.0.0
-    port: 5335+    port: 53
     do-ip4: yes     do-ip4: yes
     do-udp: yes     do-udp: yes
Ligne 47: Ligne 75:
  
     # May be set to yes if you have IPv6 connectivity     # May be set to yes if you have IPv6 connectivity
-    do-ip6: no+    do-ip6: yes 
 +</code>
  
-    # You want to leave this to no unless you have *native* IPv6. With 6to4 and +Ces paramètres sont également a configurer dans le fichier compose, pour valider le healthcheck: 
-    # Terredo tunnels your web browser should favor IPv4 for the same reasons +<code yaml> 
-    prefer-ip6no+    healthcheck: 
 +      test: drill @127.0.0.1 -p 53 cloudflare.com || exit 1 
 +      interval30s 
 +      timeout: 30s 
 +      retries: 3 
 +      start_period: 10s 
 +</code>
  
-    # Use this only when you downloaded the list of primary root servers! +On va également vérifier et adapter les droits d'accès a notre serveur DNS:
-    # If you use the default dns-root-data package, unbound will find it automatically +
-    #root-hints"/var/lib/unbound/root.hints"+
  
-    Trust glue only if it is within the server's authority +<code yaml> 
-    harden-glueyes+    ##########################################################################
 +    # SECURITY SETTINGS 
 +    ########################################################################### 
 +    # Only give access to recursion clients from LAN IPs 
 +    access-control127.0.0.1/32 allow 
 +    access-control: 192.168.0.0/16 allow 
 +    access-control: 172.16.0.0/12 allow 
 +    access-control: 10.0.0.0/8 allow 
 +    # access-control: fc00::/7 allow 
 +    # access-control: ::1/128 allow 
 +</code>
  
-    # Require DNSSEC data for trust-anchored zonesif such data is absent, the zone becomes BOGUS +On va retirer la référence au "forwarder" de Matthewen commentant l'inclusion du fichier
-    harden-dnssec-strippedyes+
  
-    Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes +<code yaml> 
-    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details +    ##########################################################################
-    use-caps-for-id: no+    # FORWARD ZONE 
 +    ###########################################################################
  
-    # Reduce EDNS reassembly buffer size. +    #include: /opt/unbound/etc/unbound/forward-records.conf 
-    # IP fragmentation is unreliable on the Internet today, and can cause +</code>
-    # transmission failures when large DNS messages are sent via UDP. Even +
-    # when fragmentation does work, it may not be secure; it is theoretically +
-    # possible to spoof parts of a fragmented DNS message, without easy +
-    # detection at the receiving end. Recently, there was an excellent study +
-    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<< +
-    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/+
-    # in collaboration with NLnet Labs explored DNS using real world data from the +
-    # the RIPE Atlas probes and the researchers suggested different values for +
-    # IPv4 and IPv6 and in different scenariosThey advise that servers should +
-    # be configured to limit DNS messages sent over UDP to a size that will not +
-    # trigger fragmentation on typical network links. DNS servers can switch +
-    # from UDP to TCP when a DNS response is too big to fit in this limited +
-    # buffer size. This value has also been suggested in DNS Flag Day 2020. +
-    edns-buffer-size: 1232+
  
-    # Perform prefetching of close to expired message cache entries +j'invite le lecteur a aller consulter ce fichier, il contient énormément d'informations et de proposition de DNS externes assez détaillés.   
-    # This only applies to domains that have been frequently queried +vous y trouverez plusieurs classifications de serveurs sources déjà filtrés (malware, adulte, etc.) ainsi que d'autres forwarder (quad9, etc.)
-    prefetch: yes+
  
-    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on single machineit should be unnecessary to seek performance enhancement by increasing num-threads above 1. +Pour ma facilité de test (et ne pas de voir chaque fois redémarrer le container complétementj'ai autorisé le contrôle, mais en production ce paramètre peut être laissé par défaut sur ''no''
-    num-threads1 +<code yaml> 
- +remote-control
-    # Ensure kernel buffer is large enough to not lose messages in traffic spikes +    control-enableyes
-    so-rcvbuf1m +
- +
-    # Ensure privacy of local IP ranges +
-    private-address: 192.168.0.0/16 +
-    private-address: 169.254.0.0/16 +
-    private-address: 172.16.0.0/12 +
-    private-address: 10.0.0.0/+
-    private-address: fd00::/8 +
-    private-address: fe80::/10+
 </code> </code>
  
-En particulier le fichier nommé ''forward-records.conf'', que nous allons intégralement mettre en commentaire.+===== pi-hole =====
  
 +Pour accéder à l'interface de Pi-Hole, il suffit de se connecter via un browser (en http) sur l'ip du host docker en précisant le port (8053) et l'uri /admin (par exemple: http://192.168.1.253:8053/admin), vous serez accueilli par une page de login:
  
 +{{ tutoriaux:docker-related:dns-pihole-login-page.png?200 }}
  
 +il suffit de référencé votre mot de passe, et de se connecter, et de directement aller vers les "settings", "DNS":
  
 +{{ tutoriaux:docker-related:dns-pihole-dns-settings.png?600 }}
  
-<code yaml> +Par défaut, Pi-Hole ne réponds que aux clients situé sur le même réseau et sub-net (172.20.x.x), il transmet ensuite les requêtes aux serveurs de Google, ces paramètres ne conviennent pas, mais nous allons les changer:
-    healthcheck: +
-      test: drill @127.0.0.1 -p 5335 cloudflare.com || exit 1 +
-      interval: 30s +
-      timeout: 30s +
-      retries: 3 +
-      start_period10s +
- +
-</code>+
  
 +  * Désélectionner tout les serveurs par défaut (de google dans mon cas)
 +  * Définir notre "Upstream DNS Servers" en pointant vers notre containter unbound : ''172.20.0.200''; (si vous changer le port de ''unbound'' le format devient ''x.x.x.x#port'', ce format est très important).
 +  * Autoriser le serveur a répondre à tout nos client, pour ce faire, nous devons préciser l'option :''Permit all origins'', (''Respond only on interface eth0'' est sans doute suffisant, à vous de tester).
  
 +Il nous suffit de configurer les clients pour utiliser ce serveur DNS Pi-Hole.
 ===== fichiers ===== ===== fichiers =====
  
-<code yaml name:stack-dns-pihole-unbound-custom.yaml>+<file yaml name:stack-dns-pihole-unbound-custom.yaml>
 networks: networks:
   infrastructure:   infrastructure:
Ligne 130: Ligne 149:
 services: services:
   unbound:   unbound:
- 
-    cap_drop: 
-      - "AUDIT_CONTROL" 
-      - "BLOCK_SUSPEND" 
-      - "DAC_READ_SEARCH" 
-      - "IPC_LOCK" 
-      - "IPC_OWNER" 
-      - "LEASE" 
-      - "LINUX_IMMUTABLE" 
-      - "MAC_ADMIN" 
-      - "MAC_OVERRIDE" 
-      - "NET_ADMIN" 
-      - "NET_BROADCAST" 
-      - "SYSLOG" 
-      - "SYS_ADMIN" 
-      - "SYS_BOOT" 
-      - "SYS_MODULE" 
-      - "SYS_NICE" 
-      - "SYS_PACCT" 
-      - "SYS_PTRACE" 
-      - "SYS_RAWIO" 
-      - "SYS_RESOURCE" 
-      - "SYS_TIME" 
-      - "SYS_TTY_CONFIG" 
-      - "WAKE_ALARM" 
  
     command:     command:
Ligne 160: Ligne 154:
  
     healthcheck:     healthcheck:
-      test: drill @127.0.0.1 -p 5335 cloudflare.com || exit 1+      test: drill @127.0.0.1 cloudflare.com || exit 1
       interval: 30s       interval: 30s
       timeout: 30s       timeout: 30s
Ligne 211: Ligne 205:
  
   dns-pihole:   dns-pihole:
- 
-    cap_drop: 
-      - "AUDIT_CONTROL" 
-      - "BLOCK_SUSPEND" 
-      - "DAC_READ_SEARCH" 
-      - "IPC_LOCK" 
-      - "IPC_OWNER" 
-      - "LEASE" 
-      - "LINUX_IMMUTABLE" 
-      - "MAC_ADMIN" 
-      - "MAC_OVERRIDE" 
-      - "NET_ADMIN" 
-      - "NET_BROADCAST" 
-      - "SYSLOG" 
-      - "SYS_ADMIN" 
-      - "SYS_BOOT" 
-      - "SYS_MODULE" 
-      - "SYS_NICE" 
-      - "SYS_PACCT" 
-      - "SYS_PTRACE" 
-      - "SYS_RAWIO" 
-      - "SYS_RESOURCE" 
-      - "SYS_TIME" 
-      - "SYS_TTY_CONFIG" 
-      - "WAKE_ALARM" 
  
     container_name: dns_pihole     container_name: dns_pihole
Ligne 254: Ligne 223:
       - "DNSMASQ_USER=pihole"       - "DNSMASQ_USER=pihole"
       - "TZ=Europe/Brussels"       - "TZ=Europe/Brussels"
-      - "WEBPASSWORD=Mdr2Pq3*"+      - "WEBPASSWORD=[MONPASSWORD]"
  
     hostname: "pi-Hole"     hostname: "pi-Hole"
Ligne 283: Ligne 252:
       - "53:53/tcp"       - "53:53/tcp"
       - "53:53/udp"       - "53:53/udp"
-      - "81:80/tcp"+      - "8053:80/tcp"
  
     restart: "unless-stopped"     restart: "unless-stopped"
Ligne 297: Ligne 266:
   pihole_dnsmasq:   pihole_dnsmasq:
      
-</code> +</file>
- +
- +
- +
- +
- +
- +
tutoriaux/docker-related/stacks-pi-hole.1720261307.txt.gz · Dernière modification : 2024/07/06 12:21 de frater