[Pi-Hole] Ervaringen & discussie

[ed1703]

Kopernikus.1979 schreef op zondag 11 oktober 2020 @ 21:48:
[...]


Super, ga ik ook eens zo proberen, enkel voor de native vlan (dus lan1) wat vul ik hier in voor dns?
Voor alle andere is het simpel: het statisch IP voor de betreffende vlan gedefinieerd op de RasPi.
Want op mijn pihole kan ik deze niet defenieren? Tenzijn ik de poort aanpas native untaged maar dan zit de Pi niet meer in zijn VLAN maar op de native samen met de USG.
Moet er in de hosts file nog iets speciaal voor de USG?
Unbound gebruikte ik ook al als resolver.
Mijn 2de Pi-hole gebruikte ik als 2de DNS, enig nadeel is dat statistieken verspreid zijn over de 2 Pi-hole's, zou je eerder de HA oplossing aanraden?

Lan1: als er in native verder niets zit, niet gebruiken? Anders dns van je server lan gebruiken en bijhorende firewall rules. De USG kan ook de dnsadressen van andere vlans gebruiken. Deze adressen pas je aan in het WAN van je controller.

2e pihole: je kunt op keepalived pihole 1 als primair configureren voor al je vlans. Dacht dat je dan meerdere hagroepen moet maken. Ook met een check script, al voegt deze niet heel veel toe https://github.com/manicholls/pi-hole-keepalived of pihole functioneel echt werkt zit geen check in.
Andere ken ik niet, misschien anderen? @nero355 of iemand anders.

[ Voor 5% gewijzigd door ed1703 op 11-10-2020 22:36 ]

[nero355]

ed1703 schreef op zondag 11 oktober 2020 @ 22:29:
2e pihole: je kunt op keepalived pihole 1 als primair configureren voor al je vlans. Dacht dat je dan meerdere hagroepen moet maken. Ook met een check script, al voegt deze niet heel veel toe https://github.com/manicholls/pi-hole-keepalived of pihole functioneel echt werkt zit geen check in.
Andere ken ik niet, misschien anderen? @nero355 of iemand anders.

Dit was het eerste topic dat ooit daarover ging : https://discourse.pi-hole...-pihole-ive-done-it/12716

Maar ondertussen zijn er meerdere varianten beschikbaar geloof ik dus "Pick your poison!" zou ik zeggen

[deHakkelaar]

Kopernikus.1979 schreef op zondag 11 oktober 2020 @ 21:48:
[...]
Mijn 2de Pi-hole gebruikte ik als 2de DNS, enig nadeel is dat statistieken verspreid zijn over de 2 Pi-hole's, zou je eerder de HA oplossing aanraden?

Er is nog geen behoorlijke oplossing om alles in sync te houden.
Onderstaande synct bv. wel de gravity.db maar niet de queries in pihole-FTL.db of de DHCP leases:

https://discourse.pi-hole...ple-pi-hole-in-sync/33545

De enige oplossing die ik kan bedenken is een active/passive cluster op te zetten:

https://access.redhat.com...ailability_clusters/index

Maar dan heb je eigenlijk minimaal 3 Pi-hole nodes nodig.
De dbases etc zullen dan op shared storage moeten worden opgeslagen zoals bv een NAS, SAN oplossing of SCSI disk enclosure (2 voor reduncy).
En omdat het een active/passive cluster is zal er ook maar 1 node daadwerkelijk aktief zijn die de pihole-FTL daemon draait.
Een virtual IP welke van node naar node kan hoppen verzorgt dan een enkele ingang/endpoint voor de clients.
Maar dit is niet makkelijk op te zetten want het vergt nogal wat kennis van zaken.

Mogelijk in de toekomst zal Pi-hole ook andere dbase oplossingen ondersteunen zoals MySQL/MariaDB, Postgres of zelfs Oracle.
Dan wordt het makkelijker om dbases in sync te houden omdat bovenstaande dbase engines een eigen functie hebben om dbases via netwerk te synchroniseren onderling.
Maar dan zijn de DHCP leases nog een struikelblok aangezien deze in een plat bestandje worden opgeslagen ipv een dbase.

ps. weet je al meer ofdat vlan package en 8021q mod nodig zijn ?

[ed1703]

deHakkelaar schreef op maandag 12 oktober 2020 @ 01:28:
[...]
Maar dan zijn de DHCP leases nog een struikelblok aangezien deze in een plat bestandje worden opgeslagen ipv een dbase.

Het dhcp probleem is op te lossen als pihole isc dhcpd zou adopteren, want die heeft een hasetup.
Wel in een plat bestand, maar voor zover ik mij kan herinneren werken de master en slave (oei fout woord in 2020) elkaar bij

[ Voor 83% gewijzigd door ed1703 op 12-10-2020 08:10 ]

[Kopernikus.1979]

Lan1: als er in native verder niets zit, niet gebruiken? Anders dns van je server lan gebruiken en bijhorende firewall rules. De USG kan ook de dnsadressen van andere vlans gebruiken. Deze adressen pas je aan in het WAN van je controller.

Ik heb het nog anders opgelost en het werkt... weet enkel niet of het veilig is op deze manier...
Dus wat heb ik gedaan de LAN1 op de USG is eigenlijk VLAN1.
Op de RasPi heb ik dus ook een statisch ip aangemaakt in de vlans file voor eth0.1 en dit blijkt gewoon te werken...

[Kopernikus.1979]

ps. weet je al meer ofdat vlan package en 8021q mod nodig zijn ?

Net getest op mijn 2de Pihole zonder vlan package en 8021q mod en alles werkt, merk geen verschil...
Ik veronderstel zolang er geen echte VLAN switching gebeurt deze niet nodig zijn?

Eigenlijk zijn het gewoon allemaal aliassen dus...
Maar waarin verschilt de setup dan met deze die ik ervoor had? (dus alle VLANS naar 1 PiHole ip adres).

[ed1703]

Kopernikus.1979 schreef op maandag 12 oktober 2020 @ 07:37:
[...]


Ik heb het nog anders opgelost en het werkt... weet enkel niet of het veilig is op deze manier...
Dus wat heb ik gedaan de LAN1 op de USG is eigenlijk VLAN1.
Op de RasPi heb ik dus ook een statisch ip aangemaakt in de vlans file voor eth0.1 en dit blijkt gewoon te werken...

Ok, gebruik zelf dit netwerk niet. Heb er een drop/drop op staan.
Je kunt nu een HA setup maken voor elk vlan, dit werkt met multicast, al kun je het ook met unicast configureren.
Als je toch bezig bent, kun je gelijk een HA-NTP setup bouwen.
Kan zijn dat je de interface namen moet aanpassen.

code:

1e node:

vrrp_instance failover_link1 {
    state MASTER
    interface eth0
    virtual_router_id 15
    priority 110
    advert_int 1
    authentication {
        auth_type AH
        auth_pass xxxxxx
    }
unicast_src_ip own.address
    unicast_peer {
        remote.address
    }
    virtual_ipaddress {
        10.x.x.x dev eth0 label eth0:vip-dns1
        10.x.x.x dev eth0 label eth0:vip-ntp1
    }
}

2e node:

vrrp_instance failover_link1 {
    state BACKUP
    interface eth0
    virtual_router_id 15
    priority 50
    advert_int 1
    authentication {
        auth_type AH
        auth_pass xxxxx
    }
unicast_src_ip own.address
    unicast_peer {
        remote.address
    }
    virtual_ipaddress {
        10.x.x.x dev eth0 label eth0:vip-dns1
        10.x.x.x dev eth0 label eth0:vip-ntp1
    }
}

[ Voor 3% gewijzigd door ed1703 op 12-10-2020 08:24 ]

[deHakkelaar]

Kopernikus.1979 schreef op maandag 12 oktober 2020 @ 07:42:
[...]
Eigenlijk zijn het gewoon allemaal aliassen dus...

Yup:
Wikipedia: IP aliasing

Kopernikus.1979 schreef op maandag 12 oktober 2020 @ 07:42:
[...]
Maar waarin verschilt de setup dan met deze die ik ervoor had? (dus alle VLANS naar 1 PiHole ip adres).

Dan routeer je toch ipv aliased IP's en de switch het werk laten doen ?
Of zie ik iets over het hoofd ?

[ Voor 32% gewijzigd door deHakkelaar op 12-10-2020 09:27 ]

[deHakkelaar]

ed1703 schreef op maandag 12 oktober 2020 @ 07:30:
[...]
Het dhcp probleem is op te lossen als pihole isc dhcpd zou adopteren, want die heeft een hasetup.

Geloof dat ook één vd redenen om embeded dnsmasq te gebruiken was omdat deze ééne binary naast DNS, ook als DHCP server kan fuctioneren.
Alles wat extra is zijn weer afhankelijkheden met weer hun eigen haken en ogen.
Ze zijn bv hard bezig om het lighttpd en PHP gedeelte af te stoten.
Als vervanging gaat dan de al bestaande binary pihole-FTL deze web server functie overnemen.

[ Voor 6% gewijzigd door deHakkelaar op 12-10-2020 09:17 ]

[Kopernikus.1979]

ed1703 schreef op maandag 12 oktober 2020 @ 08:07:
[...]

Ok, gebruik zelf dit netwerk niet. Heb er een drop/drop op staan.
Je kunt nu een HA setup maken voor elk vlan, dit werkt met multicast, al kun je het ook met unicast configureren.
Als je toch bezig bent, kun je gelijk een HA-NTP setup bouwen.
Kan zijn dat je de interface namen moet aanpassen.

code:

1e node:

vrrp_instance failover_link1 {
    state MASTER
    interface eth0
    virtual_router_id 15
    priority 110
    advert_int 1
    authentication {
        auth_type AH
        auth_pass xxxxxx
    }
unicast_src_ip own.address
    unicast_peer {
        remote.address
    }
    virtual_ipaddress {
        10.x.x.x dev eth0 label eth0:vip-dns1
        10.x.x.x dev eth0 label eth0:vip-ntp1
    }
}

2e node:

vrrp_instance failover_link1 {
    state BACKUP
    interface eth0
    virtual_router_id 15
    priority 50
    advert_int 1
    authentication {
        auth_type AH
        auth_pass xxxxx
    }
unicast_src_ip own.address
    unicast_peer {
        remote.address
    }
    virtual_ipaddress {
        10.x.x.x dev eth0 label eth0:vip-dns1
        10.x.x.x dev eth0 label eth0:vip-ntp1
    }
}

Gaan we zekers eens testen.
Gebruik jij je USG of de Pi-Hole als DHCP server?

[deHakkelaar]

Ow bijna vergeten:

Kopernikus.1979 schreef op maandag 12 oktober 2020 @ 07:42:
Ik veronderstel zolang er geen echte VLAN switching gebeurt deze niet nodig zijn?

Juist

[ed1703]

deHakkelaar schreef op maandag 12 oktober 2020 @ 08:58:
[...]
Dan routeer je toch ipv aliased IP's en de switch het werk laten doen ?
Of zie ik iets over het hoofd ?

Reden om voor switching te kiezen is omdat het rechtstreeks te benaderen is.
Geen firewall, geen routering, dus minder vertraging. Maarja, ik kan ook niet echt een verschil merken tussen de 2 mogelijkheden op een thuis lannetje. Ik kan niet ontkennen dat het binnen de PiHole community groter gemaakt word, dan het is.

Kopernikus.1979 schreef op maandag 12 oktober 2020 @ 09:23:
[...]


Gaan we zekers eens testen.
Gebruik jij je USG of de Pi-Hole als DHCP server?

Ik gebruik de USG, ik heb ook geen behoefte aan bakken met logging, groups en statistieken. Logging staat op de piholes zelfs uit. Als dat ding iets blocked wat ik open wil hebben zet ik het aan.

[ Voor 34% gewijzigd door ed1703 op 12-10-2020 09:35 ]

[nero355]

deHakkelaar schreef op maandag 12 oktober 2020 @ 09:27:
Ow bijna vergeten:

[...]

Juist

Raar dat ik dan destijds overal tegenkwam dat je die module nodig had

Ik knal hem wel effe uit mijn HowTo reactie en als het niet goed werkt om wat voor reden dan ook dan merken we het vanzelf wel!

[ed1703]

nero355 schreef op maandag 12 oktober 2020 @ 17:11:
[...]

Raar dat ik dan destijds overal tegenkwam dat je die module nodig had

Ik knal hem wel effe uit mijn HowTo reactie en als het niet goed werkt om wat voor reden dan ook dan merken we het vanzelf wel!

hmm..

Zonder het vlan package:

root@raspidomoticz:~# apt-cache policy vlan
vlan:
Installed: (none)
Candidate: 2.0.5
Version table:

root@raspidomoticz:~# dmesg | grep 802

[ 7.290777] 8021q: 802.1Q VLAN Support v1.8

Ik denk dat in het vlan-package vooral de vconfig binary zit om snel een vlan te maken.
Je krijgt dan direct een warning dat hij deprecated is en het vriendelijke verzoek om de ip tool te gebruiken.
Dat kan dan weer met het ip link commando.

[ Voor 9% gewijzigd door ed1703 op 12-10-2020 17:45 ]

[deHakkelaar]

Idd die mod wordt standaard voor Raspbian al geladen:

code:

pi@ph5:~ $ lsmod
[..]
8021q                  32768  0

code:

pi@ph5:~ $ modinfo 8021q
filename:       /lib/modules/5.4.51-v7+/kernel/net/8021q/8021q.ko
version:        1.8
license:        GPL
alias:          rtnl-link-vlan
srcversion:     90AC329A6F699640D74A137
depends:        garp
intree:         Y
name:           8021q
vermagic:       5.4.51-v7+ SMP mod_unload modversions ARMv7 p2v8

code:

pi@ph5:~ $ dpkg -S 8021q.ko
raspberrypi-kernel: /lib/modules/5.4.51-v7l+/kernel/net/8021q/8021q.ko
raspberrypi-kernel: /lib/modules/5.4.51-v7+/kernel/net/8021q/8021q.ko
raspberrypi-kernel: /lib/modules/5.4.51-v8+/kernel/net/8021q/8021q.ko
raspberrypi-kernel: /lib/modules/5.4.51+/kernel/net/8021q/8021q.ko

ed1703 schreef op maandag 12 oktober 2020 @ 17:36:
[...]
Ik denk dat in het vlan-package vooral de vconfig binary zit om snel een vlan te maken.
Je krijgt dan direct een warning dat hij deprecated is en het vriendelijke verzoek om de ip tool te gebruiken.
Dat kan dan weer met het ip link commando.

Wat ik kon vinden over dit onderwerp:

code:

pi@ph5:~ $ apt show vlan
[..]
 It currently also ships a wrapper script for backwards compatibility
 called vconfig, that replaces the old deprecated vconfig program
 with translations to ip(route2) commands.
 This compatibility shim might be dropped in future releases, please
 use ip(route2) commands directly.

code:

pi@ph5:~ $ apt-file list vlan
vlan: /etc/network/if-post-down.d/vlan
vlan: /etc/network/if-pre-up.d/vlan
vlan: /etc/network/if-up.d/ip
vlan: /sbin/vconfig
vlan: /usr/share/doc/vlan/NEWS.Debian.gz
vlan: /usr/share/doc/vlan/TODO
vlan: /usr/share/doc/vlan/changelog.gz
vlan: /usr/share/doc/vlan/copyright
vlan: /usr/share/man/man5/vlan-interfaces.5.gz
vlan: /usr/share/man/man8/vconfig.8.gz

code:

pi@ph5:~ $ man ip-link
[..]
       VLAN Type Support
              For a link of type VLAN the following additional arguments are supported:

              ip link add link DEVICE name NAME type vlan [ protocol VLAN_PROTO ] id VLANID [
              reorder_hdr { on | off } ] [ gvrp { on | off } ] [ mvrp { on | off } ] [
              loose_binding { on | off } ] [ ingress-qos-map QOS-MAP ] [ egress-qos-map QOS-
              MAP ]

[deHakkelaar]

nero355 schreef op donderdag 31 januari 2019 @ 19:04:

code:

auto eth0.10
iface eth0.10 inet manual
    vlan-raw-device eth0

@nero355 , volgens mij heb je die "vlan-raw-device eth0" regel ook niet nodig ?

nero355 schreef op donderdag 31 januari 2019 @ 19:04:
En dan nog het laatste gedeelte, zodat Pi-Hole weet dat er ook op die interface geluisterd moet worden!
In de map /etc/dnsmasq.d/ heb ik een bestand "101-mijn.settings" aangemaakt met daarin alleen het volgende :

code:

interface=eth0.10

Met bovenstaande moet je wel Pi-hole confgureren, met de web GUI, om alleen naar een enkele interface te luisteren.
Pi-hole zal dan een eigen "interface=" regeltje toevoegen aan het bestand "/etc/dnsmasq.d/01-pihole.conf" met de interface welke je hebt geselecteerd tijdens de Pi-hole installatie:

code:

pi@ph5:~ $ pihole -a -i single
  [i] Listening only on interface eth0
  [✓] Restarting DNS server

code:

pi@ph5:~ $ grep 'PIHOLE_INTERFACE\|DNSMASQ_LISTENING' /etc/pihole/setupVars.conf
PIHOLE_INTERFACE=eth0
DNSMASQ_LISTENING=single

code:

pi@ph5:~ $ grep interface /etc/dnsmasq.d/01-pihole.conf
interface=eth0

code:

pi@ph5:~ $ man dnsmasq
[..]
       -i, --interface=<interface name>
              Listen  only  on the specified interface(s). Dnsmasq auto‐
              matically adds the loopback (local) interface to the  list
              of interfaces to use when the --interface option  is used.
              If no --interface or --listen-address  options  are  given
              dnsmasq  listens  on  all  available interfaces except any
              given in --except-interface options. IP  alias  interfaces
              (eg "eth1:0") cannot be used with --interface or --except-
              interface options, use --listen-address instead. A  simple
              wildcard,  consisting  of  a  trailing '*', can be used in
              --interface and --except-interface options.

EDIT: en onderstaande gedeelte

IP alias interfaces (eg "eth1:0") cannot be used with --interface or --except- interface options, use --listen-address instead.

[ Voor 6% gewijzigd door deHakkelaar op 13-10-2020 03:11 ]

[visie]

Sinds een week ben ik begonnen met een raspberry 3b+. Ik loop tegen het volgende probleem aan:
Op de raspberry pi draaien pihole en WireGuard al prima. Maar sinds ik domiticz installeer werkt het allemaal niet meer.
Na een reboot werkt pihole niet, pas als ik inlog op de webpage op de raspberry start pihole en werkt de dns weer voor alle aangesloten apparaten.
Maar de vpn verbindingen krijgen geen dns meer.
Iemand een idee hoe dit kan na deze installatie?

[Webgnome]

Heb je de logs van pihole al gecontroleerd?

[nero355]

deHakkelaar schreef op dinsdag 13 oktober 2020 @ 02:20:
@nero355 , volgens mij heb je die "vlan-raw-device eth0" regel ook niet nodig ?

Test jij het effe dan hoor ik het resultaat wel!

Met bovenstaande moet je wel Pi-hole confgureren, met de web GUI, om alleen naar een enkele interface te luisteren.

Dat is inderdaad altijd mijn "Default config" dus misschien is dat inderdaad ook wel handig om te vermelden

visie schreef op dinsdag 13 oktober 2020 @ 08:03:
Sinds een week ben ik begonnen met een raspberry 3b+. Ik loop tegen het volgende probleem aan:
Op de raspberry pi draaien pihole en WireGuard al prima. Maar sinds ik domiticz installeer werkt het allemaal niet meer.
Na een reboot werkt pihole niet, pas als ik inlog op de webpage op de raspberry start pihole en werkt de dns weer voor alle aangesloten apparaten.
Maar de vpn verbindingen krijgen geen dns meer.
Iemand een idee hoe dit kan na deze installatie?

Zie : https://discourse.pi-hole...e-along-side-pi-hole/8684

Blijkbaar is er een conflict wat betreft de poorten die worden gebruikt en staat Domoticz niet meer in die lijst

[ed1703]

nero355 schreef op dinsdag 13 oktober 2020 @ 14:42:
[...]

Test jij het effe dan hoor ik het resultaat wel!

Nou, het werkt. Weer wat geleerd

[visie]

Webgnome schreef op dinsdag 13 oktober 2020 @ 08:20:
Heb je de logs van pihole al gecontroleerd?

Ik moet zeggen dat ik zo op het eerste oog niet iets bijzonders zie...
Maar ik ben pas sinds 1 week aan het inlezen in de Raspberry pi...

[b]nero355 in "[Pi-Hole] Ervaringen & discussie"nero355 schreef op dinsdag 13 oktober 2020


[...]

Zie : https://discourse.pi-hole...e-along-side-pi-hole/8684

Blijkbaar is er een conflict wat betreft de poorten die worden gebruikt en staat Domoticz niet meer in die lijst

Maar zo ver ik kan vinden zijn er toch heel veel mensen waarbij het geen problemen op levert... 🤔

Bij mij werkt het na een fresh install van alles nog steeds niet...

[ Voor 47% gewijzigd door visie op 13-10-2020 18:50 ]

[deHakkelaar]

nero355 schreef op dinsdag 13 oktober 2020 @ 14:42:
[...]
Test jij het effe dan hoor ik het resultaat wel!

ed1703 schreef op dinsdag 13 oktober 2020 @ 17:39:
[...]
Nou, het werkt. Weer wat geleerd

Thanx!
Ik had al getest zover voor mij mogelijk was aangezien ik thuis geen vlan mogelijkheid heb:
https://discourse.pi-hole...e-vlan-interfaces/38982/3

Nu is alleen de vraag nog ofdat je die "interface=eth0.10" regel nodig hebt voor de embedded dnsmasq.
Zoals hieronder valt te lezen kun je geen aliased IP interface opgeven met deze regel:

code:

pi@ph5:~ $ man dnsmasq
[..]
                                           ... IP  alias  interfaces
              (eg "eth1:0") cannot be used with --interface or --except-
              interface options, use --listen-address instead.

Mijn voorkeur gaat toch uit om helemaal geen "interface=" regels te gebruiken:

code:

pi@ph5:~ $ pihole -a -i all
  [i] Listening on all interfaces, permitting all origins. Please use a firewall!
  [✓] Restarting DNS server

De embedded dnsmasq zal dan op alle interface IP's luisteren en antwoorden.
Je moet dan wel controleren ofdat andere software niet stiekem een "interface=" regeltje toevoegen (bijvoorbeeld PiVPN):

code:

pi@ph5:~ $ sudo grep interface= -R /etc/dnsmasq.*
/etc/dnsmasq.d/01-pihole.conf:except-interface=nonexisting

Mocht je toch op bepaalde interfaces niet de Pi-hole DNS service willen aanbieden kun je de "except-interface=" regel gebruiken:

code:

pi@ph5:~ $ man dnsmasq
[..]
       -I, --except-interface=<interface name>
              Do not listen on the specified interface.  Note  that  the
              order  of --listen-address --interface and --except-inter‐
              face options does not matter and  that  --except-interface
              options always override the others.

Wat is julie mening ?

EDIT: typos

[ed1703]

deHakkelaar schreef op dinsdag 13 oktober 2020 @ 20:59:
... IP alias interfaces
(eg "eth1:0") cannot be used with --interface or --except-
interface options, use --listen-address instead.[/code]

Het beste is wel om deze te gebruiken.. want:

-I, --except-interface=<interface name>
Do not listen on the specified interface. Note that the
order of --listen-address --interface and --except-inter‐
face options does not matter and that --except-interface
options always override the others.[/code]

Deze optie heeft als nadeel dat als je achteraf een vlan toevoegt je aanpassingen moet doen, want hij gaat bij een restart van de service luisteren op de toegevoegde interface.

Ik vraag mij alleen af wat je ermee bereikt, pihole gaat namelijk gewoon op alle interfaces zitten, hij reageert alleen niet op de verzoeken die niet op je --listen-interface hebt staan:

code:

listen-address=::1,127.0.0.1,10.0.2.53

inet 127.0.0.1/8
inet 10.0.2.53/32
inet 10.0.2.30/24

pihole-FT  4963           pihole    4u  IPv4 60901915      0t0  UDP *:domain
pihole-FT  4963           pihole    5u  IPv4 60901916      0t0  TCP *:domain (LISTEN)
pihole-FT  4963           pihole    6u  IPv6 60901917      0t0  UDP *:domain
pihole-FT  4963           pihole    7u  IPv6 60901918      0t0  TCP *:domain (LISTEN)

host nu.nl 10.0.2.30
;; connection timed out; no servers could be reached

host nu.nl 10.0.2.53
Using domain server:
Name: 10.0.2.53
Address: 10.0.2.53#53
Aliases:

nu.nl has address 13.224.68.36
nu.nl has address 13.224.68.94
nu.nl has address 13.224.68.53
nu.nl has address 13.224.68.48
nu.nl mail is handled by 0 nu-nl.mail.protection.outlook.com.

Kun je net zo goed met iptables de boel dichtgooien, zo lijkt het. Veel voegt het allemaal niet toe, of ik moet wat missen?

[deHakkelaar]

ed1703 schreef op dinsdag 13 oktober 2020 @ 22:34:
[...]
Het beste is wel om deze te gebruiken.. want:

[...]
Deze optie heeft als nadeel dat als je achteraf een vlan toevoegt je aanpassingen moet doen, want hij gaat bij een restart van de service luisteren op de toegevoegde interface.

Maar als je een vlan toevoegt aan Pi-hole, dan doe je dat toch voor de DNS service ?
Als je niet wilt dat Pi-hole luisterd/antwoord, dan tag je dat vlan toch niet en maak je ook geen aliased IP aan toch ?
Die "except-interface=" regel zal dan eerder worden toegepast als je bv. de Pi-hole host ook als WiFi Access Point inricht en je niet wilt dat DNS verzoekjes beantwoord worden op de upstream WAN interface.

ed1703 schreef op dinsdag 13 oktober 2020 @ 22:34:
[...]
Ik vraag mij alleen af wat je ermee bereikt, pihole gaat namelijk gewoon op alle interfaces zitten, hij reageert alleen niet op de verzoeken die niet op je --listen-interface hebt staan:

Dat is juist.
Alleen als onderstaande regels gebruikt worden zal embedded dnsmasq daadwerkelijk alleen binden/luisteren op een aangegeven socket:

code:

pi@ph5:~ $ man dnsmasq
[..]
       -z, --bind-interfaces
              On  systems  which  support it, dnsmasq binds the wildcard
              address, even when it is listening  on  only  some  inter‐
              faces.  It  then discards requests that it shouldn't reply
              to. This has the advantage of working even when interfaces
              come and go and change address. This option forces dnsmasq
              to really bind only the interfaces  it  is  listening  on.
              About  the  only  time when this is useful is when running
              another nameserver (or another instance of dnsmasq) on the
              same  machine.  Setting  this option also enables multiple
              instances of dnsmasq which provide DHCP service to run  in
              the same machine.

       --bind-dynamic
              Enable  a  network  mode which is a hybrid between --bind-
              interfaces and the default. Dnsmasq binds the  address  of
              individual    interfaces,    allowing   multiple   dnsmasq
              instances, but if new interfaces or addresses  appear,  it
              automatically listens on those (subject to any access-con‐
              trol configuration). This makes dynamically created inter‐
              faces  work  in  the same way as the default. Implementing
              this option requires non-standard networking APIs  and  it
              is  only  available  under  Linux.  On  other platforms it
              falls-back to --bind-interfaces mode.

ed1703 schreef op dinsdag 13 oktober 2020 @ 22:34:
[...]
Kun je net zo goed met iptables de boel dichtgooien, zo lijkt het. Veel voegt het allemaal niet toe, of ik moet wat missen?

Als je zo'n belangrijke service draait in zovele vlan's, zou ik zoiezo aanraden om een FW op te zetten.

EDIT: Ow ik betwijfel ofdat die "interface=eth0.10" regel effectief is en verwachte resultaat oplevert.
Ik kan het niet testen want ik heb geen vlans

[ Voor 6% gewijzigd door deHakkelaar op 13-10-2020 23:00 ]

[ed1703]

deHakkelaar schreef op dinsdag 13 oktober 2020 @ 22:52:
[...]


Maar als je een vlan toevoegt aan Pi-hole, dan doe je dat toch voor de DNS service ?
Als je niet wilt dat Pi-hole luisterd/antwoord, dan tag je dat vlan toch niet en maak je ook geen aliased IP aan toch ?

Hangt er maar vanaf he. De meesten op Tweakers zetten hun pi’s toch wel multifunctioneel in.
Zo heb ik pihole, domoticz en syslog op een pi.
Verder ook een pi met logitech media server, pivpn, UniFi controller.
Allemaal met eigen alias voor een service.

Als je zo'n belangrijke service draait in zovele vlan's, zou ik zoiezo aanraden om een FW op te zetten.

Draai ik sowieso, al is het maar voor het leuke om te leren wat er allemaal met een firewall kan.

[deHakkelaar]

Dat is jouw voorkeur.
Mijn voorkeur voor belangrijke services zoals DNS is om deze op dedicated HW te draaien (in mijn geval een oude Pi 1B+).
Of een dedicated VM of container als de hypervisor/docker/esx/vsphere host betrouwbaar is en hoge uptime heeft.
Met zo'n multifuntionele Pi gebeurt het toch te vaak dat je met 1 aspect aan het tweaken bent en je de Pi weer moet rebooten.
En dan hopen dat je tweaks niet iets breken voor Pi-hole.

[ed1703]

deHakkelaar schreef op dinsdag 13 oktober 2020 @ 23:21:
Dat is jouw voorkeur.
Mijn voorkeur voor belangrijke services zoals DNS is om deze op dedicated HW te draaien (in mijn geval een oude Pi 1B+).
Of een dedicated VM of container als de hypervisor/docker/esx/vsphere host betrouwbaar is en hoge uptime heeft.
Met zo'n multifuntionele Pi gebeurt het toch te vaak dat je met 1 aspect aan het tweaken bent en je de Pi weer moet rebooten.
En dan hopen dat je tweaks niet iets breken voor Pi-hole.

Ja ik vind een hypervisor nog steeds het mooiste.
Mijn reden is vooral stroomverbruik. Pi 4 met basisvoorzieningen performed prima, al is een hypervisor gewoon veel sneller en updates ros je er zo doorheen. Al is dat met ssd ook wel aardig op te lossen.

[Krypt]

Al tijden een pihole draaien op een rpi, en eindelijk het lef en de tijd genomen om pihole in een donker op m'n unraid server te draaien.

Nadeel was natuurlijk dat pihole niet benaderbaar was vanuit m'n wireguard vpn verbinding, wat het geheel nog wat meer vertraging gaf. Maar uiteindelijk pihole docker in host mode gedraaid.

Ideaal dat je nu groepen kunt aanmaken, en je per groep specifieke blokkades kunt opleggen.
Ideaal om het YouTube gedrag van de kids te sturen dacht ik, maar helaas is de API van pihole niet zodanig dat je losse domains of groups aan en uit kunt zetten.

Toen maar eens voor het eerst gaan stoeien met PHP
Extra path definitie in de docker gezet zodat ik via de appdata wat extra PHP bestandjes vanuit de docker kon benaderen. Wat geklooi met sqlite3 en hoe de database in elkaar zat, is het me nu gelukt om de group koppeling aan een domainblock te kopieeren en te verwijderen van een andere group via een curl aanroep. Hier geef je een source en target group aan, en of ie geactiveerd moet worden of niet.

Zodoende koppelt ie alle domains die gekoppeld zijn aan de source group (YoutubeBlock bij mij) aan de target group (voor elk van m'n zoons 1tje waar hun devices aan gekoppeld zijn), of verwijderd deze weer. Vervolgens in homeassistant een button per zoon, met hieraan automations gekoppeld om een curl aanroep te doen voor blokkade of deblokkade.
Nog een timescheduler erop en er wordt automatisch YouTube geblocked wanneer dat nodig is

Not bad voor zo'n hobby bob projectje terwijl je eigenlijk nog nooit echt PHP icm sqlite3 hebt geprogrammeerd

[deHakkelaar]

ed1703 schreef op dinsdag 13 oktober 2020 @ 23:29:
[...]
Ja ik vind een hypervisor nog steeds het mooiste.

Ja als je weet om te gaan met een hypervisor/orchestrator, is het opzetten, verwijderen, snaps maken etc een puileschilletje

code:

$ uname -a
Linux xen

[ Voor 7% gewijzigd door deHakkelaar op 13-10-2020 23:34 ]

[nero355]

deHakkelaar schreef op dinsdag 13 oktober 2020 @ 20:59:
Wat is julie mening ?

Dat het een VLAN Interface is en de optie "Listen to all Interfaces" van de Pi-Hole WebGUI in het verleden nog weleens problemen gaf en het IMHO daarom beter is om de boel gewoon lekker via config files vast te zetten

_{Ik heb net mijn HowTo voor de zoveelste keer aangepast en er is nu amper nog wat van over...}

[deHakkelaar]

nero355 schreef op woensdag 14 oktober 2020 @ 00:10:
[...]
Dat het een VLAN Interface is en de optie "Listen to all Interfaces" van de Pi-Hole WebGUI in het verleden nog weleens problemen gaf en het IMHO daarom beter is om de boel gewoon lekker via config files vast te zetten

Ik heb ook vele postings op Pi-hole Discourse voorbij zien komen met dit probleem.
Maar in bijna alle gevallen was dit terug te leiden naar regeltjes toegevoegt aan de dnsmasq configuratie door andere software zoals PiVPN of een AP howto die ook beiden dnsmasq gebruiken voor DNS/DHCP.
Het misverstand is voornamelijk dat de "interface=" regel een restrictie is op de default van dnsmasq om op alles te luisteren.

[ Voor 29% gewijzigd door deHakkelaar op 14-10-2020 00:27 ]

[deHakkelaar]

nero355 schreef op woensdag 14 oktober 2020 @ 00:10:
[...]
_{Ik heb net mijn HowTo voor de zoveelste keer aangepast en er is nu amper nog wat van over...}

Ik zag de kleine lettertjes niet.
LOL
&
KISS
Wikipedia: KISS principle

[ Voor 14% gewijzigd door deHakkelaar op 14-10-2020 00:38 ]

[Freee!!]

deHakkelaar schreef op woensdag 14 oktober 2020 @ 00:21:
[...]
Ik heb ook vele postings op Pi-hole Discourse voorbij zien komen met dit probleem.
Maar in bijna alle gevallen was dit terug te leiden naar regeltjes toegevoegt aan de dnsmasq configuratie door andere software zoals PiVPN of een AP howto die ook beiden dnsmasq gebruiken voor DNS/DHCP.
Het misverstand is voornamelijk dat de "interface=" regel een restrictie is op de default van dnsmasq om op alles te luisteren.

Dus nog een voordeel van Pi-Hole in een Docker container draaien, dnsmasq is veilig opgeborgen op een plek waar andere software er niet bij kan.
Het nadeel van Pi-Hole als DHCP server is, dat er maar één DNS meegegeven wordt, lastig als je meer dan één Pi met ieder een Pi-Hole hebt draaien.

[deHakkelaar]

Freee!! schreef op woensdag 14 oktober 2020 @ 01:05:
[...]
Het nadeel van Pi-Hole als DHCP server is, dat er maar één DNS meegegeven wordt, lastig als je meer dan één Pi met ieder een Pi-Hole hebt draaien.

Mogelijk je standpunt in onderstaande Feature Request hard maken en duidelijk maken dat het om Docker gaat:
https://discourse.pi-hole...-servers-in-ph-dhcp/26918

Ik zie graag meer DHCP opties die meegeven kunnen worden dus mijn stem heeft ie al.

EDIT: mogelijk onderstaande beter.
Die heeft (nu) al 3 votes:

https://discourse.pi-hole...egration-in-the-gui/21959

[ Voor 11% gewijzigd door deHakkelaar op 14-10-2020 01:29 ]

[nero355]

Freee!! schreef op woensdag 14 oktober 2020 @ 01:05:
Dus nog een voordeel van Pi-Hole in een Docker container draaien, dnsmasq is veilig opgeborgen op een plek waar andere software er niet bij kan.

Maar als je gewoon alles zelf regelt is er niks aan de hand!

Het nadeel van Pi-Hole als DHCP server is, dat er maar één DNS meegegeven wordt, lastig als je meer dan één Pi met ieder een Pi-Hole hebt draaien.

Dat moet toch ook wel op te lossen zijn door zelf wat config files aan te passen

En als je een VRRP setje draait dan heb je sowieso maar één IP dat beide Pi-Hole's delen

deHakkelaar schreef op woensdag 14 oktober 2020 @ 00:37:
Ik zag de kleine lettertjes niet.
LOL
&
KISS
Wikipedia: KISS principle

KISS ken ik wel hoor : Zowel de term als de band!

Maar het is nu wel een erg simpel suf stukje tekst geworden... Ik hoop dat jullie gelijk hebben!

deHakkelaar schreef op woensdag 14 oktober 2020 @ 00:21:
Ik heb ook vele postings op Pi-hole Discourse voorbij zien komen met dit probleem.
Maar in bijna alle gevallen was dit terug te leiden naar regeltjes toegevoegt aan de dnsmasq configuratie door andere software zoals PiVPN of een AP howto die ook beiden dnsmasq gebruiken voor DNS/DHCP.

Hier op GoT was het vaak iemand die zoiets deed :
- eth0 voor normaal gebruik.
- wlan0 richting een Guest WiFi die puur en alleen door de WiFi Router of Accesspoints is afgeschermd via een Firewall i.p.v. een apart VLAN.

Het wlan0 gedeelte werkte dan heel vaak niet...

Het misverstand is voornamelijk dat de "interface=" regel een restrictie is op de default van dnsmasq om op alles te luisteren.

Je bedoelt dat op het moment dat je een dergelijke regel erbij zet DNSmasq dan de "Listen to all" optie negeert of zo

Volgens mij zagen de meesten het helemaal niet zo en waren ze meer met het "Waarom doet die het niet ?!" gedeelte bezig

[deHakkelaar]

nero355 schreef op woensdag 14 oktober 2020 @ 14:15:
[...]
Hier op GoT was het vaak iemand die zoiets deed :
- eth0 voor normaal gebruik.
- wlan0 richting een Guest WiFi die puur en alleen door de WiFi Router of Accesspoints is afgeschermd via een Firewall i.p.v. een apart VLAN.

Het wlan0 gedeelte werkte dan heel vaak niet...

Dat klinkt juist alsof "listening behavior" niet goed stond ingesteld op "Listen on all interfaces".
Of andere software die regeltjes hebben toegevoegt die bovenstaande verstoord / te niet doen.
Ik geloof dat in het begin, de default was "Listen only on interface ...".
Toen zijn ze een korte periode overgestapt naar default "Listen on all interfaces".
En ik geloof dat het nu weer terug naar af is "Listen only on interface ...".

Andere problemen welke ik kan bedenken, dat router DHCP verschillende DNS server IP's uitspuugt voor guest en normale LAN naargelang subnet voor desbetreffende netwerk.
Of een veiligheids feature op de router zoals "rebind protection" die niet toelaat om een lokale DNS server (met private IP) te gebruiken.
En ik heb ook andere veiligheids naampjes gezien die iets vergelijkbaars doen met DNS.
Ook een dooddoener is "DNS IPv6 route discovery" die je clients een DNS server van bv je ISP meegeven.

Ik zal dan toch graag zelf deze gevallen willen inspecteren met wat nslookup's of een tcpdump.
En ben er redelijk van overtuigt dat het probleem ergens anders ligt in deze gevallen.

nero355 schreef op woensdag 14 oktober 2020 @ 14:15:
Je bedoelt dat op het moment dat je een dergelijke regel erbij zet DNSmasq dan de "Listen to all" optie negeert of zo

Niet helemaal.
Ik bedoel dat als je de pihole-FTL binary, met embedded dnsmasq, opstart zonder configuratie, dus zonder regeltjes, deze default bind met alle IP's op alle interfaces en ook antwoord op allemaal.
Binden met 0.0.0.0:53 in onderstaande voorbeeld:

code:

pi@ph5:~ $ sudo netstat -nltup | grep 'Proto\|pihole-FTL'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      15176/pihole-FTL
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      15176/pihole-FTL
tcp6       0      0 ::1:4711                :::*                    LISTEN      15176/pihole-FTL
tcp6       0      0 :::53                   :::*                    LISTEN      15176/pihole-FTL
udp        0      0 0.0.0.0:53              0.0.0.0:*                           15176/pihole-FTL
udp6       0      0 :::53                   :::*                                15176/pihole-FTL

Die "interface=" regel zorgt er dus voor dat embedded dnsmasq alleen antwoord op opgegeven interface en niet meer op de anderen.
Je kunt uiteraard meerdere "interface=" regeltjes toepassen.

EDIT: DNS discovery via IPv6 in redelijk leesbare text
https://sc1.checkpoint.co...uter%20Discovery%7C_____0

[ Voor 6% gewijzigd door deHakkelaar op 14-10-2020 17:43 ]

[deHakkelaar]

nero355 schreef op woensdag 14 oktober 2020 @ 14:15:
[...]
Je bedoelt dat op het moment dat je een dergelijke regel erbij zet DNSmasq dan de "Listen to all" optie negeert of zo

Sorry ik las weer niet goed.
Ja.
Als je "Listen to all" selecteerd verwijdert Pi-hole z'n eigen "interface=" regeltje en komt daarvoor in de plaats "except-interface=nonexisting".

code:

pi@ph5:~ $ pihole -a -i single
  [i] Listening only on interface eth0
  [✓] Restarting DNS server

code:

pi@ph5:~ $ sudo grep interface= -R /etc/dnsmasq.*
/etc/dnsmasq.d/01-pihole.conf:interface=eth0

code:

pi@ph5:~ $ pihole -a -i all
  [i] Listening on all interfaces, permitting all origins. Please use a firewall!
  [✓] Restarting DNS server

code:

pi@ph5:~ $ sudo grep interface= -R /etc/dnsmasq.*
/etc/dnsmasq.d/01-pihole.conf:except-interface=nonexisting

[ Voor 44% gewijzigd door deHakkelaar op 14-10-2020 18:13 ]

[ed1703]

nero355 schreef op woensdag 14 oktober 2020 @ 14:15:
Dat moet toch ook wel op te lossen zijn door zelf wat config files aan te passen

En als je een VRRP setje draait dan heb je sowieso maar één IP dat beide Pi-Hole's delen

Werkt dat sowieso wel goed? Pihole in HA met VRRP en de ingebouwde DHCP-server? Volgens mij al eerder besproken dat je dan tegen issues aanloopt. DHCP-servers in HA moeten van elkaar weten wat ze uitdelen.

[nero355]

ed1703 schreef op woensdag 14 oktober 2020 @ 22:42:
Werkt dat sowieso wel goed? Pihole in HA met VRRP en de ingebouwde DHCP-server? Volgens mij al eerder besproken dat je dan tegen issues aanloopt. DHCP-servers in HA moeten van elkaar weten wat ze uitdelen.

Goed punt...

Ik ken het eigenlijk alleen van non-DHCP toepassingen...

deHakkelaar schreef op woensdag 14 oktober 2020 @ 18:03:
Sorry ik las weer niet goed.
Ja.
Als je "Listen to all" selecteerd verwijdert Pi-hole z'n eigen "interface=" regeltje en komt daarvoor in de plaats "except-interface=nonexisting".

code:

pi@ph5:~ $ pihole -a -i single
  [i] Listening only on interface eth0
  [✓] Restarting DNS server

code:

pi@ph5:~ $ sudo grep interface= -R /etc/dnsmasq.*
/etc/dnsmasq.d/01-pihole.conf:interface=eth0

code:

pi@ph5:~ $ pihole -a -i all
  [i] Listening on all interfaces, permitting all origins. Please use a firewall!
  [✓] Restarting DNS server

code:

pi@ph5:~ $ sudo grep interface= -R /etc/dnsmasq.*
/etc/dnsmasq.d/01-pihole.conf:except-interface=nonexisting

Ik denk dat ik nu eindelijk snap wat je wilde zeggen zonder alle extra uitleg :

Volgens jou dacht men dat "interface=" de "Listen to all" overrulede en dat is inderdaad sowieso niet de bedoeling

Maar waar ik het over had is dat die optie gewoon niks buiten eth0 oppakte.

[deHakkelaar]

Mocht je de winkel nog veiliger willen maken is de "local" optie ook een goede:

code:

pi@ph5:~ $ pihole -a -i -h
Usage: pihole -a -i [interface]
Example: 'pihole -a -i local'
Specify dnsmasq's network interface listening behavior

Interfaces:
  local               Listen on all interfaces, but only allow queries from
                      devices that are at most one hop away (local devices)
  single              Listen only on eth0 interface
  all                 Listen on all interfaces, permit all origins

code:

pi@ph5:~ $ pihole -a -i local
  [i] Listening on all interfaces, permitting origins from one hop away (LAN)
  [✓] Restarting DNS server

Er wordt dan onderstaande regeltje toegevoegt:

code:

pi@ph5:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
local-service

Maar ja dan moet je niet afhankelijk zijn van onderstaande regels:

code:

pi@ph5:~ $ man dnsmasq
[..]
       --local-service
              Accept  DNS  queries only from hosts whose address is on a
              local subnet, ie a subnet for which an interface exists on
              the  server.  This  option only has effect if there are no
              --interface   --except-interface,   --listen-address    or
              --auth-server  options.  It  is  intended  to  be set as a
              default on installation, to allow  unconfigured  installa‐
              tions  to  be useful but also safe from being used for DNS
              amplification attacks.

@nero355 , nog één dingetje, in de howto wordt alleen de "networking" service geherstart.
Dat zal ervoor zorgen dat de aliased interfaces worden aangemaakt en UP gebracht.
Maar de extra geconfigureerde IP addresses worden dan nog niet toegewezen.
Daarvoor zal je ook "dhcpcd" een schop moeten geven:

code:

pi@ph5:~ $ sudo service dhcpcd restart
pi@ph5:~ $

code:

pi@ph5:~ $ journalctl --no-pager --full -u dhcpcd
[..
Oct 15 07:15:32 ph5.dehakkelaar.nl systemd[1]: Stopped dhcpcd on all interfaces.
Oct 15 07:15:32 ph5.dehakkelaar.nl systemd[1]: Starting dhcpcd on all interfaces...
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: dev: loaded udev
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: DUID 00:01:00:xx:xx:xx:31:5a:b8:27:eb:xx:xx:xx
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: eth0: IAID eb:5e:d7:3b
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: eth0: using static address 10.0.0.4/24
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: eth0: adding route to 10.0.0.0/24
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: eth0: adding default route via 10.0.0.1
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: forked to background, child pid 30893
Oct 15 07:15:32 ph5.dehakkelaar.nl systemd[1]: Started dhcpcd on all interfaces.
Oct 15 07:15:33 ph5.dehakkelaar.nl dhcpcd[30893]: eth0: soliciting an IPv6 router
Oct 15 07:15:45 ph5.dehakkelaar.nl dhcpcd[30893]: eth0: no IPv6 Routers available

Dus kan de howto weer een beetje groeien

[Kopernikus.1979]

ed1703 schreef op dinsdag 13 oktober 2020 @ 17:39:
[...]

Nou, het werkt. Weer wat geleerd

Dus kort samengevat:

- VLAN package en 8021q module moeten NIET geïnstalleerd worden
- in het vlans bestandje mag "vlan-raw-device eth0" weggelaten worden
- in dhcpcd.conf de statische ip's definiëren zonder static router/domain (die bij eth0 zijn voldoende)
- in Pi-Hole de optie "listen to eth0" selecteren en de vlan interfaces plaatsen in conf bestand in de dnsmasq.d folder

Eigenlijk was de config beschreven door @deHakkelaar op discourse https://discourse.pi-hole...e-vlan-interfaces/38982/3 als antwoord op mijn initiële vraag al de hele tijd het juiste antwoord (met uitzondering dat de interfaces in vlans file geconfigureerd worden nu ipv rechtstreeks in het interfaces.d bestand.

Nog iets aan toe te voegen?

@nero355 Ik heb gezien dat je je "how to" post hebt aangepast, echter staat er niet meer in dat de interfaces moeten gedefinieerd worden in het vlans bestandje, of heb ik nu niet goed opgelet?

[ Voor 15% gewijzigd door Kopernikus.1979 op 16-10-2020 07:30 ]

[nero355]

deHakkelaar schreef op donderdag 15 oktober 2020 @ 07:37:
Mocht je de winkel nog veiliger willen maken is de "local" optie ook een goede:

code:

pi@ph5:~ $ pihole -a -i -h
Usage: pihole -a -i [interface]
Example: 'pihole -a -i local'
Specify dnsmasq's network interface listening behavior

Interfaces:
  local               Listen on all interfaces, but only allow queries from
                      devices that are at most one hop away (local devices)
  single              Listen only on eth0 interface
  all                 Listen on all interfaces, permit all origins

code:

pi@ph5:~ $ pihole -a -i local
  [i] Listening on all interfaces, permitting origins from one hop away (LAN)
  [✓] Restarting DNS server

Er wordt dan onderstaande regeltje toegevoegt:

code:

pi@ph5:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
local-service

Maar ja dan moet je niet afhankelijk zijn van onderstaande regels:

code:

pi@ph5:~ $ man dnsmasq
[..]
       --local-service
              Accept  DNS  queries only from hosts whose address is on a
              local subnet, ie a subnet for which an interface exists on
              the  server.  This  option only has effect if there are no
              --interface   --except-interface,   --listen-address    or
              --auth-server  options.  It  is  intended  to  be set as a
              default on installation, to allow  unconfigured  installa‐
              tions  to  be useful but also safe from being used for DNS
              amplification attacks.

Local mag van mij de Default Setting worden voor Pi-Hole in de toekomst

@nero355 , nog één dingetje, in de howto wordt alleen de "networking" service geherstart.
Dat zal ervoor zorgen dat de aliased interfaces worden aangemaakt en UP gebracht.
Maar de extra geconfigureerde IP addresses worden dan nog niet toegewezen.
Daarvoor zal je ook "dhcpcd" een schop moeten geven:

code:

pi@ph5:~ $ sudo service dhcpcd restart
pi@ph5:~ $

code:

pi@ph5:~ $ journalctl --no-pager --full -u dhcpcd
[..
Oct 15 07:15:32 ph5.dehakkelaar.nl systemd[1]: Stopped dhcpcd on all interfaces.
Oct 15 07:15:32 ph5.dehakkelaar.nl systemd[1]: Starting dhcpcd on all interfaces...
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: dev: loaded udev
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: DUID 00:01:00:xx:xx:xx:31:5a:b8:27:eb:xx:xx:xx
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: eth0: IAID eb:5e:d7:3b
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: eth0: using static address 10.0.0.4/24
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: eth0: adding route to 10.0.0.0/24
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: eth0: adding default route via 10.0.0.1
Oct 15 07:15:32 ph5.dehakkelaar.nl dhcpcd[30872]: forked to background, child pid 30893
Oct 15 07:15:32 ph5.dehakkelaar.nl systemd[1]: Started dhcpcd on all interfaces.
Oct 15 07:15:33 ph5.dehakkelaar.nl dhcpcd[30893]: eth0: soliciting an IPv6 router
Oct 15 07:15:45 ph5.dehakkelaar.nl dhcpcd[30893]: eth0: no IPv6 Routers available

Dus kan de howto weer een beetje groeien

Ik heb het erbij gezet... hopelijk klopt het ook!

Mocht ik ooit de boel herinstalleren dan heb ik in ieder geval wat te testen, want dit begint echt maf te worden : Zoveel dingen die niet kloppen en anders moeten/kunnen!

Kopernikus.1979 schreef op donderdag 15 oktober 2020 @ 12:13:
Dus kort samengevat:

- VLAN package en 8021q module moeten NIET geïnstalleerd worden
- in het vlans bestandje mag "vlan-raw-device eth0" weggelaten worden
- in dhcpcd.conf de statische ip's definiëren zonder static router/domain (die bij eth0 zijn voldoende)

Eigenlijk was de config beschreven door @deHakkelaar op discourse https://discourse.pi-hole...e-vlan-interfaces/38982/3 als antwoord op mijn initiële vraag al de hele tijd het juiste antwoord (met uitzondering dat de interfaces in vlans file geconfigureerd worden nu ipv rechtstreeks in het interfaces.d bestand.

Nog iets aan toe te voegen?

@nero355 Ik heb gezien dat je je "how to" post hebt aangepast, echter staat er niet meer in dat de interfaces moeten gedefinieerd worden in het vlans bestandje, of heb ik nu niet goed opgelet?

Ja, ja, ja, en ja

[deHakkelaar]

Ik hou van puzzelen en heb dit varkentje wel vaker gewassen

[Kopernikus.1979]

nero355 schreef op donderdag 15 oktober 2020 @ 14:27:
[...]

Local mag van mij de Default Setting worden voor Pi-Hole in de toekomst


[...]

Ik heb het erbij gezet... hopelijk klopt het ook!

Mocht ik ooit de boel herinstalleren dan heb ik in ieder geval wat te testen, want dit begint echt maf te worden : Zoveel dingen die niet kloppen en anders moeten/kunnen!


[...]

Ja, ja, ja, en ja

Bedoelde je met laatste ja, ja klopt moet ik er nog terug bijzetten of nee is niet meer nodig? Want als ik de interfaces niet meer definieer in het vlans bestandje werkt het niet meer bij mij....

[nero355]

Kopernikus.1979 schreef op donderdag 15 oktober 2020 @ 15:19:
Bedoelde je met laatste ja, ja klopt moet ik er nog terug bijzetten of nee is niet meer nodig?

Na alle tests en aanpassingen van @ed1703 en @deHakkelaar de afgelopen dagen zou de HUIDIGE versie die op dit moment in mijn reactie staat dus gewoon moeten werken!

Want als ik de interfaces niet meer definieer in het vlans bestandje werkt het niet meer bij mij....

Dat is dan de schuld van de eerder genoemde heren, want die zeggen dat het niet meer nodig is

[kaasaanfiets]

Ik heb sinds gister een Pi-Hole draaien.
Ik had het eerst verkeerd denk ik. Ik had op mijn LAN adapter van mijn laptop de DNS richting het ip van de PiHole ingesteld. Op mijn laptop leek alles te werken maar op andere apparaten niet.

Daarna heb ik in mijn experiabox(telfort) mijn DNS ook ingesteld naar het ip van de pihole en nu lijkt het netwerk wide te werken.

Alleen kom ik tegen een probleem aan. Ik speel op mijn tablet (android) het spelletje Fallout Shelter en hier wil ik juist af en toe op reclame klikken omdat dat extra items geeft. Maar toe worden dus nu geblockt waardoor de game denkt dat ik geen netwerk verbinding heb.

Hoe maak ik hiervoor een uitzondering? Ik kan wel iets whitelisten maar ik weet niet wat.

[Webgnome]

Kijk even in de querylog op het moment dat je het spel opstart. Dan zou er vanzelf vanaf het ip van het apparaat waar je dan op zit een bepaalde hostname moeten verschijnen die je kan whitelisten.

[Kopernikus.1979]

nero355 schreef op donderdag 15 oktober 2020 @ 17:16:
[...]

Na alle tests en aanpassingen van @ed1703 en @deHakkelaar de afgelopen dagen zou de HUIDIGE versie die op dit moment in mijn reactie staat dus gewoon moeten werken!


[...]

Dat is dan de schuld van de eerder genoemde heren, want die zeggen dat het niet meer nodig is

Ik heb het nog even "snel" nagelezen en ik lees nergens dat de vlan file niet meer nodig is, ik denk dat de interface regel uit de vlan file verward wordt met deze die je plaatst in de 100-naam.conf file in de dnsmasq.d directory zodat Pihole weet naar welke interfaces deze moet luisteren.

[ Voor 4% gewijzigd door Kopernikus.1979 op 15-10-2020 17:49 ]

[kaasaanfiets]

Webgnome schreef op donderdag 15 oktober 2020 @ 17:21:
Kijk even in de querylog op het moment dat je het spel opstart. Dan zou er vanzelf vanaf het ip van het apparaat waar je dan op zit een bepaalde hostname moeten verschijnen die je kan whitelisten.

Thanks, dat heb ik gedaan maar helaas met het whitelisten daarvan werkt het nog niet.

[ed1703]

Kopernikus.1979 schreef op donderdag 15 oktober 2020 @ 17:25:
[...]


Ik heb het nog even "snel" nagelezen en ik lees nergens dat de vlan file niet meer nodig is, ik denk dat de interface regel uit de vlan file verward wordt met deze die je plaatst in de 100-naam.conf file in de dnsmasq.d directory zodat Pihole weet naar welke interfaces deze moet luisteren.

De vlanfile is inderdaad wel nodig. De zaken eerder beschreven niet.
Dus geen raw-device e.d. 2 regels per vlan is nu voldoende.

[Kopernikus.1979]

ed1703 schreef op donderdag 15 oktober 2020 @ 17:52:
[...]

De vlanfile is inderdaad wel nodig. De zaken eerder beschreven niet.
Dus geen raw-device e.d. 2 regels per vlan is nu voldoende.

En zo heb ik het ook perfect werkende

[icecreamfarmer]

Iemand hier een succesvolle block op de reclameinjectie van TuneIn voor elkaar gekregen?
Ik heb of radio met reclame of niets.
legato.radiotime.com

Deze blokkeren leverde een niet werkende tunein op.
Overigens valt mij dat wanneer ik tuneIn via alexa oproep ik geen reclame krijg. Ik kan die echter niet via een routine aanroepen op mijn sonos. Iemand daar een idee over?

[Kopernikus.1979]

Om nog even terug te komen op mijn initiële vraag op discourse betreffende mijn 05-custom.conf of VLAN interfaces.. ondertussen is hier alles duidelijk heb ik met de nodige testen en tweaks (thx to @deHakkelaar @nero355 @ed1703) alles werkende. Maar als men in Pi-Hole niet gebruikt als DHCP en men de hostnames wil zien ipv de IP heb je die file natuurlijk nog nodig, echter vroeg ik me af als de ARPA's er nog in moeten?

Zo heb ik ze nu:

server=/Kopernikus-Native.lan/10.10.1.1
server=/Kopernikus-Trusted.lan/10.10.10.1
server=/Kopernikus-IoT.lan/10.10.20.1
server=/Kopernikus-Guests.lan/10.10.30.1
server=/Kopernikus-Surveillance.lan/10.10.40.1
server=/Kopernikus-Servers.lan/10.10.50.1
server=/Kopernikus-Management.lan/10.10.100.1
server=/1.10.10.in-addr.arpa/10.10.1.1
server=/10.10.10.in-addr.arpa/10.10.10.1
server=/20.10.10.in-addr.arpa/10.10.20.1
server=/30.10.10.in-addr.arpa/10.10.30.1
server=/40.10.10.in-addr.arpa/10.10.40.1
server=/50.10.10.in-addr.arpa/10.10.50.1
server=/100.10.10.in-addr.arpa/10.10.100.1

[deHakkelaar]

Ik neem aan dat 10.10.1.1, 10.10.20.1, 10.10.30.1, 10.10.40.1 en 10.10.50.1 allemaal dezelfde DNS server is toch ?
Parkeer dat 05-custom.conf bestandje dan voor diagnose ergens anders niet in de /etc/dnsmasq.d/ folder.
En configureer en aktiveer "Use Conditional Forwarding" op onderstaande linkje:

http://pi.hole/admin/settings.php?tab=dns

Pi-hole configureert dan onderstaande:

code:

pi@ph5:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
rev-server=10.0.0.0/24,10.0.0.2
server=/dehakkelaar.nl/10.0.0.2

Met een client kun je reverse lookups testen bv:

code:

C:\>nslookup laptop.dehakkelaar.nl
Server:  ph5.dehakkelaar.nl
Address:  10.0.0.4

Name:    laptop.dehakkelaar.nl
Address:  10.0.0.220

code:

C:\>nslookup laptop.dehakkelaar.nl 10.0.0.2
Server:  noads.dehakkelaar.nl
Address:  10.0.0.2

Name:    laptop.dehakkelaar.nl
Address:  10.0.0.220

code:

C:\>nslookup 10.0.0.220
Server:  ph5.dehakkelaar.nl
Address:  10.0.0.4

Name:    laptop.dehakkelaar.nl
Address:  10.0.0.220

code:

C:\>nslookup 10.0.0.220 10.0.0.2
Server:  noads.dehakkelaar.nl
Address:  10.0.0.2

Name:    laptop.dehakkelaar.nl
Address:  10.0.0.220

Wel oppassen dat je niet een DNS loop creert waarbij DNS queries weer terug loopen naar Pi-hole!

EDIT: hmmm mogelijk heb je toch een aantal van die "rev-server=10.0.0.0/24,10.0.0.2" regeltjes nodig.
Dan is weer beter om je eigen config bestandje daarvoor te gebruiken.

EDIT2: Ja vergeet conditional forwarding via de GUI.
Maak je eigen dnsmasq config bestandje aan met alleen die twee regels voor elk vlan/domein:

code:

rev-server=10.0.0.0/24,10.0.0.2
server=/dehakkelaar.nl/10.0.0.2

Niet vergeten te herstarten met "pihole restartdns"!

[ Voor 14% gewijzigd door deHakkelaar op 16-10-2020 08:50 ]

[ed1703]

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 07:49:
Om nog even terug te komen op mijn initiële vraag op discourse betreffende mijn 05-custom.conf of VLAN interfaces.. ondertussen is hier alles duidelijk heb ik met de nodige testen en tweaks (thx to @deHakkelaar @nero355 @ed1703) alles werkende. Maar als men in Pi-Hole niet gebruikt als DHCP en men de hostnames wil zien ipv de IP heb je die file natuurlijk nog nodig, echter vroeg ik me af als de ARPA's er nog in moeten?

Zo heb ik ze nu:

server=/Kopernikus-Native.lan/10.10.1.1
server=/Kopernikus-Trusted.lan/10.10.10.1
server=/Kopernikus-IoT.lan/10.10.20.1
server=/Kopernikus-Guests.lan/10.10.30.1
server=/Kopernikus-Surveillance.lan/10.10.40.1
server=/Kopernikus-Servers.lan/10.10.50.1
server=/Kopernikus-Management.lan/10.10.100.1
server=/1.10.10.in-addr.arpa/10.10.1.1
server=/10.10.10.in-addr.arpa/10.10.10.1
server=/20.10.10.in-addr.arpa/10.10.20.1
server=/30.10.10.in-addr.arpa/10.10.30.1
server=/40.10.10.in-addr.arpa/10.10.40.1
server=/50.10.10.in-addr.arpa/10.10.50.1
server=/100.10.10.in-addr.arpa/10.10.100.1

Ik gebruik gewoon de conffiles in dnsmasq.d:

code:

02-locallan.conf:
addn-hosts=/opt/etc/services.edg.lan

/opt/etc/services.edg.lan:
10.0.2.85   domoticz.edg.lan

Ik heb een reversed zone dan niet meer nodig.

code:

domoticz.edg.lan has address 10.0.2.85
85.2.0.10.in-addr.arpa domain name pointer domoticz.edg.lan

Mocht pihole bij een upgrade mijn configfile verwijderen, dan heb ik in /opt/etc een backup staan.
Het aantal upgrades is zo weinig, dat me zoiets niet boeit.
Ik scp elke nacht de hostfiles tussen de piholes. De 2 piholes zijn gelijk op de ipadressen na.

[deHakkelaar]

ed1703 schreef op vrijdag 16 oktober 2020 @ 08:47:
[...]

Ik gebruik gewoon de conffiles in dnsmasq.d:

code:

02-locallan.conf:
addn-hosts=/opt/etc/services.edg.lan

/opt/etc/services.edg.lan:
10.0.2.85   domoticz.edg.lan

Dat kan ook.
Of DNS records maken:
http://pi.hole/admin/dns_records.php

Maar dat is allemaal het handwerk

Ps. realiseer me net onderstaande

code:

pi@ph5:~ $ man dnsmasq
[..]
       --rev-server=<ip-address>/<prefix-
       len>,<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
              This is functionally the same as  --server,  but  provides
              some  syntactic  sugar  to make specifying address-to-name
              queries       easier.       For       example       --rev-
              server=1.2.3.0/24,192.168.0.1  is  exactly  equivalent  to
              --server=/3.2.1.in-addr.arpa/192.168.0.1

[ed1703]

deHakkelaar schreef op vrijdag 16 oktober 2020 @ 09:24:
[...]


Dat kan ook.
Of DNS records maken:
http://pi.hole/admin/dns_records.php

Maar dat is allemaal het handwerk

Ps. realiseer me net onderstaande

code:

pi@ph5:~ $ man dnsmasq
[..]
       --rev-server=<ip-address>/<prefix-
       len>,<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
              This is functionally the same as  --server,  but  provides
              some  syntactic  sugar  to make specifying address-to-name
              queries       easier.       For       example       --rev-
              server=1.2.3.0/24,192.168.0.1  is  exactly  equivalent  to
              --server=/3.2.1.in-addr.arpa/192.168.0.1

Yup, alleen doorverwijzen naar een USG zag ik niet zo zitten. Dat ding is nogal crap mbt extra entry's, dus moet je alsnog gaan inkloppen. (of je moet je hosts allemaal de namen van je services gaan geven, maar meestal niet werkbaar omdat je meerdere services hebt)

[ Voor 7% gewijzigd door ed1703 op 16-10-2020 09:30 ]

[deHakkelaar]

Alleen voor apparaten waarop ik een static IP heb geconfigureerd maak ik DNS records aan.
Dit omdat zij hun hostnaam niet adverteren aan de DHCP server tijdens de DHCP dialoog/lease transactie omdat geen gebruik wordt gemaakt van DHCP.

[Kopernikus.1979]

deHakkelaar schreef op vrijdag 16 oktober 2020 @ 08:12:
Ik neem aan dat 10.10.1.1, 10.10.20.1, 10.10.30.1, 10.10.40.1 en 10.10.50.1 allemaal dezelfde DNS server is toch ?

Dat zijn de gateways van iedere VLAN, draaien inderdaad allemaal op dezelfde DNS fysiek, maar met hun eigen IP alias, dus 10.10.1.5, 10.10.10.5, 10.10.20.5 enz

Parkeer dat 05-custom.conf bestandje dan voor diagnose ergens anders niet in de /etc/dnsmasq.d/ folder.
En configureer en aktiveer "Use Conditional Forwarding" op onderstaande linkje:

http://pi.hole/admin/settings.php?tab=dns

Pi-hole configureert dan onderstaande:

code:

pi@ph5:~ $ cat /etc/dnsmasq.d/01-pihole.conf
[..]
rev-server=10.0.0.0/24,10.0.0.2
server=/dehakkelaar.nl/10.0.0.2

Met een client kun je reverse lookups testen bv:

code:

C:\>nslookup laptop.dehakkelaar.nl
Server:  ph5.dehakkelaar.nl
Address:  10.0.0.4

Name:    laptop.dehakkelaar.nl
Address:  10.0.0.220

code:

C:\>nslookup laptop.dehakkelaar.nl 10.0.0.2
Server:  noads.dehakkelaar.nl
Address:  10.0.0.2

Name:    laptop.dehakkelaar.nl
Address:  10.0.0.220

code:

C:\>nslookup 10.0.0.220
Server:  ph5.dehakkelaar.nl
Address:  10.0.0.4

Name:    laptop.dehakkelaar.nl
Address:  10.0.0.220

code:

C:\>nslookup 10.0.0.220 10.0.0.2
Server:  noads.dehakkelaar.nl
Address:  10.0.0.2

Name:    laptop.dehakkelaar.nl
Address:  10.0.0.220

Wel oppassen dat je niet een DNS loop creert waarbij DNS queries weer terug loopen naar Pi-hole!

EDIT: hmmm mogelijk heb je toch een aantal van die "rev-server=10.0.0.0/24,10.0.0.2" regeltjes nodig.
Dan is weer beter om je eigen config bestandje daarvoor te gebruiken.

EDIT2: Ja vergeet conditional forwarding via de GUI.
Maak je eigen dnsmasq config bestandje aan met alleen die twee regels voor elk vlan/domein:

code:

rev-server=10.0.0.0/24,10.0.0.2
server=/dehakkelaar.nl/10.0.0.2

Niet vergeten te herstarten met "pihole restartdns"!

Eu... moment ben even niet meer mee

Dus ik maak een config bestand plaats deze in dnsmasq.d met daarin, vb:

rev-server=10.10.10.0/24,10.10.10.1
server=/Kopernikus-Trusted.lan/10.0.0.1

en dan hetzelfde voor alle vlans?

Wat is het verschil met de config die ik deed?

[deHakkelaar]

Geen.

code:

pi@ph5:~ $ man dnsmasq
[..]
       --rev-server=<ip-address>/<prefix-
       len>,<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
              This is functionally the same as  --server,  but  provides
              some  syntactic  sugar  to make specifying address-to-name
              queries       easier.       For       example       --rev-
              server=1.2.3.0/24,192.168.0.1  is  exactly  equivalent  to
              --server=/3.2.1.in-addr.arpa/192.168.0.1

Zie je namen of IP's ?
Heb je die nslookups geprobeert ?

EDIT: in dat nslookup voorbeeld zou dan 10.0.0.2 de USG zijn (die neem ik aan DHCP doet) en 10.0.0.4 Pi-hole.

[ Voor 8% gewijzigd door deHakkelaar op 16-10-2020 09:51 ]

[MAdD]

icecreamfarmer schreef op donderdag 15 oktober 2020 @ 19:48:
Iemand hier een succesvolle block op de reclameinjectie van TuneIn voor elkaar gekregen?
Ik heb of radio met reclame of niets.
legato.radiotime.com

Deze blokkeren leverde een niet werkende tunein op.
Overigens valt mij dat wanneer ik tuneIn via alexa oproep ik geen reclame krijg. Ik kan die echter niet via een routine aanroepen op mijn sonos. Iemand daar een idee over?

beetje offtopic, maar kan je het station niet handmatig toevoegen??
Oftewel de stream eerst via je pc laten lopen, dan kijken welke url er gebruikt wordt en deze in sonos ingeven? (dit heb ik gedaan voor GrandPrixRadio), werkt een stuk beter. (heb dan een directe stream van GPR en deze loopt niet via tunein)

[Kopernikus.1979]

deHakkelaar schreef op vrijdag 16 oktober 2020 @ 09:43:
Geen.

code:

pi@ph5:~ $ man dnsmasq
[..]
       --rev-server=<ip-address>/<prefix-
       len>,<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
              This is functionally the same as  --server,  but  provides
              some  syntactic  sugar  to make specifying address-to-name
              queries       easier.       For       example       --rev-
              server=1.2.3.0/24,192.168.0.1  is  exactly  equivalent  to
              --server=/3.2.1.in-addr.arpa/192.168.0.1

Zie je namen of IP's ?
Heb je die nslookups geprobeert ?

EDIT: in dat voorbeeld zou dan 10.0.0.2 de USG zijn (die neem ik aan DHCP doet) en 10.0.0.4 Pi-hole.

Ik zie de hostnames
Nslookup ga ik deze middag eens testen want ben niet thuis nu

[deHakkelaar]

Das goed toch ?
Die PTR arpa records zijn nodig omdat via DNS de eigen hostnaam niet wordt geadverteerd zoals via DHCP.
Dus Pi-hole ziet alleen maar IP addresses als DNS verzoekjes binnen komen.
Wat Pi-hole doet is, ik geloof om het uur, de IP's naar naam binnen trekken via die in-addr.arpa PTR records op je DHCP server om de namen te verversen:

code:

pi@ph5:~ $ dig +short -t ptr  220.0.0.10.in-addr.arpa @10.0.0.2
laptop.dehakkelaar.nl.

code:

C:\>nslookup -type=ptr 220.0.0.10.in-addr.arpa 10.0.0.2
Server:  noads.dehakkelaar.nl
Address:  10.0.0.2

220.0.0.10.in-addr.arpa name = laptop.dehakkelaar.nl

[ Voor 16% gewijzigd door deHakkelaar op 16-10-2020 10:17 ]

[icecreamfarmer]

MAdD schreef op vrijdag 16 oktober 2020 @ 09:49:
[...]

beetje offtopic, maar kan je het station niet handmatig toevoegen??
Oftewel de stream eerst via je pc laten lopen, dan kijken welke url er gebruikt wordt en deze in sonos ingeven? (dit heb ik gedaan voor GrandPrixRadio), werkt een stuk beter. (heb dan een directe stream van GPR en deze loopt niet via tunein)

Goede tip. Zal eens kijken of dat werkt.

[Kopernikus.1979]

Vraagje: in de pihole log zie ik nogal veel request naar wpad.mylocaldomain komende van Windows 10 pc's, deze requests worden geforwared en de meeste krijgen geen antwoord komt er N/A en hier en daar komt er als antwoord NXDOMAIN meestal rond de 0.34ms. Voor zover ik me herinner zijn dit samba requests, echter moet er hier iets aangepast worden? of hoe gaan jullie hier mee ok?

[Webgnome]

Dit zijn volgens mij windows 10 discovery requests. Je kunt dit op internet vinden hoe je dat uit kan zetten. In principe laat ik die gewoon door. Heeft nit heel veel impact

[Kopernikus.1979]

Momenteel gebruik ik Pi-Hole voor al mijn VLANS, echter het probleem dat ik nu heb is op mijn management VLAN dat er bijna elke seconde een request gestuurd wordt mijn switches/ap naar de Ubiquiti controller, dus naar unifi.mijndomein en die wordt netjes beantwoord met het correcte IP van de controller, maar deze blijft dit doen.... voorheen zal dat ook zo geweest zijn denk ik maar dan zag ik het niet gezien de management VLAN niet over Pi-Hole liep. Iemand een idee?

[JeroenE]

@Kopernikus.1979 Is dat niet omdat je niet wil dat wanneer je unifi controller een ander IP adres krijgt het 24 uur (of wat dan ook) duurt voordat je AP's weer met de controller kunnen kletsen? Als is iedere seconde dan natuurlijk ook wel weer wat vaak.

[Kopernikus.1979]

JeroenE schreef op vrijdag 16 oktober 2020 @ 13:21:
@Kopernikus.1979 Is dat niet omdat je niet wil dat wanneer je unifi controller een ander IP adres krijgt het 24 uur (of wat dan ook) duurt voordat je AP's weer met de controller kunnen kletsen? Als is iedere seconde dan natuurlijk ook wel weer wat vaak.

Alle Ubiquiti devices switches/ap/cameras melden zich via de "inform host" zodat deze kunnen beheerd worden door de controller.

Ik heb het nu opgelost door als inform host het IP van de controller op te geven en de optie "Overschrijf inform host met de Controller hostnaam/IP" zo is er geen resolving nodig... echter ideaal?

Verder zie ik nu ook dat de switches/graag es naar huis bellen naar ping.ui.com om de paar seconden...

[ Voor 23% gewijzigd door Kopernikus.1979 op 16-10-2020 13:39 ]

[JeroenE]

@Kopernikus.1979 Ik weet niet of het verder te controleren is, maar hier wordt geschreven dat de AP's toch "unifi" blijven resolven, ondanks dat er al een controller is opgegeven. In dat geval gaat het echter wel om iedere 30 seconden en niet iedere seconde.

[Kopernikus.1979]

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 09:52:
[...]


Ik zie de hostnames
Nslookup ga ik deze middag eens testen want ben niet thuis nu

Bij nslookup krijg ik dit:

code:

C:\WINDOWS\System32>nslookup 10.10.10.109
Server:  UnKnown
Address:  10.10.10.5

Name:    Nicos-Galaxy-S20-Ultra-5G.Kopernikus-Trusted.lan
Address:  10.10.10.109

Het lijkt te werken maar de servernaam staat wel unknown, hoe zou dit komen?

EDIT ---> gevonden Ik was vergeten nu ik voor iedere VLAN een alias IP heb in Pihole, ik ook die Pihole aliassen in mijn hosts file moet plaatsen

Zo ziet het er nu uit:

code:

Microsoft Windows [Version 10.0.19041.572]
(c) 2020 Microsoft Corporation. Alle rechten voorbehouden.

C:\WINDOWS\System32>nslookup 10.10.10.109
Server:  pihole.Kopernikus-Trusted.lan
Address:  10.10.10.5

Name:    Nicos-Galaxy-S20-Ultra-5G.Kopernikus-Trusted.lan
Address:  10.10.10.109


C:\WINDOWS\System32>

[ Voor 45% gewijzigd door Kopernikus.1979 op 16-10-2020 18:10 ]

[Kopernikus.1979]

JeroenE schreef op vrijdag 16 oktober 2020 @ 13:48:
@Kopernikus.1979 Ik weet niet of het verder te controleren is, maar hier wordt geschreven dat de AP's toch "unifi" blijven resolven, ondanks dat er al een controller is opgegeven. In dat geval gaat het echter wel om iedere 30 seconden en niet iedere seconde.

Misschien was iedere seconde wat overdreven, maar ze doen het niet allemaal tegelijk maar als iedere device om de 30 seconden een request stuurt komt er hier wel om de seconde een request binnen al was het wel van een andere switch/ap.

Als je PiHole niet als resover gebruikt heb je hier geen last van natuurlijk, de vraag is kan dit kwaad naar performantie toe in PiHole? Want in de instellingen van PiHole kun je instellen bepaalde domeinen niet te loggen....

@ed1703 Hoe doe jij dit? Want zoals ik begrepen heb, heb jij ook een USG en resolve je ook alles met Pi-Hole?

[ed1703]

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 13:57:
[...]


Misschien was iedere seconde wat overdreven, maar ze doen het niet allemaal tegelijk maar als iedere device om de 30 seconden een request stuurt komt er hier wel om de seconde een request binnen al was het wel van een andere switch/ap.

Als je PiHole niet als resover gebruikt heb je hier geen last van natuurlijk, de vraag is kan dit kwaad naar performantie toe in PiHole? Want in de instellingen van PiHole kun je instellen bepaalde domeinen niet te loggen....

@ed1703 Hoe doe jij dit? Want zoals ik begrepen heb, heb jij ook een USG en resolve je ook alles met Pi-Hole?

Ik gebruik pihole op al m'n netwerken. Ik heb er verder geen last van omdat ik geen logging aan heb staan, want daar zie ik behalve als ik iets moet whitelisten, het nut niet van.

Ik verstouw ongeveer 200k aan dns-lookups per dag. Is dat heel veel meer bij jou?

* ed1703 Is niet zo statistieken horny

[nero355]

Kopernikus.1979 schreef op donderdag 15 oktober 2020 @ 17:56:
En zo heb ik het ook perfect werkende

Post dan eens een werkende config "op de nieuwe manier" want ik ben er wel een beetje klaar mee!

MAdD schreef op vrijdag 16 oktober 2020 @ 09:49:
beetje offtopic, maar kan je het station niet handmatig toevoegen??
Oftewel de stream eerst via je pc laten lopen, dan kijken welke url er gebruikt wordt en deze in sonos ingeven? (dit heb ik gedaan voor GrandPrixRadio), werkt een stuk beter. (heb dan een directe stream van GPR en deze loopt niet via tunein)

icecreamfarmer schreef op vrijdag 16 oktober 2020 @ 10:21:
Goede tip. Zal eens kijken of dat werkt.

Ik heb zoiets werkende d.m.v. https://www.pimusicbox.com/ op een aparte Pi en dat werkt best wel goed afhankelijk van de stream die je erin klopt!

Het geheel is gebaseerd op Mopidy en een WebGUI waarmee je dus Mopidy bestuurt.
Er zijn ook apps en normale applicaties voor beschikbaar zoals Cantata die ik weer i.c.m. het originele mpd gebruikt op de laptop

Kortom : Ga er eens mee testen en kijk of het wat voor je kan betekenen!

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 12:11:
Vraagje: in de pihole log zie ik nogal veel request naar wpad.mylocaldomain komende van Windows 10 pc's, deze requests worden geforwared en de meeste krijgen geen antwoord komt er N/A en hier en daar komt er als antwoord NXDOMAIN meestal rond de 0.34ms. Voor zover ik me herinner zijn dit samba requests, echter moet er hier iets aangepast worden? of hoe gaan jullie hier mee ok?

Dat is de 'Automatic Proxy Discovery and Configuration" van Windows en kan je op verschillende manieren mee omgaan...

Moet je effe wat meer over onderzoeken en dan zelf bepalen wat je ermee doet

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 13:29:
Ik heb het nu opgelost door als inform host het IP van de controller op te geven en de optie "Overschrijf inform host met de Controller hostnaam/IP" zo is er geen resolving nodig... echter ideaal?

Zo heb ik het ook gedaan, maar ik weet de exacte reden niet meer...

Wat ik nog wel weet : Als je daar een DNS naam invoert dan zal je USG in een Bootloop komen en moet je hem via SSH eruit halen!

Verder zie ik nu ook dat de switches/graag es naar huis bellen naar ping.ui.com om de paar seconden...

De USG doet dat sowieso om je Ping te meten voor de UniFi Controller WebGUI Statistics meuk, maar er zit ook het een en ander aan telemetry zooi in die je kan disablen!

Hoe je dat doet hebben we onlangs in [Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 4 besproken dus kijk daar effe rond

[Gulli]

Hoi mede-tweakers

Sinds vandaag ben ik de gelukkige eigenaar van een Raspberry Pi en dus ben ik meteen aan de slag gegaan om PI-Hole aan de gang te krijgen, maar er lijkt ergens iets nog niet helemaal te werken.

Wat ik wil;
Mijn Pi instellen zodat al het netwerkverkeer via Pi-Hole wordt geleid en dus zo min mogelijk ads/trackers binnen mijn netwerk.

Ik heb;
Raspberry Pi 3B+
Raspbian nieuwste versie
KPN Experia V10 (ZTE) router
3x KPN Experia Wifi AP's
Losse oude wifi router waarvan de DHCP is uitgeschakeld

Wat ik heb gedaan;
Via SSH Pi-Hole geïnstalleerd en alle settings op default laten staan, ik kan daar nu via mijn browser op de adminpagina inloggen in het dashboard en alles zien.
De Pi heeft in mijn router een statisch IP-adres gekregen.
Een aantal bekende blacklists ingeladen.
In mijn router de DNS aangepast naar het IP-adres van de Pi.
ipconfig /flushdns
Alle routers en AP's opnieuw opgestart.

Ik ben allang blij dat ik nog internet heb en ik dus met die setting in mijn router niet de hele boel ontregeld heb, maar ik vind het wel vreemd dat er dus totaal niets geblokkeerd wordt en er in het dashboard dus ook geen geblokkeerde ads tevoorschijn komen.

Een paar opmerkingen;
Tijdens de installatie heb ik IPv6 niet aangevinkt (was geen default keuze), later heb ik hem in de instellingen via de adminpagina alsnog aangevinkt (geen verschil).
Het IP-adres dat ik nu van de Pi gebruik is het WiFi IP, om de een of andere reden kon ik bedraad niet bij de Pi inloggen via SSH.
De Pi hangt via UTP aan de losse router waarvan de DHCP dus uitstaat, naar mijn weten is dat nu dus een simpele switch. Moet ik de Pi misschien direct aan de Experia router hangen?

Wat doe ik fout? Zie ik iets heel simpels over het hoofd wellicht?

DNS van mijn router ingesteld op het IP=adres van de Pi;


Ziehier het IP-adres;


Het IP-adres is statisch;

[ Voor 0% gewijzigd door Gulli op 16-10-2020 17:03 . Reden: typo's ]

[Freee!!]

Gulli schreef op vrijdag 16 oktober 2020 @ 17:01:
[...]
Wat doe ik fout? Zie ik iets heel simpels over het hoofd wellicht?

Voor zover ik kan zien, doe je niets fout. Je ziet echter wel over het hoofd, dat de DNS-adressen meegegeven worden met de DHCP-lease en zolang die niet verloopt, halen je apparaten nog geen nieuw DNS-adres op.

Probeer op je computer maar eens het commando:
ipconfig /renew

[Gulli]

Gedaan, moet ik nog iets herstarten/even wachten nu?

In ipconfig /all zie ik trouwens dat de router ook als DNS vermeld staat;

DNS Servers . . . . . . . . . . . : fe80::b2ac:d2ff:fe04:81a2%21
192.168.2.14
192.168.2.254
fe80::b2ac:d2ff:fe04:81a2%21
NetBIOS over Tcpip. . . . . . . . : Enabled

[Freee!!]

Gulli schreef op vrijdag 16 oktober 2020 @ 17:26:
Gedaan, moet ik nog iets herstarten/even wachten nu?

In ipconfig /all zie ik trouwens dat de router ook als DNS vermeld staat;

DNS Servers . . . . . . . . . . . : fe80::b2ac:d2ff:fe04:81a2%21
192.168.2.14
192.168.2.254
fe80::b2ac:d2ff:fe04:81a2%21
NetBIOS over Tcpip. . . . . . . . : Enabled

Dat is wat minder fijn, kijk nog eens goed naar een tweede (en derde) DNS-adres in de settings.

[Gulli]

In dit topic op het KPN forum geeft een mod aan dat er maar 1 DNS in te stellen is en dat de andere dus blijkbaar hardcoded is.

Iemand anders geeft aan dat je de ISP DNS uit zou kunnen zetten omdat dat een fallback DNS zou kunnen zijn, maar zoals je ziet in mijn eerdere screenshot staat die al uit

Geen idee hoe ik hier dan weer omheen kom

[Freee!!]

Gulli schreef op vrijdag 16 oktober 2020 @ 17:49:
In dit topic op het KPN forum geeft een mod aan dat er maar 1 DNS in te stellen is en dat de andere dus blijkbaar hardcoded is.

Iemand anders geeft aan dat je de ISP DNS uit zou kunnen zetten omdat dat een fallback DNS zou kunnen zijn, maar zoals je ziet in mijn eerdere screenshot staat die al uit

Geen idee hoe ik hier dan weer omheen kom

In dat geval zou je kunnen overwegen om de DHCP-functionaliteit van je router compleet uit te schakelen en Pi-Hole die taak ook te laten vervullen.

[Gulli]

Ik ga eens kijken of ik de Pi dichter bij de router kan plaatsen, mocht ik dan een DHCP moeten overnemen dan heb ik denk ik liever dat de Pi direct aan de router hangt ipv de constructie die ik nu heb

Thx voor de hulp, ik ga weer even klussen!

[Freee!!]

Gulli schreef op vrijdag 16 oktober 2020 @ 18:12:
Ik ga eens kijken of ik de Pi dichter bij de router kan plaatsen, mocht ik dan een DHCP moeten overnemen dan heb ik denk ik liever dat de Pi direct aan de router hangt ipv de constructie die ik nu heb

Maakt weinig uit, ik heb twee RPi's met ieder een Pi-Hole en een aparte DHCP-server^*) (op één van de twee RPi's) via een PoE switch verbonden met modem/router/wifi, draait echt uitstekend.

Thx voor de hulp, ik ga weer even klussen!

Succes ermee.


^*) DHCP-functionaliteit van modem/router heeft de geest gegeven, dus DHCP-server op de RPi 4B erbij geïnstalleerd, kan ik weer twee Pi-Holes meegeven voor DNS.

[Webgnome]

Hoe werkt dat eigenlijk? Als ik bij mijn ziggo router dhcp uitzet. Hoe zorg ik er dan voor dat de devices weten wat dan mijn dhcp server is?

[Kopernikus.1979]

Beste,

Zonet mijn gateway.config.json aangepast om toestellen die hardcoded DNS hebben toch via Pi-Hole te laten resolven, voordien werkte deze perfect, maar nu aangepast voor VLAN setup, ziet iemand fouten:

code:

{
  "service": {
    "mdns": {
      "repeater": {
        "interface": [
          "eth1.10",
          "eth1.20"
        ]
      }
    },
    "nat": {
      "rule": {
        "1": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.1",
          "inside-address": {
            "address": "10.10.1.5-10.10.1.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.1.5-10.10.1.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "2": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.10",
          "inside-address": {
            "address": "10.10.10.5-10.10.10.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.10.5-10.10.10.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "3": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.20",
          "inside-address": {
            "address": "10.10.20.5-10.10.20.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.20.5-10.10.20.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "4": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.30",
          "inside-address": {
            "address": "10.10.30.5-10.10.30.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.30.5-10.10.30.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "5": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.40",
          "inside-address": {
            "address": "10.10.40.5-10.10.40.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "6": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.50",
          "inside-address": {
            "address": "10.10.50.5-10.10.50.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "7": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.100",
          "inside-address": {
            "address": "10.10.100.5-10.10.100.6",
            "port": "53"
          },
          "source": {
            "address": "!10.10.100.5-10.10.100.6"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "6000": {
          "description": "MASQ DNS requests to LAN",
          "destination": {
            "address": "10.10.1.5-10.10.1.6-10.10.10.5-10.10.10.6-10.10.20.5-10.10.20.6-10.10.30.5-10.10.30.6-10.10.40.5-10.10.40.6-10.10.50.5-10.10.50.6-10.10.100.5-10.10.100.6",
            "port": "53"
          },
          "log": "disable",
          "outbound-interface": "eth1",
          "protocol": "tcp_udp",
          "type": "masquerade"
        }
      }
    }
  }
}

[Freee!!]

Webgnome schreef op vrijdag 16 oktober 2020 @ 18:34:
Hoe werkt dat eigenlijk? Als ik bij mijn ziggo router dhcp uitzet. Hoe zorg ik er dan voor dat de devices weten wat dan mijn dhcp server is?

Op dezelfde manier dat ze nu weten dat je ziggo router de DHCP server is. Op het moment, dat devices een IP-adres nodig hebben, sturen ze een broadcast message naar poort 67. De eerste DHCP-server, die reageert, bepaalt het IP-adres dat uitgedeeld wordt. Om oorlog te voorkomen, is er meestal maar één actieve DHCP-server in een netwerk.

[Kopernikus.1979]

Wat ik nog wel weet : Als je daar een DNS naam invoert dan zal je USG in een Bootloop komen en moet je hem via SSH eruit halen!

Dat probleem heb ik niet, als ik de DNS naam van mijn controller ingeef (die gedefinieerd staat in mijn hosts bestand in Pi-Hole en naar de controller IP verwijst) dan werkt alles perfect, enkel... om de 30 sec krijg ik van iedere switch en AP een request binnen dus dat loopt al snel op... met een IP adres heb ik dit niet, maar aan de andere kant zou ik liever de dns naam gebruiken omdat als ik dan de controller bv verplaats ik enkel de host record moet aanpassen en alles werkt terug. Ik probeer eigen alles met statische DHCP toe te kennen. Misschien dat ik voor test eens hem 24u laat draaien via hostname en zie hoeveel querry's dat extra oplevert, ik weet ook niet wat de impact naar performantie toe is.

[ed1703]

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 18:46:
[...]


Dat probleem heb ik niet, als ik de DNS naam van mijn controller ingeef (die gedefinieerd staat in mijn hosts bestand in Pi-Hole en naar de controller IP verwijst) dan werkt alles perfect, enkel... om de 30 sec krijg ik van iedere switch en AP een request binnen dus dat loopt al snel op... met een IP adres heb ik dit niet, maar aan de andere kant zou ik liever de dns naam gebruiken omdat als ik dan de controller bv verplaats ik enkel de host record moet aanpassen en alles werkt terug. Ik probeer eigen alles met statische DHCP toe te kennen. Misschien dat ik voor test eens hem 24u laat draaien via hostname en zie hoeveel querry's dat extra oplevert, ik weet ook niet wat de impact naar performantie toe is.

Je kunt de TTL van lokale records die clients moeten hanteren aanpassen via local-ttl=seconden.
Dat zal de client dan dwingen om het record niet eerder weer bij de DNS-server op te vragen, zolang de TTL aan het aftellen is. Deze zou je bv op 300 kunnen zetten oid. Ik zou dit niet te hoog zetten. Geen 86400 bijvoorbeeld, want dat is een hel bij het aanpassen van ipadressen of verhuizen van systemen van vlan naar vlan wat je echt binnen je resolving nodig hebt
Unifi is inderdaad een druk systeem als je dat via DNS doet. Ik heb overigens ook slechte ervaringen met stack van trans-ip. Die pompte m'n statistieken ook flink omhoog. Waarschijnlijk gebruiken die ook een lage TTL. Ook dat is via dnsmasq te overrulen. (min-cache-ttl=)

[ Voor 9% gewijzigd door ed1703 op 16-10-2020 20:12 ]

[icecreamfarmer]

nero355 schreef op vrijdag 16 oktober 2020 @ 16:46:
[...]

Post dan eens een werkende config "op de nieuwe manier" want ik ben er wel een beetje klaar mee!


[...]


[...]

Ik heb zoiets werkende d.m.v. https://www.pimusicbox.com/ op een aparte Pi en dat werkt best wel goed afhankelijk van de stream die je erin klopt!

Het geheel is gebaseerd op Mopidy en een WebGUI waarmee je dus Mopidy bestuurt.
Er zijn ook apps en normale applicaties voor beschikbaar zoals Cantata die ik weer i.c.m. het originele mpd gebruikt op de laptop

Kortom : Ga er eens mee testen en kijk of het wat voor je kan betekenen!

Ik gebruik domoticz en een stereo paar Sonos one om een bedtijd muziek af te spelen.

Dit werkt:
http://0.0.0.0:5005/bedroom%20speaker/tunein/play/6702
Dit niet:
http://0.0.0.0:5005/bedroom%20speaker/stream.player.arrow.nl
http://0.0.0.0:5005/bedro...ay/stream.player.arrow.nl
http://0.0.0.0:5005/bedro...ay/stream.player.arrow.nl

Iemand nog ideeën om de reclame van tunein te omzeilen?

[Kopernikus.1979]

ed1703 schreef op vrijdag 16 oktober 2020 @ 20:07:
[...]

Je kunt de TTL van lokale records die clients moeten hanteren aanpassen via local-ttl=seconden.
Dat zal de client dan dwingen om het record niet eerder weer bij de DNS-server op te vragen, zolang de TTL aan het aftellen is. Deze zou je bv op 300 kunnen zetten oid. Ik zou dit niet te hoog zetten. Geen 86400 bijvoorbeeld, want dat is een hel bij het aanpassen van ipadressen of verhuizen van systemen van vlan naar vlan wat je echt binnen je resolving nodig hebt
Unifi is inderdaad een druk systeem als je dat via DNS doet. Ik heb overigens ook slechte ervaringen met stack van trans-ip. Die pompte m'n statistieken ook flink omhoog. Waarschijnlijk gebruiken die ook een lage TTL. Ook dat is via dnsmasq te overrulen. (min-cache-ttl=)

Super Ga ik meteen eens testen

[ed1703]

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 20:49:
[...]


Super Ga ik meteen eens testen

Dacht dat jij je lokale records van de USG haalt he.. Misschien is het dan beter om min-cache-ttl aan te passen.

-T, --local-ttl=<time>
When replying with information from /etc/hosts or configuration or the DHCP leases file dnsmasq by default sets the time-to-live field to zero, meaning that the requester should not itself cache the information. This is the correct thing to do in almost all situations. This option allows a time-to-live (in seconds) to be given for these replies. This will reduce the load on the server at the expense of clients using stale data under some circumstances.

--min-cache-ttl=<time>
Extend short TTL values to the time given when caching them. Note that artificially extending TTL values is in general a bad idea, do not do it unless you have a good reason, and understand what you are doing. Dnsmasq limits the value of this option to one hour, unless recompiled.

Hoe dan ook denk ik dat 1 van die settings zou moeten werken.

[ Voor 15% gewijzigd door ed1703 op 16-10-2020 20:56 ]

[Kopernikus.1979]

ed1703 schreef op vrijdag 16 oktober 2020 @ 20:55:
[...]


Dacht dat jij je lokale records van de USG haalt he.. Misschien is het dan beter om min-cache-ttl aan te passen.


[...]

Hoe dan ook denk ik dat 1 van die settings zou moeten werken.

Vroeger wel, maar heb nu alles op Pi-Hole gezet.
Dus in mijn geval local-ttl, heb deze nu op 300 gezet, we zullen eens zien wat dat geeft.
Ik snap dat deze niet te hoog mag zijn, maar in het geval je niets migreert, zou dat dan niet ideaal zijn? Of zullen er andere dingen problemen beginnen geven?

[ Voor 15% gewijzigd door Kopernikus.1979 op 16-10-2020 21:02 ]

[ed1703]

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 21:00:
[...]


Vroeger wel, maar heb nu alles op Pi-Hole gezet.
Dus in mijn geval local-ttl, heb deze nu op 300 gezet, we zullen eens zien wat dat geeft.
Ik snap dat deze niet te hoog mag zijn, maar in het geval je niets migreert, zou dat dan niet ideaal zijn? Of zullen er andere dingen problemen beginnen geven?

Nee, dan kun je probleemloos de TTL op 300 of misschien zelfs nog hoger zetten.
Boven een kwartier is het irritant, maar je kunt natuurlijk altijd besluiten je switch te rebooten of de cache te legen. Al weet ik daar op de versie van USW/UAP geen commando voor.

[ Voor 8% gewijzigd door ed1703 op 16-10-2020 21:09 ]

[Kopernikus.1979]

ed1703 schreef op vrijdag 16 oktober 2020 @ 21:05:
[...]

Nee, dan kun je probleemloos de TTL op 300 of misschien zelfs nog hoger zetten.
Boven een kwartier is het irritant, maar je kunt natuurlijk altijd besluiten je switch te rebooten of de cache te legen. Al weet ik daar op een tinylinux omgeving geen commando voor.

Merk nu al een immens verschil op 300, ga het voorlopig zo laten.
Nu heb ik het aangepast in 01-pihole.conf, maar ik maak best zeker nieuwe config file aan hiervoor?
Maar de vraag is gaat deze die dat standaard in 01-pihole.conf overrulen

[ed1703]

Kopernikus.1979 schreef op vrijdag 16 oktober 2020 @ 21:10:
[...]


Merk nu al een immens verschil op 300, ga het voorlopig zo laten.
Nu heb ik het aangepast in 01-pihole.conf, maar ik maak best zeker nieuwe config file aan hiervoor?
Maar de vraag is gaat deze die dat standaard in 01-pihole.conf overrulen

In 01-pihole.conf heb ik het ook hoor.. en ja tijdens een upgrade loop je kans dat je opeens een nieuwe versie hebt. Altijd even een backup maken he en kijken wat ze aangepast hebben. Moet je eigenlijk minimaal wekelijks doen. Naar een NAS oid.

Dit zijn de defaults.. in deze repo zal ook verschijnen als ze iets aanpassen: https://github.com/pi-hol...r/advanced/01-pihole.conf

[Webgnome]

Ik ben maar eens in de wereld van dhcp via pihole gedoken. Uiteindelijk heb ik het aan de praat gekregen. Het was eigenlijk vrij simpel zoals ook al aangegeven werd in dit topic. DHCP op de router uitzetten en op de pihole aanzetten. Poortjes open zetten in de firewall en gaan.

Echter nu zit ik met een uitdaging. Ik heb nog een andere raspberry pi waar ik initieel pihole op heb geinstalleerd en ik zou eigenlijk willen dat via dhcp beide pihole's worden gepushed als DNS. Nu heb ik gevonden dat men dit standaard niet ondersteund maar door de file 02-pihole-dhcp.conf aan te passen in /etc/dnsmasq.d kun je het voor elkaar krijgen door deze regel erin zetten

code:

dhcp-option=6,192.168.0.49,192.168.0.46

in dit geval zijn dit dus mijn beide pihole. Echter wanneer ik dat doe dan werkt het ineens allemaal niet meer. Als ik het weer terug zet naar

code:

dhcp-option=option:router,192.168.0.1

waarbij 192.168.0.1 mijn router is ( gateway dus) dan is er geen probleem. Ook als ik deze regel laat staan en de andere regel eronder toevoeg werkt het nog niet.

Iemand enig idee waar dat aan zou kunnen liggen? Beide piholes zijn hetzelfde ingesteld, gebruiken unbound.

[Freee!!]

Webgnome schreef op zaterdag 17 oktober 2020 @ 19:27:
Ik ben maar eens in de wereld van dhcp via pihole gedoken. Uiteindelijk heb ik het aan de praat gekregen. Het was eigenlijk vrij simpel zoals ook al aangegeven werd in dit topic. DHCP op de router uitzetten en op de pihole aanzetten. Poortjes open zetten in de firewall en gaan.

Echter nu zit ik met een uitdaging. Ik heb nog een andere raspberry pi waar ik initieel pihole op heb geinstalleerd en ik zou eigenlijk willen dat via dhcp beide pihole's worden gepushed als DNS. Nu heb ik gevonden dat men dit standaard niet ondersteund maar door de file 02-pihole-dhcp.conf aan te passen in /etc/dnsmasq.d kun je het voor elkaar krijgen door deze regel erin zetten

code:

dhcp-option=6,192.168.0.49,192.168.0.46

in dit geval zijn dit dus mijn beide pihole. Echter wanneer ik dat doe dan werkt het ineens allemaal niet meer. Als ik het weer terug zet naar

code:

dhcp-option=option:router,192.168.0.1

waarbij 192.168.0.1 mijn router is ( gateway dus) dan is er geen probleem. Ook als ik deze regel laat staan en de andere regel eronder toevoeg werkt het nog niet.

Iemand enig idee waar dat aan zou kunnen liggen? Beide piholes zijn hetzelfde ingesteld, gebruiken unbound.

Ik heb met hetzelfde bijltje gehakt en een losse DHCP-server geïnstalleerd op de krachtigste Pi. Ik heb min of meer deze handleiding gevolgd. Het belangrijkste verschil is, dat je "update-rc.d isc-dhcp-server start" waarschijnlijk moet vervangen door een overeenkomstige systemctl opdracht (systemctl start isc-dhcp-server). En de IP-adressen van de Pi-Holes moeten in apart bestandje bijgevoegd worden (/etc/resolvconf/resolv.conf.d/tail).

[Webgnome]

Freee!! schreef op zaterdag 17 oktober 2020 @ 19:59:
[...]

Ik heb met hetzelfde bijltje gehakt en een losse DHCP-server geïnstalleerd op de krachtigste Pi. Ik heb min of meer deze handleiding gevolgd. Het belangrijkste verschil is, dat je "update-rc.d isc-dhcp-server start" waarschijnlijk moet vervangen door een overeenkomstige systemctl opdracht (systemctl start isc-dhcp-server). En de IP-adressen van de Pi-Holes moeten in apart bestandje bijgevoegd worden (/etc/resolvconf/resolv.conf.d/tail).

Thanks ik zal er eens naar kijken. Denk dat ik nog maar eens een raspbery pi ga bestellen. Elke pi een eigen dienst. Lijkt mij verstandiger als alles op 1 pi.

[MJV]

Het duurde even voordat ik doorhad dat mijn unbound niet stuk was maar dat ze daarvoor default poort van 5353 naar 5335 hebben gewijzigd, blijkbaar vanwege een mogelijke clash met de poort voor Avahi. Op het eerste gezicht valt deze wisseling van 3 en 5 ook nog eens niet op. Gelukkig kwam ik er na één reinstall al achter en heb ik niet ook mijn tweede raspberry opnieuw in hoeven te stellen .

[Freee!!]

Webgnome schreef op zaterdag 17 oktober 2020 @ 22:52:
[...]
Thanks ik zal er eens naar kijken. Denk dat ik nog maar eens een raspbery pi ga bestellen. Elke pi een eigen dienst. Lijkt mij verstandiger als alles op 1 pi.

Ik heb twee Pi's, ieder met een eigen Pi-Hole en twee Unbounds en nog wat zaken, vrijwel alles als Docker containers. De enige functionaliteit, die ik niet in een container heb, is het management van de Pi zelf (OMV) en de DHCP-server.

[Webgnome]

@Freee!! Heb je de DHCP server op een van de twee pi's draaien of staat die op een compleet ander systeem?

[ Voor 5% gewijzigd door Webgnome op 18-10-2020 11:49 ]